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
News
-
Mageia 9 Beta 2 is Ready for Testing
The latest beta of the popular Mageia distribution now includes the latest kernel and plenty of updated applications.
-
KDE Plasma 6 Looks to Bring Basic HDR Support
The KWin piece of KDE Plasma now has HDR support and color management geared for the 6.0 release.
-
Bodhi Linux 7.0 Beta Ready for Testing
The latest iteration of the Bohdi Linux distribution is now available for those who want to experience what's in store and for testing purposes.
-
Changes Coming to Ubuntu PPA Usage
The way you manage Personal Package Archives will be changing with the release of Ubuntu 23.10.
-
AlmaLinux 9.2 Now Available for Download
AlmaLinux has been released and provides a free alternative to upstream Red Hat Enterprise Linux.
-
An Immutable Version of Fedora Is Under Consideration
For anyone who's a fan of using immutable versions of Linux, the Fedora team is currently considering adding a new spin called Fedora Onyx.
-
New Release of Br OS Includes ChatGPT Integration
Br OS 23.04 is now available and is geared specifically toward web content creation.
-
Command-Line Only Peropesis 2.1 Available Now
The latest iteration of Peropesis has been released with plenty of updates and introduces new software development tools.
-
TUXEDO Computers Announces InfinityBook Pro 14
With the new generation of their popular InfinityBook Pro 14, TUXEDO upgrades its ultra-mobile, powerful business laptop with some impressive specs.
-
Linux Kernel 6.3 Release Includes Interesting Features
Although it's not a Long Term Release candidate, Linux 6.3 includes features that will benefit end users.