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
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
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
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
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
is all that's needed. DNSSEC has been in the default configuration since
Fedora 15. But, he cautioned, you probably shouldn't do that, at least on a
laptop, because you depend on spoofed DNS all the time.
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.
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
[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.
to post comments)