Archives.org is served by the following servers. archives.gov. 300 IN NS sauthns1.qwest.net. archives.gov. 300 IN NS sauthns2.qwest.net.
Those servers return BADVERS to EDNS(0) queries with a EDNS option present. BADVERS is NEVER a valid rcode to a EDNS(0) request because there is no EDNS version smaller than version 0. BADVERS was defined in RFC 2671. Its purpose is to negotiate the highest common EDNS version the client and server support which is determined by the version field in the EDNS request. Now RFC 2671 didn’t explicitly specify how to handle unknown EDNS options but STD 13 has a catch all rcode (FORMERR) for how to answer unknown messages. RFC 2671 has subsequently been replaced by RFC 6891 which explicitly says to ignore unknown EDNS options. Named treats BADVERS to a EDNS(0) query as a indication that the server DOES NOT UNDERSTAND EDNS as it is a response that should never appear and retries the query without a EDNS option present. This is fine if the data being served is from a unsigned zone. This, however, DOES NOT WORK when with DNSSEC as DNSSEC REQUIRES EDNS to send the DO=1 bit to the server to get a DNSSEC response. QWEST were informed years ago that their servers are broken. Making up stuff is not the way to get inter operability. The best thing archive.gov can do now is find a DNS provider that uses DNS servers that follow the DNS protocol. Mark On 12 Apr 2018, at 4:28 am, Mark Boolootian <boo...@ucsc.edu> wrote: > > > > Hi folks, > > I upgraded out of 9.10 and into 9.12 > last week. Subsequent to that, I received > complaints about hosts in archives.gov > failing to resolve. > > We run validating recursive servers, and > archives.gov is signed. > > I've poked at this but concluded I lack > enough DNS foo to understand the specifics > of the trouble. It seems clear that archives.gov > isn't fully baked when it comes to EDNS: > > https://ednscomp.isc.org/ednscomp/77e4f9ead1 > > and I suspect that is what causes the resolution > failures. > > I've read the thread on "Enforce EDNS". I've > tried reaching out to the standard RFC2142 > aliases at archives.gov, but it looks like most of > them bounce. I'm not feeling particularly optimistic > about being able to effect change on that end, > even if I got an answer. > > I'm wondering if anyone from this august group > can clue me in to how I might config around this > issue for the archives.gov servers (assuming that > is possible). > > Any help greatly appreciated. > > best regards, > mark > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users