Resolving .gov w/dnssec

[Timothe Litt]

I get a "connection timed out; no servers could be reached" after the
"Truncated, retrying in TCP mode"  even with +bufsiz=512
 
I am not blocking tcp/53.  In fact, telnet dns1.uspto.gov 53 will happily
establish a connection :-)  I'm on a fiber (Verizon FiOS business) circuit -
given that others are seeing this over a wide geography, seems like the
investigation needs to start closer to the .gov servers...
 
If you're into numerology, 1736 is 1500 + 236 -- with a 20 byte header on
the 236, you get 256 for the fragement - which is mildly curious.
 
Folks on DSL should remember that their magic number is less than 1500 bytes
(1492 is common, as is 1453).  
 
Sigh.

---------------------------------------------------------
This communication may not represent my employer's views,
if any, on the matters discussed. 

 


  _____  

From: Casey Deccio [mailto:casey at deccio.net] 
Sent: Thursday, April 22, 2010 18:22
To: Michael Sinatra
Cc: bind-users at isc.org
Subject: Re: Resolving .gov w/dnssec


On Thu, Apr 22, 2010 at 11:36 AM, Michael Sinatra
<michael at rancid.berkeley.edu> wrote:


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.




Actually, what seems interesting to me is that the cutoff seems to be at a
payload size of 1736, which happens to be the exact size of the complete
response.  Is this just coincidence?

$ dig +bufsize=1735 +dnssec @dns1.uspto.gov uspto.gov dnskey

;; Truncated, retrying in TCP mode.

$ dig +bufsize=1736 +dnssec @dns1.uspto.gov uspto.gov dnskey
 
; <<>> DiG 9.6.1-P3 <<>> +bufsize=1736 +dnssec @dns1.uspto.gov uspto.gov
dnskey
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Casey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100422/b47fc9f1/attachment.html>