The Domain Name System (DNS) is the service that allows to retrieve the IP address associated with a specific server or domain name, such as those included in email addresses (after the “@” sign) and in web addresses, so that your computer can then establish a connection. It is a fundamental piece of the Internet’s architecture: whatever service you are using on your computer, the connection starts with a DNS request to a local name server, to learn the address that allows you to reach the desired service.
Like most Internet protocols, when DNS was initially designed there were no real security threats, so all the information travels in clear, and the system is based on trust: there is no authentication of the legitimacy of the source of a DNS reply. Moreover, to speed up responses, name servers cache the name-address associations they discover, and repeat them in reply to any further requests by other clients for the same name. This makes DNS susceptible to a number of attacks.
Specifically, the DNS cache poisoning attack allows an attacker to forge a response to a query so that the name server learns a wrong address for a given server name, and stores it in its cache. As long as the cache does not expire, all users and local servers making requests for the same name to that same name server will be pointed out at the wrong address. This allows the attacker to set up a fake server at that address, and to receive all the connections and communications that were intended for the true server.
To counter this and other threats, the Domain Name System Security Extensions (DNSSEC) have been developed. In DNSSEC, all replies to a DNS query are cryptographically signed, so that every client or name server can verify the source of the replies to the queries it made.
The verification is made through a chain of trust model, parallel to the recursive nature of the DNS. In the DNS, when willing to discover the address associated to “www.example.com”, a name server will ask a root server for the address of an authoritative name server for “.com”; then it will ask the “.com” server for the address of an authoritative name server for “example.com”; and then will ask this latter server for the address of “www.example.com”.
With DNSSEC, when the root server provides the address of a “.com” name server, it will also sign this reply with its own key, and add a hash of the authorized key for “.com”. The querying name server will match the signature of the root server’s reply with a list of valid root server keys, thus proving that the reply is not forged, and will then proceed querying the “.com” server for “example.com”; that reply will be signed as well, and will contain a hash of the authorized key for “example.com”. The server will match the signature of the “.com” server’s reply with the hash it received from the root server, thus proving that the reply is not forged, and will proceed to the next hierarchical level.
To secure a domain name with DNSSEC, every domain name owner must perform two operations:
- activate the signing of DNS replies on the domain name’s authoritative name servers;
- communicate a hash of the domain’s keys to the owner of the domain’s parent zone, e.g. “.com” for “example.com”.
All recent name server applications now implement DNS zone signing; the domain owner just needs to configure them properly. This includes the creation of two keys, a zone signing key (ZSK), which will be used to sign the actual DNS records, and a key signing key (KSK), which will be used to sign the records related to the ZSK currently in use. This allows the use of shorter ZSKs and shorter replies, and lets you change (rollover) ZSKs more frequently, while still maintaining appropriate security.
In the past, name server applications would require you to create the keys, and to (re)sign the zone yourself every time you wanted to change it. Now, however, most applications support live signing (also called inline signing), which means that you can provide a traditional zone file/description and the keys, and the application will manage all cryptographic operations on its own. Some name server applications even automate key creation and rollover, while others still require the system administrator to manage the keys by hand.
When the KSK is created, and whenever the KSK (not the ZSK) is changed, some information about the new KSK must be communicated to the parent zone’s owner, which will then generate the so-called DS records – the hash that will be added to the parent zone server’s replies to allow verification of the chain of trust. This usually involves copying some numbers and strings from the key file into a specific form on your registrar’s Web-based management interface. However, if you do not run your own authoritative name servers, but use your registrar’s servers, then your registrar may manage keys and DS records automatically for you.
If you intend to use DNSSEC, you should be sure to register your domain in a DNSSEC-enabled TLD and with a registrar that supports DNSSEC. If you run your own authoritative name servers, the registrar must support DS record management for domains that it does not host directly. If you intend to use your registrar’s name servers as authoritative servers for your domain, then you need to ensure that your registrar supports automatic key creation and zone signing for the domain names it hosts. ICANN maintains lists of the DNSSEC status of all TLDs and of DNSSEC-friendly registrars.
