Re: [DNSOP] Updated KSK Sentinel document

Hi John,

thanks for the review of this draft

> On 17 Feb 2018, at 4:35 am, John Dickinson <jad@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. 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?

> 
> 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