DNS Operation Group P. Zuo Internet-Draft Z.W. Yan Intended status: Informational CNNIC Expires: 4 July 2024 January 2024 A lightweight DNS delegation confirmation protocol draft-zuo-dns-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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 author 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 4 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, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . 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 4 July 2024 [Page 13]