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
;;
In article [EMAIL PROTECTED] 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,
Mark Andrews wrote:
In article [EMAIL PROTECTED] 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,
* 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
Last mile usage? May be, but it is not supported by many consumer level
firewalls/NAT's/DSL devices, cheap switches and so on.
I agree, it is most likely usage for it (multicast) - last mile and 'last
patch' -:).
- Original Message -
From: Frank Coluccio [EMAIL PROTECTED]
To: 'Ross
Found: one jump drive in Terminal Room
* 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
... 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
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
Forgive the forwarding, but I thought this BCP might be of
interest to the list.
- ferg
[snip]
A new Request for Comments is now available in online RFC libraries.
BCP 104
RFC 4084
Title: Terminology for Describing Internet Connectivity
Author(s): J.
11 matches
Mail list logo
