]> Google, LLC

ietf@tapril.net

ISC

pspacek@isc.org

Akamai Technologies

rweber@akamai.com

Salesforce

tale@dd.org

Internet deleg Internet-Draft DNS delegation A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation of the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the deleg Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In the Domain Name System, subdomains within the domain name hierarchy are indicated by delegations to servers which are authoritative for their portion of the namespace. The DNS records that do this, called NS records, contain hostnames of nameservers, which resolve to addresses. No other information is available to the resolver. It is limited to connect to the authoritative servers over UDP and TCP port 53. This limitation is a barrier for efficient introduction of new DNS technology. The proposed DELEG and DELEGI record types remedy this problem by providing extensible parameters to indicate capabilities and additional information, such as addresses that a resolver may use for the delegated authority. The DELEG record is authoritative and thus signed in the parent side of the delegation making it possible to validate all delegation parameters with DNSSEC. This document only shows how a DELEG record can be used instead of or along side a NS record to create a delegation. Future documents can use the extensible mechanism for more advanced features like connecting to a name server with an encrypted transport.

Terminology 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 when, and only when, they appear in all capitals, as shown here. Terminology regarding the Domain Name System comes from , with addition terms defined here:

• legacy name servers: An authoritative server that does not support the DELEG record
• legacy resolvers: A resolver that does not support the DELEG record
• DELEG-aware: An authoritative server or resolver that follows the protocol defined in this document

DELEG and DELEGI Record Types The DELEG record (whose RRtype is TBD) has Rdata is one field, a list of key-value pairs called "delegation information". The delegation information field has wire and display formats that are based on the rules in Appendix A of . A DELEG record is authoritative for the named zone, and creates a delegation and thus lives in the parent of the named zone. The DELEGI record has the identical format as the DELEG record. The use of the DELEGI record is different from the use of the DELEG record: it gives information about delegation. DELEGI records are treated like regular authoritative records in their zone. Some delegation information key-value pairs are actions that a DELEG-aware resolver takes when it gets a DELEG or DELEGI record. The actions defined in this document are described briefly here, and more fully described in .

• server-ip4: a set of IPv4 addresses for nameservers of the given zone
• server-ip6: a set of IPv6 addresses for nameservers of the given zone
• server-name: the domain name of a nameserver of the given zone; the addresses must be fetched
• include-name: the domain name of a zone that has more information about the nameservers of the given zone

Future documents might define additional delegation information that are actions, and might also define delegation information key-value pairs that modify actions. TODO: Add some introduction comparing how resolvers see legacy delegatation (set of NS and A/AAAA records) and DELEG delegation (DELEG and DELEGI records with server-ip4 and server-ip6 keys)

Use of DELEG Records A DELEG RRset MAY be present at a delegation point. The DELEG RRset MAY contain multiple records. DELEG RRsets MUST NOT appear at a zone's apex. A DELEG RRset MAY be present with or without NS or DS RRsets at the delegation point.

Resolvers

Signaling DELEG support A resolver that is DELEG-aware MUST signal its support by sending the DE bit when iterating. This bit is referred to as the "DELEG" (DE) bit. In the context of the EDNS0 OPT meta-RR, the DE bit is the TBD of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, structured as follows (to be updated when assigned): Setting the DE bit to one in a query indicates the resolver understands new DELEG semantics and does not need NS records to follow a referral. The DE bit cleared (set to zero) indicates the resolver is unprepared to handle DELEG and hence can only be served NS, DS and glue in a delegation response. Motivation: For a long time there will be both DELEG and NS needed for delegation. As both methods should be configured to get to a proper resolution it is not necessary to send both in a referral response. We therefore purpose an EDNS flag to be use similar to the DO Bit for DNSSEC to be used to signal that the sender understands DELEG and does not need NS or glue information in the referral.

Referral The DELEG record creates a zone cut similar to the NS record. If one or more DELEG records exist at a given delegation point, a DELEG-aware resolver MUST treat the name servers from those DELEG records as authoritative for the child zone. In such case, a DELEG-aware resolver MUST NOT use NS records even if they happen to be present in cache, even if resolution using DELEG records have failed for any reason. Such fallback from DELEG to NS would invalidate security guarantees of DELEG protocol. If no DELEG record exists at a given delegation point, DELEG-aware resolvers MUST use NS records as specified by .

