DNSSEC: What Is It Good For?

DNSSEC, which stands for DNS Security
Extensions, is a method by which DNS servers can verify that DNS data
is coming from the correct place, and that the response is
unadulterated. In this article we will discuss what DNSSEC can and
cannot do, and then show a simple ISC Bind 9.3.x configuration example.

DNSSEC is a public/private key system. This means that the owner of
a DNS zone has a private key and a public key. Using the private key to
digitally sign a zone will allow anyone with the zone’s public key to
verify that the data is authentic. Be very careful with your private key: If an attacker can intercept it, the entire zone is compromised, so sending keys via email
or other Internet vehicles probably isn’t a good idea.

There also exists a problem with other DNS servers getting your public key securely. If someone were to intercept the transmission, and replace your public key with a new one, a sufficiently motivated attacker could take over your DNS zone. This would require effectively replacing your DNS server, but that isn’t too difficult – they have already overcome the hard part. If other DNS servers have the new key, they will trust the malicious data signed by the attacker’s private key.

The proposed solution to the basic key management problem is to
have Network Solutions sign everyone’s public key. For example;
myname.com will create a key, sign it, and then send it to Network
Solutions for signing. DNS servers around the world who have Network
Solutions’ key are now able to reject DNS records about myname.com that
aren’t accompanied by the appropriate signatures.

This is the proposed method for global DNSSEC. It hasn’t
happened. There is no Network Solutions key that everyone knows, and
Network Solutions has no mechanism to gather *.com keys. The highest
level domain, ‘.’ (dot), also needs to be under some administrative
control. IANA or ICANN can hold this key, and sign all TLD’s (.com,
.org, etc), but the political mess this would create puts the
implementation a long ways off. Whether the U.S. holds the key to the
entire Internet or not, someone must before DNSSEC can work globally.
Until this is in place, DNSSEC cannot protect anything outside your
administrative control or access; meaning you have to manually
distribute keys.

DNSSEC cannot currently verify information for zones which you do
not control. For DNS servers to trust data, they must know the other
server’s public key, or the key of another zone above it in the DNS
tree. As discussed before, that will stop at com (for .com DNS names),
since there is no system currently in place.

DNSSEC can, however, be used internally or even between different
entities if they chose to cooperate and exchange keys. This will
provide a mechanism to verify the data came from the right place, and
it was unaltered during transit.

Also important to note, is that DNSSEC cannot currently help with
DNS cache poisoning either. DNSSEC provides authenticated denial of
existence, but this requires the non-existent global cooperation. We’ll deal with the problem of DNS caches next week.

Create DNSSEC Keys and Configure a Zone

As alluded to before, DNSSEC can be useful. Let’s look at an
example of how to set up keys and configure a zone. A different DNS
server that knows your public key can then trust the signed DNS data it
receives. How to securely get the key to other DNS servers is left as
an exercise for the reader. I suggest AOL-style CDROMs, mailed to
everyone you think will want to use your key.

Bind 9.3.x provides some tools in the form of executable programs
that make configuring DNSSEC easy, once you know what needs to be done.
The first step is to generate keys. The keys will be used to digitally
sign all DNS records in a zone, along with any secure delegated zones.
The Bind manual suggests using the cryptographic algorithm which the
IETF states is “mandatory to implement,” currently RSA SHA1. This will
provide the best chance of interoperation with other DNS servers. To
generate keys:

dnssec-keygen a RSASHA1 b 768 n ZONE my.domain.com

The options specify, in order: algorithm, size of key to use, the
owner type of the key, and the zone name. This will create the key
files, which need to be added to the zone’s configuration file. You can
use
$INCLUDE <filename>
as the manual recommends, but I find it better to just paste the KEY
record into the zone file. This not only looks really cool, but serves
as a reminder every time you use this zone file.

The next step is to actually sign the zone. Using dnssec-signzone:

dnssec-signzone [-o origin] my.domain.com

The origin is assumed to be the same as the zone file if you omit
the o option. The result of this command is a my.domain.com.signed
file. This is the file you now use for the zone inside named.conf:

zone "my.domain.com" { type master; file
"pri/my.domain.com.signed"; };

The dnssec-signzone command also produces a
.keyset file. These are the keys you would give to a parent zone, if
you have access to it as well. Some day, as optimists believe, we will
be giving these to a central authority.

The final step in making two servers speak to each other, is to
tell them about foreign public keys, since we can’t count on a common
root domain having them. In named.conf:

key other.differentdomain.com {
algorithm rsa-sha1;
secret "***************************";
};

The public key from a parent server would also be included in
named.conf’s trusted-keys statement. This can be used when the parent
of both zones doesn’t support DNSSEC, so the key cannot be obtained
securely via DNS. The root key would also have to be manually
configured, since there is nothing above it in the DNS tree. If a zone,
for example domain.com, is configured with a trusted-key, then Bind
will attempt DNSSEC validation of all DNS data for any subdomains of
that zone.

DNSSEC is really a great idea. There are even a few DNS servers
that have implemented it. Unfortunately, it relies on a public/private
key system, and that type of system typically doesn’t scale
Internet-wide. ISC’s Bind also supports transaction signatures, which
needs key pairs as well. It would be great to see DNSSEC usable on the
entire Internet, but there will likely be many different security
options for DNS implemented before a keeper is found.

Latest Articles

Follow Us On Social Media

Explore More