<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.43 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ye-problems-and-requirements-of-dns-for-ioa-03" category="info" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.1 -->
  <front>
    <title abbrev="Problems and Requirements of DNS for IoA">Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA)</title>
    <seriesInfo name="Internet-Draft" value="draft-ye-problems-and-requirements-of-dns-for-ioa-03"/>
    <author initials="J." surname="Ye" fullname="Jiaming Ye">
      <organization>China Mobile</organization>
      <address>
        <email>yejiaming@chinamobile.com</email>
      </address>
    </author>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="D." surname="Ma" fullname="Di Ma">
      <organization>ZDNS</organization>
      <address>
        <email>madi@zdns.cn</email>
      </address>
    </author>
    <date year="2026" month="September" day="14"/>
    <area>OPS</area>
    <workgroup>DNSOP</workgroup>
    <keyword>keyword1</keyword>
    <keyword>keyword2</keyword>
    <keyword>keyword3</keyword>
    <abstract>
      <?line 47?>
<t>In the AI-driven era, DNS is supposed to evolve with technological advancements to accommodate the complex and diverse requirements of the IoA. This draft analyzes the issues surrounding DNS in supporting agents collaboration and explores corresponding technical requirements.</t>
    </abstract>
  </front>
  <middle>
    <?line 50?>

