ISC

950 Charter St Redwood City CA 94063 USA each@isc.org

General DNS EDNS(0) ESD Diagnostic The widespread adoption of DNSSEC implies more frequent DNSSEC failures. Unfortunately, DNSSEC's failure mode is largely opaque to the client: when validation fails, the only signal that the clients of a validating resolver receive is an empty response with a SERVFAIL response code. This note proposes a protocol extension to allow SERVFAIL responses to include additional diagnostic information, giving the client greater insight into what went wrong and a better chance of delivering useful problem reports to DNS operators.

DNSSEC's failure mode is largely opaque to the client: when validation fails, the only signal of this that a resolver's clients receive is a SERVFAIL response code. With no information provided to explain the exact cause of a SERVFAIL response, there is no straightforward way for an end user to determine whether a failure occurred due to a broken local resolver, a zone misconfiguration such as expired signatures, or a spoofing attack. This makes it difficult to address complaints and problem reports to the right people, slowing the correction of DNSSEC errors while increasing the support burden on validating resolver operators. This note proposes a protocol extension allowing a name server, upon request from a client, to accompany SERVFAIL responses with detailed diagnostic information indicating what specifically caused the failure. In the typical use case for this mechanism, a validating caching name server would be able to convey specific failure information to a non-validating stub resolver or other client.

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 .

A DNS client such as a non-validating stub resolver may use an EDNS(0) option, ESD, to solicit extended diagnostic information from a DNS server. The ESD option payload includes a 16-bit "flags" field and a 16-bit diagnostic code; additional payload data may be included in the response. One bit in the "flags" field is defined as "human-readable": if this bit is set in the solicitation, it indicates a desire for the server to return human-readable text, in addition to machine-readable diagnostic data; this text can be displayed or sent to a logging facility such as syslog . All other payload data MUST be left empty in the solicitation. The response payload, in addition to the flags field and the diagnostic code, may also include a supplemental data field whose content and schema are dependent on the diagnostic code being returned. If the "human-readable" flag is set in the response, then the response also includes human-readable text in a counted string, i.e., a single length octet followed by that number of characters, as in the TXT RDATA format .

A stub resolver or other DNS client requests extended diagnostic data by sending an ESD option () in an EDNS(0) OPT pseudo-RR in the query message. The requestor MAY set the "human-readable" bit in the flags field of the request payload. The requestor MUST NOT include any other payload data in the ESD option. The requestor MUST ignore any ESD option included in a response that does not have response code SERVFAIL.

A resolver or other name server which encounters a server failure while answering a query that included an ESD option MAY add an ESD option to the SERVFAIL response. If the query did not include an ESD option, then the response MUST NOT include one. The server MUST NOT include an ESD option in any non-SERVFAIL response.

The OPTION-CODE for the ESD option is [TBD]. The format for the OPTION-DATA portion of an ESD option is shown below:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS |H| DIAGCODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ HRTEXT (optional, resonse only) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ SUPPDATA (optional, response only) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in which the fields are defined as follows: A 16-bit field. Bit 15 (H) is defined to mean "human-readable"; when set in the solicitation, this bit signals a desire for human-readable text to be included in the response; when set in the response, it signals that such text has been included. All other bits in the field MUST be set to zero. A 16-bit diagnostic code () indicating the reason for the SERVFAIL response. In the solicitation payload, this field MUST be set to zero. An counted string, containing human-readable text suitable for logging. The first octet defines the length of the following text; if the first octet contains 0, the string is emty. This is intended as an opaque string to be passed through to a logging mechanism; content and encoding are outside the scope of the protocol. This field MUST NOT be included in a solicitation payload. Optional supplementary data about the cause of the server failure. The presence or absence, content, and schema of this field are entirely dependent on the diagnostic code being returned in the DIAGCODE field (). This field MUST NOT be included in a solicitation payload.

Diagnostic codes are grouped in five general categories: Internal server error conditions (diagnostic codes 1-255), general DNS failures (256-511), policy-dependent security errors (512-767), temporary security errors (768-1023), and fatal security errors (1024-1279). Space has been reserved in the namespace for additional categories and codes. All diagnostic codes are optional; there is no requiremnt to impelement all of them. The DIAGCODE field MUST be set to zero (No Error) in ESD solicitations.

These diagnostic codes indicate a system failure in the responding server.

Diagnostic code 1 indicates an unspecified internal server error unrelated to DNSSEC. A server MAY return this code in place of any other internal server error, at the discretion of the implementor or operator, if information about the internal state of the server is regarded as security sensitive. This code has no supplemental data.

Diagnostic code 2 indicates that the server was not able to dynamically allocate memory. This code has no supplemental data.

Diagnostic code 3 indicates that a needed resource was not available. This code has no supplemental data.

