Trusted name resolution with DNSSEC
Chains of Trust
DNSSEC uses asymmetric key pairs – that is, pairs of private keys and public keys. The two-element system was devised by IETF (Internet Engineering Task Force) architects. A Zone Signing Key (ZSK) protects the individual RRs in a zone file and, in turn, is protected by the Key Signing Key (KSK) (see Figure 2).
Inside a zone, it is sufficient to know the public KSK to validate the ZSK and then the RRs. Between a parent and a child zone, DNSSEC uses a delegation signer RR (DS-RR). At the top of the chain of trust is a KSK, which specifies the SEP, or Trusted Anchor, and designates the zone hierarchy below it as a secure island. Adding these SEPs to the DNSSEC server configuration is the responsibility of an organization's admin.
To do so, the admin enters the KSKs for the secure islands to be supported to the trusted-keys section of the named.conf file (see Listing 1). The hierarchy should use the highest possible KSKs available and make sure that the keys were transferred in a trustworthy manner. The zone names are followed by three fields. The Flags field defines the key type; 256 stands for ZSK and 257 for KSK. The second value is the Protocol field, which must contain a 3, in line with RFC 4034. The third value specifies the algorithm used, with 5 standing for RSA/SHA-1.
Listing 1
DNS Config for SEPs
Client or Server?
The standard scenario uses a DNS server as the resolver on the local network that queries a forwarder on the provider's network. The DNS server validates the responses it receives from the provider-side DNS server. To be able to do so, the administrator first must enable DNSSEC. As of version 9.4.2, ISC recommends a BIND server. Enabling DNSSEC when building the program is imperative. Most distributions offer this option as part of their bind9 packages. The dnssec-tools are useful for testing and debugging but are not necessary to run the system [4].
The dnssec-enable yes; option in the named.conf configuration file generically enables DNSSEC functionality. If at least one trusted key is defined as a SEP, you just need to reload named; the resolver in this example would validate the example.com and tux.local zones, as well as any zones below them in the chain of trust (e.g., branch1.example.com).
Signing a Zone
Name server operators first must generate and set up key pairs for their domains and zones, starting with ZSKs and KSKs on the primary domain server to sign the individual zone records. Authoritative zone servers must be enabled by setting dnssec-enable yes; for DNSSEC. The following command issued on the primary name server creates a key pair for the example.com zone:
dnssec-keygen -a RSASHA1 -b 2048 -n ZONE example.com
The -a option specifies the algorithms RSA and SHA1. Although the developers typically recommend RSA with SHA-1, you can specify other algorithms, such as DSA or RSA/MD5.
The -b parameter specifies the key length, and -n is followed by the record owner, which is ZONE for a zone; however I will ignore other records (i.e., HOST, ENTITY, USER) for the purposes of this article.
The newly created key serves as the ZSK. To create a matching KSK, you need to add the -f KSK option to the command. This results in a file called Kexample.net.+005+18553, which is a concatenation of K for the KSK, the domain name, the encryption and hash algorithms, and a randomly generated key ID separated by plus characters. The algorithm designators are 1 for RSA/MD5, 3 for DSA, and 5 for RSA/SHA-1.
After generating the keys, listing the current directory should reveal the public key with its .key file extension and the private key with a suffix of .private. Now the public key (see Listing 2) can be added to the zone file with the $include directive, as shown in Listing 3.
Listing 2
Key Entry for a Zone File
Listing 3
Zone File Before Signing
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.