Recommendations for DNSSEC Resolvers Operators

Status of This Memo

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 28 July 2023.¶

Copyright Notice

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

Table of Contents

1. Introduction

The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC validation in to their users.¶

By validating with DNSSEC a received Resource Record Set (RRset), the resolver provides a high level of certainty that the information carried by the RRset is effectively as published by the legitimate owner of the RRset. The act of DNSSEC validation [RFC4033][RFC4035] can be broken into two part: A Signature Validation which binds the RRset to a private key as well as Trust in the owner of the private being the legitimate owner.¶

Signature Validation consists in checking the cryptographic signature of a RRset and involves among other parameters a DNSKEY Resource Record (RR) and RRSIG RR and the RRset itself. The signature validation process results in designating the owner of the RRset as the owner of the corresponding private part of the public key contained in the DNSKEY RR. Cryptography provides a high level of confidence in the binding to the private key. In that sense, a rogue RRset likely results from the private key being exposed or guessed -- as opposed to signature or key collisions for example. As such differ the confidence into the Trust to designate which DNSKEY RR is legitimate.¶

Trust implicitly assumes the private keys used to sign are not shared and as such can be associated their respective owners. The purpose of Trust is to put significant confidence into designating the legitimate DNSKEY RR - which also characterizes the corresponding private key. Such trust is provided by a Trust Anchor (TA), and the chain of trust established between the TA and the DNSKEY RR. The chain of trust is obtained by recursively validating the DNSKEY RRs.¶

As a result, such trust results from the trust placed in the TA as well as the delegation mechanism provided by DNSSEC and the Signature Validation. As TAs need to be managed over time, the trust also concerns the management procedure of the TA. This is the main concern of this document.¶

Data's authenticity and integrity is tied to the operator of the key that generates the signature. It is conceivable that a validator could "know" the keys of each data source, but this is not practical at large scale. To counter this, DNSSEC relied on securely chaining keys in a manner isomorphic to the way names are delegated. Keys for a name will "vouch for" keys at a name delegated via the signing of a DS resource record set.¶

Using keys to vouch for keys, recursively, works when a manageable set of key to name associations are determined to be "trusted" - and are called trust anchors. In DNSSEC, a validator needs one or more Trust Anchors from which to grow chains of verified keys.¶

With operational experience, a twist has emerged. More often, to date, failed validation is due to operator error or software bug [ENT] and not an attempt to forge data. In general badly signed RRsets or zone badly delegated are out of scope of the DRO's responsibility. However, the DRO may reflect this operational error with a temporary solution designated as Negative Trust Anchors (NTA) [RFC7646]. A NTA instructs a validator to ignore the presence of keys for a name, reacting as if the name is unsigned.¶

Once accurately validated the RRset is assumed to be accurately validated and trusted during the time indicated by its TTL.¶

The responsibilities of a DRO are limited to the management of TAs as well as providing the necessary infrastructure to perform the signature validation, e.g. appropriated libraries and time. More specifically, badly signed zones or insertion of malicious DNSKEY fall out of the DRO's responsibilities. Even though these threats fall out of these responsibilities, a DRO may collaborate with authoritative servers to limit the damage of their operational errors.¶

This document is focused on operational recommendations that a DRO SHOULD put in place in order to implement sufficient trust that makes DNSSEC validation output accurate. The recommendations described in this document include provisioning mechanisms as well as monitoring and management mechanisms.¶

The mechanisms provided are designed in accordance of the DNSSEC trust model as to meet the current operations of DNSSEC. Such trust model is briefly recapped in Section 4 so operators understand the limits and motivations for such mechanisms.¶

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. 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 providing DNSSEC validation service and managing DNSSEC validators¶

4. DNSSEC Validator Description

This is a conceptual block diagram of the elements involved with DNSSEC validation. This is not meant to be an architecture for code, this is meant to be a framework for discussion and explanation.¶

    +-------------+  +---------------+
    |             |  |               |
    | Time Source |  | Cryptographic |
    |             |  |   Libraries   |
    |             |  |               |
    +-------------+  +---------------+
           |                 |
           v                 v
    +--------------------------------+   +--------------+
    |                                |   |              |
    |                                |<--| Trust Anchor |
    |    DNSSEC Validation Engine    |   |   Manager &  |
    |                                |-->|   Storage    |
    |                                |   |              |
    +--------------------------------+   +--------------+
          ^ |               ^                   |
          | v               |                   |
    +-------------+  +---------------+          |
    |             |  |               |          |
    | DNS Caches  |  | DNS Messages  |<---------+
    |             |  |               |
    +-------------+  +---------------+