Parent-side types, QTYPE=DELEG Record types defined as authoritative on the parent side of zone cut (currently DS and DELEG types) retain the same special handling as described in Section 2.6 of . Legacy resolvers can get different types of answers for QTYPE=DELEG queries based on the configuration of the server, such as whether it is DELEG-aware and whether it also is authoritative for subdomains.

Algorithm for "Finding the Best Servers to Ask" This document updates instructions for finding the best servers to ask. That information currently is covered in Section 5.3.3 of and Section 3.4.1 of with the text "2. Find the best servers to ask." Section 3.1.4.1 of should have explicitly updated Section 5.3.3 of for the DS RRtype, but failed to do so; this was remedied by . This document simply extends this existing behavior to DELEG RRtype as well, and makes this special case explicit. When a DELEG RRset exists in a zone, DELEG-aware resolvers ignore the NS RRset for that zone. This means that the DELEG-aware resolver ignores the NS RRset in the zone's parent as well as any cached NS RRset that the resolver might have gotten by looking in the apex of the zone. DELEG and NS RRtypes can be used differently at each delegation level, and DELEG-aware resolvers MUST be able follow chains of delegations which combines both types in arbitrary ways. An example of a valid delegation tree: TODO: after the text below, refer back to this figure and show the order that a DELEG-aware resolver would take when there is a failure to find any good DELEG addresses at sub.sld.test, then any usable nameservers at sub.sld.test, and then maybe a good DELEG record at test. The terms SNAME and SLIST used here are defined in Section 5.3.2 of : SNAME is the domain name we are searching for. SLIST is a structure which describes the name servers and the zone which the resolver is currently trying to query. Neither nor this document define how a resolver uses SLIST; they only define how to populate it. A DELEG-aware SLIST needs to be able to hold two types of information: delegations defined by NS records and delegations defined by DELEG records. DELEG and NS delegations can create cyclic dependencies and/or lead to duplicate entries which point to the same server. Resolvers need to enforce suitable limits to prevent damage even if someone has incorrectly configured some of the data used to create an SLIST. This leads to a modified description of find the best servers to ask" from earlier documents for DELEG-aware resolvers. That description becomes:

1. Determine deepest possible zone cut which can potentially hold the answer for given (query name, type, class) combination:
   1. Start with SNAME equal to QNAME.
   2. If QTYPE is a type that is authoritative at the parent side of a zone cut (currently, DS or DELEG), remove the leftmost label from SNAME. For example, if the QNAME is "test.example." and th eQTYPE is DELEG or DS, set SNAME to "example.".
2. Look for locally-available DELEG and NS RRsets, starting at current SNAME.
   1. For given SNAME, check for existence of a DELEG RRset. If it exists, the resolver MUST use its content to populate SLIST. However, if the DELEG RRset is known to exist but is unusable (for example, if it is found in DNSSEC BAD cache), the resolver MUST NOT instead use an NS RRset, even if it is locally available; instead, the resolver MUST treat this case as if no servers were available.
   2. If a given SNAME is proven to not have a DELEG RRset but does have NS RRset, the resolver MUST copy the NS RRset into SLIST.
   3. If SLIST is now populated, stop walking up the DNS tree. However, if SLIST is not populated, remove leftmost label from SNAME and go back to the first step, using the new (shortened) SNAME. Do not go back to the first step if doing so would exceed the amount of work that the resolver is configured to do when processing names; see .

The rest of the Step 2's description is not affected by this document. (TODO: Determine what to do about ". DELEG" or ". DS" queries, which by definition do not exist.)

Actions in Delegation Information The DELEG and DELEGI records have four keys that describe actions the resolver takes. The purpose of these actions is to populate the SLIST with IP addresses of the nameservers for a zone. The actions defined in this document are:

• server-ip4: a set of IPv4 addresses for nameservers of the given zone
• server-ip6: a set of IPv6 addresses for nameservers of the given zone
• server-name: the domain name of a nameserver of the given zone; the addresses must be fetched
• include-name: the domain name of a zone that has more information about the nameservers of the given zone

