DNS drives the Internet. It may not be broken, but the fact that it trusts explicitly is a bad idea. Nasty people have figured out how to leverage that trust to hurt us using what’s called spoofed DNS replies. I know, that’s geek-speak. See if this example helps.
Needing to transfer money to a different account, you click on the bookmark for your bank. Bang, your bank’s Internet portal shows up in the browser. You log in normally, but the site responds that something is wrong; please try later. Come on, but what can you do?
Then yours truly shows up asking,” How do you know that really was your bank’s Web site?” Currently, there is no for-sure way to tell, and the bad guys love it. By altering DNS information, they can point browsers to a malicious copy of the queried Web site. None the wiser, we log in and they have our credentials.
Since 1997, the IETF has been trying to figure out a way to make sure that misdirection does not happen. Their solution is DNSSEC (Domain Name System Security Extensions). It seems like a good idea, according to the papers written about it.
What seems a bit odd is that there’s not much available information about what DNSSEC means to us and our SOHO/home networks. After some searching, I have been able to piece together the following requirements.
1: What routers must handle
Routers must be able to handle larger than normal DNS packets. Because of the new authentication requirements, DNSSEC responses are larger than the current 512-byte UDP packets used by DNS. This could be a problem. Some routers are programmed to reject DNS packets larger than 512 bytes.
Routers must also be able to process DNSSEC queries that have reverted to TCP/IP. If there is a problem with the larger UDP packet size, DNS servers are instructed to send DNSSEC responses using TCP/IP. If the router does not support this, the DNS query will fail.
Finally, routers must be able to handle DNSKEY, RRSIG, NSEC, and NSEC3 correctly. These are all new DNS resource records needed to authenticate DNSSEC traffic. The perimeter router must know how to handle them or the chain of trust is broken.
2: Determining whether a router is DNSSEC-capable
I haven’t been able to find much in the way of recent information, but I did find this 2008 report: DNSSEC Impact on Broadband Routers and Firewalls. The research team did a thorough job of testing 24 consumer and SOHO routers. Check to see how yours did. If it’s not on the list, I would check with the manufacturer.
3: Other DNS security tests
Although not directly related to DNSSEC, you will notice the following two tests were reported in the paper’s results:
- Rejects uninitiated DNS queries
- Randomizes DNS query ports
Both are important. They remove two exploit possibilities. Typically, this information is not accessible. I would make a point to call the router manufacturer and ask.
4: Firmware updates
Updating firmware on gateway devices is always a good idea and more important now than ever. If your router did not pass the DNSSEC testing in 2008, more than likely the latest firmware update will.
5: Upstream Internet provider readiness
This should not be an issue. Still, it won’t hurt to ask the provider about it. Two questions I like to inquire about are:
- How are DNSSEC authentication keys protected?
- Who should be called if things are not working right?
Extra tip for Firefox users
DNSSEC Validator is a Mozilla add-on that checks for the existence and authenticity of DNSSEC records. Different colored keys in the address bar indicate the status of that particular domain with regard to DNSSEC.
DNSSEC has the potential to increase online security in a big way, but it has to be implemented correctly. That means our routers must belong to the chain of trust. Here’s some added incentive to get on board: If the router does not handle DNSSEC packets correctly, your online experience could slow down considerably.