Trusted name resolution with DNSSEC
Chain of Trust

© Sergey Ilin, Fotolia
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
News
-
Linux Mint 19.3 Will be Released by Christmas
The developers behind Linux Mint have announced 19.3 will be released by Christmas 2019.
-
Linux Kernel 5.4 Released
A number of new changes and improvements have reached the Linux kernel.
-
System76 To Design And Build Laptops In-House
In-house designed and built laptops coming from System76.
-
News and views on the GPU revolution in HPC and Big Data:
-
The PinePhone Pre-Order has Arrived
Anyone looking to finally get their hands on an early release of the PinePhone can do so as of November 15.
-
Microsoft Edge Coming to Linux
Microsoft is bringing it’s new Chromium-based Edge browser to Linux.
-
Open Invention Network Backs Gnome Project Against Patent Troll
OIN has deployed its legal team to find prior art.
-
Fedora 31 Released
The latest version of Fedora comes with new packages and libraries.
-
openSUSE OBS Can Now Build Windows WSL Images
openSUSE enables developers to build their own WSL distributions.
-
Sudo Vulnerability
A vulnerability in the sudo package gives sudo users more powers than they deserve.