Most people reading this will already know that the Domain Name System (DNS) is a mechanism used to translate alphanumeric domain and host names into numerical IP addresses — just like a phonebook. Aside from the obvious advantage of making Internet addresses easier to remember, this allows human-readable addresses to remain constant regardless of IP- or route-related modifications. If Microsoft decides to move their Web server to another address, it can update its IP addresses as necessary, but end users have only to remember the friendly URL: microsoft.com.
DNS provides another essential service, which is MX (Mail Exchanger) record lookups. The MX record is a type of resource record stored in DNS that gives instructions on how to route e-mail for a specific domain. This is particularly useful, as it allows multiple MX records to be stored in the order that delivery should be attempted. A mail transfer agent will deliver mail to the first available MX address. This helps large mail systems cope with the huge amount of data constantly being received and also provides a simple method of introducing redundancy into mail systems. Because DNS has to scale to cover the entire Internet, it is implemented as a distributed system; it uses a hierarchical approach whereby each domain has at least one authoritative DNS server that publishes information related to that domain plus details of name servers of the domains that lie underneath — this chain continues until a root server is referenced. Root servers control top-level domains like .com or .net.
The problem with DNS is that it currently faces several threats, particularly cache-poisoning and ‘monkey in the middle’ attacks.
DNSSEC (Domain Name System Security Extensions) is a backward compatible ‘secure’ extension of DNS that is currently being tested and deployed across the globe. Sweden was the first to deploy and enable DNSSEC in its zone (the .SE top-level domain). Russia’s .RU zone followed in 2006 with Bulgaria also signing the .BG top-level domain zone early this year.
DNSSEC secures DNS by authenticating the origins of DNS data, ensuring integrity of that data, and also providing an authenticated denial of existence. DNSSEC protects revolvers (clients) from being fed forged data by digitally signing DNS records. Clients can use this digital signature to check whether or not the supplied DNS information is identical to that held on the authoritative DNS server. It will also be possible to use DNSSEC-enabled DNS to store other digital certificates; this makes it possible to use DNSSEC as public key infrastructure for signing of e-mail — possible, but perhaps not viable. I’ll explain why below.
At this point, I should point out the two major problem areas with DNSSEC — the first is technical in nature, but the second is purely political.
Let’s start with the technical bit. DNS zone data can be quite valuable to an attacker and is, therefore, almost always kept private. Even if no confidential data is stored in the DNS records, knowing which hostnames exist and which do not can greatly aid an attacker in mapping a remote network. With traditional DNS systems a ‘split zone’ is used that enables the DNS server to deny existence of records to some clients while providing correct records to others (internal/external clients for example).
The problem DNSSEC introduces is that it must be able to report when a name is not found. DNSSEC information is signed as being authoritative (the truth, the truth, and nothing but the truth); providing a signed ‘not found’ record for a name which actually does exist is problematic because that signed response can then be retransmitted to cause a denial of service. Providing an unsigned ‘not found’ report is a bad idea as that could easily be spoofed.
Key signing should not be carried out online, so DNSSEC was designed to return a pre-signed report containing a range of names which do not exist; this could be signed offline and ahead of time. This gives a potential attacker much more information about the network that otherwise, would have been unavailable. I suggested above that DNSSEC could be used as a public key infrastructure for signing of e-mail; however, the aforementioned issue means that doing so would be tantamount to publishing a list of all employees in the organisation — something most wouldn’t even consider!
A potential solution to these issues is NSEC3 also known as DNSSEC Hashed Authenticated Denial of Existence. In this case, the DNSSEC server returns a response that has been encrypted, and therefore does not give away information that is best kept secret.
The political issues surrounding DNSSEC are rather interesting. Countries around the world are very obviously concerned about U.S. control of the Internet. As a representative of the national top-level domain registries, Bernard Turcotte (president of the Canadian Internet Registration Authority) drew attention to the proposal of the U.S. Department of Homeland Security that the key to sign the DNS root zone be placed in the hands of the U.S. government. Heise online reports that “this ultimate master key would then allow authorities to track DNS Security Extensions all the way back to the servers that represent the name system’s root zone on the Internet.”. Lars-Johan Liman of the Swedish firm Autonomica pointed out the political implications of this last year; Autonomica run one of three root servers currently located outside of the U.S. A representative of the EU commission has said that the matter is being discussed with member states.
I have to say that I find this political quandary quite interesting; should each country be given control of it’s own top-level domain root keys? Should those who are given the keys be government agencies or civil organisations? Wherever I find discussion on this topic, opinions seem to be deeply divided with convincing arguments on both sides: What’s your view?