Time Source:

The wall clock time provides the DNSSEC Validation Engine the current time. Time is one input used to validate the RRSIG Signature and Inception Fields to provide some protection against replay attacks.¶

Cryptograhic Libraries:

The code performing the cryptographic functions providing the DNSSEC Validation Engine the ability to check the Signature Field that contains the cryptographic signature covering the RRSIG RDATA.¶

DNS Message:

DNS responses are used to carry the information from the DNS system. The receiver of the DNS message can be any kind of application including DNS-related application such as in the case of automated Trust Anchor update performed by the Trust Anchor Manager & Storage. The DNSSEC Validator Engine accurately validates the DNS responses before caching them in the DNS Cache and forwarding them to the DNS receiver. In case of validation failure, an error is returned and the information may be negatively cached.¶

DNS Caches:

Include positive and negative caches. The DNSSEC Validation Engine fills DNS Caches with validated DNS RRsets. The DNSSEC trust model considers that once a RRset has been accurately validated by the DNSSEC Validator Engine, the RRset is considered trusted (or untrusted) for its associated TTL. DNS Caches contain RRsets that may contain information requested by the application (RRset of type AAAA for example) as well as RRset necessary to accurately validate the RRsets (RRsets of type DNSKEY or RRSIG for example). This can also include RRsets that were not DNSSEC signed at validation time.¶

Trust Anchor Manager:

The database of trust anchors associated to database management processes. This function provides the DNSSEC Validation Engine Trust Anchor information when needed. When a TA needs to be updated, the Trust Anchor Manager is also responsible for handling the update procedure. This includes sending DNS Messages as well as treating appropriately the DNS responses that have been accurately validated by the DNSSEC Validator Engine. This will require the DNSSEC Validator to update Trust Anchor information, whether via methods like Automated Updates of DNSSEC Trust Anchors [RFC5011], management of Negative Trust Anchors, or other, possibly not yet defined, means.¶

DNSSEC Validation Engine:

This follows local policy to approve data. The approved data is returned to the requesting application as well as to the DNS Caches. While the cryptographic computation of the RRSIG signature may be the most visible step, the RRSIG record also contains other information intended to help the validator perform its work, in some cases sanity checks are performed. For instance, the original TTL (needed to prepare the RR set for validation) ought to be equal to or higher than the received TTL.¶

Not shown - Name Server Process Management interfaces to elements, handling of Checking Disabled request, responses, as well as all API requests made of the name server.¶

5. Recommendations Categories

A DRO needs to be able to enable DNSSEC validation with sufficient confidence they will not be held responsible in case their resolver does not validate the DNSSEC response. The minimization of these risks is provided by setting automated procedures, when a resolver is started or while it is operating, as well as some on-demand operations that enable the DRO to perform a specific operation. The recommendations do not come with the same level of recommendations and some are likely to be required. Others are optional and may be followed by more advanced DROs. It is up to the DRO to determine their applicability.¶

Regarding recommendations on the behavior of the resolver, some recommendations may already be applied by default by the operated resolver software, in which case the DRO does not have to perform any action. Some recommendations may require to be activated via configuration by the DRO. Some recommendations may simply not be provided by the operated software, in which case we recommend the DRO to contact the software vendor for further discussion.¶

The recommendations are voluntary restrictive to prevent side effects of interventions that will be hard to predict, debug and understand.¶

The RECOMMENDATIONS in this document are subdivided into the following categories:¶

Start-up recommendations (STARTUP):

which describes RECOMMENDED operations the DRO is expected to perform when the resolver is started. These operations typically include health checks of the infrastructure the resolver is instantiated on as well as configuration check.¶

Run time recommendations (RUNTIME):

which describes RECOMMENDED operations the DRO is expected to perform on its running resolvers. These operations typically include health checks of the infrastructure as well as the resolvers.¶

On demand recommendations (ONDEMAND):

which describes the RECOMMENDED operations a DRO may perform. This includes the ability to operate health checks at a given time as well as specific operations such as flushing the cache. The reason this document mentions these recommendations is to enable DROs to have the appropriates tools as well as to restrict their potential interventions.¶

