Monday, May 3rd, 2010 by Mark Newton
If you follow the technology press, you might have seen some recent articles about something called DNSSEC, and its impending introduction.
The articles have mostly been about technical problems which DNSSEC might uncover, but have generally been light on the subject of what, exactly, DNSSEC actually is.
The Domain Name System (DNS) is part of the fundamental infrastructure of the Internet. It’s the globally-deployed system which translates names like www.facebook.com into the numeric IP addresses like 188.8.131.52 which your computer understands. Every time you type a website name, a part of your computer’s operating system called the “resolver” sends a query to a DNS server, and the DNS server responds with an answer which contains various types of useful information about the question.
One of the problems the DNS system has is that there are various techniques which are hard to explain but which are pretty well understood in certain nefarious quarters which can be used to trick a computer into believing a forged answer when its resolver asks a question. So somebody who wanted to know your online banking password (for example) could conceivably construct a fake bank website, and fool your computer into visiting it when you type www.yourbank.com.au. This is not believed to be a common problem in practice as yet, but the motivation here is to stop this potential problem from becoming an actual one later on.
When DNSSEC is fully deployed, it’ll provide a method your computer can use to thwart that kind of attack. DNS responses will be “signed”, and your computer’s resolver will be able to check the signatures to make sure they match. So when you type www.yourbank.com.au and get a forged answer, your computer will know it’s forged.
DNSSEC deployment is a world-wide change to one of the systems that holds the Internet together, and is not something instigated or under the control of Internode as such. We are, however, trying to ensure that in the unlikely event that it causes you a hassle, you will understand it and be able to do something about it.
So that all sounds pretty good, why are the articles in the IT press doomsaying about it?
To answer that, you need to know a bit of DNS history: Until relatively recently, DNS responses have usually been limited to 512 bytes, and have mostly been carried by an Internet protocol called “UDP”. So various bits of infrastructure such as firewalls and home ADSL routers have been designed on the assumption that all DNS responses are 512 bytes or less, transported by UDP.
The problem, of course, is that the digital signatures required by DNSSEC tend to push the size of DNS responses past the 512 byte point.
This shouldn’t present a huge challenge, because the DNS protocol has a mechanism for transporting larger responses by sending them over TCP instead of UDP. But the mechanism has been so rarely needed that many vendors haven’t implemented it. Indeed, large DNS responses have been so rare that some firewall vendors and some companies’ security managers have actively blocked them on the assumption that the only possible reason they’d exist would be as part of an attack!
For people using systems which don’t work correctly with large DNS responses, Wednesday 5th May 2010 will represent a bit of a flag-day. On that day, the Internet’s root DNS servers will start emitting the digital signatures needed to authenticate their responses, and there’s a reasonable expectation that people who aren’t correctly processing large DNS responses will suffer connectivity problems to random bits of the Internet.
Most systems should be fine, but older firewalls and ADSL modems might suffer problems.
So what can you do about it?
If you’re a residential customer with an ADSL modem which stops working correctly after Wednesday May 5th, consider an upgrade to the latest firmware version. If that doesn’t help, try disabling your ADSL modem’s DNS proxy, which will cause you to use our DNS servers (which we’ve tested with DNSSEC) instead of your ADSL modem’s possibly-faulty built-in DNS server.
If you’re a firewall administrator, make sure your company’s firewall is permitting DNS over TCP/53, and that fragmented DNS responses over UDP or TCP aren’t blocked. Check out the test tools at https://www.dns-oarc.net/oarc/services/replysizetest and make sure you conform. Consider a firmware upgrade if you haven’t done one already. Read-up on the nature of the problem, and understand that TCP/53 has always been a valid part of the DNS protocol, and that blocking it isn’t “industry best practice,” it’s a configuration error.
Our Customer Service staff will try their best to assist people with DNS problems after May 5th, but please understand that it’s possible that any problems you experience may be caused by deficiencies in your own equipment. Although it’s very unlikely, it remains possible that you’ll need to purchase a new firewall or a new ADSL modem after May 5th if your current equipment is old enough to have problems which haven’t been fixed by the vendor because they’re no longer offering support for your product.
The overwhelming majority of our customers won’t notice anything on May 5th, but the difference behind the scenes will be considerable. DNSSEC is undergoing a phased rollout and it won’t be ready for full use for a couple of years, but when the work is complete the security of the Internet infrastructure will be vastly improved.