Re: [DNSOP] kskroll-sentinel and unclear results

[Geoff Huston <[e-mail]>]

> 
> 
> Thank you, I like most of the changes, but the primary text which addresses
> the above question is:
> "If the resolvers don't all have the same setup (such as if some validate
> but others do not, or if those that validate don't all have the same root
> KSKs trusted), the results of the sentinel test described in this document
> may be indeterminate.  For example, running the same test twice could get
> different results if the different resolvers are queried in a different
> order."
> 
> I believe that the ordering doesn't matter - it will always converge to the
> same answer.
> I've got a really long response to this, which shows all of the options in
> all the different orders, but my co-authors are in different time-zones,
> and want them to sanity check it for me.

Warren’s analysis indicates that when we apply the proposed tests to a user’s collection of resolvers (as distinct from a single resolver)  the proposed test methodology generates responses that may well be unclear at best, particularly when the collection of resolvers include validating and non-validating resolvers and resolvers that variously do and do not recognise this sentinel mechanism. So I’ve been thinking about a subtly different test methodology than that described in the draft that is intended to provide better clarification of the capabilities of the user’s DNS resolution environment.

Firstly a few assumptions that lie behind this proposed analysis methodology:

1) when the user passes a query to a resolver it will get a consistent answer (well consistent over the timeframe of queries). i.e. when the same question asked multiple times by the same user in succession to the same IP address, the DNS responses should give the same answer. (Job’s scenario where the same query passed to the same resolver IP address may generate different responses is a tough situation, and I have no idea just how prevalent this kind of variant behaviour is in any case).

2) all current DNSSEC-validating resolvers have KSK-2010 in their local trust anchor cache.

3) When a resolver returns SERVFAIL the user will re-query using the next resolver in the set. The user’s resolution process will conclude with a SERVFAIL if and only if all the resolvers in the user’s resolver collection have responded with SERVFAIL back to the user.

The modified test uses three queries:

a) a DNS name that is badly signed

b) a DNS name with the left-most label "root-key-sentinel-not-ta-<key-tag=of-ksk-2010>"

c) a DNS name with the left-most label "root-key-sentinel-is-ta-<key-tag=of-ksk-2017>"

(note that the keys referred to in queries b) and c) are different)

I'll describe the responses to these queries as either ‘A’, indicating that the A or AAAA query returned the desired RRset, or ’S’ indicating the the query returned SERVFAIL, and  I’ll describe the sequence of the three responses as the triplet (x x x) indicating responses to queries a, b and c in order.

Firstly, let’ look at the simple case of a single resolver:

If we get a response patter of the form (A * *) then the resolver is not validating, and will survive the key roll just fine.

If we get a response pattern of the form (S A *) then the resolver is validating, but the A response to query b) indicates that it does not recognise the sentinel queries, so we cannot determine its trusted key state.

If we get a response pattern of the form (S S S) then the resolver is validating, and the S response to query b) indicates that it recognises the sentinel queries, and the S response to query c) indicates that it has _NOT_ loaded KSK-2017 as a locally trusted key, and this resolver will not fare well when the KSK rolls.

If we get a response pattern of the form (S S A) then the resolver is validating, and the S response to query b) indicates that it recognises the sentinel queries, and the A response to query c) indicates that it has loaded KSK-2017 as a locally trusted key

Now lets look at the same three queries when used with a collection of resolvers and apply a similar exercise:

The set of possible responses are:

(A * *) - if any of the resolvers returns an A result to query a), then the user’s resolver set contains at least one non-validating resolver, and the KSK roll will not affect them (other than potentially lengthening the DNS resolution times I guess).

(S A *) if any of the resolvers returns an A result to query b) at least one of the user’s resolvers does not recognise the sentinel mechanism, and the behaviour of the collection of resolvers during the KSK roll cannot be reliably determined.

(S S A) implies that all of the user’s resolvers are validating resolvers, all of the user’s resolvers recognise the sentinel mechanism and at least one of the user’s resolvers has loaded KSK-2017 as a trusted key - the user is ok for the KSK roll.

(S S S) implies that all of the user’s resolvers are validating resolvers, all of the user’s resolvers recognise the sentinel mechanism and none of the user’s resolvers has loaded KSK-2017 as a trusted key - the user is NOT ok for the KSK roll.

This analysis approach in no way modifies the actual resolver mechanism described in the draft - the resolver actions are unaltered. The change described here is a change in a test mechanisms that is intended to disambiguate the case of a collection of resolvers where one or more resolvers does not not support this sentinel mechanism from the case where one or more resolvers in the collection has not loaded KSK-2017

Finally, as a personal opinion, not necessarily shared by anyone else, I also note its now June 2018 and the KSK roll appears to be scheduled for early October 2018. As fun as this exercise has been in trying to get this draft through the DNSOP Working Group’s processes, I fear that we are now too late to get this sentinel mechanism implemented and deployed in any meaningful manner to assist in providing meaningful data to inform us of the state of uptake of KSK-2017 before the scheduled KSK roll. That makes me a bit sad.