<section anchor="intro">
      <name>Introduction</name>
      <t>In the AI-driven era of intelligence, as intelligent agents with autonomous capabilities in perception, decision-making, execution, and learning enter the network, the network ecosystem is undergoing a profound transformation towards intelligentization and autonomization. Agents, as the core interconnected entities in the Internet of Agents (IoA), autonomously discover, efficiently interact, and harmoniously collaborate with human users, other agents, and various tools, enabling flexible resource scheduling and promoting the Internet towards intelligentization and autonomization.</t>
      <t>Currently, the stable operation of the network heavily relies on IP addresses, with the Domain Name System (DNS) serving as a critical network infrastructure responsible for converting human-readable domain names to machine-readable addresses and acting as a bridge for  network resources access. Throughout decades of stable operation and global development, there are a suite of protocols and mechanisms also has been developed to establish a fully matured DNS ecosystem. For examples, DNS-Based Service Discovery (DNS-SD) <xref target="RFC6763"/> is designed to facilitate service discovery, Service Binding (SVCB) and HTTPS <xref target="RFC9640"/>records provide instruction of accessing a service, DNS Security (DNSSEC) <xref target="RFC4033"/> <xref target="RFC4034"/> <xref target="RFC4035"/> ensure data origin authentication and data integrity, and protocols such as DNS over HTTPS (DoH) <xref target="RFC8484"/>, DNS over TLS (DoT) <xref target="RFC7858"/> and DNS over QUIC (DoQ) <xref target="RFC9250"/> supply encrypted transmission and enhance privacy and security. Therefore, in the context of the flourishing development of AI agents, the DNS is supposed to evolve with technological advancements to serve the complex and diverse requirements of the IoA. During interactions and collaborations between humans and agents, agents and agents, DNS as an infrastructure will continue to play a key role, providing technical support for efficient agent registration and discovery, real-time data synchronization, and intelligent scheduling and decision-making. Moreover, its capabilities might be further expanded to achieve semantic awareness, and effective orchestration of agents interactions.</t>
      <t>This draft aims to conduct an in-depth analysis of the issues surrounding the DNS system in supporting agents collaboration and to explore corresponding technical requirements, thereby providing robust support for the large-scale implementation and efficiency enhancement of the IoA.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>DNS: Domain Name System</t>
        <t>DNS-SD: DNS-Based Service Discovery</t>
        <t>EDNS: Extension Mechanisms for DNS</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="problem-statement">
      <name>Problem Statement</name>
      <section anchor="identifiers-reconstruction">
        <name>Identifiers Reconstruction</name>
        <t>DNS, centered around domain names and IP addresses, fulfills a crucial role in addressing, mapping domain names to IP addresses. However, the existing IP addresses struggle to identify agents effectively. This because that it is predicted that the number of AI agents will reach the scale of hundreds of billions in the future. Given the limited address space of IPv4, it isinadequate to support large-scale agent deployment and ensure stable connectivity. Even if a full transition to IPv6, which offers abundant address resources, can alleviate the address shortage, issues such as address instability and oversized routing tables will still arise. This is because that the IPv6 interface IDs undergo periodic rotation for security. Additionally, the IPv6 addresses of some physical AI agents, such as embodied intelligent agents, dynamically change with variations of their geographical locations and the network they access. The aforementioned factors make it challenging to uniquely identify an intelligent agent using its IP address.</t>
      </section>
      <section anchor="proliferating-ai-agents">
        <name>Proliferating AI Agents</name>
        <t>With the emergence of new agents, corresponding resource records will be generated accordingly. However, manually adding records to authoritative servers are inefficient and cannot keep pace with the rapid generation of agents. Currently, there is no suitable capability-based registration and discovery.</t>
        <t>On one hand, the most interactions among agents are based on capabilities, but the current names of each level domains in the hierarchical architecture, which primarily convey information, such as organization and region, fails to intuitively grasp and describe their basic functionalities, making it difficult to directly use domain names to register and discover for agents.</t>
        <t>On the other hand, in the Internet, considering the intricate roles and the enormous quantity of devices involved, the current service discovery and registration mechanisms (e.g. DNS-SD) are deficient in essential security authentication capabilities, rendering them ineffective for application in the IoA. Consequently, these situation underscores an urgent necessity for developing a service discovery and registration mechanism specifically tailored to the IoA.</t>
      </section>
      <section anchor="high-density-and-parallel-interaction">
        <name>High-density and Parallel Interaction</name>
        <t>Interactions in IoA exhibit high frequency and complexity. Agent interactions often involve multiple subtask calls within a single task query, triggering multiple DNS queries and significantly increasing the number of queries and densities, accompanied by parallel queries. This high-frequency and concurrent query pattern imposes extremely high demands on the processing performance of the DNS sytem.</t>
      </section>
      <section anchor="dynamically-changing-services">
        <name>Dynamically Changing Services</name>
        <t>As services undergo continuous evolution and agents engage in frequent interactions, the services of agents are developing and upgrading, and their operational states are also in a state of constant change. New services continually emerge, while existing services may be gradually phased out or subject to updates. Meanwhile, agent states may transition from active to inactive, or continuously fluctuate load conditions. However, the resource records (RR) within the existing DNS system remain static and are updated only infrequently, thereby failing to accurately and promptly reflect the latest situations of agents.</t>
      </section>
      <section anchor="upgrade-of-resolution-mode">
        <name>Upgrade of Resolution Mode</name>
        <t>The resolution mechanism of the current DNS system is relatively simplistic and falls short of optimally matching capabilities with resources during agent interactions. When processing multiple resource records associated with the same tree-tuple (name, class, type), existing mechanisms frequently depend on scheduling dimensions such as round-robin, weights, and geographical proximity. Although there are scenarios that take resource load into account, these mechanisms merely offer crude estimations based on simple request counts. Such estimations can significantly deviate from the actual load, thereby leading to reduced scheduling flexibility and accuracy.</t>
      </section>
      <section anchor="security-issues">
        <name>Security Issues</name>
        <t>During the interaction of agents, the underlying security issues should not be overlooked. For example, it is crucial whether an agent's identity is forged, whether the capabilities it registers are genuine, and whether these capabilities accurately correspond to its claimed identity. Any lapses in these areas could potentially expose users to attacks, threats, privacy leakage and other risks, or even lead to widespread network breakdown.</t>
      </section>
    </section>
    <section anchor="requirements-analysis">
      <name>Requirements Analysis</name>
      <t>The proliferation of agents is driving the network towards enhanced efficiency, intelligence, and flexibility. During the processes of autonomous discovery, efficient interaction, and collaborative collaboration among agents as well as between agents and users, new requirements are imposed on the DNS, such as identitication, data structure, and resolution mode. The detailed requirement analysis of the key capabilities required for the DNS within the IoA is as below.</t>
      <section anchor="global-unique-identifier">
        <name>Global Unique Identifier</name>
        <t>It is of paramount importance to assign a unique identity identifier to each agent. Firstly, this immutable ID will effectively isolate the impact caused by the frequent changes of IP addresses or URLs. In addition, while facilitating precise identification and differentiation of individual agents, it also provide a solid foundation for the verification of agent identities.</t>
      </section>
      <section anchor="autonomous-capability-registration-and-discovery">
        <name>Autonomous Capability Registration and Discovery</name>
        <t>As services keep evolving, new agents are constantly emerging, and there will be new agents registered in the Internet at any given time. Therefore, it is of vital importance to achieve automatic capability registration, discovery, and publication of agents without manual intervention.</t>
        <t>One approach is to directly achieve the mapping from agents’ capabilities to their identity identifiers by introducing capability-aware domain names. New domain names ought to incorporate additional hierarchical levels that convey capability-related information, beyond the basic information (such as organizations and regions) typically found in conventional domain names. The newly introduced name levels should be capable of intuitively and succinctly representing the capabilities of a specific type of agent or other distinctive attributes. For example, a domain name designated for an image processing agent might include keywords relevant to image processing, such as "...appname.ImageProcess.organizer." This approach would enable authoritative servers to directly identify and retrieve all image processing agents through domain names when other agents or users are searching for image processing agents, thereby enhancing the efficiency of agent discovery.</t>
        <t>The other involves refining the existing DNS-SD mechanism. Crucially, this mechanism should be enhanced by incorporating authentication and rights verification to effectively prevent counterfeiting and impersonation attacks during the registration and discovery of a large number of agents. Furthermore, the structure "&lt; Service &gt;.&lt; Domain &gt;" defined in <xref target="RFC6763"/> also should intruduce capability-aware service names to handle the mapping from agents’ capabilities to domain names, locating a scope of candidate agents.</t>
      </section>
      <section anchor="information-exchange">
        <name>Information Exchange</name>
        <section anchor="rich-information-metadata">
          <name>Rich-information Metadata</name>
          <t>In addition to utilizing domain names or PTR <xref target="RFC1035"/> to narrow down the scope of agents that provide specific capabilities, there should also be other data presenting more detailed descriptions of these agents, thereby facilitating further decision-making. Therefore, resource records (e.g. SRV, TXT, SVCB) should be capable of carrying extensive metadata, encompassing detailed capability descriptions, configuration parameters, load conditions, and other pertinentially valuable information about the agents. These metadata serves as an agent's "digital business card," providing other agents, users, and schedulers with a comprehensive insight into the agent's information. For example, an agent's RRset could include its processing performance, supported protocol types, and current workload, thereby assisting schedulers and other agents in making well-informed decisions.</t>
          <t>Meanwhile, to gain a better understanding of requester intentions and preferences, it is recommended to incorporate additional information into DNS request messages through Extended DNS (EDNS) <xref target="RFC6891"/> or service-related tags labeled by recursive server or gateways.</t>
        </section>
        <section anchor="data-freshness-maintenance">
          <name>Data Freshness Maintenance</name>
          <t>Given the frequent changes in agent information, a data update mechanism is imperative to guarantee the freshness of data. Within this mechanism, subscription-push <xref target="RFC8490"/>, regular detection and/or periodic reporting should be employed to ensure that the data (e.g. RRset) remains up-to-date. For data with low change frequencies, such as capability descriptions and configurations, real-time updates can be adopted, pushing or reporting relevant resource records when subscribed data undergoes changes. For data with high change frequencies, such as workload and network performance, periodic updates can be utilized to to prevent adverse impacts on network and processing performance. Additionally, to prevent a large number of simultaneous data refreshes across the network, a standby mode can be configured for agents with low usage, thereby reducing network load while maintaining low power consumption.</t>
        </section>
      </section>
      <section anchor="high-performance-resolution-system">
        <name>High-Performance Resolution System</name>
        <t>With the growing number of agents and increasing interaction densities, the entire resolution system must possess high performance, capable of rapidly and accurately processing a large number of concurrent query requests.</t>
      </section>
      <section anchor="multi-dimensional-dynamic-scheduling-strategies">
        <name>Multi-Dimensional Dynamic Scheduling Strategies</name>
        <t>Given the enormous number of agents, selecting the most suitable one from a pool of agents of the same type poses a significant challenge. The DNS for IoA should be equipped with multi-dimensional dynamic scheduling capabilities. It should dynamically select the optimal resolution result based on agent resource records (including capability descriptions, geographical locations, workload, etc.), business demands obtained through EDNS or other labels in pakctes, and in conjunction with network environments and load-balance strategies to achieve appropriate resource allocation.</t>
      </section>
      <section anchor="authentication-and-authorization-mechanism">
        <name>Authentication and Authorization Mechanism</name>
        <t>In agent networks, authentication and authorization are crucial for ensuring network security and reliability. This includes verifying agent IDs and capabilities (e.g., resource records). Strict identity authentication guarantees that only legitimate agents whose IDs are corresponding to their feature can access the network for registration. Meanwhile, capability authentication serves to prevent the advertisement of false capability information, thereby ensuring the accuracy of information about agents. These verifications occur during capabilities registration, with authoritative servers validating the relevant information of service providers to ensure their capability and qualification to provide the corresponding services. Additionally, service consumers (e.g. terminals and other agents) also could validate the received data to prevent tampering during transmission by intermediate third parties. By establishing a robust authentication and authorization mechanism, a secure and reliable network ecosystem can be constructed for IoA.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC6763">
          <front>
            <title>DNS-Based Service Discovery</title>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
            <date month="February" year="2013"/>
            <abstract>
              <t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6763"/>
          <seriesInfo name="DOI" value="10.17487/RFC6763"/>
        </reference>
        <reference anchor="RFC9640">
          <front>
            <title>YANG Data Types and Groupings for Cryptography</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="October" year="2024"/>
            <abstract>
              <t>This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9640"/>
          <seriesInfo name="DOI" value="10.17487/RFC9640"/>
        </reference>
        <reference anchor="RFC4033">
          <front>
            <title>DNS Security Introduction and Requirements</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4033"/>
          <seriesInfo name="DOI" value="10.17487/RFC4033"/>
        </reference>
        <reference anchor="RFC4034">
          <front>
            <title>Resource Records for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t>
              <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4034"/>
          <seriesInfo name="DOI" value="10.17487/RFC4034"/>
        </reference>
        <reference anchor="RFC4035">
          <front>
            <title>Protocol Modifications for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t>
              <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4035"/>
          <seriesInfo name="DOI" value="10.17487/RFC4035"/>
        </reference>
        <reference anchor="RFC8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RFC7858">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="D. Wessels" initials="D." surname="Wessels"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
              <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="RFC9250">
          <front>
            <title>DNS over Dedicated QUIC Connections</title>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9250"/>
          <seriesInfo name="DOI" value="10.17487/RFC9250"/>
        </reference>
        <reference anchor="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC6891">
          <front>
            <title>Extension Mechanisms for DNS (EDNS(0))</title>
            <author fullname="J. Damas" initials="J." surname="Damas"/>
            <author fullname="M. Graff" initials="M." surname="Graff"/>
            <author fullname="P. Vixie" initials="P." surname="Vixie"/>
            <date month="April" year="2013"/>
            <abstract>
              <t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</t>
              <t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="75"/>
          <seriesInfo name="RFC" value="6891"/>
          <seriesInfo name="DOI" value="10.17487/RFC6891"/>
        </reference>
        <reference anchor="RFC8490">
          <front>
            <title>DNS Stateful Operations</title>
            <author fullname="R. Bellis" initials="R." surname="Bellis"/>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="T. Lemon" initials="T." surname="Lemon"/>
            <author fullname="T. Pusateri" initials="T." surname="Pusateri"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8490"/>
          <seriesInfo name="DOI" value="10.17487/RFC8490"/>
        </reference>
      </references>
    </references>
    <?line 167?>

