CZ.NIC

libor.peltan@nic.cz

NLnet Labs

tomcarpay@gmail.com

Internet-Draft This document describes the textual and JSON representation formats of EDNS options. It also modifies the escaping rules of the JSON representation of DNS messages, previously defined in RFC8427.

Introduction A DNS record of any type can be converted between its binary Wire format and textual Presentation format. The Wire format is used in DNS messages transferred over the Internet, while the Presentation format is used not only in Zone Files (called "master files" in the referenced document), but also to display the contents of DNS messages to humans by debugging utilities and possible other use-cases. The Presentation format can, however, be processed programatically and also converted back to Wire Format unambiguously. The EDNS option pseudo-record does not appear in Zone Files, but it sometimes needs to be converted to human-readable or even machine-readable textual representation. This document describes such a Presentation Format of the OPT pseudo-record. It is advised to use this when displaying an OPT pseudo-record to humans. It is recommended to use this when the textual format is expected to be machine-processed further. The JSON representation of DNS messages is also helpful as both human-readable and machine-readable format (despite the limitation in non-preservation of the order of options and possible issues with repeated options, which prevents reversing the conversion unambiguously), but it did not define a JSON representation of EDNS option pseudo-record. This document defines it. The aforementioned document also defined ambiguous and possibly conflicting rules for escaping special characters when representing DNS names in JSON. This document modifies and clarifies those rules.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document is to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Base16 is the representation of arbitrary binary data by an even number of case-insensitive hexadecimal digits (). Backslash is the character, also called Reverse Solidus, ASCII code 0x5c. ID-string is a string of characters containing only (uppercase or lowercase) letters, digits, dashes, and underscores, and its first character is a (uppercase or lowercase) letter. "Note" denotes a sentence that is not normative. Instead, it points out some non-obvious consequences of previous statements.

Generic EDNS Presentation Format A malformed EDNS record or a record of an unsupported EDNS version can be converted to Presentation format using this generic method. OPT pseudo-record is, in this case, represented the same way as a RR of unknown type according to . In specific: Owner Name is the Owner Name of the OPT record. Note that this is usually . (DNS Root Domain Name) unless malformed. TTL is the 32-bit big-endian integer appearing at the TTL position of the OPT pseudo-record Wire format, see . CLASS is a text representation of the 16-bit integer at the CLASS position of the OPT pseudo-record Wire format (UDP payload size happens to appear there). This will usually result in CLASS#### (where #### will be the integer), but it might also result, for example in IN or CH if the value is 1 or 4, respectively. TYPE is either TYPE41 or OPT. RDATA is formatted by \#, its length as a decadic number, and data as Base16 as per . Example:

Generic EDNS JSON representation A malformed EDNS record or a record of an unsupported EDNS version can be converted to JSON using this generic method. The OPT pseudo-record is, in this case, represented in JSON as an object with following members: NAME - String with the Owner Name of the OPT record. Note that this is usually . (DNS Root Domain Name) unless malformed. See for representing DNS names in JSON. TTL - Integer with the 32-bit big-endian value appearing at the TTL position of the OPT pseudo-record Wire format, see . CLASS - Integer with the 16-bit value at the CLASS position of the OPT pseudo-record Wire format (UDP payload size happens to appear there). TYPE - Integer with the value 41. RDATAHEX - String with the pseudo-record RDATA formatted as Base16. Example:

Common Concept In order to represent the binary data from EDNS option textually, we first define the abstract concept of FIELDs. First four FIELDs represent the OPT record header, one more FIELD represents every EDNS option that appears in the OPT record RDATA. Each FIELD has a defined FIELD-NAME, which is an ID-string; a specific FIELD-TYPE from the list below; and prescribed way how to construct the FIELD-VALUE from given binary data. Based on those, the Presentaion and JSON formats are defined in and , respectively. The FIELD-NAMEs of FIELDs representing the OPT record header are version, flags, rcode and udpsize. The FIELD-NAMEs of FIELDs representing EDNS options are defined as their Mnemonics according to (see also ). A FIELD-TYPE can be one of following: int, a non-negative integer ID-NAME, a mnemonic string denoting a numeric value defined by this document, other referenced RFC, and/or referenced IANA table; mnemonics that are not ID-strings MUST NOT be used ID-CODE, a non-negative integer prefixed with a fixed ID-string mixed, a variant type that can be any of the above-defined types base16, an even number of hexadecimal (case-insensitive) digits representing a string of arbitrary octets list, a variable-sized (possibly empty) list of values of homogenous type defined above (possibly mixed) dname, a Fully-Qualified Domain Name string, a string of arbitrary octets where quoting and escaping is used to represent it as ASCII string object, a defined fixed number of SUBFIELDs, each having its FIELD-NAME and FIELD-TYPE defined according to the rules above (nested objects are forbidden) The FIELD-TYPE and the construction of FIELD-VALUE of each FIELD is defined in .

