On May 5, the world's top domain authorities (led by ICANN, the US Government and Verisign) will complete the first phase of the roll-out of DNSSEC (Domain Name System Security Extensions) across the 13 root servers that direct user requests to the relevant websites on the internet.
The DNSSEC upgrade adds a digital signature to the response from every DNS (Domain Name Server) request to give an internet user an extra level of assurance that the domain name is translated to the correct Internet location (such as a website, or email destination).
DNSSEC was developed in an attempt to thwart 'man in the middle' attacks, in which hackers intercept a request and respond with a message that fools the user system into going to a false location.
But the new protocol - much welcomed by the industry - could have an unfortunate side effect for unprepared network managers, according to Bruce Tonkin, chief strategy officer at Melbourne IT and a board director at ICANN.
A response to a standard DNS request tends to be in a single packet (UDP protocol) and tends to fall below 512 bytes in size.
In some older networking equipment, any larger request than this would be blocked by pre-configured factory settings, under the assumption that larger packets (and several of them) represent an anomaly of some kind.
As of May 5 at 17:00 UTC (which is actually pre-dawn on Thursday 6th on the East Coast of Australia), all DNSSEC signature-laden messages sent back to a user's DNS resolver will be four times the size - up to 2 KB. And should packets of that size be rejected, the message would likely be sent in multiple packets via the TCP protocol.
(These signatures will be dummies at first to test the system, as of July 1, they will be the real deal.)
Tonkin fears that while DNSSEC has been on the agenda for some time, many IT and network managers have yet to test their older routers and firewalls to ensure they can handle the larger DNS responses.
"The bigger answer coming back from the DNS request might get blocked by some internet devices in the Corporate network," he said.
DNSSEC is in fact already rolled out across most of the world's 13 root server clusters, in an effort that began in December 2009.
But to date, Tonkin explained, it would only have resulted in a slight lag in the loading of a web page for those with outdated network equipment.
The beauty of DNS is that should a request made to one root server not receive a response, the DNS resolver on a user's machine simply makes the same request along the line of the 13 root servers until it gets a satisfactory response.
But on May 5, once all 13 root server clusters are live with the DNSSEC signatures, responses from all 13 root servers won't make it back inside the corporate LAN on some older systems.
Tonkin expects that the larger Internet Service Providers will have addressed the issue, so most home internet users will be unaffected.
"I'm not entirely sure all ISPs will be prepared, but I imagine the major ones are," he said. "ISPs tend to do DNS translation for you. But it is likely to have a big impact in the corporate environment, where you might run your own DNS server and infrastructure."
In that sense Tonkin doesn't expect a "Y2K meltdown" of the internet May 5.
But he predicts a number of organisations will start experiencing internet access issues, and a number of network administrators will be left scratching their heads as to why.
To complicate the scenario further, network administrators and helpdesks "may not know what has gone wrong," he said.
The problem may take several days to surface and be inconsistent from one user's PC to the next. A user at one machine that hasn't switched on his PC for two or three days will have no access to the internet. A user that left his machine on the night before will have some pages - and responses from DNS servers - cached on their machine, and will still have connectivity.
"It is usually much easier to address a problem when everything isn't working!" Tonkin said.
Tonkin recommended network managers run a series of simple online tests to ensure their network can handle the larger DNS responses:- A reply-size test available at DNS-OARC:https://www.dns-oarc.net/oarc/services/replysizetest
- Ripe Labs' 'Test your DNS Resolver'http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues