[ksk-change] How to tell which trust anchors are present at a DNS resolver.

Wessels, Duane dwessels at verisign.com
Tue Mar 24 22:17:34 UTC 2015

> On Mar 24, 2015, at 4:55 PM, Michael StJohns <msj at 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.


More information about the ksk-rollover mailing list