[ksk-change] How to tell which trust anchors are present at a DNS resolver.
One of the discussions we've been having about 5011 roll overs is that there's no way to tell whether or not they are "taking" because there's no way to check the resolvers externally. I was looking at various possibilities including locally significant RRs that could be queried to , but nothing clicked. After a beer with Scott Rose - we came up with the following convention: Querying a server with QNAME="." and QTYPE="DS" and with no recursion, gets you a set of DS records that represent the trust anchors for that server for the root. This would have to be implemented, but given that I think it may take 2 years to get the rollover done, that may not be a problem. Comments on this approach? (Note comments of "this won't work because its too late" are understood and ignored). What we;re looking for are comments on whether the convention has bad side effects or would be difficult to implement correctly. Mike
On Mar 24, 2015, at 4:03 PM, Michael StJohns <msj@nthpermutation.com> wrote:
One of the discussions we've been having about 5011 roll overs is that there's no way to tell whether or not they are "taking" because there's no way to check the resolvers externally.
I was looking at various possibilities including locally significant RRs that could be queried to , but nothing clicked.
After a beer with Scott Rose - we came up with the following convention:
Querying a server with QNAME="." and QTYPE="DS" and with no recursion, gets you a set of DS records that represent the trust anchors for that server for the root.
This would have to be implemented, but given that I think it may take 2 years to get the rollover done, that may not be a problem.
Comments on this approach? (Note comments of "this won't work because its too late" are understood and ignored). What we;re looking for are comments on whether the convention has bad side effects or would be difficult to implement correctly.
I think its reasonable enough to discuss. Negative side effects that I can think of: - Special case in recursive resolver code for this name/type - I'd expect to see "IN/./DS" queries become used in DDoS attacks - Some (incorrect) implementations would almost certainly forward these to the roots. - Doesn't work for stubs. I'm not sure it solves the problem of being able to check resolvers externally. You would rely on them to have an open resolver path or use some other tricks. Perhaps worth considering alternative proposals such as some kind of CHAOS TXT query? Or an EDNS extension whereby a client can transmit its trust anchor/DS keytag(s) along with a DNSKEY query? This could work for all zones, not just root, but I suppose it assumes the validator knows the DS before it makes the DNSKEY query (top-down vs bottom-up). DW
On 3/24/2015 5:41 PM, Wessels, Duane wrote:
On Mar 24, 2015, at 4:03 PM, Michael StJohns <msj@nthpermutation.com> wrote:
One of the discussions we've been having about 5011 roll overs is that there's no way to tell whether or not they are "taking" because there's no way to check the resolvers externally.
I was looking at various possibilities including locally significant RRs that could be queried to , but nothing clicked.
After a beer with Scott Rose - we came up with the following convention:
Querying a server with QNAME="." and QTYPE="DS" and with no recursion, gets you a set of DS records that represent the trust anchors for that server for the root.
This would have to be implemented, but given that I think it may take 2 years to get the rollover done, that may not be a problem.
Comments on this approach? (Note comments of "this won't work because its too late" are understood and ignored). What we;re looking for are comments on whether the convention has bad side effects or would be difficult to implement correctly.
I think its reasonable enough to discuss. Negative side effects that I can think of:
- Special case in recursive resolver code for this name/type Yes - unclear how large scale of a problem this might be.
- I'd expect to see "IN/./DS" queries become used in DDoS attacks Probably not. Basically, the root trust anchor set is pseudo-static. It changes, but over long long time. This is no worse than retrieving any other static data record given smart programming.
- Some (incorrect) implementations would almost certainly forward these to the roots.
If the "recurse" flag isn't set and the resolver is forwarding queries then you have a different problem.
- Doesn't work for stubs.
You mean because they don't actually answer external queries. Probably not a big issue.
I'm not sure it solves the problem of being able to check resolvers externally. You would rely on them to have an open resolver path or use some other tricks.
What I think we're looking for is to survey a broad set of known recursive validating resolvers to see if they're paying attention to 5011 signalling. Unclear we need to worry about more than a large subset of the existing systems.
Perhaps worth considering alternative proposals such as some kind of CHAOS TXT query?
Yuck.
Or an EDNS extension whereby a client can transmit its trust anchor/DS keytag(s) along with a DNSKEY query? This could work for all zones, not just root, but I suppose it assumes the validator knows the DS before it makes the DNSKEY query (top-down vs bottom-up).
Thought about this for a few minutes and decided it was probably a non-starter due to the possible size of the responses. There's also this problem that the resolver may be gleaning data (e.g. the non-cached DNSKEY) from upstream when what we really want is the current state of the server-local trust anchor set. Mike
DW
On Mar 24, 2015, at 4:55 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 3/24/2015 5:41 PM, Wessels, Duane wrote:
- Special case in recursive resolver code for this name/type
Yes - unclear how large scale of a problem this might be.
Yes, I would like to hear from implementors.
- I'd expect to see "IN/./DS" queries become used in DDoS attacks
Probably not. Basically, the root trust anchor set is pseudo-static. It changes, but over long long time. This is no worse than retrieving any other static data record given smart programming.
I don't think it matters whether or not its static. What matters is if attackers would be able to rely on it and find it useful. I guess the amplification factor is not significant, so maybe this point is not worth worrying about.
- Some (incorrect) implementations would almost certainly forward these to the roots.
If the "recurse" flag isn't set and the resolver is forwarding queries then you have a different problem.
I'd say we have that problem today.
- Doesn't work for stubs.
You mean because they don't actually answer external queries. Probably not a big issue.
I'm not so sure. If we expect validation to be pushed out to applications then this becomes important.
Or an EDNS extension whereby a client can transmit its trust anchor/DS keytag(s) along with a DNSKEY query? This could work for all zones, not just root, but I suppose it assumes the validator knows the DS before it makes the DNSKEY query (top-down vs bottom-up).
Thought about this for a few minutes and decided it was probably a non-starter due to the possible size of the responses. There's also this problem that the resolver may be gleaning data (e.g. the non-cached DNSKEY) from upstream when what we really want is the current state of the server-local trust anchor set.
What I proposed shouldn't affect responses. It would only be present in queries, and just a few extra bytes I think (EDNS option code, length, keytag). This would only work for measuring stubs if we made the recursives forward the option for cache misses. DW
On 24.3.2015 22:55, Michael StJohns wrote:
Perhaps worth considering alternative proposals such as some kind of CHAOS TXT query? Yuck.
I really dislike messing with IN class semantics and CH TXT either. Why not use query . CH DS ? Looking at BIND 9.11 sources, it seems that DS and DNSKEY are class-independent. -- Petr Spacek @ Red Hat
participants (3)
-
Michael StJohns -
Petr Spacek -
Wessels, Duane