DNSSEC validation on BIND named
BIND named, the most widely used DNS server software, can function as an (authoritative) name server and/or as a (caching) resolver. This article deals looks at the configuration of named as a DNSSEC-validating resolver. This signing of a zone on an authoritative name server is dealt with in a separate article.
Because so many legacy BIND implementations are in use — some of which have been running for years — when explaining each feature, we have wherever possible stated the version in which it was first made available. We nevertheless recommend using the most recent version of BIND that you can, if for no other reason than that each successive version has bug-fixes and security-fixes absent from the earlier versions.
dnssec-enable yes; dnssec-validation auto; //dnssec-lookaside auto;
It's important to note that the 'dnssec-enable' option needs to be set to 'yes' not only to enable digital signature (RRSIG record) generation on an authoritative DNS server, but also to enable DNSSEC validation on a server that operates exclusively as a resolver.
The 'auto' option is available for the other two statements from BIND version 9.7.0, which also introduced support for RFC 5011. In earlier versions, the only options are 'yes' and 'no'. The versions in question support only static trust anchors specified in a 'trusted-keys' statement.
Dynamic Lookaside Validation
The 'dnssec-lookaside' option is used to configure Dynamic Lookaside Validation (DLV), an ISC service that dates from before the root zone was signed. In that period, operators who wanted to sign their domains but couldn't construct continuous chains of trust to the root zone could lodge partial DNS trees ('islands of trust') with the dlv.isc.org domain, which had its own BIND trust anchor.
However, the signing of the root made the DLV service redundant, and it was withdrawn in September 2017.
From version 9.7.0, BIND saves its trust anchors in the managed key database (in the managed-keys.bind file, or, from version 9.8.0, in an .mkeys file for each view). In a one-off procedure, the database is initialised with the trust anchors specified in the 'managed-keys' statement ('initial-key'). If no such statement is present, BIND falls back on the external 'bindkeys-file' (default: bind.keys) for the keys that are hard-coded into the software.
BIND performs the initialisation only when the resolver is started for the first time and if the managed key database is empty. This 'bootstrap' procedure ensures that the current trust anchors are fetched from the internet, validated and installed. Thereafter, the trust anchors in the managed key database are managed automatically (in band) on the basis of RFC 5011.
Root KSK rollover
At the time of writing (spring 2018), we are midway through a rollover process for the root zone's KSK pair. In other words, ICANN, the root zone's administrator, is in the process of replacing the existing cryptographic key pair that forms the basis for the entire DNSSEC infrastructure (KSK-2010) with a new key pair (KSK-2017).
The rollover itself was to have taken place on 11 October 2017, but has recently been postponed. A new date has yet to be announced, but validating resolver operators are being urged to update their systems as a matter of urgency, if they haven't already done so.
New trust anchor
That implies checking that the new public root KSK has indeed been installed and activated on their systems as a trust anchor. The reason being that, as soon as the rollover proper takes place, any digital signatures based on the old KSK-2010 key pair will cease to be valid. Consequently, any validating resolver that doesn't have the new trust anchor installed will be unable to verify the signatures attached to DNS records, making all domain names unreachable for people and applications that rely on the resolver in question.
The most important aspects of the new KSK-2017 trust anchor's installation in the various versions of BIND are set out below. For additional detail, refer to the articles mentioned above, which also include more specific information about the configuration of BIND.
KSK-2017 trust anchor supplied with software from April 2017 (versions 9.9.10, 9.10.5, 9.11.1 and later)
Support for RFC 5011 from version 9.7.0 (initialisation using 'managed-keys')
Manual installation from version 9.6.2 (static trust anchors from 'trusted-keys')
From BIND version 9.11.0, you can check out the contents of the managed key database using the following command:
rndc managed-keys status
In older versions (from 9.9.3), the script contrib/check5011.pl provides similar functionality.
The output is a list of trust anchors (per view):
[root@system ~]# rndc managed-keys status view: resolver next scheduled event: Tue, 03 Oct 2017 15:29:38 GMT name: . keyid: 19036 algorithm: RSASHA256 flags: SEP next refresh: Tue, 03 Oct 2017 15:29:38 GMT trusted since: Mon, 28 Dec 2015 20:05:54 GMT keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Tue, 03 Oct 2017 15:29:38 GMT trusted since: Thu, 10 Aug 2017 16:21:39 GMT
The command 'rndc secroots -' (from version 9.7.2) is used to obtain a list ('dump') of both the managed keys and the static and negative trust anchors (again per view):
[root@system ~]# rndc secroots - secure roots as of 11-Apr-2018 13:24:11.522: Start view localhost_resolver Secure roots: ./RSASHA256/20326 ; managed ./RSASHA256/19036 ; managed Negative trust anchors: Start view internal Secure roots: ./RSASHA256/20326 ; managed ./RSASHA256/19036 ; managed Negative trust anchors: Start view external Secure roots: ./RSASHA256/20326 ; managed ./RSASHA256/19036 ; managed Negative trust anchors:
If the KSK-2017 trust anchor, whose key ID is 20326, isn't listed (with the status 'managed' or 'trusted'), you'll need to refer to the detailed information about the root KSK rollover published by ISC (BIND named's developer).
Negative trust anchors
To set a negative trust anchor — a domain for which validation is disabled, as specified in RFC 7646 — you need to use the command 'rndc nta' (from BIND version 9.11.0). The negative trust anchor functionality is intended mainly so that validation errors involving incorrectly configured ('bogus') domains can be (temporarily) disregarded.
Old configuration files
When checking the version of an existing BIND installation ('named -v'), make sure that the configuration file used (/etc/named.conf) is up to date. If a DNS server was set up some time ago, and the software has since been upgraded to a more recent version by system updates, the configuration will often remain based on an earlier version. In that case, the best approach is to upgrade the configuration to the current version of BIND before setting up DNSSEC. On RHEL/CentOS and Fedora, the templates supplied for named.conf can be found in the directory /usr/share/doc/bind(-version)/sample/etc/. However, the template at that location is also now somewhat outdated.
From version 9.10, you can check the current status of validation by the resolver using the command 'rndc validation check':
[root@system ~]# rndc validation check DNSSEC validation is enabled (view localhost_resolver)
Finally, there is the command for remotely checking that your validating resolver is working properly (replace <ADDRESS> with the name or address of the server):
dig @ADRES servfail.nl
If your resolver is validating, the response to that command will be the status message SERVFAIL, because, as the domain name indicates, the command deliberately involves a bogus DNSSEC chain of trust. A non-validating server won't check for a digital signature and will therefore return the status NOERROR.
If and when new DNSSEC functionality is added to BIND, we will update this article accordingly.