Network Working Group T. April
Internet-Draft Google, LLC
Updates: 1035 (if approved) P. Špaček
Intended status: Standards Track ISC
Expires: 22 August 2025 R. Weber
Akamai Technologies
D. Lawrence
Salesforce
18 February 2025
Extensible Delegation for DNS
draft-wesplaap-deleg-02
Abstract
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 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 August 2025.
April, et al. Expires 22 August 2025 [Page 1]
Internet-Draft DELEG February 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. DELEG Record Type . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Differences from SVCB . . . . . . . . . . . . . . . . . . 4
2.2. Use of DELEG record . . . . . . . . . . . . . . . . . . . 4
2.3. Signaling DELEG support . . . . . . . . . . . . . . . . . 5
2.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Normative References . . . . . . . . . . . . . . . . . . 6
4.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
A.1. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8
A.2. DO bit clear, DE bit clear . . . . . . . . . . . . . . . 8
A.2.1. Query for foo.example . . . . . . . . . . . . . . . . 8
A.2.2. Query for foo.test . . . . . . . . . . . . . . . . . 9
A.3. DO bit set, DE bit clear . . . . . . . . . . . . . . . . 9
A.3.1. Query for foo.example . . . . . . . . . . . . . . . . 9
A.3.2. Query for foo.test . . . . . . . . . . . . . . . . . 9
A.4. DO bit clear, DE bit set . . . . . . . . . . . . . . . . 10
A.4.1. Query for foo.example . . . . . . . . . . . . . . . . 10
A.4.2. Query for foo.test . . . . . . . . . . . . . . . . . 10
A.5. DO bit set, DE bit set . . . . . . . . . . . . . . . . . 11
A.5.1. Query for foo.example . . . . . . . . . . . . . . . . 11
A.5.2. Query for foo.test . . . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgments {:unnumbered} . . . . . . . . . . . 12
Appendix C. TODO . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 12
D.1. since draft-wesplaap-deleg-00 . . . . . . . . . . . . . . 13
D.2. since draft-wesplaap-deleg-01 . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
April, et al. Expires 22 August 2025 [Page 2]
Internet-Draft DELEG February 2025
1. Introduction
In the Domain Name System [STD13], 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 record type remedies this problem by providing
extensible parameters to indicate capabilities and additional
information, such as glue that a resolver may use for the delegated
authority. It is authoritative and thus signed in the parent side of
the delegation making it possible to validate all delegation
parameters (names and glue records) with DNSSEC.
This document only shows how DELEG 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.
1.1. 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 [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:
* legacy name servers: An authoritative server that does not support
the DELEG record.
* legacy resolvers: A resolver that does not support the DELEG
record.
2. DELEG Record Type
The DELEG record uses a new resource record type, whose contents are
identical to the SVCB record defined in [RFC9460]. For extensions
SVCB and DELEG use Service Parameter Keys (SvcParamKeys) and new
SvcParamKeys that might be needed also will use the existing IANA
Registry.
April, et al. Expires 22 August 2025 [Page 3]
Internet-Draft DELEG February 2025
2.1. Differences from SVCB
* DELEG can only have two priorities 0 indicating INCLUDE and 1
indicating a DIRECT delegation. These terms MUST be used in the
presentation format of the DELEG record.
* INCLUDE and DIRECT delegation can be mixed within an RRSet
* The final INCLUDE target is an SVCB record, though there can be
further indirection using CNAME or AliasMode SVCB records.
* There can be multiple INCLUDE DELEG records, but further
indirections through SVCB records have to comply with [RFC9460] in
that there can be only one AliasMode SVCB record per name.
* In order to not allow unbound indirection of DELEG records the
maximum number of indirections, CNAME or AliasMode SVCB is 4.
* The SVCB IPv4hint and IPv6hint parameters keep their key values of
4 and 6, but the presentation format with DELEG MUST be Glue4 and
Glue6.
* Glue4 and Glue6 records when present MUST be used to connect to
the delegated name server.
* The target of a DELEG record MUST NOT be '.' and for INCLUDE must
be outside of the delegated domain and for DIRECT in domain
delegations below the zone cut.
2.2. Use of DELEG record
The DELEG record creates a zone cut similar to the NS record so all
data at or below the zone cut has to be resolved using the name
servers defined in the DELEG record.
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.
An authoritative server that is DELEG aware MUST put all DELEG
resource records for the delegation into the authority section when
the resolver has signalled DELEG support. It SHOULD NOT supply DELEG
records in the response when receiving a request without the DE bit.
April, et al. Expires 22 August 2025 [Page 4]
Internet-Draft DELEG February 2025
If the delegation does not have DELEG records the authoritative
server MUST send the NS records and, if the zone is DNSSEC signed,
prove the absence of the DELEG RRSet.
A resolver that is DELEG aware MUST signal its support by sending the
DE bit when iterating and MUST use the DELEG records in the referral
response.
2.3. Signaling DELEG support
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.
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):
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|CO|DE| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Setting the DE bit to one in a query indicates to the server that the
resolver is able to accept delegations using DELEG only. 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. The DE bit of the query MUST be copied in the response.
2.4. DNSSEC
As the DELEG record is authoritative in the parent zone of a zone cut
similar to DS it has to be signed in the parent zone.
In order for the validator to understand that the delegation uses
DELEG this draft introduces a new DNSKEY flag TBD. When this flag is
set for the key that signs the DS or DELEG record, usually the zone
signing key (ZSK), and the request has signalled that it understands
DELEG an authenticated denial of existence MUST be send with the
referral response, so that a DELEG aware validator can prove the
existence or absence of a DELEG record and detect a downgrade attack.
April, et al. Expires 22 August 2025 [Page 5]
Internet-Draft DELEG February 2025
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
this has to be security and DELEG aware as well.
3. IANA Considerations
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.
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
enabled" 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.
4. References
4.1. Normative References
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/rfc/rfc4034>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/rfc/rfc6891>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
[STD13] Internet Standard 13,
<https://www.rfc-editor.org/info/std13>.
At the time of writing, this STD comprises the following:
April, et al. Expires 22 August 2025 [Page 6]
Internet-Draft DELEG February 2025
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
4.2. Informative References
[BCP219] Best Current Practice 219,
<https://www.rfc-editor.org/info/bcp219>.
At the time of writing, this BCP comprises the following:
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[I-D.tapril-ns2]
April, T., "Parameterized Nameserver Delegation with NS2
and NS2T", Work in Progress, Internet-Draft, draft-tapril-
ns2-01, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-tapril-
ns2-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Appendix A. 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.
April, et al. Expires 22 August 2025 [Page 7]
Internet-Draft DELEG February 2025
example. 300 IN DELEG 1 a.example. Glue4=192.0.2.1 (
Glue6=2001:DB8::1 )
example. 300 IN DELEG 0 ns2.example.net.
example. 300 IN DELEG 0 ns3.example.org.
example. 300 IN RRSIG DELEG 13 4 300 20250214164848 (
20250207134348 21261 . HyDHYVT5KcqWc7J..= )
example. 300 IN NS a.example.
example. 300 IN NS b.example.net.
example. 300 IN NS c.example.org.
example. 300 IN DS 65163 13 2 5F86F2F3AE2B02...
example. 300 IN RRSIG DS 13 4 300 20250214164848 (
20250207134348 21261 . O0k558jHhyrC21J..= )
example. 300 IN NSEC a.example. NS DS RRSIG NSEC DELEG
example. 300 IN RRSIG NSEC 13 4 300 20250214164848 (
20250207134348 21261 . 1Kl8vab96gG21Aa..= )
a.example. 300 IN A 192.0.2.1
a.example. 300 IN AAAA 2001:DB8::1
The "test." delegation point has a DELEG record and no NS record.
test. 300 IN DELEG 0 ns2.example.net
test. 300 IN RRSIG DELEG 13 4 300 20250214164848 (
20250207134348 21261 . 98Aac9f7A1Ac26Q..= )
test. 300 IN NSEC a.test. RRSIG NSEC DELEG
test. 300 IN RRSIG NSEC 13 4 300 20250214164848 (
20250207134348 21261 . kj7YY5tr9h7UqlK..= )
A.1. Responses
The following sections show referral examples:
A.2. DO bit clear, DE bit clear
A.2.1. Query for foo.example
;; Header: QR RCODE=0
;;
;; Question
foo.example. IN MX
;; Answer
;; (empty)
;; Authority
example. 300 IN NS a.example.
example. 300 IN NS b.example.net.
example. 300 IN NS c.example.org.
April, et al. Expires 22 August 2025 [Page 8]
Internet-Draft DELEG February 2025
;; Additional
a.example. 300 IN A 192.0.2.1
a.example. 300 IN AAAA 2001:DB8::1
A.2.2. Query for foo.test
;; Header: QR AA RCODE=3 ;;
;; Question
foo.test. IN MX
;; Answer
;; (empty)
;; Authority
. 300 IN SOA ...
;; Additional
;; (empty)
A.3. DO bit set, DE bit clear
A.3.1. Query for foo.example
;; Header: QR DO RCODE=0
;;
;; Question
foo.example. IN MX
;; Answer
;; (empty)
;; Authority
example. 300 IN NS a.example.
example. 300 IN NS b.example.net.
example. 300 IN NS c.example.org.
example. 300 IN DS 65163 13 2 5F86F2F3AE2B02...
example. 300 IN RRSIG DS 13 4 300 20250214164848 (
20250207134348 21261 . O0k558jHhyrC21J..= )
;; Additional
a.example. 300 IN A 192.0.2.1
a.example. 300 IN AAAA 2001:DB8::1
A.3.2. Query for foo.test
April, et al. Expires 22 August 2025 [Page 9]
Internet-Draft DELEG February 2025
;; Header: QR DO AA RCODE=3
;;
;; Question
foo.test. IN MX
;; Answer
;; (empty)
;; Authority
. 300 IN SOA ...
. 300 IN RRSIG SOA ...
. 300 IN NSEC aaa NS SOA RRSIG NSEC DNSKEY ZONEMD
. 300 IN RRSIG NSEC 13 4 300
test. 300 IN NSEC a.test. RRSIG NSEC DELEG
test. 300 IN RRSIG NSEC 13 4 300 20250214164848 (
20250207134348 21261 . aBFYask;djf7UqlK..= )
;; Additional
;; (empty)
A.4. DO bit clear, DE bit set
A.4.1. Query for foo.example
;; Header: QR DE RCODE=0
;;
;; Question
foo.example. IN MX
;; Answer
;; (empty)
;; Authority
example. 300 IN DELEG 1 a.example. Glue4=192.0.2.1 (
Glue6=2001:DB8::1 )
example. 300 IN DELEG 0 ns2.example.net.
example. 300 IN DELEG 0 ns3.example.org.
;; Additional
;; (empty)
A.4.2. Query for foo.test
April, et al. Expires 22 August 2025 [Page 10]
Internet-Draft DELEG February 2025
;; Header: QR AA RCODE=0
;;
;; Question
foo.test. IN MX
;; Answer
;; (empty)
;; Authority
test. 300 IN DELEG 0 ns2.example.net
;; Additional
;; (empty)
A.5. DO bit set, DE bit set
A.5.1. Query for foo.example
;; Header: QR DO DE RCODE=0
;;
;; Question
foo.example. IN MX
;; Answer
;; (empty)
;; Authority
example. 300 IN DELEG 1 a.example. Glue4=192.0.2.1 (
Glue6=2001:DB8::1 )
example. 300 IN DELEG 0 ns2.example.net.
example. 300 IN DELEG 0 ns3.example.org.
example. 300 IN RRSIG DELEG 13 4 300 20250214164848 (
20250207134348 21261 . HyDHYVT5KcqWc7J..= )
example. 300 IN DS 65163 13 2 5F86F2F3AE2B02...
example. 300 IN RRSIG DS 13 4 300 20250214164848 (
20250207134348 21261 . O0k558jHhyrC21J..= )
;; Additional
a.example. 300 IN A 192.0.2.1
a.example. 300 IN AAAA 2001:DB8::1
A.5.2. Query for foo.test
April, et al. Expires 22 August 2025 [Page 11]
Internet-Draft DELEG February 2025
;; Header: QR DO DE AA RCODE=3
;;
;; Question
foo.test. IN MX
;; Answer
;; (empty)
;; Authority
. 300 IN SOA ...
. 300 IN RRSIG SOA ...
. 300 IN NSEC aaa NS SOA RRSIG NSEC DNSKEY ZONEMD
. 300 IN RRSIG NSEC 13 4 300
test. 300 IN NSEC a.test. RRSIG NSEC DELEG
test. 300 IN RRSIG NSEC 13 4 300 20250214164848 (
20250207134348 21261 . aBFYask;djf7UqlK..= )
;; Additional
;; (empty)
Appendix B. Acknowledgments {:unnumbered}
This document 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.
Appendix C. 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
Appendix D. Change Log
RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.
April, et al. Expires 22 August 2025 [Page 12]
Internet-Draft DELEG February 2025
D.1. since draft-wesplaap-deleg-00
* Clarified SVCB priority behaviour
* Added section on differences to draft-homburg-deleg-incremental-
deleg
D.2. since draft-wesplaap-deleg-01
* Reorganised and streamlined the draft to the bare mininum for
DELEG as an NS replacement
* Defined codepoints for temporary testing
* Added examples
Contributors
Christian Elmerot
Cloudflare
Email: christian@elmerot.se
Edward Lewis
ICANN
Email: edward.lewis@icann.org
Roy Arends
ICANN
Email: roy.arends@icann.org
Shumon Huque
Salesforce
Email: shuque@gmail.com
Klaus Darilion
nic.at
Email: klaus.darilion@nic.at
Libor Peltan
CZ.nic
Email: libor.peltan@nic.cz
April, et al. Expires 22 August 2025 [Page 13]
Internet-Draft DELEG February 2025
Vladimír Čunát
CZ.nic
Email: vladimir.cunat@nic.cz
Shane Kerr
NS1
Email: shane@time-travellers.org
David Blacka
Verisign
Email: davidb@verisign.com
George Michaelson
APNIC
Email: ggm@algebras.org
Ben Schwartz
Meta
Email: bemasc@meta.com
Jan Včelák
NS1
Email: jvcelak@ns1.com
Peter van Dijk
PowerDNS
Email: peter.van.dijk@powerdns.com
Philip Homburg
NLnet Labs
Email: philip@nlnetlabs.nl
Erik Nygren
Akamai Technologies
Email: erik+ietf@nygren.org
Vandan Adhvaryu
Team Internet
Email: vandan@adhvaryu.uk
April, et al. Expires 22 August 2025 [Page 14]
Internet-Draft DELEG February 2025
Manu Bretelle
Meta
Email: chantr4@gmail.com
Bob Halley
Cloudflare
Email: bhalley@cloudflare.com
Authors' Addresses
Tim April
Google, LLC
Email: ietf@tapril.net
Petr Špaček
ISC
Email: pspacek@isc.org
Ralf Weber
Akamai Technologies
Email: rweber@akamai.com
David C Lawrence
Salesforce
Email: tale@dd.org
April, et al. Expires 22 August 2025 [Page 15]