The presentation values for server-ip4 and server-ip6 are comma-separated list of one or more IP addresses of the appropriate family in standard textual format . The wire formats for server-ip4 and server-ip6 are a sequence of IP addresses in network byte order (for the respective address family). The presentation values for server-name and include-name are as full-qualified domain names. The wire formats are the same as the wire formats for domain names, and MUST NOT be compressed. If any of these keys are used, it MUST have a value (that is, it cannot be a key with a zero-length value). A DELEG or DELEGI record SHOULD have only one of the following:

• one server-ip4 key
• one server-ip6 key
• one server-ip4 and one server-ip6 key
• one server-name key
• one include-name key

Populating the SLIST from DELEG and DELEGI Records Each individual DELEG record inside a DELEG RRset, or each individual DELEGI record in a DELEGI RRset, can cause the addition of zero or more entries to SLIST. A resolver processes each individual DELEG record within a DELEG RRset, or each individual DELEGI record in a DELEGI RRset, using the following steps:

1. If one or more server-ip4 or server-ip6 actions are present inside the record, copy all the address values from either key into SLIST. Ignore any server-name or include-name keys that are (erroneously) present in the same record. Stop processing this record.
2. If a server-name action is present in the record, resolve it into addresses from the resolver cache or using A and AAAA queries. Copy these addresses into SLIST. Ignore any include-name keys that are (erroneously) present in the same record. Stop processing this record.
3. If a include-name action is present in the record, resolve it into a DELEGI RRset from the resolver cache or by sending queries for the domain name in the value of the include-name pair. Go through these same steps with the result of the DELEGI RRset, after checking that the maximum loop count described in has not been reached.
4. If none of the above applies, SLIST is not modified by this particular record.

A DELEG-aware resolver MAY implement lazy filling of SLIST, such as by deferring processing remaining records if SLIST already has what the resolver considers a sufficiently large pool of addresses to contact.

Authoritative Servers DELEG-aware authoritative servers act differently when handling queries from DELEG-unaware clients (those with DE=0) than from DELEG-aware clients (those with DE=1). The server MUST copy the value of the DE bit from the query into the response. (TODO: not really necessary protocol-wise, but might be nice for monitoring the deployment?)

DELEG-unaware Clients DELEG-unaware clients do not use DELEG records for delegation. When a DELEG-aware authoritative server responds to a DELEG-unaware client, any DELEG record in the response does not create zone cut, is not returned in referral responses, and is not considered authoritative on the parent side of a zone cut. Because of this, DELEG-aware authoritative servers MUST answer as if they are DELEG-unaware. Please note this instruction does not affect DNSSEC signing, i.e. no special handling for NSEC type bitmap is necessary and DELEG RRtype is accurately represented even for DELEG-unaware clients. Two specific cases of DELEG-aware authoritative responding in DELEG-unaware manner are described here.

DELEG-unaware Clients Requesting QTYPE=DELEG In DELEG-unaware clients, records with the DELEG RRtype are not authoritative on the parent side. Thus, queries with DE=0 and QTYPE=DELEG MUST result in a legacy referral response.

DELEG-unaware Clients with DELEG RRs Present but No NS RRs DELEG-unaware clients might ask for a name which belongs to a zone delegated only with DELEG RRs (that is, without any NS RRs). Such zone is, by definition, not resolvable for DELEG-unaware clients. In this case, the DELEG record itself cannot create a zone cut, and the DELEG-aware authoritative server MUST return a legacy response. The legacy response might be confusing for subdomains of zones which actually exist because DELEG-aware clients would get a different answer, namely a delegation. An example of a legacy response is in . The authoritative server is RECOMMENDED to supplement these responses to DELEG-unaware resolvers with Extended DNS Error "New Delegation Only". TODO: debate if WG wants to do explicit SERVFAIL for this case instead of 'just' EDE.

DELEG-aware Clients When the client indicates that it is DELEG-aware by setting DE=1 in the query, DELEG-aware authoritative servers treat DELEG records as zone cuts, and the servers are authoritative on parent side of zone cut. This new zone cut has priority over legacy delegation with NS RRset.

