Internet DRAFT - draft-zuo-dnsop-delegation-confirmation
draft-zuo-dnsop-delegation-confirmation
DNS Operation Group P. Zuo
Internet-Draft Z.W. Yan
Intended status: Informational CNNIC
Expires: 5 July 2024 January 2024
A lightweight DNS delegation confirmation protocol
draft-zuo-dnsop-delegation-confirmation-00
Abstract
Delegation occurs when an NS record is added in the parent zone for
the child origin. In the current DNS delegation mechanism, a
delegated zone/child zone (see Section1.1 for definition of delegated
zone) can specify any NS records at the zone apex without requiring
confirmation from the zone maintaining Glue records of the NS record.
Recently, new types of attacks that exploit this flaw have been
discovered. This draft suggests a protocol-level solution for DNS
delegation confirmation to reduce the risk of these attacks.
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 4 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zuo & Yan Expires 5 July 2024 [Page 1]
Internet-Draft DDC January 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Meaning of DNS Delegation Confirmation . . . . . . . . . 4
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
2. DNS Delegation Confirmation(DDC) Option . . . . . . . . . . . 6
2.1. DDC Request Option . . . . . . . . . . . . . . . . . . . 6
2.2. DDC Respond Option . . . . . . . . . . . . . . . . . . . 7
3. AOD (Authorization Of Delegation) Resource Record . . . . . . 7
3.1. AOD record field . . . . . . . . . . . . . . . . . . . . 8
3.1.1. NAME Field . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. RDATA Field . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. RDATA Wire Format . . . . . . . . . . . . . . . . . . 8
3.2. Usage of AOD Record . . . . . . . . . . . . . . . . . . . 9
3.3. An example of AOD Record . . . . . . . . . . . . . . . . 9
4. DNS Delegation Confirmation Protocol . . . . . . . . . . . . 9
4.1. Originating a request . . . . . . . . . . . . . . . . . . 9
4.2. Responding to a request . . . . . . . . . . . . . . . . . 9
4.3. Processing Responses . . . . . . . . . . . . . . . . . . 10
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Implementation and Compatibility considerations . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Delegation is the process by which a separate zone is created in the
name space beneath the apex of a given domain [RFC8499]. It occurs
when an NS RRSet is added in the parent zone for the child origin.
In the current DNS delegation mechanism, a delegated zone (child
zone) can specify any NS records at the zone apex without requiring
confirmation from the the zone maintaining Glue records of the NS
record (“Glue Zone”,see Section1.1). Recently, new types of attacks
such as NXNSattack [NXNSAttack] that exploit vulnerabilities in the
Zuo & Yan Expires 5 July 2024 [Page 2]
Internet-Draft DDC January 2024
DNS delegation mechanism were discovered. This draft proposes a
lightweight DNS delegation confirmation (see Section1.1 for the
definition) protocol. Based on this protocol, the “Glue Zone” can
verify the validity of NS records from a delegated zone(child zone).
1.1. Definitions
“Delegated Zone”, A Delegated Zone owns authoritative NS records at
zone apex. Delegation happens when an NS RRset is added in the
parent zone for the child origin [RFC8499], where the child zone is a
Delegated Zone.
“Glue Zone”, A Glue Zone owns authoritative Glue Records of NS. If
authoritative NS records and corresponding Glue Records are in
different zones(which usually happens for out-of-bailiwick NS
records), then the zone that owns authoritative NS records is a
Delegated Zone and the zone that owns corresponding Glue Records is a
Glue Zone(See Figure 1). If authoritative NS records and
corresponding Glue Records are in one zone, then this zone is both a
Delegated Zone and a Glue Zone(See Figure 2).
Parent Zone ("com.")
+----------------------------+
| com. IN SOA RDATA |
| com. IN NS ns1.com. |
| com. IN NS ns2.com. |
| a.com. IN NS ns1.b.net. |
| a.com. IN NS ns2.b.net. |
+----------------------------+
|
|
| Delegattion
|
V Delegated Zone / Child Zone ("a.com.") Glue Zone ("b.net.")
+---------------------------------+ +---------------------------+
| | | |
| a.com. IN SOA RDATA | References | b.net. IN SOA RDATA |
| a.com. IN NS ns1.b.net. | ---------> | b.net. IN NS ns1.b.net. |
| a.com. IN NS ns2.b.net. | | b.net. IN NS ns2.b.net. |
| …… | | ns1.b.net. IN A 1.1.1.1 |
| | | ns2.b.net. IN A 2.2.2.2 |
+---------------------------------+ +---------------------------+
Figure 1: a.com. is a Delegated Zone, b.net. is a Glue Zone.
Zuo & Yan Expires 5 July 2024 [Page 3]
Internet-Draft DDC January 2024
Parent Zone ("com.")
+----------------------------+
| |
| com. IN SOA RDATA |
| com. IN NS ns1.com. |
| com. IN NS ns2.com. |
| a.com. IN NS ns1.b.net. |
| a.com. IN NS ns2.b.net. |
| …… |
+----------------------------+
|
| Delegattion
|
V Delegated Zone / Glue Zone / Child Zone ("a.com.")
+---------------------------------------+
| |
| a.com. IN SOA RDATA |
| a.com. IN NS ns1.a.com. |
| a.com. IN NS ns2.a.com. |
| ns1.a.com. IN A 1.1.1.1 |
| ns2.a.com. IN A 2.2.2.2 |
| …… |
+---------------------------------------+
Figure 2: a.com. is both a Delegated Zone and a Glue Zone.
1.2. Meaning of DNS Delegation Confirmation
DNS Delegation Confirmation refers to the confirmation of NS records
from the “Glue Zone” to the “Delegated Zone”. To be specific, this is
a mechanism by which a Glue Zone can confirm whether the owned Glue
is the NS-corresponding glue of a certain delegated zone(See
Figure 3).
This term is clarified here to differentiate it from two usual
understanding of DNS delegation validation: The first one refers to
the verification of NS data integrity based on DNSSEC; The second one
refers to the process that recursive DNS should go to the child zone
to verify NS records because the child zone owns authoritative NS
records.
Zuo & Yan Expires 5 July 2024 [Page 4]
Internet-Draft DDC January 2024
Parent Zone ("com.")
+--------------------------+
| com. SOA RDATA |
| com. NS ns1.com. |
| com. NS ns2.com. |
| a.com. NS ns1.b.net. |
| a.com. NS ns2.b.net. |
+--------------------------+
|
|
| Delegattion
|
V Delegated Zone / Child Zone ("a.com.") Glue Zone ("b.net.")
+-------------------------------+ +-------------------------+
| | | |
| a.com. SOA RDATA | References | b.net. SOA RDATA |
| a.com. NS ns1.b.net. | ---------> | b.net. NS ns1.b.net. |
| a.com. NS ns2.b.net. | | b.net. NS ns2.b.net. |
| …… | | ns1.b.net. A 1.1.1.1 |
| a.com. NS {a1-a100}.b.victim | | ns2.b.net. A 2.2.2.2 |
+-------------------------------+ +-------------------------+
A |
| | Glue Zone ("b.victim.")
| | +------------------------------+
| | | |
| | References | b.victim. SOA RDATA |
| |----------------------------->| b.victim. NS ns1.b.victim. |
| a.com can arbitrarily specify | |
| NS record to any zone(b.victiom). | ns1.b.victim. A 3.3.3.3 |
| | ns2.b.victim. A 4.4.4.4 |
| +------------------------------+
| |
|---------------------------------------------------
based on DNS Delegation Confirmation(DDC), Glue Zone(b.victim) can
confirm {a1-a100}.b.victim are not vaild glues for "a.com" NS.
Figure 3: DNS Delegation has no confirmation mechanism.
Zuo & Yan Expires 5 July 2024 [Page 5]
Internet-Draft DDC January 2024
1.3. Motivation
The entire DNS system is based on the principle of delegation. As
described in Section1.2, in the current DNS Delegation mechanism, a
Delegated Zone can arbitrarily specify any NS records to any Glue
Zones. If a malicious Delegated Zone specifies a large amount of
fake NS pointing to victim zones, much more queries from recursive
DNS to victim zones will be triggered. This protocol vulnerability
can be abused to launch new types of attacks, such as NXNSAttack.
Current mitigation measures against such attacks are based on
optimizing DNS software implementations, such as limiting the number
of outgoing queries for NS glue. To further optimize and improve DNS
delegation mechanism, this draft proposes a protocol-level solution
for DNS delegation confirmation.
Actually, if a DNS zone is hosted by a DNS hosting service provider,
the zone's NS at zone apex has to be pointed to that DNS hosting
service provider. Thus, the DNS hosting service provider is aware of
the valid NS of hosted zones and can confirm if received requests for
a zone's glue is necessary.
2. DNS Delegation Confirmation(DDC) Option
The DNS Delegation Confirmation option(DDC Option) is an OPT RR
[RFC6891] option that can be included in the RDATA portion of an OPT
RR in DNS requests and responses. This option is used to enable DNS
Delegation Confirmation functionality within the DNS protocol.
2.1. DDC Request Option
DDC Request Option is added in a query when a recursive DNS initiates
a query to resolve glue address of a zone’s NS records. DDC Request
Option is used to inform upstream authoritative DNS that this is a
query for resolving glue address of a zone’s NS. Then the
authoritative DNS can confirm the validity of the NS to be resolved.
The wire format of a DDC request option is shown in Figure 4. The
option length varies, depending on the zone name for which the NS are
being resolved.
Zuo & Yan Expires 5 July 2024 [Page 6]
Internet-Draft DDC January 2024
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = 11 | OPTION-LENGTH >= 1, <= 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ ZONE NAME (variable size, 1 to 255 bytes) /
/ /
+-+-+-+-...
Figure 4: DDC Request Option
2.2. DDC Respond Option
DDC Respond Option is added by a DDC-aware authoritative DNS. When
receiving a query including DDC Request Option, it checks if a
suitable AOD record (See Section 3) exists. An AOD record contains a
zone’s valid NS. If such a record exists, it indicates that the
authoritative DNS has the Glue records of the NS records for the zone
specified in the Request Option. Then the authoritative DNS
populates each field in DDC respond option according to AOD
record（see section 3.1）.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = 10 | OPTION-LENGTH >= 16, <= 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count of NS (fixed size, 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ NS DNAME (variable size, 1 to 255 bytes) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ NS DNAME (variable size, 1 to 255 bytes) /
/ /
+-+-+-+-...
Figure 5: DDC Respond Option
3. AOD (Authorization Of Delegation) Resource Record
An AOD record stores necessary delegation information that
authoritative servers require to populate DDC respond option in a DNS
response.
Zuo & Yan Expires 5 July 2024 [Page 7]
Internet-Draft DDC January 2024
It is important to note that the AOD record is not used and visible
by validators or resolvers. Its purpose is solely to provide the
authoritative servers with the data they need to generate the
appropriate DDC Respond Option when responding to DNS queries.
3.1. AOD record field
3.1.1. NAME Field
AOD records are stroed in Glue Zone. The NAME Field of AOD is
concatenation of Delegated Zone name and Glue Zone name.
As an example, for “a.com. NS ns1.b.net”, the name of AOD record
should be “a.com.b.net.”.
3.1.2. RDATA Field
(1) NS Count:The NS Count specify the count of NS DNAME in an AOD
record.
(2) Flag:The flag filed is reserved for future use and must be zero.
(3) NS DNAME:The RDATA of NS record [RFC8499 section 3.3.11]. There
may be more than one NS DNAME, depending on the NS Count.
3.1.3. RDATA Wire Format
The RDATA of the AOD RR is as shown below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NS Count | Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ NS DNAME (variable size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ NS DNAME (variable size) /
/ /
+-+-+-+-...
Figure 6: AOD record wire format
Zuo & Yan Expires 5 July 2024 [Page 8]
Internet-Draft DDC January 2024
3.2. Usage of AOD Record
The operator of a “Glue Zone” is aware of what DNS zones are hosted
on this name server, because zone files of those delegated zones must
be resolved on name servers of “Glue Zone”. According to the zone
information, the operator of the "Glue Zone" can determine when to
add, delete or update AOD records. By analyzing the zone
information, the operator can identify changes in the delegation
status of zones and make corresponding updates to the AOD records.
This allows the "Glue Zone" to ensure that the delegation information
remains accurate and up to date.
3.3. An example of AOD Record
In Figure 1, “a.com.” is a delegated zone and “b.net.” is a “Glue
Zone”. An AOD record for zone “a.com.” is:
"a.com.b.net. TTL IN AOD 2 ns1;ns2”
This AOD record is maintained by Glue Zone “b.net.”.
4. DNS Delegation Confirmation Protocol
4.1. Originating a request
DNS Delegation Confirmation is trigged by a recursive server. When a
DDC-aware recursive server sends requests to resolve address (Glue
record) of delegation points, it adds DDC request option in query.
For other queries, it does not add DDC request option. This
inclusion of DDC request option serves as a notification to the
upstream authoritative DNS that the purpose of the request is to
resolve the glue records of a zone's NS. The response to request
which contains DDC request option is being expected contains DDC
respond option to indicate if the requested zone’s NS is confirmed by
the upstream authoritative DNS.
4.2. Responding to a request
DDC request option should be responded by a DDC-aware authoritative
server. For a DDC-not-aware server, the presence of a DDC request
option is ignored and the server responds as if no DDC request option
had been included in the request.
In the case of an DDC-aware authoritative server receiving a request
with a DDC request option, the following possibilities exist:
(1) If the DDC request option is invalid, the server ignores the DDC
request option and responds to the request as normal;
Zuo & Yan Expires 5 July 2024 [Page 9]
Internet-Draft DDC January 2024
(2) If the request is not for A type, the server ignores the DDC
request option and responds to the request as normal;
(3) If the request is for A type, the server first handles the
request as normal, then it adds DDC respond option in additional
section. If a suitable AOD record exist, then it populates the
DDC respond option according to AOD record data. If no suitable
AOD record exists, then it sets value of NS Count filed in DDC
respond option to zero.
It's important to note that for other requests that do not involve
resolving glue records, the DDC option is not included.
In response to a request that contains DDC request option, a DDC-
aware recursive server expects to receive a response that contains a
DDC respond option. This respond option serves to indicate whether
the NS records of the zone have been validated by the upstream
authoritative DNS. In this way, the recursive server can determine
if the delegation is verified and proceed accordingly with the
resolution process.
4.3. Processing Responses
If the client(usually a Recursive server) is expecting the response
to contain a DDC respond option and it is missing, the response MUST
be discarded.
Regarding the processing of the DNS delegation respond option by a
recursive server, there are 4 possibilities:
(1) The client is expecting the response to contain a DDC respond
option and it is missing. In this case, the client processes
the response as normal and does not implement DNS delegation
confirmation.
(2) The client is expecting the response to contain a DDC respond
option and it exists. In this case, the client first processes
the response as normal, then it uses DDC respond option to
validate delegation data. To be specific, if respond option has
at least one NS DName, it compares the delegation NS Records in
local cache with NS DName set in respond option. If there is no
difference between these two sets, the NS Records in cache is
considered as legal. However, if there is difference between
these two sets, then the NS Records in cache is considered as
illegal and it is recommended to use intersection of these two
NS Sets to proceed name resolution.
(3) The client is expecting the response does not contain a DDC
respond option and it is missing. In this case, the client
processes the response as normal.
Zuo & Yan Expires 5 July 2024 [Page 10]
Internet-Draft DDC January 2024
(4) The client is expecting the response does not contain a DDC
respond option and it exists. In this case, the response MUST
be discarded.
5. Example
Below is a simplified example to illustrate the workflow of the DNS
Delegation Confirmation Option, some steps in the resolution process
such as interaction with the DNS root are omitted.
Parent Zone ("com.")
+-------------------------+
(1)www.a.com ? | com. SOA RDATA |
|--------------> | com. NS ns1.com. |
| |------------- | com. NS ns2.com. |
| | (2)a.com NS | a.com. NS ns1.b.net. |
| | | a.com. NS ns2.b.net. |
| | +-------------------------+
| | |
| V |
+-----------+ | Delegattion
| | |
| RDNS | |
| | | Delegated Zone /
+-----------+ V Child Zone ("a.com.") Glue Zone ("b.net.")
A | A | +--------------------+ +------------------------+
| | | | | | | |
| | | |(3) |a.com. SOA RDATA |References|b.net. SOA RDATA |
| | | |a.com NS?|a.com. NS ns1.b.net.|--------->|b.net. NS ns1.b.net. |
| | | |-------->|a.com. NS ns2.b.net.| |b.net. NS ns2.b.net. |
| | |-----------| …… | |ns1.b.net. A 1.1.1.1 |
| | (4) a.com NS |a.com. NS xxx.b.net | |ns2.b.net. A 2.2.2.2 |
| | | | | …… |
| | | | |a.com.b.net. AOD ns1;ns2|
| | +--------------------+ +------------------------+
| | A |
| | (5) xxx.b.net ? (with DDC Request Option, this | |
| | query is for glue of a.com NS) | |
| |---------------------------------------------------------- |
|--------------------------------------------------------------
(6) xxx.b.net NXDOMAIN (with DDC Respond Option,indicate a.com's
valid NS is ns1.b.net;ns2.b.net;)
Figure 7: validate a.com NS based on DNS Delegation Confirmation
Option.
Zuo & Yan Expires 5 July 2024 [Page 11]
Internet-Draft DDC January 2024
The main steps in the example are as follows:
(1) The RDNS (recursive DNS) initiates a “www.example.com A” query
to “.com” ADNS (Authoritative DNS).
(2) The “.com” ADNS returns an NS RRSet for "a.com".
(3) The RDNS initiates “a.com NS” query to “a.com” ADNS because it
owns authoritative data for “a.com NS”.
(4) The “a.com” ADNS returns an NS RRSet for "a.com". Compared to
the NS RRset in “com”, the NS RRset in “a.com” contains extra NS
records（a.com NS xxx.b.net）.
(5) To resolve the NS record "a.com NS xxx.b.net", the RDNS
initiates “xxx.b.net A” query to “b.net” ADNS. In this step,
the RDNS SHOULD add DDC Request Option to inform the upstream
ADNS that this query is for resolving glue address of “a.com” NS
records.
(6) The “b.net.” ADNS returns NXDOMAIN for “xxx.b.net A”. In
addition, based on AOD record (“a.com.b.net AOD 2 ns1;ns2”),
“b.net” ADNS add DDC Respond Option to inform the RDNS of valid
NS configurations of “a.com”.
(7) After receiving DDC Respond Option from “b.net.”, the RDNS can
recognize that “a.com NS xxx.b.net” is an invalid NS and avoid
other unneccessary queries.This determination is made based on
the information provided in the DV Respond Option.
6. IANA considerations
IANA is requested to assign a new type code for AOD record and option
code 11 for DNS Delegation Confirmation Option.
7. Implementation and Compatibility considerations
The proposed DNS Delegation Confirmation protocol is compatible with
current DNS protocol. For an DDC-aware recursive DNS, if it sends a
request with DDC Request Option but receives a respond with no DDC
Respond Option, it just considers that the authoritative DNS being
requested is not DDC-aware and handles the respond as normal. For an
DDC-not-aware authoritative DNS, if it receives a request with DDC
Request Option” it just ignores the option and handles the request as
normal.
8. Acknowledgements
The authors would like to specifically thank Geoff Huston for his
review and valuable comments.
This work was supported by the National Key Research and Development
Program of China through project 2023YFB3105700.
Zuo & Yan Expires 5 July 2024 [Page 12]
Internet-Draft DDC January 2024
This document was produced using the xml2rfc tool [RFC2629].
9. References
9.1. Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
[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/info/rfc6891>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
9.2. Informative References
[NXNSAttack]
Afek, Y., Bremler-Barr, A., and L. Shafir,, "NXNSAttack:
Recursive DNS Inefficiencies and
Vulnerabilities", Proceedings of the 29th USENIX Security
Symposium, August 2020.
Authors' Addresses
Peng Zuo
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
100190
China
Email: zuopeng@cnnic.cn
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
100190
China
Email: yan@cnnic.cn
Zuo & Yan Expires 5 July 2024 [Page 13]
