Binding Keys to Zones

After completing this, the zone can be signed by issuing a dnssec-signzone command, modified as follows:

dnssec-signzone -o example.com -k Kexample.com.+005+42209 example.com.zone Kexample.com.005+42209

The -k option specifies the KSK.

The program now sorts the zone records, adds NSEC records, signs DNSKEY RRs with the use of ZSK and KSK, and then uses the ZSK to sign the other records. On top of this, the program creates two new files: dsset-example.com and keyset-example.com. The new files have an extension of .signed. The resulting zone records are shown in detail in Listing 4, although the keys are curtailed to save space.

One RRSIG record for each of the original zone records is signed by the private ZSK. The server publishes the two public keys, the ZSK (256) and the KSK (257), in the DNSKEY RR. The key pairs sign each other reciprocally here, and the ZSK is used for all other signatures.

To prevent unauthorized removal of a zone record, the sorted RRs are linked to form a chain. Ironically, the NSEC RR is one of the biggest obstacles to more widespread coverage by DNSSEC. Some critics say that this leads to data protection problems because attackers can just query the chain to learn all the records in a zone in what is known as "zone walking."

After reloading the zone files, the server returns DNS responses with its own signatures. Zone signatures are valid for 30 days by default, but with the -e YYYYMMDDHHMMSS option, you can modify the validity period. After doing so, it is important to resign the zone manually or periodically with a script by calling dnssec-signzone with the required options. If you add entries to or remove entries from a zone, you must resign.

After saving the parent zone, it is possible to establish a chain of trust to extend protection to the child zones. A resolver can use a DS-RR to reference the delegated zone. A hash value in this record signs the KSK in the child zone.

Gaining Trust

The signature procedure uses dnssec-signzone to create two files: dsset-example.com and keyset-example.com. The administrator in the subordinate zone must send at least one of the two to the administrator in the parent zone. The DS set in dsset-example.com already contains a corresponding DS-RR for the parent's zone file.

After the administrator has run dnssec-signzone for the child zone branch1.example.com, a line like the following is added to the file:

branch1.example.com. IN DS 18890 1 1 AE9882AD0F80C91663A1ADE3742B2BF2403A7283

In contrast, the key set in the keyset-branch1.example.com file has the DNSKEY zone file record for the KSK in the child zone.

This means that the admininistrator in the parent zone can set up the DS record by storing the key in a file with a keyset-child prefix; in this case, it would be keyset-child-filiale1.example.com.

All the files are stored in the zone file directory. Once the new files are in place, the provider needs to resign the parent zone to enable the links. Adding the -d option tells dnssec-signzone to create the corresponding DS record. As an alternative, you can $include the DS set and sign the parent's zone file.

Once the DS record has signed the KSK in the branch1.example.com child zone, and assuming a DNSSEC-enabled resolver has the parent KSK as a SEP, the resolver will now validate both the parent and the child zone. This validation can also occur for any other subordinate zones.

If the parent zone is not secure, you can validate your own KSK through a DNSSEC Lookaside Validation (DLV) registry. ISC itself runs a DLV registry [5]. Administrators wanting to submit the KSK in their zones to the DLV registry would use the -l option and specify an address:

dnssec-signzone -l dlv.isc.org -o example.com -k Kexample.com.+005+42209 example.com.zone Kexample.net.+005+18553

This call writes the dlvset-example.com file, which the admin then mails to dlv-registry@isc.org along with the domain name and the administrator's name.

After the DLV registrar has verified the entry, a DS record that points to the applicant's zone is created. This means that the name server run by ISC is a useful SEP as long as you trust the company and its authentication processes.

To Be, or Not to Be?

DNSSEC is no panacea, but is can be a useful extension if you want to make sure that your communications partners are legitimate. Obviously, this is the case with things like online shopping and banking, but also if you need to transfer confidential data between computers that use DNS to locate each other and thus rely on name resolution.

On the client side, local clients typically do not support the protocol; therefore, widespread implementation of DNSSEC is prevented. Clients tend to rely on a local DNS server with this ability, and this is unlikely to change in the near future.

In highly sensitive environments, the use of DNSSEC on both local networks and the backbone is highly recommended. DNSSEC is used in healthcare scenarios, in which it authenticates communications partners such as doctors, pharmacists, and health insurance companies.