DELEG-aware Clients Requesting QTYPE=DELEG An explicit query for the DELEG RRtype at a delegation point behaves much like query for the DS RRtype: the server answers authoritatively from the parent zone. All previous specifications for special handling queries with QTYPE=DS apply equally to QTYPE=DELEG. In summary, server either provides an authoritative DELEG RRset or proves its non-existence.

Delegation with DELEG If the delegation has a DELEG RRset, the authoritative server MUST put the DELEG RRset into the Authority section of the referral. In this case, the server MUST NOT include the NS RRset into the Authority section. Presence of the covering RRSIG follows the normal DNSSEC specification for answers with authoritative zone data. Similarly, rules for DS RRset inclusion into referrals apply as specified by DNSSEC protocol.

DELEG-aware Clients with NS RRs Present but No DELEG RRs If the delegation does not have a DELEG RRset, the authoritative server MUST put the NS RRset into the authority section of the referral. Absence of DELEG RRset must be proven as specified by DNSSEC protocol for authoritative data. Similarly, rules for DS RRset inclusion into referrals apply as specified by the DNSSEC protocol. Please note in practice the same process and records are used to prove non-existence of DELEG and DS RRsets.

DNSSEC Signers The DELEG record is authoritative on the parent side of a zone cut and needs to be signed as such. Existing rules from DNSSEC specification apply. In summary: for DNSSEC signing, treat the DELEG RRtype the same way as the DS RRtype. In order to protect validators from downgrade attacks this draft introduces a new DNSKEY flag ADT (Authoritative Delegation Types). In zones which contain a DELEG RRset, this flag MUST be set to 1 in at least one of the DNSKEY records published in the zone.

DNSSEC Validators DELEG awareness introduces additional requirements on validators.

Clarifications on Nonexistence Proofs This document updates Section 4.1 of to include "NS or DELEG" types in type bitmap as indication of a delegation point, and generalizes applicability of ancestor delegation proof to all RRtypes that are authoritative at the parent (that is, both DS and DELEG). The text in that section is updated as follows: An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:

• the NS and/or DELEG bit set,
• the Start of Authority (SOA) bit clear, and
• a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR.

Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that (original) owner name other than types authoritative at the parent-side of zone cut (DS and DELEG), and all RRs below that owner name regardless of type.

Insecure Delegation Proofs This document updates Section 4.4 of to include secure DELEG support, and explicitly states that Opt-Out is not applicable to DELEG. The first paragraph of that section is updated to read: Section 5.2 of specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also MUST check for the presence of the NS or the DELEG bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation). Alternately, the validator must make sure that the delegation with NS record is covered by an NSEC3 RR with the Opt-Out flag set. Opt-Out is not applicable to DELEG RRtype because DELEG records are authoritative at the parent side of a zone cut in the same way that DS RRtypes are.

Referral downgrade protection When DNSKEY flag ADT is set to 1, a DELEG-aware validator MUST prove the absence of a DELEG RRset in referral responses for a zone. Without this check, an attacker could strip the DELEG RRset from a referral response and replace it with an unsigned (and potentially malicious) NS RRset. A referral response with an unsigned NS and signed DS RRsets does not require additional proofs of nonexistence according to pre-DELEG DNSSEC specification, and it would have been accepted as a delegation without DELEG RRset.

Chaining A Validating Stub Resolver that is DELEG-aware has to use a Security-Aware Resolver that is DELEG-aware and, if it is behind a forwarder, that forwarder has to be security-aware and DELEG-aware as well.

Security Considerations TODO: Add more here

Preventing Over-work Attacks Resolvers MUST prevent situations where accidental misconfiguration of zones or malicious attacks cause them to perform too much work when resolving. This document describes two sets of actions that, if not controlled, could lead to over-work attacks:

• Names with many subdomains can cause walking up the tree to populate SLIST () to be burdensome. To prevent this, the resolver SHOULD NOT walk up more than %%TODO: come up with a number%% labels in order to contribute to SLIST.
• Long chains of include-name actions (), and those with circular chains if include-name actions, can be burdensome. To prevent this, the resolver SHOULD NOT follow more than 3 include-name chains in an RRset when populating SLIST. Note that include-name chains can have CNAME steps in them; in such a case, a CNAME step is counted the same as a DELEGI step when determining when to stop following a chain.

