[ksk-rollover] 答复: Observation on Large response issue during Yeti KSK rollover

[Geoff Huston]

> On 22 Aug 2017, at 12:23 am, Olaf Kolkman <kolkman at isoc.org> wrote:
> 
> On 3 Aug 2017, at 7:33, Davey Song wrote:
> 
> Geoff reported that 17% of resolvers cannot ask a query in TCP. So probably in extreme case there are 0.34% of IPv6 resolvers around the world will fail to validate the answers. 0.34% of millions (if IPv6 dominant), It is not a trivial number.
> 
> Is the set of resolvers that cannot ask a TCP query (inversely) correlated with resolvers that do DNSSEC? I would assume that a DNSSEC capable resolver will happily resolve over TCP. I can't imagine that there is a 17% prevalence of TCP blocking firewalls. But who knows…
> 

(Heh - no matter how broken and stupid the behaviour you are looking for, if you look hard enough on the Internet you _will_ find it.!)

I got that number of deliberately truncating a DNS response and then looking at the resolvers that performed a followup response using TCP. The primary observation was that 17% of the IP addresses that queries using UDP and (presumably) received the UDP response failed to query using TCP. This appears to relate to resolvers used by some 6% of endpoints. 2/3 of these endpoints appear to then re-query using another resolver, and this other resolver performed a TCP query in response to the truncated UDP response. Some 1/3 of these endpoints, (or 2% of all observed endpoints) appeared to not resolve the name as we saw NO TCP queries for the given DNS name.

The issue with truncation is that you should get a truncated response back to the resolver to trigger the TCP re-query. Now for that to happen the resolver needs to query using a small (or none) EDNS(0) UDP buffer size, or the server needs to arbitrarily truncate the UDP response even though it may be smaller than the offered EDNS(0) UDP Bbuffer size.

If we look at root server letters it appears that B and G truncate a large UDP response in IPv4 at 1,252 bytes of payload (1,280 bytes overall IP packet size). In IPv6 it appears that A, B, G and J truncate IPv6 UDP responses at 1232 octets of DNS payload (corresponding to an Ipv6 packet of 1,280 bytes in size).

So your question was : Is this correlated with resolvers that do DNSSEC? 

This is a hard question to answer as it is not clear how to reliably tell if a resolver “does” DNSSEC. Merely looking for resolvers that set the DO bit in the query is highly misleading. Some 70% of all observed queries have the DO bit set, but more than half of these resolvers never followup with validation-related queries for DNSKEY and DS RRs. So maybe we should look for DNSKEY and DS queries as well? But if I ask a query through a recursive resolvers and set the CD bit then the resolver will not query for DS and DNSKEY records. Equally, if a validating recursive resolver uses a non-validating resolver as its forwarder then the “front end” of the resolver will issue the DNSSEC and DS queries to the server, so it will give the appearance that it is validating when in fact it is not. It’s not an easy problem to unravel, and in the end I used a slightly different approach and looked for a count of the proportion of endpoints that exclusively use DNSSEC validating resolvers rather than attempt to conduct a count of the number of DNSSEC validating resolvers.


regards,

   Geoff