My personal favorite broken domain is New York State Thruway folks. https://ednscomp.isc.org/ednscomp/cb652bc112
If you ask for AAAA of www.thruway.ny.gov it is a CNAME to www.wip.thruway.ny.gov and that breaks a number of DNS servers and load balancers, eg: $ host -t aaaa www.wip.thruway.ny.gov ;; reply from unexpected source: 2001:558:100e:4:69:252:66:215#53, expected 2001:558:feed::1#53 ;; reply from unexpected source: 2001:558:100e:4:69:252:66:215#53, expected 2001:558:feed::1#53 Waiting for the timeouts to occur or trying to get a robust response via TCP is problematic at best. DNS works really well despite much of the damage from firewall vendors and ill informed consultants. - Jared > On Aug 26, 2016, at 7:54 PM, Josh Reynolds <[email protected]> wrote: > > Excellent info, thank you Mark. > > On Aug 26, 2016 6:53 PM, "Mark Andrews" <[email protected]> wrote: > >> >> In message <CAC6=tfYnPX2pGCNNjaeV+yVENypMFqf02JmD58fgJExQfZku_Q@ >> mail.gmail.com>, Josh Reynolds writes: >>> >>> Just looking at the RFC... >>> ----- >>> VERSION Indicates the implementation level of the setter. Full >> conformance >>> with this specification is indicated by version '0'. Requestors are >>> encouraged to set this to the lowest implemented level capable of >>> expressing a transaction, to minimise the responder and network load of >>> discovering the greatest common implementation level between requestor >> and >>> responder. A requestor's version numbering strategy MAY ideally be a >>> run-time configuration option. If a responder does not implement the >>> VERSION level of the request, then it MUST respond with RCODE=BADVERS. >> All >>> responses MUST be limited in format to the VERSION level of the request, >>> but the VERSION of each response SHOULD be the highest implementation >> level >>> of the responder. In this way, a requestor will learn the implementation >>> level of a responder as a side effect of every response, including error >>> responses and including RCODE=BADVERS. >>> ----- >>> What am I missing, based on your output? >> >> The servers do not RESPOND to EDNS version != 0 queries. The following >> sends a EDNS version 1 query and tells dig not to complete the EDNS version >> negotiation so you can see the BADVERS response. >> >> % dig lostoncampus.com.au. @205.251.195.156 +edns=1 +noednsneg soa >> >> ; <<>> DiG 9.11.0rc1 <<>> lostoncampus.com.au. @205.251.195.156 +edns=1 >> +noednsneg soa >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> % >> >> A EDNS version 0 query to show reachability and that EDNS is supported. >> >> % dig lostoncampus.com.au. @205.251.195.156 +edns=0 +noednsneg soa >> >> ; <<>> DiG 9.11.0rc1 <<>> lostoncampus.com.au. @205.251.195.156 +edns=0 >> +noednsneg soa >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63224 >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1 >> ;; WARNING: recursion requested but not available >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;lostoncampus.com.au. IN SOA >> >> ;; ANSWER SECTION: >> lostoncampus.com.au. 900 IN SOA ns-1222.awsdns-24.org. >> awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 >> >> ;; AUTHORITY SECTION: >> lostoncampus.com.au. 172800 IN NS ns-1222.awsdns-24.org. >> lostoncampus.com.au. 172800 IN NS ns-1812.awsdns-34.co.uk. >> lostoncampus.com.au. 172800 IN NS ns-78.awsdns-09.com. >> lostoncampus.com.au. 172800 IN NS ns-924.awsdns-51.net. >> >> ;; Query time: 126 msec >> ;; SERVER: 205.251.195.156#53(205.251.195.156) >> ;; WHEN: Sat Aug 27 09:40:29 EST 2016 >> ;; MSG SIZE rcvd: 248 >> >> % >> >> What you should see is something like the following. Note the >> version field is zero (0) and the rcode (status) field is BADVERS. >> This response does show a protocol error: AD should not be set in >> this response as there is no authenticated data. >> >> % dig . @a.root-servers.net +edns=1 +noednsneg soa >> >> ; <<>> DiG 9.11.0rc1 <<>> . @a.root-servers.net +edns=1 +noednsneg soa >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 22570 >> ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> ;; WARNING: recursion requested but not available >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 1232 >> ;; Query time: 438 msec >> ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) >> ;; WHEN: Sat Aug 27 09:34:32 EST 2016 >> ;; MSG SIZE rcvd: 23 >> >> % >> >> Amazon are not alone here (about 20% of servers fail to respond to >> EDNS version 1 queries) but they are big player so they should be >> doing things correctly. See >> https://ednscomp.isc.org/compliance/alexa-report.html for others >> serving the Alexa top 1000 that get things wrong there are a lot >> of you out there. There are also reports for the bottom 1000, .GOV, >> .AU and the root zone at https://ednscomp.isc.org along with a >> online compliance checker so others can test their servers. You >> just need to name a zone and it will work out the rest or you can >> target individual servers even those not listed in the NS RRset. >> >> There is also a whole series of graphs showing failure trends for >> different EDNS compliance tests at >> https://ednscomp.isc.org/compliance/summary.html >> >> Mark >> >>> On Aug 23, 2016 6:43 PM, "Mark Andrews" <[email protected]> wrote: >>> >>>> >>>> I'm curious. What are you trying to achieve by blocking EDNS version >>>> negotiation? Is it really too hard to return BADVERS to a EDNS >>>> query with version != 0 along with the version of EDNS you support >>>> in the version field? Are you deliberately trying to prevent the >>>> IETF from deciding to bump the EDNS version in the future? Do you >>>> have firewalls that have this behaviour hard coded? Do you even >>>> test for RFC compliance? >>>> >>>> Mark >>>> >>>> lostoncampus.com.au. @205.251.195.156 (ns-924.awsdns-51.net.): dns=ok >>>> edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok >>>> ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok >>>> lostoncampus.com.au. @205.251.192.78 (ns-78.awsdns-09.com.): dns=ok >>>> edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok >>>> ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok >>>> lostoncampus.com.au. @205.251.196.198 (ns-1222.awsdns-24.org.): dns=ok >>>> edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok >>>> ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok >>>> lostoncampus.com.au. @205.251.199.20 (ns-1812.awsdns-34.co.uk.): >> dns=ok >>>> edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok >>>> ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: >> [email protected] >>>> >>> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: [email protected] >>