Diagnostic code 4: The server has been configured to be authoritative for a zone which is an ancestor of the query name, but was unable to load it. The supplemental data contains the name of the zone the server was unable to load, in DNS wire format.

Diagnostic code 5: The server has been configured to be authoritative for a zone which is an ancestor of the query name, but the zone contents are invalid; for example, there is no SOA RR or NS RRset at the zone apex. The supplemental data contains the name of the zone in DNS wire format.

Diagnostic code 6: The server could not be initialized, e.g., as a result of an error in loading or parsing the configuration file. This code has no supplemental data.

Diagnostic code 7: Query processing timed out. This code has no supplemental data.

Diagnostic code 8: The server is shutting down. This code has no supplemental data.

These codes describe failure conditions due to bad or inconsistent data in the DNS not specifically related to DNSSEC.

Diagnostic code 256: The name servers which have been delegated responsibility for a zone cannot be reached or are not performing name service for that zone. The supplemental data contains the zone apex name of the faulty zone.

Diagnostic code 257: A CNAME or DNAME record fails sanity checks after name expansion. The supplemental data contains the name and RR type (CNAME or DNAME) of the faulty record, in the following format:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RRTYPE | NAME \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Diagnostic code 258: Processing this query requires a protocol extension that is not supported. This code has no supplemental data.

These are errors returned due to locally-configured policy constraints on DNSSEC processing or other security considerations.

Diagnostic code 512: Local policy disallows a DNSKEY being used to validate a record on the grounds that it is too large. The supplemental data specifies the owner name (in DNS wire format) and key tag of the problematic DNSKEY, using the following format:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG | NAME \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Diagnostic code 513: Local policy disallows a DNSKEY being used to validate a record on the grounds that it is too small. The supplemental data contains the nam5 and tag of the problematic key, in the format specified in .

Diagnostic code 514: Local policy does not authorize a key to be used for validation. The supplemental data contains the name and tag of the problematic key, in the format specified in .

Diagnostic code 515: Local policy prohibits validation using a given signing algorithm. The supplemental data contains a 16-bit unsigned integer indicating which algorithm has been disallowed.

Diagnostic code 516: Local policy disallows accepting signatures created by this signer. The supplemental data contains the name of the signer that has been disallowed.

Diagnostic code 517: There is no trust anchor for the chain of trust needed to validate this data, but local policy requires validation. This code has no supplemental data.

Diagnostic code 518: The chain of trust is longer than local policy permits. This code has no supplemental data.

Diagnostic code 519: The response to this query has been blocked by local policy. This code has no supplemental data.

These are error conditions occurring from DNSSEC processing which are time-dependent: i.e., problems due to signature validity interval or key expiry.

Diagnostic code 768: An RRSIG is past its useful lifetime. The supplemental data contains the name and covering RR type of the failed RRSIG, in the format specified in .

Diagnostic code 769: An RRSIG has not yet begun its useful lifetime. The supplemental data contains the name and covering RR type of the invalid RRSIG, in the format specified in .

Diagnostic code 770: A trust anchor can no longer be used. The supplemental data contains the name of the expired trust anchor in wire format.

These error conditions due to DNSSEC processing are always fatal, regardless of time or local policy.

Diagnostic code 1024: Cryptographic validation failed. The supplemental data contains the name and RR type of data which failed to validate, in the format specified in .

Diagnostic code 1025: There was no RRSIG found for an RRset, but one should have been present. The supplemental data contains the name and RR type of the data that should have been signed, in the format specified in .

Diagnostic code 1026: No DNSKEY was found, but one should have been present. The supplemental data contains the zone apex name at which the DNSKEY should have been found, in wire format.

Diagnostic code 1027: RRSIG records have been found for an RRset which is to be validated, but none of them has a key tag matching a valid DNSKEY. The supplemental data contains the name and covering RR type for the faulty RRSIG, in the format specified in .

Diagnostic code 1028: No DS record was found, but there should have been one present. The supplemental data contains the name at which the DS record should have been found.

Diagnostic code 1029: No NSEC or NSEC3 record was found, but there should have been one present. The supplemental data contains the name and RR type (NSEC or NSEC3) of the record that was expected, in the format specified in .

Diagnostic code 1030: The "next owner" name in an NSEC or NSEC3 record goes beyond another record which is known to exist. The supplemental data contains the name and RR type (NSEC or NSEC3) of the invalid record, in the format specified in .

Diagnostic code 1031: The ordering of records in the NSEC or NSEC3 chain does not follow canonical ordering rules. The supplemental data contains the name and RR type (NSEC or NSEC3) of the invalid record, in the format specified in .

Diagnostic code 1032: A proof of non-existence was provided for a record whose non-existence did not need to be proven. This code has no supplemental data.

