DNSSEC Validators Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

DNSSEC validation [refer to DNSSEC RFC documents; 4033-4035+updates] has two core concepts. One is the matching of a RRSIG resource record's contents to a RRset, making use of a DNSKEY resource record (named in the RRSIG record). Two is the placing of trust in the DNSKEY resource record. Evaluation based on a RRSIG records involves a few steps. Most visible is a cryptographic operation, matching the digital signature in the RRSIG with the specified public key in the named DNSKEY record and a properly prepared DNS RRset. This is meant to demonstrate that the RRset came from an entity with the private component of the key (source authenticity). Not to be forgotten are the other matches to perform. To address the threat of reply attacks, wall-clock (absolute) time is checked. To address the authority of the source, the named DNSKEY record is checked for appropriateness (i.e., owned by the same zone is the default policy). The RRSIG record also contains other information intended to help the validator perform its work, in some cases "sane value" 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. Requirements related to validation exist in RFC 4034/4035. This document describes what an implementation is required to do to allow proper, accurate validation.

This document uses the following terminology: DNSSEC validator: the entity that performs DNSSEC resolution and performs signature validation. Accurate validation: validation that avoids false positives and catches true negatives. (not sure if this is needed, but seems appropriate)

With M2M communication some devices are not expecting to embed Real Time Clock (Raspberry Pi is one example of such devices). When these devices are re-plugged the initial time is set to January 1 1970. Other devices that have clocks that may suffer from time derivation. All these devices cannot rely on their time estimation to perform DNSSEC validation. A DNSSEC validator MUST be provided means to update the time without relying on DNSSEC. Note that updating time in order to be able to perform DNSSEC validation may easily come with a chicken-and-egg problem when the NTP server is designated by its FQDN. The update mechanisms 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.

A validator needs to have trust anchors or it will never be able to construct a chain of trust. Trust anchors are defined by DNSSEC to be keys that are inherently trusted, configured by authorized parties, in the validator. The configuration can be via an automated process, such as Automated Updates of DNSSEC Trust Anchors [RFC 5011 as reference], or via manual process. An implementation of a validator needs to allow an operator to choose any automated process supported by the validator. (No requirements are stated about what processes to support, only one is standardized to date.) An implementation needs to also afford the operator the ability to override or manage via a purely manual process, the storage of managed keys. This includes adding, deleting, changing and inspecting. Beyond the scope of these requirements are the decision processes of authorized parties in placing trust in keys. A DNSSEC validator MUST check the validity of its Trust Anchors. When a Trust Anchor cannot be verified, the DNSSEC validator MUST send a warning and SHOULD NOT start validating traffic without manual validation. A DNSSEC validator SHOULD be able to retrieve a Trust Anchor with bootstrapping mechanism. Such mechanism' security MUST NOT be based on DNSSEC, but could instead include downloading a XML file from a trusted URL, or a PKIX certificate. Although some bootstrapping mechanisms to securely retrieve publish and retrieve the Root Zone Trust Anchor have been defined, it is believed these mechanisms should be extended to other KSKs or Trust Anchors. In fact it is not always possible to build a trusted delegation between the Root Zone and any sub zone. This may happen for example if one of the upper zones does not handle the secure delegation or improperly implement it. A DS RRset may not be properly filled or its associated signature cannot be validated. As the chain of trust between a zone and the root zone may not be validated, the DNSSEC validation for the zone requires a Trust Anchor. Such DNS(SEC) resolutions may be critical for infrastructure management. A company "Example" may for address all its devices under the domain example.com and may not want disruption to happen if the .com delegation cannot be validated for any reason. Such companies may provision there DNSSEC validator with the Trust Anchor KSK for the zone example.com in addition to the regular DNSSEC delegation. Similarly some some domains may present different views such as a "private" view and a "public view". These zones may have some different content, and may use a different KSK for each view.

