On 18 Feb 2018, at 20:21, Geoff Huston wrote:
Hi John,
thanks for the review of this draft
On 17 Feb 2018, at 4:35 am, John Dickinson <j...@sinodun.com> wrote:
Hi,
I like what this draft is trying to do.
I am a bit concerned about adding a invalid RR in to a otherwise
correctly signed zone. It suspect that there may be a variation in
how validating resolvers treat authoritative servers that appear to
have sent bogus data. Some might retry, retry other auth servers,
stop using that server altogether etc etc…
I have been doing this for many years in an ad-based measurement
campaign. When a validating resolver is incapable of validating a
response it sends back a SERVFAIL response code of course. Some years
back “incapable of validating a response” implied an exhaustive
search through all NS’s of all parent zones to see if any path
exists that can validate the RRSIG - these days many resolvers simply
accept the first invalid response and pass back SERVFAIL.
OK great - I just wondered if there was all sorts of strange differences
between different implementations.
Obviously the SERVFAIL response will prompt a stub resolver to pass
the query tyo any other recursive resolvers that it is configured to
query. This is of course the same behaviour as one would expect from a
validating recursive resolver that has failed to track a KSK roll. I
have not observed any signal that a client resolver accepts a SERVFAIL
response from a recursive resolver as anything other than a failure
for the query itself.
I suggest that the example A/AAAA RRs on page 4 be written fully
qualified so there can be no doubt that this draft does not imply new
special names at the root (which is what I first thought).
“example.com” appears four times on page 4 - are you suggesting
that this be altered to read “example.com.”?
Or are you suggesting that the 5 instances of the label
kskroll-sentinel-(is|not)-ta-2222 which refer to a “resoirce” be
edited to read "kskroll-sentinel-(is|not)-ta-2222.example.com"?
Or both?
The second one but only for the 3 examples
invalid IN AAAA 2001:DB8::1
kskroll-sentinel-is-ta-2222 IN AAAA 2001:DB8::1
kskroll-sentinel-not-ta-2222 IN AAAA 2001:DB8::1
regards
John
In the discussion of Charlie’s resolvers I think “from
this he knows (see the logic below) that he is using legacy, non-
validating resolvers.”
should have the “non-“ removed.
yes - that’s correct. That was a typo.
regards
John
On 12 Feb 2018, at 20:28, Warren Kumari wrote:
<author hat only>
Hi all,
Sorry it has taken so long to get a new version of this document
posted - you deserve better.
Anyway, we've finally posted an updated version -
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
This version includes a (hopefully easily understood) description of
how this would actually be used, and not just "here's a protocol, k,
thnx, bye!". I've tried to layout what each party does, and how it
all
fits together - please let me know if it isn't clear. This section
is
towards the top of the document - we will likely make it an Appendix
before publication.
I've also updated it to use the kskroll-sentinel-is-ta-<id> format.
It
is easy to change again in the future, but this seemed to be what
the
working group liked. I also updated my demo implementation
(http://www.ksk-test.net) to use this naming scheme.
This version also clarifies that the test is "Is the Key ID a DNSSEC
root KSK?" Originally my view was that it should be "Is there *any*
key in the trust store with this keyID?", but after running some
numbers I decided that there is a significant chance of false
positives.
As I mentioned, it took an embarrassingly long time to post the
update
- please let us know if we missed your comments.
W
--
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
John Dickinson
http://sinodun.com
Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
John Dickinson
http://sinodun.com
Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
