O DNS and Encryption TSIG and DNSSEC

Recent updates to the DNS specification involve the use of DNS for solving the open issues of hijacking, poisoning, and securing zone transfers.

We mentioned how zone transfers can be restricted to trusted peers, but due to the possibly sensitive nature of your zone information, Transaction SIGnature (TSIG, RFC 2845) was created. TSIG enables you to authenticate, using a stronger method than simple IP address matching, clients that are allowed to update your dynamic database.

TSIG works by signing the DNS messages with a message digest computed using a shared secret between the sender and the receiver. The function used is 128-bit HMAC-MD5.

Here's an example of TSIG usage for securing the zone transfer between a master and slave server. We use the example name tsigkey-domain.com for the key:

$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST tsigkey-ourdomain.com.

This results in two files being created:

• Ktsigkey-ourdomain.com.+157+54730.key

• Ktsigkey-ourdomain.com.+157+54730.private

$ cat Ktsigkey-ourdomain.com.+157+54730.key tsigkey-ourdomain.com. IN KEY 512 3 157 hiYDa6iDNpPmGPkgtofRww==

The generated key can be specified in your configuration using the key statement:

key tsigkey-ourdomain.com. { algorithm hmac-md5;

secret "hiYDa6iDNpPmGPkgtofRww==";

You can then enforce signing of all DNS traffic to a specific server with the server and key statements:

Finally, on the master server, zone transfer can be restricted to signing peers:

zone "ourdomain.com" { type master; file "ourdomain.com"; allow-query { any; };

allow-transfer { key tsigkey-ourdomain.com.; };

TSIG is a simple mechanism and because of that it has some downsides. You have to manually distribute the keys across servers, which is not a scalable solution. Also, no levels of authority exist and it's not as flexible as public key cryptography.

For addressing these issues, the DNSSEC protocol has been proposed (DNS Security Extensions, RFC 4033/4034/4035). This protocol involves using public key cryptography for signing zone files. Basically, a public key is published using a dedicated DNSKEY record, secured records are signed with the related private key (which is kept private on the signing server), and the signature is stored in a Resource Record Signature (RRSIG). This allows zones to be freely validated by any other peer against the published public key.

Using public key signing also allows upper-level validation that a private/public key pair is authorized for that domain. This is done by having the public key signed by the upper-level domain authority (which would validate your identity through other, usually social, means). A Delegation Signature (DS) record stored on the upper-level authoritative domain server can be used to accomplish this. For instance, the DS record for 'ourdomain.com' would be stored in the parent com' zone file.

DNSSEC is a complex protocol that has undergone many reimplementations in the last few years and was very recently completely redesigned. It will be a few years until it stabilizes enough to be widely adopted, and for this reason, discussing it in detail at this date doesn't make much sense.

Because of the impossibility of signing a generic negative query, the use of Next Secure (NSEC) records is involved in DNSSEC for explicitly publishing which records exist in a zone file. This information is used for having an authoritative denial of existence. In other words, rather than getting a negative reply for a certain query, you get a listing of available records in the range of your query (using a canonical sorting order), which can be matched against your request.

In this example, you can see a NSEC record advertising that between alpha. ourdomain.com and delta.ourdomain.com there are no other domains. This would be the reply if you asked for beta.ourdomain.com:

alpha.ourdomain.com. 86400 IN NSEC delta.ourdomain.com (

A MX RRSIG NSEC TYPE1234 )

As you can see, this allows anyone to evaluate the contents of your zones. For this reason, when using DNSSEC, you should treat all the information in your public zones as easily retrievable, even without explicit queries.

An NSEC3 proposal is being discussed by the IETF for solving this issue. You can find more information at http://dnssec.org and http://nsec3.org.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook


Post a comment