On 4/22/10 8:55 AM, Timothe Litt wrote:
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?
I have had good luck reporting this issues to the contact in the SOA:
;; ANSWER SECTION:
uspto.gov. 7200 IN SOA dns1.uspto.gov. nmb.uspto.gov.
2010042002 10800
and I also cc Donna Samblanet who is the whois contact for GOV. (Try
'whois -h whois.iana.org =GOV' at your favorite unix prompt for her
contact info.)
FWIW, I tried +vc - from here, it doesn't help. Also, one sometimes gets
SERVFAIL - and once in a while, it actually resolves!
That may explain why it's broken for you and not for me. My BIND
servers (a mix of 9.7.0-P1 and 9.6.1-P3) all resolve uspto.gov
correctly, with the AD bit set. That's because they lower the EDNS0
buffer if they don't get a response right away, thereby triggering a
fallback to tcp. Are you blocking (or is your network blocking) tcp/53
somewhere?
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.
You're correct that this isn't a DNSSEC problem. It's arguably not even
a DNS problem, since UDP fragments are used by other protocols.
michael
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