EDNS Presentation Format The EDNS Presentation Format follows the RR format of the master file (), including quotation of non-printable characters, multi-line format using round brackets, and semicolons denoting comments. However, one difference is that <character-string>s are not limited in size (to 255 represented octets). Depending on the use-case, implementations MAY choose to display only RDATA. In the event that the resource-record-like Presentation format is desired, the following applies: Owner Name MUST be . (DNS Root Domain Name). TTL MAY be omitted. If it is present, it MUST be 0 (zero). Note that this differs from DNS RR wire-to-text conversion as well as Generic Presentation Format. CLASS MAY be omitted. If it is present, it MUST be ANY. TYPE MUST be EDNS. RDATA consists of <character-string>s, each FIELD is represented by at least two of them. First represented FIELDs are version, flags, rcode, and udpsize in this order; however, version MAY be omitted if the EDNS Version is zero. The rest of FIELDs respect the EDNS options in the same order as they appear in the OPT record, including possibly repeated options. The following paragraph defines how a single FIELD is represented with <character-string>s. The first <character-string> is the FIELD-NAME concatenated (no spaces in between) with a colon (:) and SHOULD NOT be enclosed in quotes. The rest depends on the FIELD-TYPE: int is represented as a decadic number with no leading zeroes ID-NAME or ID-CODE is represented as-is base16 is represented as-is, zero-length base16 as an empty string enclosed in quotes ("") list is represented as a comma-separated list of its items with no spaces; an empty list as an empty string enclosed in quotes ("") dname is represented according to the rules of representing Domain names in the master file (); Internationalized Domain Name (IDN) labels MAY be expressed in their U-label form, as described in . string is represented as <character-string> according to ; and SHOULD be enclosed in quotes even when not containing any spaces object is represented by the same number of <character-string>s as how many SUBFIELDs it has; their FIELD-NAMEs are ignored and FIELD-VALUEs are represented in their defined order Note that each object has fixed number of <character-string>s, other types have one. This is cruical for parsing, the colon plays only decorative role, strings might also end with a colon.

EDNS Representation in JSON The EDNS OPT record can be represented in JSON as an object called EDNS. Each FIELD is represented as one object member (name-value pair) ,where the name is FIELD-NAME and the value depends on FIELD-TYPE: int is represented as an Integer ID-NAME, ID-CODE or base16 is represented as a String mixed is represented as a String even when it happens to be int list is represented as a JSON Array containing its members in specified order dname is represented as a String with quotation rules in string is represented as a String according to object is represented as a JSON object with each SUBFIELD represented as one of its member according to rules above (note that nested objects are forbidden) Note that the order of members is not preserved in JSON and that repeated options might cause issues in JSON. The FIELDs flags, rcode, and udpsize MUST be represented, version MAY be omitted if the EDNS Version is zero.

Field Definitions

Version EDNS Version is represented by FIELD-NAME version, its FIELD-TYPE is int and FIELD-VALUE is the EDNS Version.

Flags EDNS FLAGS is represented by FIELD-NAME flags and its FIELD-TYPE is a list of mixed: ID-NAME DO if the DO bit is set ID-CODE BITn for each n-th bit (other than DO) set Examples of Presentation format:

Extended RCODE Extended RCODE is represented by FIELD-NAME rcode and its FIELD-TYPE is a mixed. For the sake of readability, it is RECOMMENDED to compute the whole DNS Message Extended RCODE from both the OPT record and the DNS Message Header. If the whole DNS Message Extended RCODE is computed and has a mnemonic in , the FIELD-VALUE MAY be this mnemonic as ID-NAME. If the whole DNS Message Extended RCODE is computed and no mnemonic is available (or used), the FIELD-VALUE is an int with the computed Extended RCODE. If the whole DNS Message Extended RCODE cannot be computed, the FIELD-VALUE is an ID-CODE EXT##, where ## stands for DNS Message Extended RCODE with the lower four bits set to zero (i.e. the four-bit left shift still applies). Examples of Presentation format:

UDP Payload Size UDP Payload Size is represented by FIELD-NAME udpsize, its FIELD-TYPE is int and FIELD-VALUE is the UDP Payload Size.

Unrecognized Option EDNS options that are not part of this specification, and their own specifications do not specify their FIELD-NAME and FIELD-VALUE MUST be displayed according to this subsection. Other options (specified below or otherwise) MAY be displayed so as well. Unrecognized EDNS option is represented by FIELD-NAME OPT##, where ## stands for its OPTION-CODE, its FIELD-TYPE is base16 and FIELD-VALUE is its OPTION-VALUE encoded as Base16.

