DNSSEC: What Is It Good For?

Securing DNS: DNSSEC is no silver bullet for your DNS security concerns, but it can solve a few potential problems, and that's better than nothing.

 By Charlie Schluting
Page of   |  Back to Page 1
Print Article

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.

This article was originally published on Apr 2, 2005
Get the Latest Scoop with Networking Update Newsletter