In an interesting development to this, UltraDNS are starting to REFUSE a
UDP/ANY request on some of their name servers. As they're unicast, your local
ones may or may not. The implication is that any software making an ANY query
will start to fail when they're all switched over. In my region (W.Canada):
UDNS1.ULTRADNS.NET, UDNS2.ULTRADNS.NET, PDNS1.ULTRADNS.NET,
PDNS2.ULTRADNS.NET, all refuse a UDP/ANY, whereas PDNS3.ULTRADNS.ORG,
PDNS4.ULTRADNS.ORG, PDNS5.ULTRADNS.INFO and PDNS6.ULTRADNS.CO.UK still accept
them
qmail is the 1st piece of software out there that jumps to mind that is going
to break, but what else is there out there that makes these queries? When all 6
start refusing ANYs, I predict there may be some backlash.
I published a one line fix for djbdns (on the djbdns list) if you use it as a
local cache, to force an ANY query via TCP instead of UDP (dns_transmit.c, line
220)
- if (len + 16 > 512) return firsttcp(d);
+ if ((len + 16 > 512) || byte_equal(qtype,2,DNS_T_ANY)) return
firsttcp(d);
which (partly) solves the issue in case you have software making ANY queries;
but it also has the downside that misconfigured DNS servers that don't listen
on TCP then don't work correctly; (such as midco.net's name servers).
I really wish that ISPs would solve the root problem here, which is allowing
spoofed packets to exit their networks, then a reflected DNS/UDP attack simply
wouldn't be possible.
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