LLQ Option The LLQ (OPTION-CODE 1 ) option is represented as unrecognized (), since this option has been deprecated since year 2020.

NSID Option The NSID (OPTION-CODE 3 ) option is represented by FIELD-NAME NSID and its FIELD-VALUE is an object with two SUBFIELDs in the following order: first FIELD-NAME is HEX and FIELD-VALUE is a base16 representation of the OPTION-VALUE second FIELD-NAME is TEXT and FIELD-VALUE is a string representation of the OPTION-VALUE The TEXT value MAY be substituted with an empty string (for example, if the OPTION-VALUE contains non-printable characters). Within JSON, the TEXT SUBFIELD MAY be omitted if it is an empty string.

DAU, DHU and N3U Options The DAU, DHU, and N3U (OPTION-CODES 5, 6, 7, respectively ) options are represented by FIELD-NAMEs DAU, DHU, and N3U, respectively, and their FIELD-VALUES are lists of ints with their ALG-CODEs. Within Presentation format, their FIELD-VALUEs MAY be substituted with lists of ID-NAMEs with the textual mnemonics of the ALG-CODEs found in their respective IANA registries . Examples of Presentation format:

Edns-Client-Subnet Option The EDNS Client Subnet (OPTION-CODE 8 ) option is represented by FIELD-NAME ECS and its FIELD-TYPE is a string. If FAMILY is either IPv4 (1) or IPv6 (2) and the OPTION-LENGTH matches the expected length, the FIELD-VALUE is a slash-separated (no spaces) tuple of: the textual IPv4 or IPv6 address ( or , respectively) SOURCE PREFIX-LENGTH as a decadic number SCOPE PREFIX-LENGTH as a decadic number, SHOULD be omitted (including the separating slash) if zero Otherwise, the FIELD-VALUE is a string with base16-representation of the OPTION-VALUE. Examples of Presentation format:

EDNS EXPIRE Option The EDNS EXPIRE (OPTION-CODE 9 ) option is represented by FIELD-NAME EXPIRE and its FIELD-VALUE is a mixed: ID-NAME NONE if OPTION-LENGTH is zero int with EXPIRE value otherwise

Cookie Option The DNS Cookie (OPTION-CODE 10 ) option is represented by FIELD-NAME COOKIE and its FIELD-VALUE is a list of base16 with the Client Cookie and, if OPTION-LENGTH is greater than 8, the Server Cookie.

Edns-Tcp-Keepalive Option The edns-tcp-keepalive (OPTION-CODE 11 ) option is represented by FIELD-NAME KEEPALIVE and its FIELD-VALUE is an int with the TIMEOUT in tenths of seconds.

Padding Option The Padding (OPTION-CODE 12 ) option is represented by FIELD-NAME PADDING and its FIELD-VALUE is an object with two SUBFIELDs: first FIELD-NAME is LENGTH and its FIELD-VALUE is the OPTION-LENGTH as int second FIELD-NAME is HEX and its FIELD-VALUE is a string with base16-representation of OPTION-DATA If the OPTION-DATA consists only of zeroes (0x00 octets), the HEX SUBFIELD SHOULD be an empty string. Within JSON, the HEX SUBFIELD MAY be omitted if it is an empty string.

CHAIN Option The CHAIN (OPTION-CODE 13 ) option is represented by FIELD-NAME CHAIN and its FIELD-VALUE is the Closest trust point as dname.

Edns-Key-Tag Option The edns-key-tag (OPTION-CODE 14 ) option is represented by FIELD-NAME KEYTAG and its FIELD-VALUE is the list of Key Tag values as list of ints.

Extended DNS Error Option The Extended DNS Error (OPTION-CODE 15 ) option is represented by FIELD-NAME EDE and its FIELD-VALUE is an object with three SUBFIELDs: first FIELD-NAME is CODE and its FIELD-VALUE is the INFO-CODE as int second FIELD-NAME is Purpose and its FIELD-VALUE is the Purpose (first presented in and then governed by ) as string, or an empty string third FIELD-NAME is TEXT and its FIELD-VALUE is the EXTRA-TEXT as string (possibly of zero length) Within JSON, the Purpose SUBFIELD MAY be omitted if it is an empty string. The same applies for TEXT SUBFIELD. Examples of Presentation format:

Report-Channel Option The Report-Channel (OPTION-CODE 18) option is represented by FIELD-NAME REPORT and its FIELD-VALUE is the AGENT DOMAIN as dname. Example of JSON format:

Examples of EDNS Presentation Format The following examples shall illustrate the features of EDNS Presentation format described above. They may not make much sense and should not appear in normal DNS operation.

