Resolving .gov w/dnssec

[Timothe Litt]

So, others are also seeing this, and it's not unique to bind or my corner of
the internet.  Thanks.

It seems to have been going on for weeks, so it isn't going to fix itself.

Who do I report this to so that it gets resolved?  

FWIW, I tried +vc - from here, it doesn't help.  Also, one sometimes gets
SERVFAIL - and once in a while, it actually resolves!

As for the "make work project" and "less stability" comment -- it seems
likely to me that if DNS packets are being mishandled, others are too --
just not as visibly.  So DNSSEC may well be an over-due network diagnostic;
fixing these sorts of problems could equally well reduce retries, delays and
other mishandled fragments for other protocols. I'm not ready to blame the
indicator for the underlying problem.  At least until we get to a
DNSSEC-unique root cause.

---------------------------------------------------------
This communication may not represent my employer's views,
if any, on the matters discussed.
-----Original Message-----
From: Chris Thompson [mailto:cet1 at hermes.cam.ac.uk] On Behalf Of Chris
Thompson
Sent: Thursday, April 22, 2010 10:52
To: Paul Wouters
Cc: Timothe Litt; Bind Users Mailing List
Subject: Re: Resolving .gov w/dnssec

On Apr 22 2010, Paul Wouters wrote:

>On Thu, 22 Apr 2010, Timothe Litt wrote:
>
>> I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV 
>> configured as valdidating resolvers.
>>
>> Using dig, I get a connection timeout error after a long (~10 sec) delay.
>> +cdflag provides an immediate response.
>
>> Is anyone else seeing this?  Ideas on how to troubleshoot?
>
>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.

--
Chris Thompson
Email: cet1 at cam.ac.uk