Recommendations for DNSSEC Resolvers Operators

Introduction 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 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: Time of day (current, wall-clock time) Trust anchors (positive and negative) Monitoring of the service, including abuse 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.

Terminology This document uses the following terminology:

DNSSEC validator:: the entity that performs DNS resolution and performs signature validation.
Accurate validation:: validation that avoids false positives and catches true negatives.
Trust Anchor Data Store:: 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.
DNSSEC Resolver Operator (DRO):: The operator or anyone providing DNSSEC validation service and managing DNSSEC Validators.

Overall View of DNSSEC Validating Resolver 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.

| 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.

Service Monitoring:: 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.
Time Source:: 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.
Cryptographic Libraries:: 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.
Trust Anchor Manager/Store:: 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:

DNS Resolver:: 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.
DNSSEC Validation Engine:: 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.
DNS Caches:: Include positive and negative caches. These are the ordinary caches used in DNS operations, including DNSSEC extended record types and management.
DNS Messages:: 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.

Time Recommendations 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.

Trust Anchor Related Recommendations 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 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, or implements 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" or software updates. As is an in-band mechanism, the DRO is expected to understand these risks . 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)" , 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 - 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 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.

Negative Trust Anchors Related Recommendations 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 . 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.

Cached RRset Recommendations 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. is one of these mechanisms, for example. Section 8.1 of 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.

Cryptography Deprecation Recommendations As mentioned in and 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 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 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 in the hope that future deployment of authoritative servers will be able to leverage it.

Invalid Reporting Recommendations 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" .

Transport Recommendations 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: DNS UDP bufsize (EDNS parameter) is set to a value compatible with network MTUs the queries and responses will encounter. If the validator advertises a bufsize >> MTU, responses with the IPv4 Don't Fragment (DF) bit set whose size R where MTU < R <= bufsize exceeds the MTU will be dropped by the router with MTU < R. The validator's OS TCP configuration has its advertised Maximum Segment Size (MSS) set to a value compatible with network MTUs the queries and responses will encounter. Having an advertised MSS set to a value < MTU ensures that Path MTU Discovery is not required If PMTUD fails for any reason, or if the server responding does not maintain or use PMTUD, and advertised MSS > MTU at any point in the path, TCP may encounter problems caused by IP fragmentation and reassembly. This is particularly relevant if there are any NAT type devices in the path, as those may not properly handle fragmentation and reassembly If all TCP segments are smaller than the path MTU, TCP will work reliably. 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.

Secure Transport Recommendations A DRO should consider secure transport as a complementary element of its trust model. Such resolvers are usually designated as encrypted resolvers and their presence is usually discovered by the DNS client via a discovery mechanisms. That discovery mechanism may require the resolver to respond to specific DNS requests. In many cases, a DRO enables DNSSEC to ensure the cached RRset have not been modified on-path and corresponds to those published by the owner of the zone. To ensure RRsets are protected against on-path modification from the resolver to the DNS client, the DRO may enable a secure transport such as DNS over TLS (DoT) , DNS over HTTPS (DoH) or DNS over QUIC (DoQ) . The TLS termination may be supported by the running resolver software or via a TLS front end and TLS should follow its own TLS recommendations . A DRO should consider how the DNS client will discover the encrypted resolver. A DNS client may be provisioned with all the necessary parameters via specific mechanisms such as DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers or 3GPP TS 24.008 mechanisms. Alternatively, a DNS client configured with an unencrypted resolver may discover the encrypted resolvers operated by the same entity as the unencrypted resolver using the Discovery of Designated Resolvers (DDR) . The relation between the unencrypted resolver and the encrypted resolvers is indicated during the TLS key exchange via a certificate that contains a subjectAltName extension with the IP address of the unencrypted resolver. To ease the (even future) deployment of DDR, it is recommended that a DRO uses a global IP address for its unencrypted resolver. When the DRO deploys encrypted resolvers, it is recommended that the DRO enables DNS clients to discover the encrypted resolvers using DDR and use a certificate authority that belongs to the Web PKI.

IANA Considerations There is no IANA consideration for this document.

