LSS: DNSSEC

Paul Wouters gave a presentation on DNSSEC (Domain Name System Security Extensions) on the first day of the 2012 Linux Security Summit (LSS). It was a "pretty generic" look at DNSSEC, giving an overview of what it is and does. He also talked about some of the problems that can occur when using DNSSEC, particularly with hotspots or VPNs, along with some interesting applications that a secure data distribution mechanism will allow.

As the subtitle to Wouters's talk described, DNSSEC is a "cryptographically secured globally distributed database". But, not many people are actually running DNSSEC, at least yet. He would like to see that change, because DNSSEC has uses beyond just securing DNS. It can be used to safely distribute content that can't be modified.

Digging for DNSSEC information

Wouters stepped through some examples of using the dig program to query for DNSSEC information. The first thing to note when doing DNSSEC queries is the Authenticated Data (ad) flag that is reported in the results. It indicates that the results were validated by the recursive name server. So, an A (address) record returned from the name server with the ad flag is simply a claim by that server that it did the necessary verification. In order to be sure of the authenticity, though, the local name server needs to do its own verification.

One can retrieve the signature that corresponds to a given A record, using a command like:

    $ dig +dnssec fedoraproject.org

To verify the mapping from name to IP address, DNSSEC resolvers use the signatures returned in the RRSIG (DNSSEC signature) record. In order to reduce the processing burden, DNSSEC servers typically do not do any cryptographic operations on the fly, and rely, instead, on pre-generated signatures. The signatures for each host in the domain are generated elsewhere, then installed on the DNSSEC server. Signatures have a duration associated with them, to stop replay attacks, but that means the signatures need to be periodically regenerated.

But, the name servers cannot know in advance the queries that might be made. For example, querying doesnotexist.fedoraproject.org is a perfectly valid request, but a server can't have canned, signed responses for each invalid host. So, instead, it returns signed responses for the host names alphabetically on either side of the requested name as NSEC (next secure) records. Those essentially describe a range of names that do not exist for the domain. Multiple queries could be used to map the full namespace of the domain, which is one of the criticisms of DNSSEC. One could avoid that by having the signing key on the server to sign the "does not exist" response, but that is generally considered to be insecure.

In order to verify the signature on query results, the public key corresponding to the private key that signed the entry must be retrieved. That is available as DNSKEY record type for the domain. There will often be more than one key defined for a domain to make it easier to roll over to a new key, Wouters said.

A chain of trust needs to be established in order to verify that the keys being used are actually those used by the domain. In order to do that, the parent domain (i.e. org for fedoraproject.org) will have a hash of the valid keys in use by the child. That information is reported in DS (delegation signer) records from the parent. That trust chain can be followed all the way back to the root zone, whose keys are widely available and are typically statically stored on the system. These trust chains can be examined using the drill utility.

When using straight DNS, all answers are considered to be insecure. But, with DNSSEC, there are several different states that a query answer could be in. The answer could be verified from a known trust anchor (such as a root zone key), and thus be "secure". Or it could be proven that there is no trust anchor that can be used to verify the answer, so it is "insecure" (as with straight DNS).

But, there are two other states that an answer can be in, Wouters said. The first is the "bogus" state, which means that the cryptographic verification failed. That typically results in a SERVFAIL error from the resolver. There is also the "indeterminate" state, which indicates that the answers needed to verify the result were missing or incomplete. The indeterminate state causes lots of problems, he said. It could be mapped to the bogus state, but that makes it harder for browsers and other applications to handle "soft failures".

DNSSEC and Linux

Linux distributions have a variety of DNSSEC tools available. For resolvers, BIND or Unbound are available, with the latter being preferred for on-the-fly changes. For DNS servers, one should use BIND, NSD, or PowerDNS, any of which are modern DNS servers that should work fine, he said. To sign zones, OpenDNSSEC is the most widely used tool, but there are others, including dnssec-signzone which is part of BIND. Lastly, there are a number of utilities for querying and debugging DNSSEC installations (e.g. dig and drill) that can be found by doing a package manager search for "dnssec".

Using DNSSEC for name resolution on Fedora or RHEL is very simple, Wouters said. Installing BIND or Unbound using yum, then doing:

    echo "nameserver 127.0.0.1" >/etc/resolv.conf

In some ways, DNSSEC is too good because it blocks operations like hotspot authentication. The system needs to "know when to accept lies" in DNS answers, he said. There are also problems with VPNs when there are two different views of the DNS namespace (i.e. a VPN-internal view and the external view). Additionally, problems occur because so many different applications "mess with resolv.conf". Those problems all need to be addressed at once.

Some recent changes to NetworkManager have been made to help with the hotspot problem. The new dnssec-triggerd daemon can be used to detect hotspots and inform NetworkManager, which will ask the user if they are logging into a hotspot. If so, NetworkManager will change resolv.conf to temporarily bypass the local DNSSEC-enabled resolver, allow the user to log in, then re-enable DNSSEC resolution.

Unfortunately, many hotspots also hijack the traffic they carry. That means that the DNSSEC resolver may not get clean responses even after the authentication dance. For example, some will filter out signatures, while others block the DNS port (53) to force users to their (generally non-DNSSEC) name servers. There are workarounds that dnssec-triggerd will try (e.g. running DNS over port 80 to suitably configured servers), but there will be situations where getting DNSSEC responses is not possible. In that case, NetworkManager asks the user if they want to disable DNS or run in insecure mode. Dan Walsh pointed out that some organizations may want to remove that choice, so that users cannot run with regular DNS. Wouters said that can be configured for those who need it.

VPNs are another problem because there is a need to use internal IP addresses. To handle that, VPN clients often rewrite the resolv.conf file, but Fedora has removed that ability from the Openswan client. Instead, Openswan informs the resolver, which adds entries for the internal DNS server. Once the VPN link is shut down, the resolver removes that information.

For signing your own DNSSEC zones, he recommends the OpenDNSSEC package. It has tools to automatically re-sign zones when they are about to expire and there are systemd unit files available to control the signing daemon. Overall, OpenDNSSEC is "working pretty well" for handling all of the signing chores, he said.

Converting applications

The standard gethostbyname() call that is used to look up host names from programs does not return DNSSEC information (e.g. whether the answer was secure or not), so programs that are going to use DNSSEC need to be changed. Wouters did that conversion for Openswan using libunbound.

The changes are fairly straightforward, and he shows much of the code in his slides [PDF]. A DNSSEC cache context is established at program start, and populated with information from /etc/hosts and /etc/resolv.conf, as well as with keys for the root zone. It then makes synchronous calls to ub_resolve() whenever a host name lookup is needed, returning an error if the reply is not secure.

The conversion was "not rocket science", he said. There are other alternatives, but he liked the libunbound interface. It supports both callbacks and threads for asynchronous resolution. In addition, it has good tutorials.

There are several RFCs and draft RFCs for publishing data using the DNSSEC infrastructure. For example, HTTPS certificates, SSH known_hosts keys, IPsec public keys, PGP email keys, and others are all possibilities for being distributed via DNSSEC. He had some other thoughts, including file hashes (for file integrity checking), SELinux policies, and even a secure Twitter-like text publishing scheme. There are many different options, Wouters said, and once DNSSEC becomes pervasive, there is lots of fun to be had.