When DNSSEC validator are running and a Trust Anchor KSK roll over is ongoing, a network administrator or any trust party may be willing to check whether the new published keys are being stored in a Trust Anchor Store with an appropriated status. Such inspection is likely to avoid that an non successful Trust Anchor roll over be detected before traffic is being rejected. When a new Trust Anchor has not been considered by the DNSSEC validator, a trusted party may be able to provision the DNSSEC validator with the new Trust Anchor, and eventually may remove the revoked Trust Anchor. While Trust Anchor configured with a KSK that has been removed results in the DNSSEC validator rejecting multiple legitimate responses, the consequences associated to accepting a rogue Trust Anchor as a legitimate Trust Anchor are even worst. Such attacks would result in an attacker taking control of the entire naming space behind the Trust Anchor. In the case of the Root Zone KSK, for example, almost all name space would be under the control of the attacker. In addition, to the name space, once the rogue Trust Anchor is configured, there is little hope the DNSSEC validator be re-configured with the legitimate Trust Anchor without manual intervention. As a result, it is crucial to cautiously handle operations related to the Trust Anchor provisioning. Means must be provided so network administrator can clearly diagnose the reason a Trust Anchor is not valid to avoid accepting a rogue Trust Anchor inadvertently. DNSSEC may also be used in some private environment. Corporate networks and home networks, for example, may want to take advantage of DNSSEC for a local scope network. Typically, a corporate network may use a local scope KSK / ZSK to validate DNS RRsets provided by authoritative DNSSEC server in the corporate network. This use case is also known as the "split-view" use case. These RRsets within the corporate network may differ from those hosted on the public DNS infrastructure. Note that using different KSK/ZSK for a given zone may expose a zone to signature invalidation. This is especially the case for DNSSEC validators that are expected to flip-flop between local and public scope. How validators have to handle the various provisioned KSK/ZSKs is out of scope of the document. Homenet work may use DNSSEC with TLDs or associated domain names that are of local scope and not even registered in the public DNS infrastructure. This requires the ability to manage the Trust Anchor DB as described in . The necessity to interact with the Trust Anchors lead to the following requirements: A DNSSEC validator MUST store its Trust Anchors in a dedicated Trust Anchor Data Base. Such database MUST store informations associated to each Trust Anchor status as well as the time the status has been noticed by the DNSSEC validator. Such database MUST be resilient to DNSSEC validator reboot. Trust Anchor states SHOULD at least consider those described in (Start, AddPend, Valid, Missing, Revoked, Removed). Additional states SHOULD also be able to indicate additional motivations for revoking the Trust Anchor such as a Trust Anchor known to be corrupted, a Trust anchor miss published, or part of a regular roll over procedure. A DNSSEC validator MUST provide access to the Trust Anchor data base to authorized user only. Access control is expected to be based on a least privileged principles. A trusted party MUST be able to add, remove a Trust Anchor in the Trust Anchor Database.

