[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.
DW
More information about the ksk-rollover
mailing list