Re: [DNSOP] Updated KSK Sentinel document

["John Dickinson" <[e-mail]>]

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 <[e-mail]> 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
>>> [e-mail]
>>> 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
>> [e-mail]
>> 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.