Examples of EDNS Representation in JSON The following examples are the JSON equivalents of the examples in . They may not make much sense and should not appear in normal DNS operation.

Guidelines for Future EDNS Options This draft describes the presentation and JSON format of those ENDS options that are known at the time of writing. Other EDNS options fall in the category of Unrecognized Options (), unless specified otherwise. The following guidelines shall help define them. When defining new EDNS options, it is recommended to specify their FIELD-NAMEs, FIELD-TYPEs and the construction of FIELD-VALUEs so that the EDNS Presentation and JSON format comprehensibly handles them. Those formats should follow the semantics of the options' values rather than the syntax in order to make them more human-readable. If it is necessary to define a new FIELD-TYPE, care must be taken to define its representation in Presentation and JSON format in a similar fashion like in this document. The FIELD-NAME MUST always be an ID-string and MUST be added as new option's Mnemonic when requesting IANA to add respective entry to the table .

Forward-Compatibility Considerations This specification of ENDS Presentation and JSON format prefers displaying textual mnemonics over potentially cryptic numeric values wherever possible, which is desirable for human readers. It refers to several IANA tables collecting the definitions of those mnemonics. Those tables may be getting updated throughout time, and for human readers, it is still beneficial that the EDNS formats reflect those updates. However, this may cause difficulties for algorithms implementing the reverse process of converting EDNS Presentation and/or JSON format back to wire format, because they might not understand some new mnemonics. This limitation has to be taken into consideration. Similarly, new documents may define Presentation and JSON format of newly defined EDNS options according to (or not according to) the guidelines above (). This is, again, beneficial for human readers, as otherwise all new EDNS options would have to be represented as Unrecognized Options (). However, this may also cause difficulties for algorithms implementing the reverse process of converting EDNS Presentation and/or JSON format back to wire format, because they might not understand some new options.

Update Representing DNS Messages in JSON This section is not related to EDNS. This section updates , including erratum 5439, which introduced contradicting MUSTs for escaping backslashes. In order to solve this contradiction and correctly represent a DNS name in JSON, it MUST be first converted to textual Presentation format according to (called master file format in the referenced document), and the resulting <character-string> subsequently is inserted into JSON as String (). Note that the previous paragraph prescribes the following escaping strategy: In the first step, every problematic character (non-printable, backslash, dot within Label, or any octet) is either substituted with the sequence \DDD, where DDD is the three-digit decimal ASCII code, or in some cases (backslash, dot, any printable character) just prepended with a backslash. In the second step, every quote (") and backslash (\) in the resulting <character-string> is prepended with another backslash. Note that the JSON escaping sequence \uXXXX (where XXXX is a hexadecimal Unicode code) is thus never needed. Moreover, the following requirements from still hold: The name MUST be represented as an absolute Fully-Qualified Domain Name. Internationalized Domain Name (IDN) labels MUST be expressed in their A-label form, as described in . Example: the name with the Wire format 04005C2E2203636F6D00 can be represented in JSON as:

but also as (among other ways):

IANA Considerations IANA is requested to augment the table with a new column titled "Mnemonic", possibly as third column between "Name" and "Status". The initial values for existing entries are according to the table below: Value Name Mnemonic 1 LLQ LLQ 2 UL UL 3 NSID NSID 5 DAU DAU 6 DHU DHU 7 N3U N3U 8 edns-client-subnet ECS 9 EDNS EXPIRE EXPIRE 10 COOKIE COOKIE 11 edns-tcp-keepalive KEEPALIVE 12 Padding PADDING 13 CHAIN CHAIN 14 edns-key-tag KEYTAG 15 Extended DNS Error EDE 18 Report-Channel REPORT The values for entries and rows that are unassigned, reserved or on-hold are to be left blank with no Mnemonic defined.

Security Considerations This document only describes the textual representation of binary data and therefore has no security impact on related protocols. When implementing software, care must be taken to handle possibly inconsistent or broken input data.

Acknowledgements TODO

Implementation Status Note to the RFC Editor: Please remove this entire appendix before publication. This version of this specification draft-peltan-edns-presentation-format-02 has been implemented in Knot DNS 3.3.2.

Change History Note to the RFC Editor: Please remove this entire appendix before publication. edns-presentation-format-00

• Initial public draft.

edns-presentation-format-01

• Added Guidelines for Future EDNS Options, dummy IANA Considerations and Security Considerations.

edns-presentation-format-02

• Substantial re-work with common FIELD-TYPE specifications, bigger changes in presentation format and smaller in JSON.

edns-presentation-format-03

• Added IANA Actions for additional column for Mnemonic. Added Report-Channel option and removed LLQ. Improved Common concept, tiny fixes.

This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. 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 requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios. 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement. The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications. With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK] This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries. DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets. This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks. The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.