Guidance for DNSSEC-validating resolver operators
Advice on trust anchors, negative trust anchors and system time updated
An old Internet Draft for the operators of validating resolvers has recently been updated. The 'Recommendations for DNSSEC Resolvers Operators' have been under development for nearly 10 years, but have still not attained RFC status.
Nevertheless, because the document contains a lot of useful guidance, whose importance is set to increase as the new root KSK rollover approaches, we have decided to publish an article covering the main points, without waiting for the Draft's formal publication as an RFC.
A large proportion of the Draft relates to the management of trust anchors for DNSSEC, including both 'ordinary' trust anchors and negative trust anchors (NTAs). According to the authors, that is because validation problems are caused by resolver and name server operators or by bugs more often than by attacks.
System time
However, the Draft starts by stressing the importance of accurate system time. A detailed explanation of why accurate system time is so important for DNSSEC (and other security protocols) is provided in one of our earlier articles. In the specific context of DNSSEC, the key point is that the digital signatures (in the RRSIG records) have a finite (absolute) validity period. Consequently, they cannot be validated if the system time is not set correctly.
That is a problem mainly for devices that don't have an inbuilt real-time clock (RTC) – the Raspberry Pi, for example. Such devices have to obtain a time check from the network each time they start up (using NTP/NTS [1, 2]).
The only workable solution is automation by means of NTP/NTS, but then you still have the bootstrap problem: the device's unsynchronised system time on startup will be wrong (the date may be 1 January 1970, for example), making it impossible to validate digital signatures when obtaining a time check from the internet.
Consequently, you have to choose between 2 'evils': use a hard IP address or make a non-validated call to an NTP server. Moreover, a validating resolver will always be unable to start up until the correct system time is available. Without the correct time, not only would it be impossible to validate current signatures, but an attacker would be able to mount a replay attack where expired signatures are re-used, for example.
As well as addressing such initialisation challenges, an operator also needs to keep checking that the system time is sufficiently accurate.
DNSSEC trust anchors
As with the system time, there is a bootstrap problem with initialisation of the DNSSEC trust anchor (the public key of the root zone, which forms the starting point of the DNSSEC chain of trust). Although a detailed procedure and tooling are available for downloading and validating the trust anchor from the IANA website, it is generally used only by software developers and packagers. Operators tend to rely on the trust anchor coded into the software itself or provided with the package. The advantage of that is that they can assume that the trust anchors are up to date, providing that the software is up to date.
When initialising a resolver, an operator should nevertheless confirm that the trust anchor in use is the right one. However, the software itself will often have mechanisms for checking the validity of its initial trust anchors on startup.
If you instal separate trust anchors, e.g. for use within your own (non-public) domain example.home (a trust point outside the DNSSEC tree), you will need to devise your own procedures for validating those anchors.
Automatic updates
Trust anchor updating (required whenever there is a root KSK pair rollover, as in 2018) is nowadays normally a fully automated procedure, as defined in RFC 5011. It involves fetching the new public key (in the form of a DNSKEY record), and validating it by reference to the existing (old) DNSSEC chain of trust.
Although updating in accordance with RFC 5011 is a fully automated process, an operator should confirm that auto-updates are enabled in the configuration and that the configured timing parameters are correct. It's also good practice for an operator to regularly check that the trust anchors in use are indeed the right ones. That's particularly important following a reboot.
The automated validation process for initial/new trust anchors involves a particular problem for resolvers in containers. Such resolvers are often not 'up' for long enough to complete the entire validation process, which can go on for weeks.
Checking the current trust anchors
The current trust anchors can usually be checked by sending a simple command or query to the relevant server. For the Unbound resolver, the dialogue is as follows:
[user@system ~]$ dig @127.0.0.1 trustanchor.unbound -c CH -t TXT +short ". 20326"
With BIND named, the following command can be used to dump the current trust anchor:
rndc secroots
You will then find a list such as the following in the file '/var/named/data/named.secroots':
secure roots as of 11-Mar-2023 18:12:41.458: Start view localhost_resolver Secure roots: ./RSASHA256/20326 ; managed Negative trust anchors: Start view internal Secure roots: ./RSASHA256/20326 ; managed Negative trust anchors: Start view external Secure roots: ./RSASHA256/20326 ; managed Negative trust anchors:
The Draft also advises operators to enable signalling in accordance with RFC 8145. That enables the root server operators to monitor the progress of rollovers by referring to the key IDs of current trust anchors.
Naturally, logs of all events associated with resolver initialisation and trust anchor rollovers need to be generated, and an alert should be generated if initialisation or a rollover ever goes wrong for any reason. The main problem that can arise is that the current trust anchor is missing, causing valid, signed domain names to be rejected.
Negative trust anchors
If resolution of a domain fails because of an issue on the authoritative side, a (temporary) validation exception can be made by adding a negative trust anchor to the configuration. Of course, before doing so, one should always check whether the problem really is a misconfiguration, as opposed to an attack.
Although a resolver operator is not obliged to help overcome problems with an authoritative name server, we recommend making contact before adding a problematic domain name as an NTA (partly because the problem could be due to an attack). Never add NTAs automatically wherever there is a problem!
Most configuration problems are down to issues with the signing of DNSKEY/DS records or inconsistencies in the ZSK/KSK pairs used. In the latter scenario, which often results from failure to adhere to the timing periods during a rollover, it is inadvisable to attempt to realise a solution on the authoritative side (e.g. by searching for valid DNSSEC records) because of the complexity of that side. After all, a resolver operator generally has no control whatsoever over configuration problems associated with a given domain, and often no direct (out-of-band) point of contact with the operator in question.
For more information about NTAs, see RFC 7646.
Root KSK rollover
The pertinence of the considerations set out in this article is set to increase in the period ahead, since ICANN began preparations for the next root KSK rollover earlier this month.
Preparations are also in progress for transition to a new cryptographic algorithm. Last month, SIDN Labs Research Engineer Moritz Müller was appointed to the Root Zone Algorithm Rollover Study Design Team, which has responsibility for developing plans for the transition.
The switch to a new cryptographic algorithm will probably be entirely separate from the upcoming 'regular' rollover. By this summer, we are expecting only a recommendation regarding the algorithm to be adopted.