| Internet-Draft | DRO Recommendations | June 2023 |
| Migault, et al. | Expires 12 December 2023 | [Page] |
The DNS Security Extensions (DNSSEC) defines a process for validating received data and assert them authentic and complete as opposed to forged.¶
This document provides recommendations for DNSSEC Resolver Operators (DRO) to operate a DNSSEC resolver.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 December 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A DNS resolver is a service that locates and returns information pertaining to a query issued by some other service, such as an application. By its nature, a DNS resolver is inquisitive, susceptible to misleading information it may receive. To address this, DNS Security (DNSSEC) extensions [RFC9364] were defined to provide authenticity and integrity to responses, as well as to provide an authenticated notice for data that does not exist.¶
A DNS resolver operator is an organization or individual that runs a DNS resolver. The resolver may be for a small set of relying parties, for a large but bounded collection of customers, or it may be operated with no restriction on who or what may make use of it. To enhance the value of the service, a DNS resolver operator implements various security controls, including the use of DNSSEC validation. For the sake of this document, the term DNSSEC Resolver Operator (DRO) is defined as the responsible operator of a DNS resolver that makes use of DNSSEC validation.¶
Operating DNSSEC validation involves making use of digital signatures generated by a DNSSEC signer. Besides the simple cryptographic process of validating digital signatures there are a number of checks required due to the nature of the DNS protocol. A well-written DNSSEC validating resolver will faithfully implement the DNSSEC processes needed, leaving an operator to manage a few items.¶
The items that a DRO needs to attend to are:¶
This document will list recommended actions for DNSSEC validating resolver operators that will help achieve the goals of DNSSEC validation. First, the goals ought to be stated.¶
The primary goal of any operations endeavor is to provide a service within service level agreements intended to make relying parties happy with the performance of the service. For DNSSEC, this breaks into two parts, one of accurately achieving the protections offered by DNSSEC, the other, to avoid DNSSEC from accidentally being an impediment.¶
The recommendations will focus on preparation of the elements of a DNSSEC validating resolver, as described earlier in the diagram. In particular, there are recommendations related to service monitoring, time source, Trust Anchor Manager/Store, and DNS Resolver. The recommendations are categorized as at initialization, during runtime, and upon demand.¶
This document uses the following terminology:¶
the entity that performs DNS resolution and performs signature validation.¶
validation that avoids false positives and catches true negatives.¶
a module (of code) implementing functions related to the trust anchors used by the validator. This is essentially a database allowing access, monitoring of, and changes to trust anchors.¶
The operator or anyone providing DNSSEC validation service and managing DNSSEC Validators.¶
To help orient this document, the following schematic is offered to show some of the interrelationships among the elements of a DNSSEC validating resolver. This drawing is merely a cartoon summary, not an implementation guide.¶
+--------------+ +------------+ +---------------+ +--------------+
| | | | | | | |
| Service | | Time | | Cryptographic | | Trust Anchor |
| Monitoring | | Source | | Libraries | | Manager/Store|
| | | | | | | |
+--------------+ +------------+ +---------------+ +--------------+
| | | ^ ^
v v v | |
+--------------+ +------------------------------+ | |
| | | | | |
| | | | | |
->| DNS Resolver |->| DNSSEC Validation Engine |<-----+ |
-<| |<-| | |
| | | | |
+--------------+ +------------------------------+ |
^ ^ | ^ |
| | v | |
| +------------+ +---------------+ |
| | | | | |
+---------| DNS Caches | | DNS Messages |<----------+
| | | |
+------------+ +---------------+
Across the top row are elements that an operator needs to address to properly run a DNSSEC Validating Resolver.¶
Enforces acceptable use policy and enables management of the service This is a generic module for all services, here featuring some DNS and DNSSEC specific concerns.¶
Provides the wall clock or absolute, time DNS has always used relative time to manage the TTL of resource record sets in caches, DNSSEC introduced the need for absolute time to thwart replay attacks and to manage the lifetime of signatures.¶
Software library or a Hardware Security Module (HSM) implementing cryptography providing Due to the nature of cryptography, the implementation of this module may evolve over time or at least be subject to technical refresh.¶
The database of trust anchors used as the basis from which DNSSEC operates This module contains the foundation upon which DNSSEC evaluates received data sets. The contents of this module are essential for proper operation. For a general-purpose validator running on a public Internet, it may have a single entry, for the very top of the DNS name space (the root). Management of this may be left to automated processes that are carefully designed to address vulnerabilities related to automated trust management. For specific situations, the Trust Anchor Manager/Store will also manage local-policy supporting trust anchors as well. Careful operation of this module is crucial to the value of the DNSSEC validating resolver.¶
The other modules fill out the diagram to give the above context:¶
The service interface offered to other services/applications/users This is the generic DNS resolution service, consulting the cache for hits, and seeking new answers for misses.¶
This implements the DNSSEC validation process The validation engine is assumed to faithfully implement the DNSSEC validation algorithm, relying on the information from the Time Source, Cryptographic Libraries, Trust Anchor Management/Store as well as what is held in the local cache or gained through messages.¶
Include positive and negative caches. These are the ordinary caches used in DNS operations, including DNSSEC extended record types and management.¶
Existing DNS message passing This covers the proper implementation and operation of DNS and DNSSEC message exchanges.¶
Note that there may be other elements involved in a DNSSEC validating resolver.¶
As DNSSEC uses wall-clock time to temporally limit the validity of RRSIG resource records, a DNSSEC validator needs a reliable time source. If a validator can be fooled into believing that the time is a point well into the past, an incorrect RRSIG resource record may be replayed and used, or an old key whose private component has since been exposed may be able to forge a falsified answer.¶
The range of these recommendations include devices that do not have an embedded Real Time Clock. Such devices need to have their system clocks updated upon power up before starting the DNSSEC validator.¶
At initialization: a DNSSEC validator needs to be able to establish reliable time without relying on DNSSEC validation. The latter clause is needed as the initialization step is being carried out to start DNSSEC validation, it is not assumed to be up and running at this point. One way to interpret this is that a time source (Network Time Protocol) ought to be identified by a numerical IP address and not a fully qualified domain name (which would require a DNS lookup).¶
During runtime: a DNSSEC validator operator ought to have controls in place to monitor the current time of a validator as well as monitor the number of validation failures that can be attributed to temporal violations. Updates to the current time ought to make use of secure environments, whether secure channels for NTP or as appropriate for the installation. Updates ought to be part of an automated process, running at appropriately frequent intervals.¶
Upon demand: a DNSSEC validator operator ought to be able to perform any of the runtime actions upon demand, for instance, to help diagnose a service failure.¶
The TA store implements a trust model. The default trust model consists in trusting a single TA which is the KSK of the root zone.¶
While not generally recommended, a DRO may consider alternative TAs, for example, when the secure delegation to these RRsets may not be validated for any reasons. The trust model should at least ensure that any domain name in the DNS be covered by at least one TA. As the number of top level domains is evolving overtime, it remains safe to keep the root zone as a security entry point in order to cover the full domain name space. Upon considering TA, the DRO should carefully ensure that the TA meets all necessary operational criterias. This includes for example, having a bootstrapping mechanism, or having their signers committed to respect the [RFC5011] timing - at least when the DRO relies on automatic updates (see below).¶
TAs are usually represented by a DNSKEY or DS RRset and are involved in the signature validation process to determine whether the validation is successful or not.¶
At initialization: The DRO needs to ensure the resolver can only be started with a TA store that matches the trust model and that is up-to-date. The DRO needs to securely retrieve and check the TA upon starting the resolver. For the default trust model, for example, [UNBOUND-ANCHOR] or [ta-fetcher] implements [RFC7958] and ensures the resolver is configured with the up-to-date TA of the root zone. Similarly, the up-to-date default trust model is very commonly implemented by the software release in which case the DRO may simply rely on software update.¶
During runtime: The DRO needs to ensure the TA is up-to-date. This is achieved by enabling TA to be updated automatically as well as being able to check the status of the TA. TA updates are not expected to be handled manually as this introduces a potentially huge vector for configuration errors as well as potential misunderstanding of ongoing operations. Instead, the DRO should rely on automated procedures such as, for example, Automated Updates to DNSSEC Trust Anchors" [RFC5011] [I-D.ietf-dnsop-rfc5011-security-considerations] or software updates. As [RFC5011] is an in-band mechanism, the DRO is expected to understand these risks [RFC5011], Section 8. Software update or other mechanisms may also be used.¶
Upon demand: The DRO should be able to check the status of the TA within its resolvers on a regular basis or when it is aware a TA roll over is ongoing. This includes the TA stored in the running resolver as well as potential configuration files. The TA used by the resolver is expected to be retrieved using "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" [RFC8145], and may re-use similar software as those used at the initialisation to retrieve and check the expected value of the TA. The TA health check should associate a status to the TA - as defined in Section 3 of [RFC7583] - to ease the TA monitoring and potential analysis. When an unexpected (old) TA is found, the health check should evaluate if the mismatch resulted from an ongoing normal roll over, a potential emergency key roll over, failed roll over or any other envisioned cases. In any case restarting the resolver is expected to address any situation that cannot be addressed otherwise, which reinforces the recommendation to rely on TA bootstrapping mechanisms.¶
Note also that [RFC8145] also enables any authoritative server to check how the TA roll over is performed. Such cooperation is expected to be useful and benefit the overall operation of the DNS system.¶
When the DNSSEC Resolver is not able to validate signatures because a key or DS has been published with an error, the DRO may temporarily disable the signature check for that key until the time the error is addressed. Negative Trust Anchor (NTA) represents the only permitted intervention in the resolving process for a DRO.¶
The designation of NTA might be misleading, but NTA is not expected to be part of the trust model even though the NTA belongs to the TA store.¶
At initialization: Similarly to TA, the DRO is expected to automatically configure the resolver with the NTA.¶
Upon demand: the DRO is expected to automatically determine the used NTA and handle NTA as described in [RFC7646].¶
A signature validation failure is either an attack or a failure in the signing operation on the authoritative servers. The DRO is expected to confirm this offline before introducing the NTA. This is likely to happen via a human confirmation which is based on information collected during running time.¶
At running time: The DRO should monitor the number of signature failures associated with each DNSKEY. These numbers are only hints and must not trigger automated insertion of NTA.¶
During runtime: A DRO is not expected to perform any operations over the cached RRSet. A common concern DRO has is the consistency between the cached RRset with those published by the DNS system. DRO should not implement or deploy any non standard mechanism. [I-D.ietf-dnsop-ns-revalidation] is one of these mechanisms, for example. Section 8.1 of [RFC4033] also mentions the ability by the resolver to set the upper bound of the TTL to the remaining signature validity period. This value has usually a default value set by the resolver and the DRO may change that default value.¶
Upon demand: a DRO may have been informed that a rogue or unwilling DNSKEY has been published. In such a situation, the DRO should be able to remove the RRsets validated by the rogue DNSKEY - which may be done by flushing the full cache.¶
As mentioned in [RFC8247] and [RFC8221] cryptography used one day is expected over time to be replaced by new and more robust cryptographic mechanisms. In the case of DNSSEC signature protocols are likely to be updated over time. In order to anticipate the sunset of one of the signature schemes, a DNSSEC validator may be willing to estimate the impact of deprecating one signature scheme.¶
Currently, interoperability and security are enforced via cryptographic recommendations [RFC8624] that are followed by both resolvers and authoritative servers. The implementation of such guidance is ensured by the software vendors and the compliance of their releases.¶
At initialization: The DRO is expected to ensure recent software releases are used and that this release complies with the most recent cryptographic guidelines.¶
During runtime: a DRO may regularly request and monitor the signature scheme supported by an authoritative server. In addition, when a validation fails because a deprecated algorithm is used, the DRO should return an "Unsupported DNSKEY Algorithm" as defined in [RFC8914] to the DNS client.¶
Note that one inconvenience to such a strategy is that it does not let one DRO take advantage of more recent cryptographic algorithms. While currently not being widely used, a DRO may announce an authoritative server the supported signature schemes to the authoritative server [RFC6975] in the hope that future deployment of authoritative servers will be able to leverage it.¶
A DNSSEC validator receiving a DNS response cannot make the difference between receiving an non-secure response versus an attack. Dropping DNSSEC fields by misconfigured middle boxes, such as DS, RRRSIG is considered as an attack. A DNSSEC validator is expected to perform secure DNS resolution and as such protects its stub client. An invalid response may be the result of an attack or a misconfiguration, and the DRO may play an important role in sharing this information with the authoritative server or domain name owner.¶
At runtime: a DRO should monitor and report DNSSEC validation errors and inform the DNS client with "Extended DNS Errors" [RFC8914].¶
DNSSEC validation requires that the validator is able to reliably obtain necessary records, especially DNSKEY records. This should be done at initial configuration, and tested periodically.¶
This means the validator must ensure it is configured so that the UDP and TCP transports, and DNS resolver components, are compatible with the network paths that the majority of DNS queries traverse - which includes compatibility between DNS and transport parameters with the Maximum Transmission Unit (MTU).¶
In other words, make sure that:¶
The avoidance of fragmentation in order to address known fragmentation-related security issues with DNS (leading to cache poisoning, for example) has resulted in the need to set the DF bit on UDP. Validators will need to ensure their local environment can reliably get any critical DNSSEC records (notably DNSKEY) over UDP, or reliably get responses with TC=1 if overly large responses cannot be sent over UDP due to answers not fitting within the advertised bufsize payload. Validators also need to ensure TCP works if it is needed, for the same situations.¶
There is no IANA consideration for this document.¶
The recommendations provide very limited ability for a DRO to alter or directly interfere with the validation process. In many cases, it is believed that best practices are implemented by the software vendor and anything implemented by the DRO has a high chance of disrupting the resolution service or raising corner cases that would make analysis and troubleshooting very hard. To a lesser extent, there is also a high chance that default values set by the software vendor may be the appropriate value to be used.¶
To alter the DNSSEC resolution, an attacker may provide information to the DRO to flush the KSK/ZSK and associated data from its cache. This generates additional DNSSEC resolution and additional validations, as RRSet that were cached require a DNSSEC resolution over the Internet. This affects the resolution service by slowing down responses, and increases the load on the DNSSEC validator.¶
An attacker may ask the DNSSEC validator to consider a rogue TA, thus hijacking the DNS zone.¶
An attacker can advertise a "known insecure" KSK or ZSK is "back to secure" to prevent signature check to be performed correctly.¶
As a result, information considered by the DNSSEC validator should be from a trusted party. This trust party should have been authenticated, and the channel used to exchange the information should also be protected and authenticated.¶
The software used for the DNSSEC validator is not immune to bugs [ENT] and may become vulnerable independently of how it is operated. As a result, DROs are expected to run resolvers from different pieces of software- usually different vendors.¶
The need to address DNSSEC issues on the resolver occurred during multiple discussions including among others Ted Lemon, Ralph Weber, Normen Kowalewski, Mikael Abrahamsson, Jim Gettys, Paul Wouters, Joe Abley, Michael Richardson, Vladimír Čunát, James Gannon, Andrew McConachie, Peter Thomassen, Florian Obser and Brian Dickson.¶
We also appreciated the support of the DNSOP chairs Tim Wicinski, Suzanne Woolf and Benno Overeinder.¶