Security Considerations Security consideration of DNSSEC operations are described in . However, most DNSSEC operations are performed by the owner of the zone as opposed to the DRO. In addition, DRO are largely relying on the software vendor as well as automated procedure as to limit potential intervention from the DRO. This section emphases on DRO related security considerations. Regarding time inaccuracy, a RRSIG is only valid between the inception and expiration time. As a result, when the time is outside this period validation is disabled, and this could be used by an attacker to disable validation for example to poison the cache. Trust anchors are the root of the trust in DNSSEC and potentially, an attacker being able to provide a rogue trust anchor is potentially able to hijack any RRset below that Trust Anchor. On the other hand, mishandling Trust Anchor is likely resulting in a validator unable to validate most of the traffic under the TA. The use by a DRO of a common trust model shared by many DRO and implemented by multiple vendors reduces these risks. Negative trust anchors by definition disable validation, and as such must be handled very cautiously by the DRO. This could be used by an attacker, for example, to disable validation and poison the resolver. Using weak cryptography reduces the strength in the trust implemented by DNSSEC as it relied on cryptographic signatures. A weak cryptographic algorithm may be used by an attacker to forge a signature. It is probably something the DRO may observe as use as an indicator, but there is little action the DRO can actually do, as the cryptographic algorithms to be used are defined by the owner of the zone or the RRSet. The DRO is operating one part of the DNS system. While a DRO operates independently, it is believed that communication between the different actors involved in the DNS system will enhance the global resiliency of the system. As a result, this document encourages the DRO to provides some information to the stub client when a signature validation fails. It also encourages the DRO to authorize third parties to request what trust anchor or more generally DNSKEY are being used, so concerned party may be able to contact the DRO if needed. This is expected, for example when a authoritative server is performing a key roll over to check the update has been performed properly before removing the old key. The same considerations for communications also holds between DRO as well as with software vendors. As the software used for the DNSSEC validator is not immune to bugs and may become vulnerable independently of how it is operated, it is recommended a DRO relies on different vendors.

DNSSEC and TLS Trust Models While the document is essentially focused on the security implemented by DNSSEC, it also mentions the combination of TLS and DNSSEC. DNSSEC is essentially a protocol focused on authenticating the DNS data, but is not addressing confidentiality of the data nor the privacy of the user requesting that data. TLS provides authentication and confidentiality of a communication. As a result, TLS is necessary wherever privacy is needed. In the current model a DNS client is using TLS to protect the communication with the resolver. If that resolver is trusted and believed to host trustworthy RRsets - that is unmodified RRsets validated by the DNSSEC - the TLS communication enables the DNS client to trust the RRSets without performing a DNSSEC validation. If that resolver is expected to perform some operations agreed by the DNS client that may change the RRsets, DNSSEC cannot be performed by the DNS client and TLS is used to carried these trusted RRsets to the DNS client.
On the other hand, if the DNS client does not fully trust the resolver, than the DNS client must authenticate the received RRsets with DNSSEC. In that case, TLS is only providing privacy protection. The trust in a DNS resolver depends on multiple factors, but one significant concern is the ability of the DRO to perform a man in the middle attack and change on the fly the RRsets without the stub client being aware of it. Confidential computing may be one way to address such attacks. Another concern, related to privacy, is the ability of a resolver to track a certain user and log every sites requested by the user. Confidential Computing or oblivious DNS are means to address such issues. A model where TLS would be used to protect the transactions between the DNS client and the authoritative server is unlikely in a near future for scalability reasons. A compromise to this model may consists in having the TLS communications between the resolvers and the authoritative servers. In such scenario, the privacy requirement might be questionable as the resolver aggregates the traffic of multiple DNS clients which may be considered to provide sufficient privacy. However, a model involving a communication composed of multiple TLS segments is only trusted if all involved nodes are trusted (DNS client, resolver, authoritative server). In practice, it is unlikely to have all these intermediary nodes trusted, in which case trust will rely on DNSSEC.

Acknowledgment 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, Brian Dickson and Christian Huitema. We also appreciated the support of the DNSOP chairs Tim Wicinski, Suzanne Woolf and Benno Overeinder.