Resolving .gov w/dnssec

[Michael Sinatra]

On 04/22/10 10:23, Paul Wouters wrote:
> On Thu, 22 Apr 2010, Chris Thompson wrote:
>
>>> I have the same problems with our validating unbound instance.
>>
>> I suspect that this has to do with
>>
>> dig +dnssec +norec dnskey uspto.gov @dns1.uspto.gov.
>> dig +dnssec +norec dnskey uspto.gov @sns2.uspto.gov.
>>
>> failing with timeouts, while dig +dnssec +norec +vc dnskey uspto.gov
>> @dns1.uspto.gov.
>> dig +dnssec +norec +vc dnskey uspto.gov @dns2.uspto.gov.
>>
>> work fine ... with a 1736-byte answer. Probably the fragmented
>> UDP response is getting lost somewhere near the authoritative
>> servers themselves.
>
> But wouldn't it fall back to TCP then? Also with dig +cd I got an
> instant answer, and the (old) cache dump contains the dnskey.

But it doesn't contain the RRSIGs for the DNSKEY.  'dig +norec +cdflag 
dnskey uspto.gov @dns1.uspto.gov' does not contain RRSIGs so it is only 
1131 bytes.  A non-EDNS0 query will receive the TC bit and will retry in 
TCP.  'dig +dnssec +norec dnskey uspto.gov @sns2.uspto.gov' has a 
response that includes the RRSIGs and is 1736 bytes, which on most 
ethernets will cause UDP fragmentation.  I get a timeout when using dig 
with +dnssec and without +vc.  However, 'dig +bufsize=1024 +dnssec 
+norec dnskey uspto.gov @dns1.uspto.gov' which sets an EDNS0 buffer size 
of 1024, does get a response, after retrying in TCP mode.

In other words, uspto.gov's DNS servers and network are able to send 
responses longer than 512 bytes, but if the response is longer than 1500 
bytes, something in the network between those DNS servers and the rest 
of us is blocking the UDP fragments.

Note that later versions of BIND can generally deal with this, as they 
will lower their EDNS0 buffer sizes until they get a response.

michael