Trusted name resolution with DNSSEC

Chain of Trust

© Sergey Ilin, Fotolia

© Sergey Ilin, Fotolia

Author(s):

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).

Teamwork

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.

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.

Read full article as PDF:

064-069_dns-sec.pdf  (690.33 kB)

Related content

  • Security Lessons: DNSSEC

    One of the largest holes in the Internet is finally plugged.

  • Charly's Column: Nameserver Diagnostics

    Many administrators rely on Linux tools whose fate is already sealed, but external forces can help people let go of old habits.

  • Security Lessons: DNS Security

    Kurt describes how to keep bad guys out of your network using a targeted filtering approach.

  • Bind 10 Test Drive

    Admins have waited all of five years for the 10th major release of the Bind name server, which appeared at the end of March this year. The latest release is a complete rewrite of the DNS server, with a modular design and new configuration tools, but is it ready for business?

  • DIC: Domain Name Registries to Promote DNSSEC

    The DNSSEC Industry Coalition (DIC) was founded in the U.S. with the goal to drive further development and acceptance of the DNSSEC security protocol. The consortium includes a half dozen top Domain Name Registries and software developers that are currently laying out an action plan.

comments powered by Disqus

Direct Download

Read full article as PDF:

064-069_dns-sec.pdf  (690.33 kB)

News