6. Time deviation and absence of Real Time Clock Recommendations

With M2M communication some devices are not expected to embed Real Time Clock (Raspberry Pi is one example of such devices). With Raspberry Pi for example, when these devices are re-plugged their time is reset to some initial values like (January 1, 1970 for example) until they get re synchronized via NTP. Other devices that have clocks may suffer from time deviation. These devices cannot rely on their time estimation to perform DNSSEC validation.¶

Time synchronization may be performed manually, but for the sake of operations it is strongly RECOMMENDED to automate the time synchronization on each resolver.¶

STARTUP:¶

• A DRO MUST provide a mean to update the time without relying on DNSSEC when the DNSSEC validator is started. The resolver MUST NOT start if the time synchronization does not succeed at start time.¶

Note that updating time in order to be able to perform DNSSEC validation may become a form of a chicken and egg problem when the NTP server is designated by its FQDN. The update mechanism must consider the DNSSEC validator may not able to validate the DNSSEC queries. In other words, the mechanisms may have to update the time over an unsecure DNSSEC resolution.¶

RUNTIME:¶

• While operating, a DRO MUST closely monitor time derivations of the resolvers and maintain the time synchronized.¶

ONDEMAND:¶

• A DRO SHOULD be able to check and synchronize, on demand, the time of the system of its resolver.¶

Note that time synchronization is a sensible operation. A DRO MUST update time over an authenticated and secure channel.¶

For all recommendations, it is strongly RECOMMENDED that recommendations are supported by automated processes.¶

7. Trust Anchor Related Recommendations

A TA store maintains associations between domain names and keys (whether stored as in a DNSKEY resource record or a DS resource record) and domain names whose key are to be ignored (negative trust anchors). The TA store is essentially a database, storing the (positive) trust anchors. Management of the TA can be done manually or in an automated way. Automatic management of the TA is RECOMMENDED and can be subdivided into the following sub-categories:¶

1. Initial TA provisioning:

   that is the ability, for a DRO, to ensure a starting resolver is automatically provisioned with an up-to-date configuration. This includes defining a trust model and ensuring the associated TAs values are valid at the time the resolver is started. # This includes the TA associated to the trust model established by the DRO.¶

2. TA update over time:

   while the trust model may not evolve, the cryptographic keys associated to the security entry points are subject to change and thus a TA needs to be updated dynamically over time by a resolver. In this case, the DRO needs to check that the resolver has properly updated the TAs.¶

3. TA reporting:

   The reporting of the TA used by the resolver is made to the DRO as well as the authoritative servers which are hold responsible for making their zone validated by DNSSEC resolvers.¶

Note that TA update and TA reporting only concerns running resolvers. This section is only considering TA and not NTA. The handling of NTA is detailed in Section 8.¶

8. 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 DNSSEC Operator MAY temporarily disable the signature check for that key until the time the error is addressed. This is performed using NTA[RFC7646]. NTA represents the only permitted intervention in the resolving process for a DRO.¶

NTA are considered as temporary fix for a known unsecured domain, which is different from an TA that would not be trusted. The designation of NTA might be misleading, but NTA are not expected to be part of the trust model. This does not prevent a DRO to provision NTA as a configuration parameters NTA. The management of the configuration SHOULD be automated as described in Section 7.1.¶

Handling NTA is described in [RFC7646] and a DRO SHOULD follow these guidelines. The intent of this section is to position these guidelines toward the operational recommendations provided in this document.¶

STARTUP:¶

• DRO SHOULD be able to automatically configure NTA when starting DNSSEC resolvers.¶

ONDEMAND:¶

• DRO SHOULD set automated procedures to determine the NTA of DNSSEC resolvers.¶
• DRO SHOULD be able to handle NTA as defined in [RFC7646].¶

Note that adding a Negative Trust Anchor only requires the domain name to be specified. Note also that NTA can disable any sort of DNSKEY and is not restricted to TA.¶

A failure in signaling validation is associated to a mismatch between the key and the signature. DNSKEY/DS RRsets for TA have a higher level of trust then regular KSK/ZSK. In addition, DRO are likely to have specific communication channel with TA maintainer which eases trouble shooting.¶

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 off line before introducing the NTA. This is likely to happen via a human confirmation. As a result here are the following recommendations:¶

