Trusted name resolution with DNSSEC

Chain of Trust

© Sergey Ilin, Fotolia

© Sergey Ilin, Fotolia

Article from Issue 90/2008

Some Internet exploits target name resolution servers. DNSSEC uses cryptography to protect the name resolution service.

System administrators and security consultants have devised elaborate strategies for protecting computer networks, but one very basic part of the Internet infrastructure is still surprisingly vulnerable: the name resolution system. Intruders have developed sophisticated techniques for spoofing DNS responses. Of course, the white hats have fought back with their own defensive maneuvers, but experts agree that a fundamentally different approach is necessary. The DNS Security Extensions (DNSSEC) system [1] offers a comprehensive solution for authentication and data integrity for DNS.

DNSSEC adds cryptographic signatures to the legacy name resolution service. But a signature can't solve the problem alone (because an attacker can create a signature, too). DNSSEC also needs a method for authenticating the public key used in the asymmetric encryption, which means the system must provide its own form of Public Key Infrastructure (PKI).


To help DNSSEC succeed, two groups must make a contribution: Users can only benefit from the system if network managers provide servers that use DNSSEC responses to validate their users. Name server managers must sign their zones and integrate them with the chain of trust in the superordinate zones [2]. The free ISC BIND name server, which many regard as being a DNS reference implementation, provides solutions for both these objectives [3].

DNSSEC name server extends its zone file. Besides administrative information in the SOA record, it mainly contains RRs that support mapping of DNS names to IP addresses or vice versa. DNSSEC uses signatures to protect the RRs. To do so, the DNSSEC introduces another series of RRs, as listed in Table 1.

Chain Reaction

Because the DNS system typically resolves names through a hierarchical chain of interacting name servers, DNSSEC can only guarantee authenticity if it operates at all levels of the chain. A complete solution therefore requires the adoption of DNSSEC on a massive scale. So far, the Swedish .se domain is the only top-level domain signed with DNSSEC, but many organizations have started implementing and experimenting with DNSSEC at lower levels. In this article, I will look at trusted name resolution with DNSSEC.

Public Keys for DNS

The first thing you will need is a resolver that supports DNSSEC. Because most stub resolvers can't do this – and the one in libc is no exception – administrators on enterprise networks will need to install a name server and enable its DNSSEC functionality.

Now, thanks to DNSSEC, when clients on the network ask the server for IP addresses, the name server is guaranteed to return reliable results. Of course, the hop between the client and the first server is not safeguarded and theoretically could be manipulated. If you are responsible for security on your network, you will need to decide on an individual basis whether to take this lapse seriously.

The DNSSEC resolver now checks to see whether the query is for a DNSSEC-secured zone. If the requested target is on a secure island, this is always true. The top nodes in these structures are referred to as Secure Entry Points (SEPs, see Figure 1). Admins must make these entries the top priority on the DNSSEC resolver. Thus, the list of SEPs is the functional equivalent of providing CA certificates to a web browser.

Figure 1: DNSSEC adds SEPs to the DNS domain hierarchy. Later on, these secure islands will grow together to form a large DNS continent.

Lonely Islands

DNSSEC uses the same access mechanisms as legacy DNS. Because the resolver only requests Resource Records (RRs) from a server, the system is downwardly compatible. Additional security is provided by a DNSSEC-enabled resolver validating the signatures in the RRs. If a response is not correctly signed, it is discarded.

Because the user is never tempted to use a potentially compromised response, this is a very secure approach. However, users must get used to the server responding with NXDOMAIN, which means "this domain does not exist."

In contrast to this, PKI will pop up a window with web certificates in the same situation. The user can decide how to react to the invalid certificate; unfortunately, many users just ignore the warning.

If the response does not come from a secure island, the resolver will resort to legacy methods to resolve it and then return the response to the requesting client. Security admins should be aware that, if they use DNSSEC, the user will not be able to tell whether or not a response is authenticated by DNSSEC.

In the long term, the DNSSEC lobby seeks to have just a single SEP that points to the DNS root zone. A chain of trust links the signing key with all the zones below it in the hierarchy. This lets DNSSEC resolvers validate signatures. On the Internet today, this is not the case, in that it is still just interspersed with independent secure islands. Until the islands grow together, resolver administrators still need to manage multiple trusted keys as SEPs.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More