Extensible Delegation for DNS
draft-wesplaap-deleg-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tim April , Petr Špaček , Ralf Weber , David C Lawrence | ||
| Last updated | 2024-10-21 | ||
| Replaces | draft-dnsop-deleg | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wesplaap-deleg-01
Network Working Group T. April
Internet-Draft Google, LLC
Updates: 1035 (if approved) P. Špaček
Intended status: Standards Track ISC
Expires: 24 April 2025 R. Weber
Akamai Technologies
D. Lawrence
Salesforce
21 October 2024
Extensible Delegation for DNS
draft-wesplaap-deleg-01
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, which contains 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 24 April 2025.
April, et al. Expires 24 April 2025 [Page 1]
Internet-Draft DELEG October 2024
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Motivation and Design Requirements for DELEG . . . . . . 4
2. DELEG Record Type . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Including DELEG RRs in a Zone . . . . . . . . . . . . . . 6
2.2. Difference between the records . . . . . . . . . . . . . 6
2.3. Use of DNSSEC . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Signing DELEG RRs . . . . . . . . . . . . . . . . . . 8
2.3.2. Preventing downgrade attacks . . . . . . . . . . . . 8
2.4. Multiple Service Providers . . . . . . . . . . . . . . . 8
2.5. Loop Prevention . . . . . . . . . . . . . . . . . . . . . 9
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Deployment Considerations . . . . . . . . . . . . . . . . 10
4.1.1. AliasMode and ServiceMode in the Parent . . . . . . . 10
4.1.2. Rollout . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Availability . . . . . . . . . . . . . . . . . . . . 11
4.2. Signaling DELEG support . . . . . . . . . . . . . . . . . 11
4.3. Response Size Considerations . . . . . . . . . . . . . . 11
4.4. Authoritative Name Servers . . . . . . . . . . . . . . . 12
4.4.1. Including DELEG RRs in a Response . . . . . . . . . . 12
4.4.2. Responding to Queries for Type DELEG . . . . . . . . 12
4.4.3. Priority of DELEG over NS and Glue Address records . 13
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Availability of Zones Without NS . . . . . . . . . . . . 13
6.2. Resolution Procedure . . . . . . . . . . . . . . . . . . 13
6.2.1. Failures when DELEG Delegation is Present . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
April, et al. Expires 24 April 2025 [Page 2]
Internet-Draft DELEG October 2024
Appendix A. Legacy Test Results . . . . . . . . . . . . . . . . 15
Appendix B. Acknowledgments {:unnumbered} . . . . . . . . . . . 16
Appendix C. Differences to
draft-homburg-deleg-incremental-deleg . . . . . . . . . . 16
Appendix D. TODO . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 17
E.1. since draft-wesplaap-deleg-00 . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 that a resolver may
use for the delegated authority, for example that it should be
contacted using a transport mechanism other than DNS over UDP or TCP
on port 53.
DELEG records are served with NS and DS records in the Authority
section of DNS delegation type responses. Standard behavior of
legacy DNS resolvers is to ignore the DELEG type and continue to rely
on NS and DS records (see compliance testing described in
Appendix A). Resolvers that do 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, however as DELEG creates a zone cut and requires special
processing from authoritative name servers as well as resolvers it
has to be a new record type similar in handling to the DS record
type.
April, et al. Expires 24 April 2025 [Page 3]
Internet-Draft DELEG October 2024
DELEG can use AliasMode, inherited from SVCB, to insert a level of
indirection to ease the operational maintenance of multiple zones by
the same servers. For example, an operator can have numerous
customer domains all aliased to nameserver sets whose operational
characteristics can be easily updated without intervention from the
customers. Most notably, this provides a method for addressing the
long-standing problem operators have with maintaining DS records on
behalf of their customers. This type of facility will be handled in
separate documents.
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.
1.2. Motivation and Design Requirements for DELEG
NS based delegation supports DNS over UDP and TCP, but does not have
the ability to provide additional connection information like how to
contact an authoritative server over an encrypted transport or which
port to use when contacting the delegated server. DELEG was designed
to support communicating this type of information and more, taking
into account various design goals and tradeoffs. The design
requirements for DELEG were:
* Deliberate and Extensible Protocol: A distinct DNS record served
from the parent was selected to provide a deliberate and new
signal that additional information was available for how a
resolver can communicate with an authoritative nameserver. The
record existing in the parent eliminates the need for a resolver
to send additional queries to a delegated authoritative nameserver
in an attempt to learn connection parameters. Introducing a new
resource record type rather than using reserved fields from
another record type enables future expansion of functionality
beyond one or a small number of bits of information for a
delegation. This tradeoff does have the limitation that adoption
April, et al. Expires 24 April 2025 [Page 4]
Internet-Draft DELEG October 2024
at the root and TLD levels of the hierarchy may be delayed, but
this approach can lead to a cleaner and easier to support
solution.
* Extensibility: DELEG as described in this document could be
implemented through an existing Resource Record like the TXT
record, but doing so would limit the ability to build on the
record in the future. To support extending the data that can be
communicated, the SVCB record format was used for DELEG to support
future growth.
* Support for Abstract Delegation: the SVCB record format has
support for an Alias Form record. In the case of DELEG, the
AliasForm record enables a domain owner to indicate that their
zone will be hosted elsewhere, like a DNS service provider, in a
way that enables the service provider to update their
authoritative information without coordination with the domain
owner, domain registrar.
* Authenticated and Parent Centric: While NS records are
authoritative at the child, some resolver algorithms are parent
centric while others are child centric. With DELEG, this
ambiguity is removed and parent centricity and authority is
specified. This decision also enables the records to be signed in
the parent zone, reducing the potential risk of a denial of
service for clients when being delegated. Additionally, a parent
centric record is required to support resolution with a cold cache
and duplication of data in the child zone can lead to
inconsistencies as the records change over time.
* Able to coexist in the ecosystem: DELEG is defined as being a
record in the parent, signifying a zone cut. As a result of that
design decision, additional effort and time will be required to
deploy DELEG to all levels of the DNS hierarchy, especially when
considering the Root zone and TLDs. To support the deployment,
DELEG must be able to coexist within the ecosystem with the
existing NS based methods of resolution. Testing has been done to
show that many deployed resolvers can handle DELEG and NS records
side-by-side to enable a rollout.
* While DELEG can be used in an unsigned zone, it is recommended to
use DNSSEC. The DELEG record must be signed or denied in the
parent zone when it is signed. Without DNSSEC, certain security
properties might not be available and hence certain features only
will work when the DELEG record is signed.
April, et al. Expires 24 April 2025 [Page 5]
Internet-Draft DELEG October 2024
2. DELEG Record Type
The DELEG record wire format is the same as the SVCB record defined
in [RFC9460], but with a different value for the resource record type
of TBD. For extensions SVCB and DELEG use Service Parameter Keys
(SvcParamKeys) and new SvcParamKeys that might be needed also will
use the existing IANA Registry.
The SVCB record allows for two types of records, the AliasMode and
the ServiceMode. The DELEG record uses both. The Target Name either
points to a set of name servers answering for the delegated domain if
used in ServiceMode or to an SVCB record in AliasMode that then has
to be interpreted further to get to the actual name server. The
AliasMode DELEG record might point to another AliasMode SVCB record
or a CNAME. In order to not allow unbound indirection of DELEG
records the maximum number of indirections, CNAME or AliasMode SVCB
is 4. The SvcPriority field either can be 0 for AliasMode or 1 for
ServiceMode. Different priorities are not used for DELEG delegations
as all DELEG records are considered equally important and selection
amongst can be decided by the resolver for a good user experience.
2.1. Including DELEG RRs in a Zone
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.
Construction of a DELEG RR requires knowledge which implies
communication between the operators of the child and parent zones.
This communication is an operational matter not covered by this
document.
2.2. Difference between the records
This document uses two different resource record types. Both records
have the same functionality, with the difference between them being
that the DELEG record MUST only be used at a delegation point, while
the SVCB is used as a normal resource record and does not indicate
that the label is being delegated. For example, take the following
DELEG record:
Zone com.:
example.com. 86400 IN DELEG 1 config2.example.net.
April, et al. Expires 24 April 2025 [Page 6]
Internet-Draft DELEG October 2024
When a client receives the above record, the resolver should send
queries for any name under example.com to the nameserver at
config2.example.net unless further delegated. By contrast, when
presented with the records below:
Zone com.:
example.com. 86400 IN DELEG 0 config3.example.org.
Zone example.org.:
config3.example.org. 86400 IN SVCB 1 . (
ipv4hint=192.0.2.54,192.0.2.56
ipv6hint=2001:db8:2423::3,2001:db8:2423::4 )
A resolver trying to resolve a name under example.com would get the
first record above from the parent authoritative server, .COM,
indicating that the SVCB records found at config3.example.org should
be used to locate the authoritative nameservers of example.com, and
other parameters.
The primary difference between the two records is that the DELEG
record means that anything under the record label should be queried
at the delegated server while the SVCB record is just for redirection
purposes, and any names under the record's label should still be
resolved using the same server unless otherwise delegated.
It should be noted that both DELEG and SVCB records may exist for the
same label, but they will be in different zones. Below is an example
of this:
Zone com.:
example.com. 86400 IN DELEG 0 c1.example.org.
Zone example.org.:
c1.example.org. 86400 IN DELEG 1 config3.example.net. (
ipv6hint=2001:db8:2423::3 )
c1.example.org. 86400 IN NS test.c1.example.org.
test.c1.example.org. 600 IN A 192.0.2.1
Zone c1.example.org:
c1.example.org. 86400 IN SVCB 1 config2.example.net. (
ipv6hint=2001:db8:4567::4 )
c1.example.org. 86400 IN NS test.c1.example.org.
test.c1.example.org. 600 IN A 192.0.2.1
April, et al. Expires 24 April 2025 [Page 7]
Internet-Draft DELEG October 2024
In the above case, the DELEG record for c1.example.org would only be
used when trying to resolve names at or below c1.example.org. This
is why when an AliasMode DELEG or SVCB record is encountered, the
resolver MUST query for the SVCB record associated with the given
name.
2.3. Use of DNSSEC
While DNSSEC is RECOMMENDED, unsigned DELEG records may be retrieved
in a secure way from trusted, Privacy-enabling DNS servers using
encrypted transports.
FOR DISCUSSION: This will lead to cyclical dependencies. A DELEG
record can introduce a secure way to communicate with trusted,
Privacy-enabling DNS servers. For that, it needs to be DNSSEC
signed.
2.3.1. Signing DELEG RRs
A DELEG RRset MUST be DNSSEC signed if the zone is signed.
If a signed zone contains DELEG records, the referral response
containing DELEG records MUST be signed with a DNSKEY that has the
DELEG flag set.
2.3.2. Preventing downgrade attacks
A flag in the DNSKEY record signing the delegation is used as a
backwards compatible, secure signal to indicate to a resolver that
DELEG records are present or that there is an authenticated denial of
a DELEG record. Legacy resolvers will ignore this flag and use the
DNSKEY as is.
Without this secure signal an on-path adversary can remove DELEG
records and its RRsig from a response and effectively downgrade this
to a legacy DNSSEC signed response.
2.4. Multiple Service Providers
Some zone owners may wish to use multiple providers to serve their
zone, in which case multiple DELEG AliasMode records can be used. In
the event that multiple DELEG AliasMode records are encountered, the
resolver SHOULD treat those as a union the same way this is done with
NS records, picking one at random for the first lookup and eventually
discovering the others. How exactly DNS questions are directed and
split between configuration sets is implementation specific:
April, et al. Expires 24 April 2025 [Page 8]
Internet-Draft DELEG October 2024
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 keeps the randomization part. Section 2.4.2 of
SVCB ]
2.5. Loop Prevention
The TargetName of an SVCB or DELEG record MAY be the owner of a CNAME
record. Resolvers MUST follow CNAMEs as well as further alias SVCB
records as normal, but MUST NOT allow more then 4 total lookups per
delegation, with the first one being the DELEG referral and then 3
SVCB/CNAME lookups maximal.
Special care should be taken by both the zone owner and the delegated
zone operator to ensure that a lookup loop is not created by having
two AliasMode records rely on each other to serve the zone. Doing so
may result in a resolution loop, and likely a denial of service. The
mechanism on following CNAME and SVCB alias above should prevent
exhaustion of server resources. If a resolution can not be found
after 4 lookups the server should reply with a SERVFAIL error code.
3. Examples
To introduce DELEG record, this example shows the authority section
of a DNS response that delegates a subdomain to another nameserver.
example.com. 86400 IN DELEG 1 ns1.example.com. (
ipv4hint=192.0.2.1 ipv6hint=2001:DB8::1 )
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
In this example, the authoritative nameserver is delegating using the
same parameters as regular DNS, but the delegation as well as the
glue can be signed.
Like with SVCB, DELEG also offer the ability to use the Alias form of
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.
example.com. 86400 IN DELEG 0 config2.example.net.
example.com. 86400 IN NS ns2.example.net.
The example.net authoritative server may return the following SVCB
records in response to a query as directed by the above records.
April, et al. Expires 24 April 2025 [Page 9]
Internet-Draft DELEG October 2024
config2.example.net 3600 IN SVCB . (
ipv4hint=192.0.2.54,192.0.2.56
ipv6hint=2001:db8:2423::3,2001:db8:2423::4 )
The above records indicate to the client that the actual
configuration for the example.com zone can be found at
config2.example.net
Later sections of this document will go into more detail on the
resolution process using these records.
4. Implementation
This document introduces the concept of signaling capabilities to
clients on how to connect and validate a subdomain. This section
details the implementation specifics of the DELEG record for various
DNS components.
4.1. Deployment Considerations
The DELEG and SVCB records are intended 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.
4.1.1. AliasMode and ServiceMode in the Parent
Both the AliasMode and ServiceMode records can be returned for the
DELEG record from the parent. This is different from the SCVB
[RFC9460] specification and only applies for the DELEG RRSet in the
parent.
4.1.2. Rollout
When introduced, the DELEG and SVCB records might not initially be
supported by the DNS root or TLD operators. So for initial usage
zone owners may place DELEG records into their zones for delegating
down the tree into child domains of their zones, as the only way to
discover new delegations is with the DELEG record at the parent.
When AliasMode is used to the SVCB record the Target SVCB has to
exists.
April, et al. Expires 24 April 2025 [Page 10]
Internet-Draft DELEG October 2024
4.1.3. Availability
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.
4.2. 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 neccassary 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 DO bit is the first bit of the third and
fourth bytes of the "extended RCODE and flags" portion of the EDNS0
OPT meta-RR, structured as follows:
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|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 DO 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.
4.3. Response Size Considerations
For latency-conscious zones, the overall packet size of the
delegation records from a parent zone to child zone should be taken
into account when configuring the NS, DELEG and SVCB records.
Resolvers that wish to receive DELEG and SVCB records in response
SHOULD advertise and support a buffer size that is as large as
possible, to allow the authoritative server to respond without
truncating whenever possible.
As
April, et al. Expires 24 April 2025 [Page 11]
Internet-Draft DELEG October 2024
4.4. Authoritative Name Servers
4.4.1. Including DELEG RRs in a Response
If a DELEG RRset is present at the delegation point, the name server
MUST return both the DELEG RRset and its associated RRSIG RR in the
Authority section along with the DS RRset and its associated RRSIG RR
and the NS RRset.
If no DELEG RRset is present at the delegation point, and the
delegation was signed with a DNSKEY that has the DELEG flag set, the
name server MUST return the NSEC or NSEC3 RR that proves that the
DELEG RRset is not present including its associated RRSIG RR along
with the DS RRset and its associated RRSIG RR if present and the NS
RRset, if present.
Including these DELEG, DS, NSEC or NSEC3, and RRSIG RRs increases the
size of referral messages. If space does not permit inclusion of
these records, including glue address records, the name server MUST
set the TC bit on the response.
4.4.2. Responding to Queries for Type DELEG
DELEG records, when present, are included in referrals. When a
parent and child are served from the same authoritative server, this
referral will not be sent because the authoritative server will
respond with information from the child zone. In that case, the
resolver may query for type DELEG.
The DELEG resource record type is unusual in that it appears only on
the parent zone's side of a zone cut. For example, the DELEG RRset
for the delegation of "foo.example" is part of the "example" zone
rather than in the "foo.example" zone. This requires special
processing rules for both name servers and resolvers because the name
server for the child zone is authoritative for the name at the zone
cut by the normal DNS rules, but the child zone does not contain the
DELEG RRset.
A DELEG-aware resolver sends queries to the parent zone when looking
for a DELEG RR at a delegation point. However, special rules are
necessary to avoid confusing legacy resolvers which might become
involved in processing such a query (for example, in a network
configuration that forces a DELEG-aware resolver to channel its
queries through a legacy recursive name server). The rest of this
section describes how a DELEG-aware name server processes DELEG
queries in order to avoid this problem.
April, et al. Expires 24 April 2025 [Page 12]
Internet-Draft DELEG October 2024
The need for special processing by a DELEG-aware name server only
arises when all the following conditions are met:
* The name server has received a query for the DELEG RRset at a zone
cut.
* The name server is authoritative for the child zone.
* The name server is not authoritative for the parent zone.
* The name server does not offer recursion.
In all other cases, the name server either has some way of obtaining
the DELEG RRset or could not have been expected to have the DELEG
RRset, so the name server can return either the DELEG RRset or an
error response according to the normal processing rules.
If all the above conditions are met, however, the name server is
authoritative for the domain name being searching for, but cannot
supply the requested RRset. In this case, the name server MUST
return an authoritative "no data" response showing that the DELEG
RRset does not exist in the child zone's apex.
4.4.3. Priority of DELEG over NS and Glue Address records
DELEG-aware resolvers SHOULD prioritize the information in DELEG
records over NS and glue address records. Glue records MUST NOT be
considered for a DELEG delegation. If there is an in domain name
server for a non alias mode DELEG record ipv4hint and ipv6hint MUST
be used to convey the IP address. An a alias mode DELEG record can
not have an in domain name server.
5. Privacy Considerations
All of the information handled or transmitted by this protocol is
public information published in the DNS.
6. Security Considerations
TODO: Fill this section out
6.1. Availability of Zones Without NS
6.2. Resolution Procedure
An example of a simplified DNS interaction after priming. This is a
query for www.example.com type AAAA with DELEG-aware com and
example.com authoritative servers.
April, et al. Expires 24 April 2025 [Page 13]
Internet-Draft DELEG October 2024
* Ask www.example.com qtype AAAA to a.root-servers.net the answer
is: Answer section: (empty) Authority section: com. 172800 IN NS
a.gtld-servers.net. Additional section: a.gtld-servers.net.
172800 IN AAAA 2001:db8:a83e::2:30
* Ask www.example.com qtype AAAA to a.gtld-servers.net the answer
is: Answer section: (empty) Authority section: example.com.
172800 IN NS ns1.example.com. example.com. 172800 IN DELEG 1
config1.example.com. ( ipv6hint=2001:db8:440:1:1f::24 )
Additional section: ns1.example.com. 172800 IN AAAA
2001:db8:322c::35:42
* Ask www.example.com qtype AAAA to config1.example.com
(2001:db8:1:1f::24) the answer is: Answer section:
www.example.com. 3600 IN AAAA 2001:db8:a0:322c::2 Authority
section: (empty) Additional section: (empty)
TODO: more resolution examples (e.g out of bailiwick)
6.2.1. Failures when DELEG Delegation is Present
When a delegation using DELEG to a child is present, the resolver
MUST use it and SERVFAIL if none of the configurations provided work.
7. IANA Considerations
DELEG will use the SVCB IANA registry definitions in section 14.3 of
[RFC9460].
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.
8. References
8.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>.
April, et al. Expires 24 April 2025 [Page 14]
Internet-Draft DELEG October 2024
[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:
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>.
8.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. Legacy Test Results
In December 2023, Roy Arends and Shumon Huque tested two distinct
sets of requirements that would enable the approach taken in this
document.
April, et al. Expires 24 April 2025 [Page 15]
Internet-Draft DELEG October 2024
* legacy resolvers ignore unknown record types in the authority
section of referrals.
* legacy resolvers ignore an unknown key flag in a DNSKEY.
Various recent implmentations were tested (BIND, Akamai Cacheserve,
Unbound, PowerDNS Recursor and Knot) in addition to various public
resolver services (Cloudflare, Google, Packet Clearing House). All
possible variations of delegations were tested, and there were no
issues. Further details about the specific testing methodology,
please see test-plan.
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. Differences to draft-homburg-deleg-incremental-deleg
The draft mentioned above uses a similar yet different method to
achieve a new delegation method. The main difference is that it does
not use a new RR type, but instead uses SVCB under a different label
(_deleg). This has the following issues:
* The DNS tree now is no longer consistent as names under e.g
_deleg.com decide where example.com is delegated. That is a big
deviation from a consistent naming structure.
* It is also possible delegate the _deleg label making resolution
even more complex
* As it is an SVCB record only one alias mode is allowed per
delegation
* Every resolver supporting it would immediately have to send two
queries for every iteration possibly causing a huge traffic
increase to authorities
Appendix D. TODO
RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.
* Write a security considerations section
* worked out resolution example including alias form delegation
April, et al. Expires 24 April 2025 [Page 16]
Internet-Draft DELEG October 2024
Appendix E. Change Log
RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.
E.1. since draft-wesplaap-deleg-00
* Clarified SVCB priority behaviour
* Added section on differences to draft-homburg-deleg-incremental-
deleg
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
Vladimír Čunát
CZ.nic
Email: vladimir.cunat@nic.cz
April, et al. Expires 24 April 2025 [Page 17]
Internet-Draft DELEG October 2024
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
Manu Bretelle
Meta
Email: chantr4@gmail.com
April, et al. Expires 24 April 2025 [Page 18]
Internet-Draft DELEG October 2024
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 24 April 2025 [Page 19]