RUNTIME:¶

• DRO SHOULD monitor the number of signature failure associated to each DNSKEY. These number are only hints and MUST NOT trigger automated insertion of NTA.¶
• A DRO MAY collect additional information associated each DNSKEY RRSets. This information may be useful to follow-up roll over when these happen and evaluate when a key roll over is not performed appropriately on the resolver side or on the authoritative server. It would provide some means to the DRO to take action with full knowledge without necessary asking for a confirmation. In other cases it could prevent invalidation to happen. These check may be performed for a limited subset of domains or generalized.¶

9. ZSK / KSK (non TA) Related Recommendations

KSK / ZSK are not part of the DNSSEC validator configuration. Their values in the DNS Caches may not reflect those published by the authoritative servers or may be incoherent with the RRset in the DNS Cache they are validating. However, such incoherence primary results from error in the management of the authoritative servers. As a result, it is not expected that the DNSSEC validator provides complex management facilities to address these issues as this will modify the DNS architecture and add complexity that is not proved to be beneficial. As a result, recommendations always belong to the run time or on demand recommendations. The main difference between TA and KSK/ZSK is that the DRO does not necessarily have an out of band mechanism to retrieve the RRsets. As a result, the DRO has less information to determine and confirm what is happening. The default recommendation is to let things go.¶

A number of reasons may result in inconsistencies between the RRsets stored in the cache and those published by the authoritative server.¶

An emergency KSK / ZSK rollover may result in a new KSK / ZSK with associated new RRSIG published in the authoritative zone, while DNSSEC validator may still cache the old value of the ZSK / KSK. For a RRset not cached, the DNSSEC validator performs a DNSSEC query to the authoritative server that returns the RRset signed with the new KSK / ZSK. The DNSSEC validator may not be able to retrieve the new KSK / ZSK while being unable to validate the signature with the old KSK / ZSK. This either results in a bogus resolution or in an invalid signature check. Note that by comparing the Key Tag Fields, the DNSSEC validator is able to notice the new KSK / ZSK used for signing differs from the one used to generate the received generated signature. However, the DNSSEC validator is not expected to retrieve the new ZSK / KSK, as such behavior could be used by an attacker. Instead, ZSK / KSK key roll over procedures are expected to avoid such inconsistencies.¶

Similarly, a KSK / ZSK roll over may be performed normally, that is as described in [RFC6781] and [RFC7583]. While the KSK / ZSK roll over is performed, there is no obligation to flush the RRsets in the cache that have been associated with the old key. In fact, these RRsets may still be considered as trusted and be removed from the cache as their TTL timeout. With very long TTL, these RRsets may remain in the cache while the ZSK / KSK with a shorter TTL is no longer published nor in the cache. In such situations, the purpose of the KSK / ZSK used to validate the data is considered trusted at the time it enters the cache, and such trust may remain after the KSK / ZSK is being rolled over. Note also that even though the data may not be associated to the KSK / ZSK that has been used to validate the data, the link between the KSK / ZSK and the data is still stored in the cache using the RRSIG. Note also that inconsistencies between the ZSK / KSK stored in the cache and those published on the authoritative server, may lead to inconsistencies to downstream DNSSEC validators that rely on multiple cache over time.¶

Typically, a request for the KSK / ZSK may have been provided by a cache that is storing the new published value, while the data and associated signatures may be associated to the old KSK / ZSK.¶

Incoherence between RRsets and DNSKEYs is not the responsibility of the DRO. Instead, it is the responsibility of authoritative server publishing these data. This includes insuring the coherence between TTLs and signature validation periods as well as small variations of the resolvers clocks. Section 4.4.1 of [RFC6781] provides some recommendations that can be implemented by the authoritative server which puts the responsibility of failure of signature validation under the responsibility of the authoritative server. A DRO MAY however limit the risks for these inconsistencies to happen by configuring the DNSSEC validator with generic rules that applies to the validation process. Typically, the TTL associate to the DNSKEY is an engagement from the authoritative server that the DNSKEY will remain valid over this period. As this engagement supersedes the validation of any RRSIG and by extension to any RRset in the zone, this TTL value may be used as the maximum value for the TTL associated to FQDNs in the zone. Section 8.1 of [RFC4033] mention the ability by the resolver to set the upper bound of the TTL to the remaining signature validity period. In addition, the DNSSEC validator should also be able to provide a maximum values for TTLs. These values MAY also consider the small inaccuracy of the local clock.¶

