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.

IANA Considerations There is no IANA consideration for this document.

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

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