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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
