From c163d5ffc4cdef376085620ab57fa261e0a94aae Mon Sep 17 00:00:00 2001 From: tale Date: Sat, 11 Nov 2023 22:00:27 -0500 Subject: [PATCH 1/4] More exposition on motivation and use cases. --- draft-dnsop-deleg-transport.md | 101 ++++++++++++++++++--------------- draft-dnsop-deleg.md | 27 ++++++--- 2 files changed, 74 insertions(+), 54 deletions(-) diff --git a/draft-dnsop-deleg-transport.md b/draft-dnsop-deleg-transport.md index d6b2777..b10c6d2 100644 --- a/draft-dnsop-deleg-transport.md +++ b/draft-dnsop-deleg-transport.md @@ -100,76 +100,82 @@ contributor: --- abstract -This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in {{?I-D.draft-dnsop-deleg}}, with ability to specify transport protocols and authentication parameters supported by name servers. +This document extends the DNS DELEG record, and SVCB records pointed to by the DELEG record, as defined in {{?I-D.draft-dnsop-deleg}}, with the ability to specify transport protocols and authentication parameters supported by nameservers. --- middle # Introduction -The new delegation mechanism based on DELEG record type allows to specify attributes a resolver can use when talking to a delegated authority. This document introduces parameters specific to different transport mechanism than the default udp/53 protocol. +The new Domain Name System delegation mechanism based on the DELEG record type allows an authoritative nameserver to specify attributes a resolver can use when talking to another delegated authority. This document introduces parameters specific to different transport mechanisms than the default DNS protocol transports of udp and tcp to port 53. -Legacy DNS resolvers unaware of DELEG mechanism would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch to new transports. +Legacy DNS resolvers that are unaware of the DELEG mechanism would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch to new transports. ## 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 \\ +"OPTIONAL" in this document are to be interpreted as described in BCP 14 {{?RFC2119}} {{?RFC8174}} when, and only when, they appear in all capitals, as shown here. Terminology regarding the Domain Name System comes from {{?BCP219}}, with addition terms defined here: -* [tbd] +* transport parameters The set of attributes that define how to reach the nameserver specified in a ServiceMode DELEG record. * [tbd] ## Introductory Examples -To introduce DELEG record with DNS-over-TLS {{?RFC7858}}, this example shows a possible response from an authoritative in the authority section of the DNS response when delegating to another nameserver. - +To use a DELEG record to point a resolver to an authority that supports DNS-over-TLS {{?RFC7858}}, this example shows a possible response from an authoritative server in the Authority section of the DNS response: - example.com. 86400 IN DELEG 1 ns2.example.com. ( + example.com. 86400 IN DELEG 1 ns2.example.com. ( alpn=dot tlsa="2 0 1 ABC..." ipv4hint=192.0.2.54 ipv6hint=2001:db8:2423::3 ) - example.com. 86400 IN NS ns1.example.com. - ns1.example.com. 86400 IN A 192.0.2.1 - ns1.example.com 86400 IN AAAA 2001:DB8::1 + example.com. 86400 IN NS ns1.example.com. -In this example, the authoritative nameserver is delegating using DNS-over-TLS. -Like in SVCB, DELEG also offer the ability to use the AliasMode delegation. The example below shows an example where example.com is being delegated with a DELEG AliasMode record which can then be further resolved using standard SVCB to locate the actual parameters. +The alpn attribute specifies DNS-over-TLS, with the tlsa attribute +providing the necessary cryptographic material to establish the +connection. The ipv4hint and ipv6hint serves the traditional role of +glue, since the ns2 server lives in the example.com zone. - example.com. 86400 IN DELEG 0 config2.example.net. - example.com. 86400 IN NS ns1.example.net. +The Additional section would continue to serve glue records for the +nameservers within example.com as well, for the benefit of legacy +resolvers. Note that these could potentially be the same addresses as +are used in the hints of a DELEG record; NS and DELEG are orthogonal. -The example.net authoritative server may return the following SVCB records in response to a query as directed by the above records. + ns1.example.com. 86400 IN A 192.0.2.1 + ns1.example.com 86400 IN AAAA 2001:DB8::1 - config2.example.net 3600 IN SVCB ns2.example.net. ( - alpn=dot - tlsa="2 0 1 ABC..." - ipv4hint=192.0.2.54 - ipv6hint=2001:db8:2423::3 ) +As with SVCB, DELEG also offer the ability to use AliasMode for a +delegation. The example below shows that example.com is +being delegated with a DELEG AliasMode record which can then be +further resolved using SVCB to locate the actual parameters. -The above records indicate to the client that the actual configuration for the example.com zone can be found at config2.example.net. + example.com. 86400 IN DELEG 0 config2.example.net. + example.com. 86400 IN NS ns1.example.net. -Later sections of this document will go into more detail on the resolution process using these records. +The example.net authoritative server's SVCB record could look like this: -## Goal of the DELEG record + config2.example.net 3600 IN SVCB ns2.example.net. ( + alpn=dot + tlsa="2 0 1 ABC..." + ipv4hint=192.0.2.54 + ipv6hint=2001:db8:2423::3 ) -The primary goal of transport specification in DELEG records is to provide zone owners a way to signal to new clients how to connect to servers serving a child domain that can coexist with NS records in the same zone, and do not break software that does not support new transports. +This document defines in detail the resolution process using these records. -### SvcParams +## SvcParams -All SvcParamKeys for the "dns" scheme {{?9461}} apply as specified. These are the "transport parameters", describing how to reach an endpoint. +All SvcParamKeys for the "dns" scheme from SVCB-DNS {{?RFC9461}} apply as specified. These are the "transport parameters", attributes describing how to reach an endpoint. -The "alpn" transport parameter is OPTIONAL to include (unlike in SVCB-DNS, where it is generally required). If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". +The "alpn" transport parameter is OPTIONAL to include, unlike in SVCB-DNS, where it is generally required. If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53. Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn". [Why do we not require do53 to be explicit?] When TargetName is below the zone cut, DELEG ServiceMode records MUST include "ipv4hint" or "ipv6hint" SvcParamKeys. These keys provide the address glue, which enables the initial connection to this endpoint. -The following additional DNS SVCB parameters are defined for the DELEG and SVCB ServiceModes. +The following additional SVCB-DNS parameters are defined for the DELEG and SVCB ServiceModes. -#### "tlsa" +### tlsa The "tlsa" SvcParamKey is a transport parameter representing a TLSA RRset {{?RFC6698}} to be used when connecting to TargetName using a TLS-based transport. If present, this SvcParam SHOULD match the TLSA records whose base domain ({{?RFC6698, Section 3}}) is TargetName. Due to bootstrapping concerns, this SvcParamKey has been added to the DELEG record as the TLSA records might only be resolveable after the initial connection to the delegated nameserver was established. When this field is not present, certificate validation should be performed by either DANE or by traditional TLS certification validation using trusted root certification authorities. @@ -182,8 +188,8 @@ To avoid a circular dependency, "tlsa" MUST appear in any DELEG record that is u Resolvers that support TLS-based transports MUST adopt one of the following behaviors: 1. Use DANE for authentication, and treat any endpoints lacking DANE support as incompatible. -1. Use PKI for authentication, and treat any DANE-only endpoint as incompatible. In this behavior, compatibility with `tlsa=disabled` endpoints is REQUIRED. -1. Support both DANE and PKI for authentication, preferring DANE if it is available for each endpoint. +2. Use PKI for authentication, and treat any DANE-only endpoint as incompatible. In this behavior, compatibility with `tlsa=disabled` endpoints is REQUIRED. +3. Support both DANE and PKI for authentication, preferring DANE if it is available for each endpoint. This SvcParamKey MAY be used in any SVCB context where TLSA usage is defined. @@ -196,6 +202,9 @@ alpn=doq tlsa="..." mandatory=alpn ;; services. All resolvers can access it, but only resolvers with ;; DANE support will use DoQ. alpn=doq tlsa="..." +[... how does this signal that it also offers do53? Is the though that it is + because only this draft specifies alpn and the core draft doesn't (currently) + have a method to explicitly signal do53? Maybe it should... ] ;; The server is authenticatable via PKI. If TLSA records exist at ;; the SVCB-DANE owner names, it is also authenticatable via DANE. @@ -208,31 +217,33 @@ alpn=doq tlsa=disabled mandatory=alpn ~~~ {: title="tlsa SvcParam Examples for DELEG"} -## Deployment Considerations +## Resolution procedure -The DELEG and SVCB records intends to replace the NS record while also adding additional functionality in order to support additional transports for the DNS. Below are discussions of considerations for deployment. +As specified in {{?I-D.draft-dnsop-deleg}}, the ServiceMode DELEG records provide a weak signal from the operator about which transport mechanisms they would most prefer clients to use, but it is not mandatory that resolvers try the delegated servers in priority order. It might not even be possible for a resolver to do, such as if the highest priority record specifies an alpn that the resolver does not implement, but a lower priority record has an alpn that it can use. -### Availability +Thus, as with authority server selection for NS records, a resolver is free to use its own policy implementation to determine which servers to continue to use for resolution. -If a zone operator removes all NS records before DELEG and SVCB records are implemented by all clients, the availability of their zones will be impacted for the clients that are using non-supporting resolvers. In some cases, this may be a desired quality, but should be noted by zone owners and operators. +If a connection error occurs when a resolver attempts to access a nameserver delegated to by a DELEG or SVCB record, such as with a certificate mismatch or by being unreachable, the resolver SHOULD attempt to connect to the other nameservers in the DELEG/SVCB RRset to until either exhausting the list or the resolver's policy indicates that they should treat the resolution as failed. -# Privacy Considerations +For resolvers that strongly favor privacy, operators may wish to return a SERVFAIL when all attempts to use privacy-enhanced alpns in the DELEG/SVCB resolution process have failed. More permissive resolvers can fall back to using the legacy DNS resolution process via NS records. -All of the information handled or transmitted by this protocol is public information published in the DNS. +## Deployment Considerations -# Security Considerations +DELEG and SVCB records are intended to be the best method for modern resolvers to use delegation information for zones. -TODO: Fill this section out +Realistically, however, legacy resolvers will continue to exist on the Internet for a long time to come. If a zone operator removes all NS records, the availability of their zones will be impacted for the clients that are using non-supporting resolvers. In some cases, this may be a desired quality, but should be noted by zone owners and operators. -## Resolution procedure +# Privacy Considerations -TODO: Define how resolver selects which server connect to, especially when faced with selection of multiple transports. I's probably resolver's policy decision, but it should be said explicitly. +All of the information transmitted by this protocol is public information published in the DNS. + +# Security Considerations -### Connection Failures +No new security risks are introduced by this specification. [Too bold to say?] -When a resolver attempts to access nameserver delegated by a DELEG or SVCB record, if a connection error occurs, such as a certificate mismatch or unreachable server, the resolver SHOULD attempt to connect to the other nameservers delegated to until either exhausting the list or the resolver's policy indicates that they should treat the resolution as failed. +The primary security considerations of DNS operators and domain owners are whether they should enable more secure transports for their domains, and how they want resolution to be handled if the secure transport is not available. -The failure action when failing to resolve a name with DELEG/SVCB due to connection errors is dependent on the resolver operators policies. For resolvers which strongly favor privacy, the operators may wish to return a SERVFAIL when the DELEG/SVCB resolution process completes without successfully contacting a delegated nameserver(s) while opportunistic privacy resolvers may wish to attempt resolution using any NS records that may be present. +Similarly, resolvers should be considering whether they will use secure transport mechanisms, and if so how strongly they want to enforce their usage. # IANA Considerations diff --git a/draft-dnsop-deleg.md b/draft-dnsop-deleg.md index 05e9a12..7d0113e 100644 --- a/draft-dnsop-deleg.md +++ b/draft-dnsop-deleg.md @@ -100,19 +100,19 @@ contributor: --- abstract -Authoritative control of parts of the Domain Name System namespace are indicated with a special record type that can only indicate the name of the server which a client resolver should contact for more information. Any other features of that server must then be discovered through other mechanisms. This draft proposes a new extensible DNS record type, DELEG, which allows additional information about authoritative nameservers to be conveyed in the delegation. +Authoritative control of parts of the Domain Name System namespace are indicated with a special record type, the NS record, that can only indicate the name of the server which a client resolver should contact for more information. Any other features of that server must then be discovered through other mechanisms. This draft proposes a new extensible DNS record type, DELEG, which allows additional information about authoritative nameservers to be conveyed in the delegation. --- middle # Introduction -In the Domain Name System [STD13], subtrees 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, can only represent the name of a nameserver. Clients can expect nothing out of this delegated server other than it will answer DNS requests on UDP port 53. +In the Domain Name System {{?STD13}}, subtrees 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, can only represent the name of a nameserver. Clients can expect nothing out of this delegated server other than that it will answer DNS requests on UDP port 53. As the DNS has evolved over the past four decades, this has proven to be a barrier for the efficient introduction of new DNS technology. Many features that have been conceived come with additional overhead as they are constrained by the least common denominator of nameserver functionality. The proposed DELEG record type remedies this problem by providing extensible parameters to describe what attributes a resolver would like to know about the the delegated authority, for example that it should be contacted using a different transport mechanism than the default udp/53. -The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all provided in the Authority section of DNS responses. Legacy DNS resolvers would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch. [This is our proposed best-case scenario, but still needs testing to confirm the assertion about legacy resolvers. We have several other backup plans about how it could be facilitated if the Authority method proves troublesome.] +The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all three types provided in the Authority section of DNS responses. Legacy DNS resolvers would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch. [This is our proposed best-case scenario, but still needs testing to confirm the assertion about legacy resolvers. We have several other backup plans about how it could be facilitated if the Authority method proves troublesome.] The DELEG record leverages the Service Binding (SVCB) record format defined in {{?RFC9460}}, using a subset of the already defined service parameters. @@ -131,14 +131,23 @@ Terminology regarding the Domain Name System comes from {{?BCP219}}, with additi * [tbd] * [tbd] -## Reasoning for changing delegation +## Motivation -* The current DNS protocol does not allow secure upgrade to new transport mechanisms between auth and resolver - e.g. authenticated DNS-over-TLS from resolver to auth. -* The current delegation with NS and glue records requires a leap of faith because these records are not signed. Spoofed delegation can be detected eventually if the domain is signed, but only after traffic is (potentially) sent to the attacker’s endpoint. -* There is no secure way to signal in delegation what capabilities authoritative servers support. The client cannot rely on any new behavior and currently must resort to trial-and-error with EDNS which is unsigned. -* DNS operators don’t have a formal role in the current system. Consequently, registries/registrars generally don’t talk to operators and users must act as go-between and make technical changes they don’t understand. - * Asking domain owners to add new NS records, modify DS records when rolling keys etc. This is very inflexible when an operator needs to make technical changes. +There is currently no secure way within the DNS protocol to signal what capabilities authoritative nameservers support. Resolvers have had to use out-of-band configuration or trial-and-error probing to use new features. While EDNS {{?REF}} is available as an extensible mechanism for capability signalling, EDNS records are not signed and are thus unreliable. +Lacking authenticatable capability signalling, the DNS protocol does not easily allow secure upgrade to new transport mechanisms between authority servers and resolvers, such as to use authenticated DNS-over-TLS {{?RFC7858}}. + +Delegations via NS and glue address records require a leap of faith, because neither the NS records nor the glue is cryptographically signed for secure validation. While the DNSSEC DS record ultimately secures the chain of trust to confirm delegated servers, spoofed delegations can still cause resolver questions to be directed to the spoofed servers. + +While third-party operators have long been part of the reality of how the DNS works, the ICANN "3R" model of Registry, Registrar, and Registrant does not formally recognize the operator role as its own entity who can interact with either registrar or registry on behalf of the registrant. Various aspects of maintaining delegation information has relied on the registrant needing to take action with their registrar, to be pushed from the registrar into the registry. This is especially difficult when the registrant is looking to outsource essentially all DNS knowledge. + +This inefficiency exposes itself in two troublesome ways. The first has been a practical operational issue for years. The DNSSEC DS record, which is not meant to be indefinitely static, is generated by the operator. While some methods have been standardized to address how the operator could publish updates to the registry {{?REF}} these have not been widely deployed. + +The second issue has been that relying on new features to be deployed via registrar development has hindered DNS protocol development. This is again demonstrated by the DS record, which some registrars still do not support, decades after its standardization, even when fronting for registries that support DNSSEC. + +We reccognize that this proposal runs headlong into the second issue, but believe it will provide powerful motivation as a "one and done" solution for the extensibility of the parent side of a delegation. Enabling powerful new features in the DNS, early discussions with a people from a wide variety of consituencies has indicated a high degree of interest in implementing this solution. + +[Add some constituency examples here?] ## Introductory Examples From 30620bcef2797b3a099e11567ed96238dc22af4d Mon Sep 17 00:00:00 2001 From: David C Lawrence Date: Fri, 17 Nov 2023 04:43:25 +0700 Subject: [PATCH 2/4] Update draft-dnsop-deleg-transport.md works for me. as i recall i was just trying to clean up some prior wording. Co-authored-by: Benjamin M. Schwartz --- draft-dnsop-deleg-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dnsop-deleg-transport.md b/draft-dnsop-deleg-transport.md index b10c6d2..28ada38 100644 --- a/draft-dnsop-deleg-transport.md +++ b/draft-dnsop-deleg-transport.md @@ -225,7 +225,7 @@ Thus, as with authority server selection for NS records, a resolver is free to u If a connection error occurs when a resolver attempts to access a nameserver delegated to by a DELEG or SVCB record, such as with a certificate mismatch or by being unreachable, the resolver SHOULD attempt to connect to the other nameservers in the DELEG/SVCB RRset to until either exhausting the list or the resolver's policy indicates that they should treat the resolution as failed. -For resolvers that strongly favor privacy, operators may wish to return a SERVFAIL when all attempts to use privacy-enhanced alpns in the DELEG/SVCB resolution process have failed. More permissive resolvers can fall back to using the legacy DNS resolution process via NS records. +Operators MAY return SERVFAIL when all attempts to use the DELEG/SVCB resolution process have failed. This might have privacy benefits, especially if the DELEG records only offer encrypted transports. More permissive resolvers can fall back to using the legacy DNS resolution process via NS records. ## Deployment Considerations From baff3405f4f8a18c18763ae41712bb2a11393708 Mon Sep 17 00:00:00 2001 From: tale Date: Thu, 4 Jan 2024 11:11:50 -0500 Subject: [PATCH 3/4] update with positive testing results. fix a couple of typos. --- draft-dnsop-deleg.md | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/draft-dnsop-deleg.md b/draft-dnsop-deleg.md index 30e3aa6..df6b52e 100644 --- a/draft-dnsop-deleg.md +++ b/draft-dnsop-deleg.md @@ -4,6 +4,7 @@ abbrev: DELEG docname: draft-dnsop-deleg-latest date: {DATE} category: std +updates: 1035 ipr: trust200902 workgroup: dnsop @@ -45,6 +46,10 @@ contributor: name: Edward Lewis organization: ICANN email: edward.lewis@icann.org +- + name: Roy Arends + organization: ICANN + email: roy.arends@icann.org - name: Shumon Huque organization: Salesforce @@ -110,13 +115,13 @@ Authoritative control of parts of the Domain Name System namespace are indicated # Introduction -In the Domain Name System {{?STD13}}, subtrees 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, can only represent the name of a nameserver. Clients can expect nothing out of this delegated server other than that it will answer DNS requests on UDP port 53. +In the Domain Name System {{STD13}}, subtrees 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, can only represent the name of a nameserver. Clients can expect nothing out of this delegated server other than that it will answer DNS requests on UDP port 53. As the DNS has evolved over the past four decades, this has proven to be a barrier for the efficient introduction of new DNS technology. Many features that have been conceived come with additional overhead as they are constrained by the least common denominator of nameserver functionality. The proposed DELEG record type remedies this problem by providing extensible parameters to describe what attributes a resolver would like to know about the the delegated authority, for example that it should be contacted using a different transport mechanism than the default udp/53. -The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all three types provided in the Authority section of DNS responses. Legacy DNS resolvers would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch. [This is our proposed best-case scenario, but still needs testing to confirm the assertion about legacy resolvers. We have several other backup plans about how it could be facilitated if the Authority method proves troublesome.] +The record lives in harmony with the existing NS records and any DS records used to secure the delegation with DNSSEC, with all three types provided in the Authority section of DNS responses. Legacy DNS resolvers will ignore the unknown DELEG type and continue to use the NS and DS records, per the testing described in Appendix A. Resolvers that understand DELEG and its associated parameters can efficiently switch to the new mechanism. The DELEG record leverages the Service Binding (SVCB) record format defined in {{?RFC9460}}, using a subset of the already defined service parameters. @@ -149,7 +154,7 @@ This inefficiency exposes itself in two troublesome ways. The first has been a The second issue has been that relying on new features to be deployed via registrar development has hindered DNS protocol development. This is again demonstrated by the DS record, which some registrars still do not support, decades after its standardization, even when fronting for registries that support DNSSEC. -We reccognize that this proposal runs headlong into the second issue, but believe it will provide powerful motivation as a "one and done" solution for the extensibility of the parent side of a delegation. Enabling powerful new features in the DNS, early discussions with a people from a wide variety of consituencies has indicated a high degree of interest in implementing this solution. +We recognize that this proposal runs headlong into the second issue, but believe it will provide powerful motivation as a "one and done" solution for the extensibility of the parent side of a delegation. Enabling powerful new features in the DNS, early discussions with a people from a wide variety of consituencies has indicated a high degree of interest in implementing this solution. [Add some constituency examples here?] @@ -248,7 +253,7 @@ Some zone owners may wish to use multiple providers to serve their zone, in whic example.com. 86400 IN DELEG 0 config1.example.net. example.com. 86400 IN DELEG 0 config1.example.org. -DRAFT NOTE: SVCB says that there "SHOULD only have a single RR". This ignores that but keep the randomization part. Section 2.4.2 of SVCB +DRAFT NOTE: SVCB says that there "SHOULD only have a single RR". This ignores that but keeps the randomization part. Section 2.4.2 of SVCB ### Loop Prevention @@ -334,11 +339,23 @@ When a delegation using DELEG to a child is present, the resolver MUST use it an # IANA Considerations -DELEG will use the SCVB IANA registry define in section 14.3 of {{?RFC9460}}. +DELEG will use the SVCB IANA registry definitions in section 14.3 of {{!RFC9460}}. + +--- back + +# Appendix A Legacy Test Results {#Testing} + +In December 2023, Roy Arends and Shumon Huque tested the core idea that enables this approach, that legacy resolvers would simply ignore the unknown DELEG record type from authoritative servers. Tested both with DNSSEC and without against the most widely used DNS resolver implementations, the tests clearly supported the soundness of this method. The tested legacy resolvers were all able to continue to successfully resolve the test domains via traditional DNS over port 53 even in the presence of DELEG records. + +The tested legacy resolver installations included BIND, Unbound, +PowerDNS, and Knot. In addition, the public resolver services run by Cloudflare (1.1.1.1), Google (8.8.8.8), and Packet Clearing House (9.9.9.9) were examined and provided similar results. + +For more details about the specific testing methodology, please see {{?test-plan}}. -# Acknowledgments +# Acknowledgments {:unnumbered} -This draft is heavily based on past work (draft-tapril-ns2) done by Tim April and thus extends the thanks to the people helping on this which are: +This draft is heavily based on past work done by Tim April in +{{?I-D.tapril-ns2}} 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. # TODO From ab3112c94e6a7d22b41180cfd7afb72dace13d8b Mon Sep 17 00:00:00 2001 From: tale Date: Thu, 19 Dec 2024 18:44:22 -0800 Subject: [PATCH 4/4] updated IANA Considerations --- draft-wesplaap-deleg.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/draft-wesplaap-deleg.md b/draft-wesplaap-deleg.md index 328325b..2e23eb2 100644 --- a/draft-wesplaap-deleg.md +++ b/draft-wesplaap-deleg.md @@ -392,11 +392,13 @@ When a delegation using DELEG to a child is present, the resolver MUST use it an # IANA Considerations -DELEG will use the SVCB IANA registry definitions in section 14.3 of {{!RFC9460}}. +IANA is requested to allocate the DELEG RR in the Resource Record (RR) TYPEs registry, with the meaning of "enchanced delegation information" and referencing this document. -The IANA has assigned a bit in the DNSKEY flags field (see Section 7 of {{!RFC4034}} for the DELEG bit (N). - -EDNS0 {{!RFC6891}} defines 16 bits as extended flags in the OPT record. This draft adds the DE bit. +IANA is requested to assign a new bit in the DNSKEY RR Flags registry ({{!RFC4034}}) for the DELEG bit (N), with the descripion "DELEG" and referencing this document. + +IANA is requested to assign a bit from the EDNS Header Flags registry ({{!RFC6891}}), with the abbreviation DE, the description "DELEG-only answer OK" and referencing this document. + +For the RDATA parameters to a DELEG RR, the DNS Service Bindings (SVCB) registry ({{!RFC9460}}) is used. This document requests no new assignments to that registry, though it is expected that future DELEG work will. --- back