Agreed. Their nameserver are broken or there is a stupid firewall that is blocking any response with "TC=1" in it. I've CC'd [email protected] with this response which they should forward to their network operations people.
[email protected], your nameservers are BROKEN. They need to be fixed ASAP. Forward this message to your IT/Network Operations people. Also please FIX the SOA record to have a working address for reporting problems with the nameservers. "[email protected]" is not as acceptable address. It just makes it harder for people to report problems to you as they need to hunt contact addresses. Mark In message <[email protected]>, Gilles Massen writes: > Hi, > > Trying to refine the issue: you get the timeout when the buffer size < > response size. Everything between 2468 and 4096 is working fine. As for > the other records: they produce smaller responses - presumably below MTU. > > So I would guess at a problem with the truncating logic (or a magic box > on the wire): whenever an answer is supposed to contain the TC bit, it > breaks. With bufsize=512 the problem disappears as a different answer > logic kicks in (only the answer section) resulting in small replies. > > What is supporting the theory is that queries like "dig @ns1.gpo.gov > gpo.gov dnskey +dnssec +norecurse +bufsize=1200" do work (falling back > to TCP), but with a warning: ";; Warning: Message parser reports > malformed message packet.". I didn't look any closer at the packet. Why > this does get an (malformed) answer but the MX queries not could be the > MTU barrier. > > What the cause of this is I wouldn't dare to guess... > > Best, > Gilles > > > On 31/10/13, 22:00 , Timothy Morizot wrote: > > Hello all, > > > > I've encountered an issue resolving MX records from gpo.gov > > <http://gpo.gov>. It's unlike anything I've encountered before and I'm > > stumped. It took me a while to figure out why resolution of just that > > one record type for the zone was failing. But I was finally able to > > recreate it. (The queries below are from my home network since I have > > more access and it's easier to pull examples here than at work. But I > > reproduced the same thing at work.) Because we had encountered issues > > getting fragmented UDP responses from some authoritative servers for > > DNSSEC signed zones with an edns0 buffer of 4096 (presumably because > > they were blocking outbound udp fragments on their firewalls) we've > > reduced the advertised buffer size on our caches to 1280. When I query > > the authoritative nameservers for gpo.gov <http://gpo.gov> directly with > > a bufsize of 4096, I get a response. When I try an intermediate buffer > > size, the query times out. When I reduce it all the way to 512 bytes, I > > get a response again. > > > > When I run the same queries (well, obviously without +norecurse) through > > an intermediate cache (my own personal one with a 4096 buffer size, the > > OVDR servers, etc.) I get a response for all specified buffer sizes. I > > don't have a similar problem querying any other authoritative nameserver > > for a signed zone that I can find. I'm stumped. And it's just MX record > > queries. SOA, DNSKEY, A, and NS responses all work just fine with > > different buffer sizes. > > > > Anyone have any ideas? > > > > Thanks, > > > > Scott > > > > ========================================================================== > > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
