Trusted name resolution with DNSSEC

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.

Listing 4

Signed Zone File

01 ; File written on Wed Nov 20 17:02:12 2007
02   ; dnssec\_signzone version 9.4.1
03   example.com.  100  IN SOA  ns.example.com. admin.example.com. (
04                              2007112001 ; serial
05                              100        ; refresh (1 minute 40 seconds)
06                              200        ; retry (3 minutes 20 seconds)
07                              604800     ; expire (1 week)
08                              100        ; minimum (1 minute 40 seconds)
09                              )
10                 100  RRSIG   SOA 5 2 100 20070429180412 (
11                              20070330180412 17000 example.com.
12                              Q7QT/Y3MhD9Zx6/...= )
13                 100  NS      ns.example.com.
14                 100  RRSIG   NS 5 2 100 20070429180412 (
15                              20070330180412 17000 example.com.
16                              k4Dy4YRfMwTUsKt...= )
17                 100  NSEC    a.example.com. NS SOA RRSIG NSEC DNSKEY
18                 100  RRSIG   NSEC 5 2 100 20070429180412 (
19                              20070330180412 17000 example.com.
20                              fEnDtTdDyYrC7Dq...= )
21                 100  DNSKEY  256 3 5 (
22                              AQPI4+0M1V055RS...=
23                              ) ; key id = 18553
24                 100  DNSKEY  257 3 5 (
25                              AQOzgs4qea+ImJ1...
26                              ) ; key id = 42209
27                 100  RRSIG   DNSKEY 5 2 100 20070429180412 (
28                              20070330180412 17000 example.com.
29                              hFcUzcQnsQbiOhn...= )
30                 100  RRSIG   DNSKEY 5 2 100 20070429180412 (
31                              20070330180412 49656 example.com.
32                              oyum/nlrNZ7Xdxi...= )
33 a.example.net.  100  IN A    192.168.0.1
34                 100  RRSIG   A 5 3 100 20070429180412 (
35                              20070330180412 17000 example.com.
36                              oN1QemG7B47dWBo...= )
37                 100  NSEC    b.example.net. A RRSIG NSEC
38                 100  RRSIG   NSEC 5 4 100 20070429180412 (
39                              20070330180412 17000 example.com.
40                              Kon6z25uqnHpGc9...= )
41 b.example.net.  100  IN A    192.168.0.2
42                 100  RRSIG   A 5 3 100 20070429180412 (
43                              20070330180412 17000 example.com.
44                              lWXfx2ebTpOBvCx...= )

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.

Read full article as PDF:

064-069_dns-sec.pdf  (690.33 kB)

Related content

  • Security Lessons: DNSSEC

    One of the largest holes in the Internet is finally plugged.

  • Charly's Column: Nameserver Diagnostics

    Many administrators rely on Linux tools whose fate is already sealed, but external forces can help people let go of old habits.

  • Security Lessons: DNS Security

    Kurt describes how to keep bad guys out of your network using a targeted filtering approach.

  • Bind 10 Test Drive

    Admins have waited all of five years for the 10th major release of the Bind name server, which appeared at the end of March this year. The latest release is a complete rewrite of the DNS server, with a modular design and new configuration tools, but is it ready for business?

  • DIC: Domain Name Registries to Promote DNSSEC

    The DNSSEC Industry Coalition (DIC) was founded in the U.S. with the goal to drive further development and acceptance of the DNSSEC security protocol. The consortium includes a half dozen top Domain Name Registries and software developers that are currently laying out an action plan.

comments powered by Disqus

Direct Download

Read full article as PDF:

064-069_dns-sec.pdf  (690.33 kB)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia