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
-
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.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.