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.
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.
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 . 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 firstname.lastname@example.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.
Buy this article as PDF
Linux Magazine will include the best of both magazines.
Popular open source encryption tool is vulnerable to attack
New “Yakkety Yak” edition emphasizes cloud and servers
Google finally enters the phone hardware business.
Innovative system adds a hard drive and Ubuntu Core to the RPi for an IoT hub.
Linux is two weeks younger than we thought!
The Apache Software Foundation considers retiring OpenOffice
Adobe won’t kill the plugin in 2017
Linux Foundation's big event celebrates the 25th anniversary of Linux