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]