Diagnostic code 1033: Proof of non-existence is incomplete. The supplemental data contains the name and RR type of the data whose non-existence needed to be proven, in the format specified in .

Diagnostic code 1034: The RRSIG being used for verification is incorrect for the RR in question. The supplemental data contains the name and covering RR type of the invalid RRSIG, in the format specified in .

Diagnostic code 1035: The DNSKEY protocol value is not set to 3. The supplemental data contains the name and tag of the faulty key, in the format specified in .

Diagnostic code 1036: A mismatch was found between the DNSKEY in a zone and the DS record in the parent. The supplemental data contains the name and tag of the DNSKEY that should have been found, in the format specified in .

Diagnostic code 1037: An algorithm specified in a DNSKEY, DS, RRSIG, NSEC3 or NSEC3PARAM record is not recognized by the server. The supplemental data contains the name and RR type of the record that referenced the invalid algorithm.

Diagnostic code 1038: An algorithm specified in a DNSKEY, DS, RRSIG, NSEC3 or NSEC3PARAM record is recognized by the server but is not implemented. The supplemental data contains the name and RR type of the record that referenced the unsupported algorithm.

Diagnostic code 1039: The key that is used to verify signatures on zone data does not have the "Zone Key" flag set. The supplemental data contains the name and tag of the faulty key, in the format specified in .

Diagnostic code 1040: A key that is required to complete a chain of trust has its REVOKED bit set. The supplemental data contains the name and tag of the revoked key, in the format specified in .

An ESD option response contains channel diagnostic data, to be used for logging, troubleshooting, and debugging; it falls outside the scope of DNSSEC per se. Ensuring integrity of the response requires the use of a channel security mechanism such as TSIG or SIG(0) . In the absence of any such mechanism, ESD responses MUST NOT be used by clients to make policy decisions with respect to DNSSEC validation, as this could allow an attacker to force a security downgrade or denial of service by forging SERVFAIL messages containing particular ESD responses. Some of the data in an ESD option response may be security sensitive, particularly those responses which increase the transparency of the current state of a running resolver. In the case of SERVFAIL responses due to authoritative server misconfiguration or other non-local conditions, this is generally not a concern, as the data which caused the failure are readily available in the DNS and can be obtained by other means. However, information about server failures due to local problems such as out-of-memory conditions may be of tactical use to an attacker. Implementors may wish to provide a mechanism for operators to disable certain types of diagnostic response while allowing others.

IANA is requested to make the assignments in this section.

This document requests the allocation of an EDNS(0) option code for the ESD option, whose value is [TBD].

This document requests the creation of a new registry of ESD diagnostic codes. The registry policy is "Specification Required" . The initial entries in the registry are: Value Description Reference 0 No Error 1 Internal Error [This] 2 Out of Memory [This] 3 Resource Unavailable [This] 4 Zone Not Loaded [This] 5 Invalid Zone [This] 6 Configuration Error [This] 7 Timeout [This] 8 Shutting Down [This] 9-255 Unassigned 256 Lame Delegation [This] 257 Name Expansion Failure [This] 258 Protocol Not Supported [This] 259-511 Unassigned 512 Key Too Large [This] 513 Key Too Small [This] 514 Key Not Authorized [This] 515 Algorithm Refused [This] 516 Unauthorized Signer [This] 517 No Trust Anchor [This] 518 Too Many Links [This] 519 Response Blocked [This] 520-767 Unassigned 768 Signature Expired [This] 769 Signature Not Yet Active [This] 770 Trust Anchor Expired [This] 771-1023 Unassigned 1024 Bogus Data [This] 1025 Signature Missing [This] 1026 DNSKEY Missing [This] 1027 Key Tag Mismatch [This] 1028 DS Missing [This] 1029 Next-Secure Record Missing [This] 1030 Overreaching Next-Secure Record [This] 1031 Next-Secure Record Pointing Backward [This] 1032 Irrelevant Proof [This] 1033 Incomplete Proof [This] 1034 Wrong RRSIG Owner [This] 1035 Unknown DNSKEY Protocol [This] 1036 DS/DNSKEY Mismatch [This] 1037 Unknown Algorithm [This] 1038 Algorithm Not Supported [This] 1039 Not a Zone Key [This] 1040 Key Revoked [This] 1041-65535 Unassigned

Thanks to Wes Hardaker, Jakob Schlyter, Sam Weiler and Francis Dupont for assistance in categorizing SERVFAIL error types, and Paul Vixie for design input.

Information Sciences Institute (ISI) USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Internet Software Consortium

950 Charter Street Redwood City CA 94063 US +1 650 779 7001 vixie@isc.org

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK] This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</t><t> This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.</t><t> This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]