<section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
    </section>
    <section numbered="false" anchor="contributors">
      <name>Contributors</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6Vb7ZIbN3b9z6dAxj8ibZGMJMu2NOXYO5qRV7Olj9mZ0TpO
KpUCu0ESnu4G3egmRblUldfIvzxLHiVPknPvBdBocuR4k63d1bCJBnC/zz0A
Z7PZxHe6Kf9NV64xp6prezMpdGdWrt2fKtss3cT3i9p6b11zu99gzOXL2x8m
dtPyaN89efTo+aMnk0o3q1Nlmsmks12FYVetW1Sm9uqmw3y1aTqFhdS1+aW3
LX/26qzR1d5br9xSXby9UUvXqsumM21jOnp2tuJhDy7d2cOJXixas80mPpou
n8WdTUpXNLrGVspWL7vZ3sw24dUZXp212aszt5yVjZ/h1Zl1evboy4lbeFeZ
zvjTSb8pNf/xhaI/TtWTR0+ezB7Rf9Vsxs8UhFjaqjIllKZ037lad7bQVbVX
i736UFdP2mWh7FI1rlMruyVN6dboU/Xu6mayc+3dqnX95pQkeHc1mdztTidK
zdSd2ePL8nH+4Un+4UvM03dr12L8DF/Yxp+qP8/VTwYfRP4/W13bZiWPXLvS
jf2I3bnmVJ2vbaPVG7ewFX1pam2rU7U3P8srfyzo+5q/nheuVpNskR/neN00
q7TOj8b+YuEH6fHvWaugsbvw5m+udzFXb3Ra7MLKp/Ea/wz1DXPXurR//AjD
zguou3EtGWVrTicT8uzh02QGM+qF71pddJPLRnVro84uZ2VLhlKm1VP2LBjZ
95uN8zBz55TZumpr1M52a9WZYt24yq3I6EqXW90UwS0xUhcQpnbsKTQ3Pm0q
84FduMQarTeqPXBlGgc3nqvbNdZlH8Z4BMxH4/lLBGVvaEctPKcpycK8yUY2
2Xb0REsIFa6q9MK1rCZe1nzYVK419FWLfzZOZmA5WIZ8P3NRUW3LErZDHCBK
W1f2BU/36xeWPn6a3Ks6kgXfm6qy2Ethpkr77EEXt8hqpMhpXO167EtvNPzA
dtbQeLUxbWE2tOBUlaawlJFmtb7DrqeQxhS9fEfCVUa3DYljKJvwnpBSKMqm
+QdlCuf3HumJTAsdmnblWGsKqWJJWkWS040PzgJZO7fTbTkSIDgfLxz2Hx7N
QwZjkcXureFX28I1jSk6OBLNEGVkm38mAU4z5SCrlNYXDp4D2ZdLW1gMxFOe
G04saljrtnaNlRcGFwguu+5r3ajew/umymHpNphCXt7qlt6ExK7CI9PoRUW6
WcJxLdIoHMS7HjZRHjFc9vwlvQjV1Y6dbyTO36a5yeQcfs1CiclQp2hRBzeQ
l0KIRFOujd5aiNmaipSJAZdXiMMSu/QG+5coxQsXSM1Q9VtkEXUjxn+AuHmo
oIgty4DSoorWcv5O8yNjtBoZAj7ftyw8QsazIqjgwJ4wBkvNekV50SXvuJT1
KGtxLqg1JTkzDEibFD0UXdrEorXlSuZP+4ha95RU8BrlB8T/au36juJCl4bT
x5G+aPJV5RaQqTRbU7kNhTYrF/Jo+h8Sh4V34G3YsHPwGNlTjaSAJOup6Fbe
wa+8WhiEd5gopENe0npEsVr2VPkQM9BVyWkphdpc/QB5zAdNKdBzYp290JRS
b8gA8KeL4Np7Nszs5uKh+vXX769/OP/6m6+//PSJYhVC2lUj6y51QWmC/NqH
GWJwwHfipC+sJLgHN389f/GQxXp1e3t1E6Z+/vXTR58+tdgl+SjE39qSQlUs
HvxNNC4JIiwlheEG2QcOIxu+eXkeN/z00Ze04fThaf7hK3wwjSdvQmFAnmzt
SsDDmmKjGMzGX1PcrGiRaYyyYCHfF2vyF9oICR3kenDhXsV9PHv6DEtPhyG3
r3nAbRzwzbOvnmE7NHEa85f3l+c06C9x0PMnX0FHXF1gXOTydr+hDMYpMmBE
qS3Nmsof9mi3utjzMx9URP4Kh4NPQ3ch5SF4OvOhiyG9rODh8CNSdOaqnBAv
U47iWP7/FGWy4P+hHF9gb9hYzLSQWYJkVGIpProdhQhngxDaMbtKVs8fkSAU
8s1hntkBVLJ+bNMb2vWm0lAooT/VAqBOg6+Oa3cAAJw5UnmQxSDYyhLSGbxr
CBbkpGrW2Tp4pN83BZJLhFfieHnpPsj8B2UZeA1WliJlu4OKXtvVuoOWkCpa
rj0AJJhDjEgpEoaHiaA8hILSqB2mQfDJHiATiicshaDBFpI4FKOi3Nw8KCY5
hrI1mx9KJQAjOp+VgBZrwVehIfkMxIpuF3HD70Nb5JgCuH4X3gpZGZ3DYF30
Lmi3RqalvVS6XZmZxwzYLrkxTZDBvGD9Yh+jMoZSdGjAuS/UrWmB9ylU9pMJ
xDu9p0zyF8jGp7+VsieTl/z6yw8dchvt4s1QPGjPBNBpxVHn9hrYv4fyyFCG
fXvHefjkzfub25Op/KvevuO/r18iM12/vKC/b16dvX6d/piEETev3r1/fTH8
Nbx5/u7Nm5dvL+RlPFWjR5OTN2c/nYiLnby7ur189/bs9YlkKfIfV/TSyLYc
iouA5TatoTSo/QRlCcBhIV3gi/Or//rPx0+RPP8OyfPJ48fPOfvTh2ePv6FS
sEOil9Vcg4wqH2GX/URvNoCw3EtS/OsN6lslONKv3Q5pBe4B0/3hX0gz/3qq
vl0Um8dPvwsPSODRw6iz0UPW2fGTo5dFifc8umeZpM3R8wNNj/d79tPoc9R7
9vDb75FijJo9fvb9dxNqPwIHMHAL7FKXJdXNpUX+hnshvlPxJs+dqoK7AbIU
R/MYmZEVxogRGIZaekGDfWEpRh1FWRNHcetRw1ZcqQ5wXj7ZXL1yO8OJkMIO
ANpzvsjHKNrtalWxa1kRZR8zSkp41T40hAtAPWB3zKc7ZFcqg/DD0nJPwQ8Z
Hff1Ark1r5xSUpDpC8HDkjowYg2dYAZOfkjTFZexUKGXPVWjufoTd3Wcd2xt
2etl/8pvdMHTXF5tn05lR+jlS4Q5d70uZa48Y0lJQvKt3D5xRAEUBQQbOiW7
ZfDwkta3ywAxBXrY0JnR0l8D6a8tRHPQGPxALyCVponDPhN+hj9oDi+ztbEv
T8KssVHsbTpUAMFYcQABQ6llgm4o93n7EfqAa0nvQ5sPyoax8f/op7wJ1js0
ICdj7F4SypJUeXmRWlLqfa2DbTF7yO2USgdIdVaWrATim6bDZINvUUPgkMk3
a5Q3qjYZkIqymXqBNUx5T3OOjnsPxw6EFuXzVYBY1CUGxCM1xbZqZdyq1Zs1
L1S5Qg8gKe/YKNFlTQy0T6CQvADDsQ1ooXMwIcCEIX/CsjBWs2LtOujG/tIb
6nlTrDTHW0d/y2gNfj8Em9Q8JJHKLrk9wggoRLrtyeTH2CpiMy1zFiRbY3ZJ
G+Manhrh2D6w0VEdMJqmpygp6BsMpvhNuQDgpmeNYl8ykbxPCIg5Pepq7Fb6
GvZmpg8yREe4UzfEKd4Zs1Ecg6nThQ1sGTcxgkdzNe6uWyYwG8cNoERdxGr7
2YIr/edh41xNJu8wOTI0HKMU/6sdsMoYI9duQEgkiMyL2XJcOFWLXsKhkB2G
hIqtc8aqqB8IuTZlJ4DFVgMICsynPwCrKGHFZIBGpIajMguCPn2vEv9HqDYG
QE4lsogkMw1YaluxVSAQFMRpWMHF/SbAXqn6wf0hFyJ12TeFhGSQSzAxOXJp
yYB9RZwIPsDqRN1QLjisIaJ0ImYyhXPsBzuy5kkFwt+I/g+IJHJXJElkkohf
ia6j/tJwQRsi0xBFSpwPcjaxUntSOzowWzA9xZ1VsG+0zlHHnRSXnCVjDx6Y
ObqC2NSTE5Qm+jJ2TbkK61IDExvqg2547CrYwSBVLZER+gLWEfrU+GLUCXVw
51AHytLg/tA8ikgvIznn+oK5UeLHWk4jKEFU8LEjmjl0pSMm4HepAGUSPdIy
JNIOfuVaaXlGcPwVmiO0JI2P9eVKt5T8KjGqhBTRrVl8QUK8D2yxtgs42RpT
qGXLcoYWPLS5UjFWovNsArfsqLaKmVUN/7QYjuhYdNrfKdqysLQEgBSlVcIq
9BXWoO4RTrVaiT3S29Qq0dc2uBnRNix/oCsLABEf/XJAK/krogc2OPPoaBOp
SlFzFLUShofiSqLPDkVvosfyZvFqR9FBLZOjAmk+dFR7sCdWXEmNZ8k0Im0M
XVhkflCKOXWEqjC0g0RtsfEuslJ5TqWSXguNEqrLmY8eM9T30OBT6BF/0Q+s
aIB/zQp/kYmDWGPTBYY0zjp0wRJhg69ixn6DxFUycg1hj5SVWEIKPcLU8iqT
fWJtptcwMaNqwlMCAubqLcpiWjnIwaJL8eQMXGWQN42t9Z5rJHYjL2zWUhCQ
/wnc9IufEctc6eX8bY5WUjc8XeBQ4l5pqgwJLltXM4+6FSzdyN9TJTxt0DRW
XFbEspBkldPsJAKjDvH6UYF/cH39MIbCCNBnzEBrOJfTFonAIGNCpSJLaPiI
6xklIm75qdoEjAN/7wlAVPvErG86JrmXFSuHCQCooBsSmM/LPDvkezY5m+8a
kgT3euPK0G+3w8MhUQXfjlGTUx4EoisdyqAn0oGkFxmXnCUYP9MUbtOh8gYu
uGBGb8QCMVYZKO1SuDV9lJzm6keUgTwOU4Y5Mo723hWWtZygkCcaAxFuZl1P
Lz2gEovCWGmilLr9xjycDlbMKtZgIOpSDLfqOe1V2lp4jqFH4OZyhg7VAjrs
DPFcgbYaAWPI8oF6KErGFcBev1pnXLxHs0oHMD70B4SBk6TsrVCPHCz2gcVH
Fcs2jugj83AbRP0r7A83sXWkJyP4YvsJ3UluxNNB3TckTP4CNUvj5F2GxonD
jbsnCqaKdzd4c2V0GbwZla4vsGqmPjlMGvoocfhiL5k00eqX3IVNJoF7DRgm
esfg8BKunFWrvWSbMEPs46DnquRDeOQeqtaVc3emHB1KhO41df27tZHTsUaW
+Xsfeg6elwDBimBRHMZhMzq87BKQk7yKSXqAFXGK7DV/8GIW/kPHwSmNSMZK
w/fKtBW4UQN1641PZ4mefUlTXiapN64TeEXZ+QPVPTn940zTdbq4YwXiDdJk
JO9hwDsqPtzm8k7Rx9JIUhh142RhmmKHnfgNHWulFm+BT3el29F53hf33/2Q
FLQZerExjUusrd0mgBBbx3CWGCjNnOacHh42U1IavCzx91lZDyVzOHrOGPGh
18ocbnpI+G/NIec7anaQ5wwRAMOpQHYEEA5gqb0cnTlwr1fLuUaAIcxixTQT
7B4A7jQw9vHgYBpA6JDZke6lzS4N4U5u6dJyR8w3cbAjXwyDy0Q8U0XISiBh
T+tFxsrtJID/JOeN77lVz/g5QFeOMDppBIarKemwsG3HwIoc0lO2AfSQPj+L
uDQLs+rUFLI2EcK29aGSEsVS1730spcX0pFnJBoWd1VkfbAw7KqYjmFcyYxX
BFoCdLxQWzml0qr316+RKi+ZD7RiBUE76UiSEWNLxyImbTw/2LOUnjkoo+PT
MeXWEiRKOQ35g5FYPJWEmREtZAnithIdRLuG0w4rxDBKrmIC83E2uPp56vMR
ngcdfkbq56CVmQY+ZmMUOfAi7LIRIEYEmCPNeJ61MPlbMTcKaz66M6DJMfdy
X0rRudT49DD60JbY8UP/CUdI6S5WRmmMmrNpHu6MsvpFdahCQSoETYWzkWyw
Fa5KCBBD/WbryB+tH3X2cSvMiwS2WDAqT/3f//4f41CTbhCw/B6f9+SfNty+
GcGp/YwPyUYcgsDzEatAOKMTWIyaspH7IDrxh2MuhdmWAEECc5KtxyiQrZaR
KQuzd4FOECIk+1Y9uI9q8RnX4h8SGAvNk1zAwc556SZscCzfLVeFXTUoBRui
7+LeQ8VfhNIqVHfO43BX2hdQZiHQGvHKNEQoEiPTkD+kHp5x4xBlCEGpjyXD
SOk/UFdbu+i5fRlBDJ0LEu4zsDaZuaDGlIpuBnhlETk2xewVIbpwB5ABudlS
W0aGPXhzKBkn8/kc/kcrzi9p1JUMmgdzmHZ+Ii10cuUda48v/5jPkJK5q2dc
LJkUsnMMVtVn5CHf4tsrYyelk7DRlSRSrmAVBseGPZTCCM8/M/MAQQUlRHtm
J6LJdAOXKXBElg5UCGl3aZv0ftbrzW4uBsw9V+cCGFMJymif5IUJsnAcxxDk
bR9f/Gi5eRhndSp6WSGDt265TFENNe3S2C62+kiI0BiCRuYThBd7LOlrP8fp
iqPzSU3GysSu8gc5sq85C8vlrHhf4eTbdCb83fzbeIr83QkTfY2k+NFlHq5s
QT0Uwj2F8HFWiyRbokaJ6qz+ppyae9g0nEsIgVc4iWM0NqXlS5qJXqVjxSyB
vfwgcIC+AKC1xXqW57c3gFaEw/gmZEyqTGF02MjHo2NCeO/V7XVQyGO5EoTR
6PxaR3l714QjOpclmpCPIxpI2WjMjUq5DYplJS+iXzNSzLIc2XFAhcJmb/Iz
HW+OYmqEcOIVjqP7H1mxPuZQmAu+uf7rVN3+0+1Uyb2se9N1AX1wO2fkVgHR
k0HTdDGROUEJ/SRFVuxzgZgLX9pVH5ye0afpGIEfcEDTrOPZ8NW+1DxtddXz
3nLbA/yHk4sYJrehJ5edSr704ZpPbCRPSrti9LKggyo6WoSw5fQku/gxvpoZ
2gWuWtJHU1aUy7PM8LZmHXRk8Y9Ui8Avp+512PZhVRp2dn3tTRc6x1hvqO+8
nwudxuNdM1xN4/oY9hp5JGrfxgQBWS5Qg4M8g+rTfZ54gEKtVAg6M1w5oljN
6EEIvNLMXKLjogMUYfXptw6s0mUkPDjNdwIufCDZDGNyPiIWiEkuW9cm3k76
DHLKnYFVTh1S5FUQ7V6vzFDv+IJMGS5HPnjJN1BDYnz2/DHyAB/wctJLQKvT
K4+kjAZL6kdL7IYfajG9s8LInd5L7vpCXZDn/YDgW7NzvdEsLVlsMhkO84+a
HdskEi7DdlpSh3CYWXXjbksoZKFcVz3iCguZOHtYno6TMMNc/Rgbx7xKkg8t
UqzONr1fp/uLzx/R/UUUrB5FicLcFLFq/YNrswNyE+9iZSW3pusF4Xqg3C1I
h+4skKQidviHgbf1kHLWuRlJKjHCIznO0N7GM/B4ysApN8Ksz+SeeBAxpB+f
37gLLDcTbQtyLEeXK6eK1MA+22bCJbx3fPZM0CnokS4iicXknIFmFwMfisSH
Hr8lU4xbFiLSMKP4TyY4EERKXzjkcgmv6FLuWUrzzSctcdpAdd+TZY5uOmTz
HaEVb4kj1o1hSodERWSTKzKz1jrvxz8M4FOOpkRcEVcStx8NFpF59mMF8oPe
8zWRmMyY4qRNR1lYZ0IKkFuhOjGQpFc3bmf4QML39SZceo9nf1fZKVPG2ceL
eOmGwgo4gZc7wGjhpmY6XcvZ0uw8TQ59O9uODgECz1/TdcONI7JDztTG9s7q
M180qHIGtxNoOkDyI+scnciFTBlA1xui92cXkV1Heg3HaupmYI9vCLsCwxI1
PCSzdIp9qBR4s6Fjkwh/+Y5CuvFA9xcEQUJoFK9Bl4ESkzMEavnkyFDnfHi6
nRJItuyHaHkm+qW3m008mOAjjFmZyRhu2eQMeY7q5uqyi7PlF3JELLkHIAcu
uTnxJ901SIx/vAZ8iMekyI85hQPwdP/NnmlW1U1XzB9OBzSTDlIX5Pp8NS3U
P75nHltmLmryMx99V3QRNUjv/3O4SiFaS7/daba2dU2d3J02MFvoioPGJ9cY
kUHU1m5aPrZICoAKgySJHTvsw86k8f0YUX4oWALzw/0A3pWf3tfG6dHrzJKF
owW+oE0lKc8Zw+UHbqIrqyN3LXfHBIyFtnA/cAN0Y0xuBGWND9e2Y/j9cE7R
Y4tuIJkONp5qeOg3+MSygkr5TMikTLimcwRe+vhycySyloZ/CSI37vjG14jO
X3JtG3rR0Ulv5owHOwyAOisCcoePf4jj00XnJbqfvKMcY5qBJPBDYxyPoYQr
OsT4Y3yfN+fwc3oz9tgHBHrOOcZfu93Dp6C7oCZ0aNJDqc83QuUtdMShDxQi
JsEb0nquObjFLz0mzmmE2EF260PDRa73sN7GNaVo0ZoCnTq+Pq6rY+D+UHpP
aSOCZCbIVRiIHRBKbkRNWJK7uWCR/Pcli/AjN4D/cG3TtiX1cZIgX+yH3yFJ
4Qn35v/XsMxgqJYQNFkAVvf9aHCACEKABIwQrvEMx5fn4f6V+Mhkcvviggdc
nr09O/5ydNWcfmrVOBk5/JyBfoy50MUdTXJW3DVuh45gJQdHk19PpfCZ8h9P
2PdPPvGlaSwkXKRrPzcI//kfIgTwhRQ+AAA=

-->

</rfc>