IANA Considerations

Changes to Existing Registries IANA is requested to allocate the DELEG RR in the Resource Record (RR) TYPEs registry, with the meaning of "enhanced delegation information" and referencing this document. IANA is requested to assign a new bit in the DNSKEY RR Flags registry () for the ADT bit (N), with the description "Authoritative Delegation Types" and referencing this document. For compatibility reasons we request the bit 14 to be used. This value has been proven to work whereas bit 0 was proven to break in practical deployments (because of bugs). IANA is requested to assign a bit from the EDNS Header Flags registry (), with the abbreviation DE, the description "DELEG enabled" and referencing this document. IANA is requested to assign a value from the Extended DNS Error Codes (), with the Purpose "New Delegation Only" and referencing this document.

New Registry for Delegation Information IANA is requested to create the "DELEG Delegation Information" registry. This registry defines the namespace for delegation information keys, including string representations and numeric key values.

Procedure A registration MUST include the following fields: Number: Wire-format numeric identifier (range 0-65535) Name: Unique presentation name Meaning: A short description Reference: Location of specification or registration source Change Controller: Person or entity, with contact information if appropriate The characters in the registered Name field entry MUST be lowercase alphanumeric or "-". The name MUST NOT start with "key". The registration policy for new entries is Expert Review (). The designated expert MUST ensure that the reference is stable and publicly available and that it specifies how to convert the delegation information's presentation format to wire format. The reference MAY be any individual's Internet-Draft or a document from any other source with similar assurances of stability and availability. An entry MAY specify a reference of the form "Same as (other key name)" if it uses the same presentation and wire formats as an existing key. This arrangement supports the development of new parameters while ensuring that zone files can be made interoperable.

Initial Contents The "DELEG Delegation Information" registry should be populated with the following initial registrations:

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] 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 is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification. 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. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] 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. 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References 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. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. 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] This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK] Akamai Technologies Within the DNS, there is no mechanism for authoritative servers to advertise which transport methods they are capable of. If secure transport methods are adopted by authoritative operators, transport signaling would be required to negotiate how authoritative servers would be contacted by resolvers. This document provides two new Resource Record Types, NS2 and NS2T, to facilitate this negotiation by allowing zone owners to signal how the authoritative nameserver(s) for their zone(s) may accept queries.

Examples The following example shows an excerpt from a signed root zone. It shows the delegation point for "example." and "test." The "example." delegation has DELEG and NS records. The "test." delegation has DELEG but no NS records. TODO: Examples of using server-ip4 and server-ip6. Also, examples that show DELEGI records in ns2.example.net and ns3.example.org. The "test." delegation point has a DELEG record and no NS record.

Responses The following sections show referral examples:

DO bit clear, DE bit clear

Query for foo.example

Query for foo.test

DO bit set, DE bit clear

Query for foo.example

Query for foo.test

DO bit clear, DE bit set

Query for foo.example

Query for foo.test

DO bit set, DE bit set

Query for foo.example

Query for foo.test

Acknowledgments {:unnumbered} This document is heavily based on past work done by Tim April in and thus extends the thanks to the people helping on this which are: John Levine, Erik Nygren, Jon Reed, Ben Kaduk, Mashooq Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann, Gordon Marx and Brian Wellington. Work on DELEG protocol has started at IETF 118 hackaton. Hackaton participants: Christian Elmerot, David Blacka, David Lawrence, Edward Lewis, Erik Nygren, George Michaelson, Jan Včelák, Klaus Darilion, Libor Peltan, Manu Bretelle, Peter van Dijk, Petr Špaček, Philip Homburg, Ralf Weber, Roy Arends, Shane Kerr, Shumon Huque, Vandan Adhvaryu, Vladimír Čunát. Other people joined the effort after the initial hackaton: Ben Schwartz, Bob Halley, Paul Hoffman, ...

TODO

RFC EDITOR:

PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.

• Write a security considerations section
• Change the parameters form temporary to permanent once IANA assigned. Temporary use:
  • DELEG QType code is 65432
  • DELEG EDNS Flag Bit is 3
  • DELEG DNSKEY Flag Bit is 0