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
* 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-(
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.
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