On Friday, February 9, 2018, Geoff Huston <g...@apnic.net> wrote:
>
>
> > On 8 Feb 2018, at 5:02 pm, Paul Wouters <p...@nohats.ca> wrote:
> >
> > On Wed, 7 Feb 2018, Robert Story wrote:
> >
> >> On Wed 2018-02-07 10:43:16-0500 Paul wrote:
> >>> How about using this query to also encode an
> >>> uptime-processstartedtime value? Maybe with accurancy reduced to
> >>> minutes. I think that would return valuable data.
> >>
> >> -1 for feature creep and the technical reasons Joe mentioned.
> >
> > We have a giant hole in our understanding of why there are updated
> > nameservers running the latest software with the older keys. We
> > need to gain understanding and we know we need more data.
> >
> > Getting more data is the core mission, not feature creep. If there is
> > a technical better way to do this, it's worth considering.
> >
>
> The sentinel mechanism is proposed to be capable of posing a question to a
> user’s
> “DNS Resolution cloud” - it is not intended capable of posing a question to
> an individual DNS resolver.
>
> <no hats>
The sentinel mechanism also *only* switches certain valid answers (received
from authorative servers) into a *SERVFAIL*:
"SERVFAIL 2 The name server encountered an internal
failure while processing this request,
for example an operating system error
or a forwarding timeout."
KSK Sentinel seems like it stretches "internal failure" a fair bit, but no
where near breaking point. Having the resursive server return any sort of
other response (especially for a zone it isn't also authorative for) is
making up answers from whole cloth, and that feels like a huge change.
While I think it would be great to be able to send questions to resolvers
and get all sorts of interesting stats (uptime, qps, list of keys, list of
zones, phase of moon), I don't think that this is the protocol to do it.
This is really now a knoch on your idea - I'd encourage you to write a
draft with a "status query" type solution, but that's a (IMO) separate
thing.
W
P.S: This written on a plane. Apoloigies if it is OBE, etc.
</>
What I am trying to say is that here is a big difference between a question
> of:
>
> "will this user be impacted at the point of the roLl of the KSK”
>
> and
>
> “what are the trust keys for this resolver?”, or
> “What is the process uptime of the DNS process on this resolver?”
>
> My intuition is that the mechanisms to implement a measurement
> framework for these questions would necessarily be very different.
>
> Geoff
>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
