Excellent info, thank you Mark. On Aug 26, 2016 6:53 PM, "Mark Andrews" <ma...@isc.org> 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" <ma...@isc.org> 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: > ma...@isc.org > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >