Noticied today. All Verisign's GTLD servers broke EDNS0 (RFC2671). Here's how it looks like: query: $ dnsget -t mx -vv microsoft.net. -n 192.5.6.30 ;; trying microsoft.net. ;; sending 42 bytes query to 192.5.6.30 port 53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64471, size: 42 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUERY SECTION (1): ;microsoft.net. IN MX ;; ADDITIONAL section (1): ;EDNS0 OPT record (UDPsize: 4096): 0 bytes Note the EDNS0 stuff (numar=1). And here's the reply to this query: ;; received 12 bytes response from 192.5.6.30 port 53 ;; unexpected number of entries in QUERY section: 0 ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64471, size: 12 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION (0): ; invalid query section They're returning FORMERR (which is wrong), *and* don't return the original query (numqd=0). Without EDNS0 extensions, it works like expected. /mjt
In article <42887A19.2010701@tls.msk.ru> you write:
Noticied today. All Verisign's GTLD servers broke EDNS0 (RFC2671). Here's how it looks like:
query:
$ dnsget -t mx -vv microsoft.net. -n 192.5.6.30 ;; trying microsoft.net. ;; sending 42 bytes query to 192.5.6.30 port 53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64471, size: 42 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION (1): ;microsoft.net. IN MX
;; ADDITIONAL section (1): ;EDNS0 OPT record (UDPsize: 4096): 0 bytes
Note the EDNS0 stuff (numar=1). And here's the reply to this query:
;; received 12 bytes response from 192.5.6.30 port 53 ;; unexpected number of entries in QUERY section: 0 ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64471, size: 12 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION (0): ; invalid query section
They're returning FORMERR (which is wrong), *and* don't return the original query (numqd=0).
Without EDNS0 extensions, it works like expected.
/mjt
This is the expected response from a server that doesn't understand EDNS. If you can't parse the original query, which is what FORMERR indicates, then the only thing you can safely send back is the DNS header. Mark
Mark Andrews wrote:
In article <42887A19.2010701@tls.msk.ru> you write:
Noticied today. All Verisign's GTLD servers broke EDNS0 (RFC2671). Here's how it looks like: [] ;; received 12 bytes response from 192.5.6.30 port 53 ;; unexpected number of entries in QUERY section: 0 ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64471, size: 12 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
This is the expected response from a server that doesn't understand EDNS. If you can't parse the original query, which is what FORMERR indicates, then the only thing you can safely send back is the DNS header.
Well ok, I know it's kinda expected -- "i don't understand what you're asking for, can't even repeat your question". But the next question is -- *why*? When at least half the world is actually *using* EDNS0 (bind8 and bind9 clients does), and another half a word isn't "dropping" EDNS0 stuff, -- why so important component of worldwide DNS infrastructure "does not understand" it? It looks pretty much like situation with ECN: you don't have to "support" it, but don't munge and drop it, just pass it along. *especially* when you're an "internet backbone". /mjt
Florian Weimer wrote:
* Michael Tokarev:
Well ok, I know it's kinda expected -- "i don't understand what you're asking for, can't even repeat your question". But the next question is -- *why*?
EDNS0 can be easily abused for traffic amplication purposes. 8-(
Root and TLD nameservers rarely have large answers to queries to exceed 512 bytes. (And for those rare cases if they exists, TCP connection should be established to get a reply -- this does not work quite well for forged UDP traffic, but it's still more legitimate traffic than larger UDP replies). But this does not really matter. I repeat: One don't have to "support" EDNS0, just don't report it as error, like broken routers does with ECN. And in this "mode of operations" there's no MORE ways to abuse it for the said purpose than currently exists. /mjt
* Michael Tokarev:
EDNS0 can be easily abused for traffic amplication purposes. 8-(
Root and TLD nameservers rarely have large answers to queries to exceed 512 bytes.
The miscreants have partial write access to most TLD zones, so they can create record sets whose size approaches or exceeds 512 bytes.
(And for those rare cases if they exists, TCP connection should be established to get a reply --
This seems to be Verisign's intent, and yet you still complain.
But this does not really matter. I repeat: One don't have to "support" EDNS0, just don't report it as error,
EDNS0-capable resolvers typically cache the information that another server doesn't support EDNS0. Returning FORMERR is compliant with RFC 2671.
like broken routers does with ECN.
IIRC, the complaint with respect to ECN was that some routers dropped packets *without* signaling an error.
... I repeat: One don't have to "support" EDNS0, just don't report it as error, like broken routers does with ECN. And in this "mode of operations" there's no MORE ways to abuse it for the said purpose than currently exists.
please actually read RFC 2671 before you ask any questions about it or make any comments on how it ought to have been writ differently. and when you're ready to ask such questions or make such comments, please make them on namedroppers@ops.ietf.org rather than on NANOG. -- Paul Vixie
On Mon, 16 May 2005, Michael Tokarev wrote:
They're returning FORMERR (which is wrong), *and* don't return the original query (numqd=0).
As others have already pointed out, the behavior of the com/net authoritative name servers with regard to EDNS0 is correct according to RFC 2671 (the EDNS0 spec). In particular, please see section 5.3: 5.3. Responders who do not understand these protocol extensions are expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. Therefore use of extensions should be "probed" such that a responder who isn't known to support them be allowed a retry with no extensions if it responds with such an RCODE. [...] Matt -- Matt Larson <mlarson@verisign.com> VeriSign Naming and Directory Services
participants (5)
-
Florian Weimer -
Mark Andrews -
Matt Larson -
Michael Tokarev -
Paul Vixie