In addition when a Trust Anchor is revoked, the DNSSEC validator may behave differently if the revocation is motivated by a regular roll over operation or instead by revoking a Trust Anchor that is known as being corrupted. In the case the roll over procedure, is motivated by revoking a Trust Anchor that is known to be corrupted, the DNSSEC validator may be willing to flush all RRsets that depends on the Trust Anchor. A DNSSEC validator MUST be able to flush the cached RRsets that rely on a Trust Anchor.

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 result in a bogus resolution or in an invalid signature check. [I AM NOT SURE THE ABOVE TEXT IS CORRECT AS THE RRSIG CARRIES THE KEY ID, SO THE DNSSEC VALIDATOR SHOULD BE ABLE TO DETECT IT IS USING THE WRONG KEY. WOULDN'T IT IN THAT CASE QUERY THE DNSKEY ? ] Similarly, a KSK / ZSK roll over may be performed normally, that is as described in and . While the KSK / ZSK is performed, there is no obligation to flush the RRsets in the cache that have been associated with the old key. In fact, these RRset may still be considered as trusted and be removed from the cache as their TTL timeout. With very long TTL, these RRset may remain in the cache while the ZSK / KSK with a shorter TTL is no longer published nor in the cache. KSK and ZSK are associated with configuration parameters, and as such are expected to be stored only in the cache. As a result, flushing their value from the cache could constitute a way forward to refresh them. On the other hand, their respective function is also to prevent illegitimate RRsets to be validated and so more understanding is need before taking any action associated to the KSK or ZSK. More specifically, the network administrator SHOULD be provided the appropriated information required to distinguish a misconfiguration from an attack. The following requirements are thus considered for the KSK / ZSK. A DNSSEC validator MUST store its KSK/ZSK in a dedicated KSK/ZSK Data Base. Such database MUST store informations associated to each KSK/ZSK status as well as the time the status has been noticed by the DNSSEC validator. Such database MUST NOT be resilient to DNSSEC validator reboot. KSK/ZSK status SHOULD be monitored continuously and associated with their respective state as well as verified time. These states and MUST NOT be resilient to reboot. KSK/ZSK states SHOULD at least consider those described in section 3.1 of (Generated, Published, Ready, Active, Retired, Dead, Removed, Revoked ). Additional states SHOULD also be able to indicate additional motivations for revoking the KSK/ZSK such as a KSK/ZSK known to be corrupted, a KSK/ZSK miss published, or part of a regular roll over procedure. A DNSSEC validator MUST provide access to the KSK/ZSK data base to authorized user only. Access control is expected to be based on a least privileged principles. A trusted party MUST be able to add, remove a Trust Anchor in the KSK/ZSK Database.

A zone may have been badly signed, which means that the KSK or ZSK cannot validate the RRSIG associated to the RRsets. This may not be due to a key roll over, but to an incompatibility between the keys (KSK or ZSK) and the signatures. When such situation occurs, there is only a choice between not validating the RRsets or invalidating their signature. This is a policy design that needs to be taken by the network administrator. In other ways, flushing the RRset are not expected to address this issue. Such KSK/ZSK are known as Negative Trust Anchors . With Negative Trust Anchor, the zone for a given time will be known as "known insecure". The DNSSEC Validator is not expected to perform signature validation for this zone. It is expected that this information is associated to a Time To Live (TTL). Note that, this information may be used as an attack vector to impersonate a zone, and must be provided in a trusted way, by a trusted party. If a zone has been badly signed, the administrator of the authoritative DNS server may resign the zone with the same keys or proceed to an emergency key rollover. If the signature is performed with the same keys, the DNSSEC Validator may notice by itself that RRSIG can be validated. On the other hand if a key rollover is performed, the newly received RRSIG will carry a new key id. Upon receiving a new key id in the RRSIG, the DNSSEC Validator is expected to retrieve the new ZSK/KSK. If the RRSIG can be validated, the DNSSEC Validator is expected to remove the "known insecure" flag. However, if the KSK/ZSK are rolled over and RRSIG cannot be validated, it remains hard for the DNSSEC Validator to determine whether the RRSIG cannot be validated or that RRSIG are invalid. As a result: A trusted party MUST be able to indicate a DNSSEC validator that a KSK or a ZSK as Negative Trust Anchor. Such Trust Anchors MUST NOT be used for RRSIG validation and MUST be moved to the Trust Anchor Database, so the information become resilient to reboot. A trusted party MUST be able to indicate a DNSSEC validator that a KSK/ZSK is known "back to secure".

In order to refresh a KSK/ZSK, a trusted third party may simply flush the corresponding KSK/ZSK from the cache. In order to avoid inconsistency between KSK/ZSK and cached RRsets, a trusted third party may willing to remove all cached RRsets that have been validated by the KSK/ZSK upon some specific states (revoked, or Removed for example), of after some time after the state is noticed. In this later case, only the RRset whose TTL has not expired yet would be flushed. Finally, when a KSK/ZSK is known to be corrupted, the DNSSEC validator may removed all cached RRsets associated to the KSK/ZSK. As a result, the following requirements are expected: A DNSSEC validator MUST be able to flush the cached KSK/ZSK. A DNSSEC validator MUST be able to flush the cached RRsets associated to a KSK/ZSK.

The DS RRset is stored in the parent zone to build a chain of trust with the child zone. This DS RRset can be invalid because its RDATA (KSK) is not anymore used in the child zone or because the DS is badly signed and cannot be validated by the DNSSEC Validator. In both cases the child zone is considered as bogus and the valid child zone's KSK should become a Trust Anchor KSK. This requirements is fulfilled by the requirement to add a Trust Anchor in .

As mentioned in and 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 willing to estimate the impact of deprecating one signature scheme. Currently 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 trying whether a signature scheme is supported by the authoritative server. In order for a DNSSEC validator to safely deprecate one signature scheme the following requirement should be fulfilled. A DNSSEC validator SHOULD be able to request the signature scheme supported by an authoritative server.

There are no IANA consideration for this document.

The requirements listed in this document aim at providing the DNSSEC validator appropriated information so DNSSEC validation can be performed. On the other hand, 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. As an appropriate time value is necessary to perform signature check (cf. ), 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 (cf. ). 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 ( cf. Invalid DS in or Private KSK in ), thus hijacking the DNS zone. Similarly, (cf. ) 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. ) 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 need to address DNSSEC issues on the resolver side started in the Home Networks mailing list and during the IETF87 in Berlin. Among others, people involved in the discussion were Ted Lemon, Ralph Weber, Normen Kowalewski, and Mikael Abrahamsson. People involved in the email discussion initiated by Jim Gettys were, with among others, Paul Wouters, Joe Abley and Michael Richardson. The current document has been initiated after a discussion with Paul Wouter and Evan Hunt.