RUNTIME:¶

• To limit the risks of incoherent data in the cache, it is RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of the DS, KSK and ZSK. RRsets TTL SHOULD NOT exceed the DS, KSK or ZSK initial TTL value, that TTL SHOULD trigger delegation revalidation as described in [I-D.ietf-dnsop-ns-revalidation]. TTL SHOULD NOT exceed the signature validity.¶

10. DNSKEY Related Recommendations

This section considers the recommendations that are common to TA as well as non TA DNSKEY RRsets.¶

11. Cryptography Deprecation Recommendations

As mentioned in [RFC8247] and [RFC8221] cryptography used one day is expected over the 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 scheme, 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.¶

To safely deprecate one signature scheme, the DNSSEC validator operator is expected to follow the recommendation below:¶

STARTUP: * DRO MUST ensure recent software releases that comply with the most recent cryptographic guidances are being used¶

RUNTIME:¶

• A DRO SHOULD regularly request and monitor the signature scheme supported by an authoritative server.¶
• A DRO SHOULD report a "Unsupported DNSKEY Algorithm" as defined in [RFC8914] when a deprecated algorithm is used for validation.¶

One inconvenient to such strategy i sthat it does not let one DRO to take advantage of more recent cryptographic. While currently not being widely used, a DRO MAY share information with authoritative server in the hope that future deployment of authoritative servers will be able to leverage it. [RFC6975] provides the ability for a DNSSEC validator to announce an authoritative server the supported signature schemes. However, a DNSSEC validator is not able to determine other than by requesting and monitoring DNSKEY RRsets as well as RRSIG. These RRsets are received by enabling DNSSEC validation by default which is obviously the case for DNSSEC validator.¶

12. 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 a 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 DNSSEC validator may play an important role in sharing this information with the authoritative server or domain name owner.¶

RUNTIME:¶

• DRO SHOULD monitor and report DNSSEC validation error. Reporting may take various means but the DRO SHOULD implement [RFC8914] to inform the DNS client.¶

13. 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: 1. 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.¶

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

STARTUP: * DRO MUST ensure UDP and TCP transport are enabled. * DRO MUST ensure DNS and TCP parameters will not exceed the expected MTU¶

RUNTIME: * DRO SHOULD regularly discover MTU and ensure the DNS and TCP parameters are aligned wit this value. * DRO SHOULD closely monitor the absence of responses, or ICMP PTB message as a potential incompatibility between configured parameters and the MTU.¶

14. IANA Considerations

There are no IANA consideration for this document.¶

15. Security Considerations

The recommendations listed in this document have two goals. First ensuring the DNSSEC validator has appropriated information to appropriately perform DNSSEC validation. Second, monitoring the necessary elements that would enable a DNSSEC validator operator to ease a potential analysis. The recommendations provide very limited ability for a DNSSEC validator operator to alter or directly interfere on the validation process and the main purpose in providing the recommendations was to let the protocol run as much as possible. Providing inappropriate information can lead to misconfiguring the DNSSEC validator, and thus disrupting the DNSSEC resolution service. As a result, enabling the setting of configuration parameters by a third party may open a wide surface of attacks. In addition, such changes may lead to unexpected corner cases that would result in making analysis and trouble shooting very hard.¶

As an appropriate time value is necessary to perform signature check, an attacker may provide rogue time value to prevent the DNSSEC validator to check signatures.¶

An attacker may also affect the resolution service by regularly asking the DNSSEC validator to flush the KSK/ZSK from its cache. All associated data will also be flushed. 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 KSK/ZSK, thus hijacking the DNS zone. Similarly, an attacker may inform the DNSSEC validator not to trust a given KSK in order to prevent DNSSEC validation to be performed.¶

An attacker (cf. Section 7) 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 DNSSEC validator is not immune to bugs and may become vulnerable independently of how it is operated. As a result a DRO SHOULD NOT depend on a single implementation or version of a given software and SHOULD instead run at least two independent pieces of software.¶

16. Contributors

We would like to thank very much Edward Lewis without who the document might probably not exist.¶

17. Acknowledgment

The need to address DNSSEC issues on the resolver occured 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.¶

Authors' Addresses