[AfrICANN-discuss] Will DNSSEC kill your internet?

Anne-Rachel Inné annerachel at gmail.com
Wed Apr 14 10:15:05 SAST 2010

 Will DNSSEC kill your internet?

5 May will sort the men from the boys

By Kevin Murphy<http://forms.theregister.co.uk/mail_author/?story_url=/2010/04/13/dnssec/>


<http://www.theregister.co.uk/2010/04/13/dnssec/print.html>Posted in
Telecoms <http://www.theregister.co.uk/networks/telecoms/>, 13th April 2010
11:02 GMT

Free whitepaper – Taking control of your data demons: Dealing with
unstructured content <http://go.theregister.com/tl/323/-1338/-?td=wptl323>

Internet users face the risk of losing their internet connections on 5 May
when the domain name system switches over to a new, more secure protocol.

While the vast majority of users are expected to endure the transition to
DNSSEC smoothly, users behind badly designed or poorly configured firewalls,
or those subscribing to dodgy ISPs could find themselves effectively
DNSSEC adds digital signatures to normal DNS queries, substantially reducing
the risk of falling victim to man-in-the-middle attacks such as the Kaminsky
exploit <http://www.theregister.co.uk/2008/07/24/dns_exploit_goes_wild/>(
http://www.theregister.co.uk/2008/07/24/dns_exploit_goes_wild/), which
caused widespread panic in July 2008.

The standard is currently being rolled out cautiously to the internet's DNS
root servers. In May, when all 13 roots are signed, anybody with an
incompatible firewall or ISP will know about it, because they won't be able
to find websites or send email.

Why? Here comes the science bit. Normal DNS traffic uses the UDP protocol,
which is faster and less resource-hungry than TCP. Normal DNS UDP packets
are also quite small, under 512 bytes.

Because of this, some pieces of network gear are configured out of the box
to reject any UDP packet over 512 bytes on the basis that it's probably
broken or malicious. Signed DNSSEC packets are quite a lot bigger that 512
bytes, and from 5 May all the DNS root servers will respond with signed
DNSSEC answers.

Keith Mitchell, head of engineering at root server operator Internet Systems
Consortium, said his biggest fear is for large enterprises with sprawling

“There are a lot of firewalls and other middleware boxes out there that make
the assumption that there are only small UDP packets,” he said. “Several
times a month we receive reports of problems like this.”

Sometimes these devices will failover to TCP, which drains bandwidth and
hardware resources because it uses handshaking to set up connections.

Mitchell said he's also concerned about ISPs that rewrite DNS answers as
they pass across their networks. Some ISPs do this to redirect their
customers to cash-making search pages when they're trying to find a
non-existent website. In China, ISPs use the same method to censor websites.

“They're doing a lot of fiddling along the way and it's by no means clear to
me that the fiddling is aware of DNSSEC,” he said.

The solution to the problem is Extension Mechanisms for DNS, EDNS0, a
decade-old IETF standard that is not yet universally implemented. Mitchell
said ISPs and enterprises need to ensure that their gear can handle EDNS0 to
avoid problems with the transition.

You can test whether your current DNS resolver is capable of handling
DNSSEC, by following the instructions at
 (https://www.dns-oarc.net/oarc/services/replysizetest) or running a Java
app that can be downloaded from

Home users using residential hubs should not panic if these tests return
scary results. According to Mitchell, it currently only matters that the ISP
supports DNSSEC. A dodgy Netgear box is not enough to kill your internet...
cross fingers. ®
Related stories

   - DNSSec update deadline penciled in for
    (16 November 2009)

   - Kaminsky calls for DNSSEC
    (21 February 2009)

   - One in ten DNS servers still vulnerable to
    (10 November 2008)

   - Will the internet die in
    (22 June 2006)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/africann/attachments/20100414/5d3e837c/attachment.htm

More information about the AfrICANN mailing list