<?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.35 (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-02" category="info" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.33.0 -->
  <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-02"/>
    <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="April" day="28"/>
    <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/h1Zl1egaB3MK7ynTG
n076Tan5jy8U/XGqnjx68gRj8F81m/EzBSGWtqpMCaUp3Xeu1p0tdFXt1WKv
PtTVk3ZZKLtUjevUym5JU7o1+lS9u7qZ7Fx7t2pdvzklCd5dTSZ3u9OJUjN1
Z/b4snycf3iSf/gS8/Td2rUYP8MXtvGn6s9z9ZPBB5H/z1bXtlnJI9eudGM/
YneuOVXna9to9cYtbEVfmlrb6lTtzc/yyh8L+r7mr+eFq9UkW+THOV43zSqt
86Oxv1j4QXr8e9YqaOwuvPmb613M1RudFruw8mm8xj9DfcPctS7tHz/CsPMC
6m5cS0bZmtPJhDx7+DSZwYx64btWF93kslHd2qizy1nZkqGUafWUPQtG9v1m
4zzM3Dlltq7aGrWz3Vp1plg3rnIrMrrS5VY3RXBLjNQFhKkdewrNjU+bynxg
Fy6xRuuNag9cmcbBjefqdo112YcxHgHz0Xj+EkHZG9pRC89pSrIwb7KRTbYd
PdESQoWrKr1wLauJlzUfNpVrDX3V4p+NkxlYDpYh389cVFTbsoTtEAeI0taV
fcHT/fqFpY+fJveqjmTB96aqLPZSmKnSPnvQxS2yGilyGle7HvvSGw0/sJ01
NF5tTFuYDS04VaUpLGWkWa3vsOsppDFFL9+RcJXRbUPiGMomvCekFIqyaf5B
mcL5vUd6ItNCh6ZdOdaaQqpYklaR5HTjg7NA1s7tdFuOBAjOxwuH/YdH85DB
WGSxe2v41bZwTWOKDo5EM0QZ2eafSYDTTDnIKqX1hYPnQPbl0hYWA/GU54YT
ixrWuq1dY+WFwQWCy677Wjeq9/C+qXJYug2mkJe3uqU3IbGr8Mg0elGRbpZw
XIs0CgfxrodNlEcMlz1/SS9CdbVj5xuJ87dpbjI5h1+zUGIy1Cla1MEN5KUQ
ItGUa6O3FmK2piJlYsDlFeKwxC69wf4lSvHCBVIzVP0WWUTdiPEfIG4eKihi
yzKgtKiitZy/0/zIGK1GhoDP9y0Lj5DxrAgqOLAnjMFSs15RXnTJOy5lPcpa
nAtqTUnODAPSJkUPRZc2sWhtuZL50z6i1j0lFbxG+QHxv1q7vqO40KXh9HGk
L5p8VbkFZCrN1lRuQ6HNyoU8mv6HxGHhHXgbNuwcPEb2VCMpIMl6KrqVd/Ar
rxYG4R0mCumQl7QeUayWPVU+xAx0VXJaSqE2Vz9AHvNBUwr0nFhnLzSl1Bsy
APzpIrj2ng0zu7l4qH799fvrH86//ubrLz99oliFkHbVyLpLXVCaIL/2YYYY
HPCdOOkLKwnuwc1fz188ZLFe3d5e3YSpn3/99NGnTy12ST4K8be2pFAViwd/
E41LgghLSWG4QfaBw8iGb16exw0/ffQlbTh9eJp/+AofTOPJm1AYkCdbuxLw
sKbYKAaz8dcUNytaZBqjLFjI98Wa/IU2QkIHuR5cuFdxH8+ePsPS02HI7Wse
cBsHfPPsq2fYDk2cxvzl/eU5DfpLHPT8yVfQEVcXGBe5vN1vKINxigwYUWpL
s6byhz3arS72/MwHFZG/wuHg09BdSHkIns586GJILyt4OPyIFJ25KifEy5Sj
OJb/P0WZLPh/KMcX2Bs2FjMtZJYgGZVYio9uRyHC2SCEdsyuktXzRyQIhXxz
mGd2AJWsH9v0hna9qTQUSuhPtQCo0+Cr49odAABnjlQeZDEItrKEdAbvGoIF
OamadbYOHun3TYHkEuGVOF5eug8y/0FZBl6DlaVI2e6gotd2te6gJaSKlmsP
AAnmECNSioThYSIoD6GgNGqHaRB8sgfIhOIJSyFosIUkDsWoKDc3D4pJjqFs
zeaHUgnAiM5nJaDFWvBVaEg+A7Gi20Xc8PvQFjmmAK7fhbdCVkbnMFgXvQva
rZFpaS+Vbldm5jEDtktuTBNkMC9Yv9jHqIyhFB0acO4LdWta4H0Klf1kAvFO
7ymT/AWy8elvpezJ5CW//vJDh9xGu3gzFA/aMwF0WnHUub0G9u+hPDKUYd/e
cR4+efP+5vZkKv+qt+/47+uXyEzXLy/o75tXZ69fpz8mYcTNq3fvX18Mfw1v
nr978+bl2wt5GU/V6NHk5M3ZTyfiYifvrm4v3709e30iWYr8xxW9NLIth+Ii
YLlNaygNaj9BWQJwWEgX+OL86r/+8/FTJM+/Q/J88vjxc87+9OHZ42+oFOyQ
6GU11yCjykfYZT/Rmw0gLPeSFP96g/pWCY70a7dDWoF7wHR/+BfSzL+eqm8X
xebx0+/CAxJ49DDqbPSQdXb85OhlUeI9j+5ZJmlz9PxA0+P9nv00+hz1nj38
9nukGKNmj599/92E2o/AAQzcArvUZUl1c2mRv+FeiO9UvMlzp6rgboAsxdE8
RmZkhTFiBIahll7QYF9YilFHUdbEUdx61LAVV6oDnJdPNlev3M5wIqSwA4D2
nC/yMYp2u1pV7FpWRNnHjJISXrUPDeECUA/YHfPpDtmVyiD8sLTcU/BDRsd9
vUBuzSunlBRk+kLwsKQOjFhDJ5iBkx/SdMVlLFToZU/VaK7+xF0d5x1bW/Z6
2b/yG13wNJdX26dT2RF6+RJhzl2vS5krz1hSkpB8K7dPHFEARQHBhk7Jbhk8
vKT17TJATIEeNnRmtPTXQPprC9EcNAY/0AtIpWnisM+En+EPmsPLbG3sy5Mw
a2wUe5sOFUAwVhxAwFBqmaAbyn3efoQ+4FrS+9Dmg7JhbPw/+ilvgvUODcjJ
GLuXhLIkVV5epJaUel/rYFvMHnI7pdIBUp2VJSuB+KbpMNngW9QQOGTyzRrl
japNBqSibKZeYA1T3tOco+Pew7EDoUX5fBUgFnWJAfFITbGtWhm3avVmzQtV
rtADSMo7Nkp0WRMD7RMoJC/AcGwDWugcTAgwYcifsCyM1axYuw66sb/0hnre
FCvN8dbR3zJag98PwSY1D0mksktujzACCpFuezL5MbaK2EzLnAXJ1phd0sa4
hqdGOLYPbHRUB4ym6SlKCvoGgyl+Uy4AuOlZo9iXTCTvEwJiTo+6GruVvoa9
memDDNER7tQNcYp3xmwUx2DqdGEDW8ZNjODRXI2765YJzMZxAyhRF7Hafrbg
Sv952DhXk8k7TI4MDccoxf9qB6wyxsi1GxASCSLzYrYcF07VopdwKGSHIaFi
65yxKuoHQq5N2QlgsdUAggLz6Q/AKkpYMRmgEanhqMyCoE/fq8T/EaqNAZBT
iSwiyUwDltpWbBUIBAVxGlZwcb8JsFeqfnB/yIVIXfZNISEZ5BJMTI5cWjJg
XxEngg+wOlE3lAsOa4gonYiZTOEc+8GOrHlSgfA3ov8DIoncFUkSmSTiV6Lr
qL80XNCGyDREkRLng5xNrNSe1I4OzBZMT3FnFewbrXPUcSfFJWfJ2IMHZo6u
IDb15ASlib6MXVOuwrrUwMSG+qAbHrsKdjBIVUtkhL6AdYQ+Nb4YdUId3DnU
gbI0uD80jyLSy0jOub5gbpT4sZbTCEoQFXzsiGYOXemICfhdKkCZRI+0DIm0
g1+5VlqeERx/heYILUnjY3250i0lv0qMKiFFdGsWX5AQ7wNbrO0CTrbGFGrZ
spyhBQ9trlSMleg8m8AtO6qtYmZVwz8thiM6Fp32d4q2LCwtASBFaZWwCn2F
Nah7hFOtVmKP9Da1SvS1DW5GtA3LH+jKAkDER78c0Er+iuiBDc48OtpEqlLU
HEWthOGhuJLos0PRm+ixvFm82lF0UMvkqECaDx3VHuyJFVdS41kyjUgbQxcW
mR+UYk4doSoM7SBRW2y8i6xUnlOppNdCo4Tqcuajxwz1PTT4FHrEX/QDKxrg
X7PCX2TiINbYdIEhjbMOXbBE2OCrmLHfIHGVjFxD2CNlJZaQQo8wtbzKZJ9Y
m+k1TMyomvCUgIC5eouymFYOcrDoUjw5A1cZ5E1ja73nGondyAubtRQE5H8C
N/3iZ8QyV3o5f5ujldQNTxc4lLhXmipDgsvW1cyjbgVLN/L3VAlPGzSNFZcV
sSwkWeU0O4nAqEO8flTgH1xfP4yhMAL0GTPQGs7ltEUiMMiYUKnIEho+4npG
iYhbfqo2AePA33sCENU+MeubjknuZcXKYQIAKuiGBObzMs8O+Z5Nzua7hiTB
vd64MvTb7fBwSFTBt2PU5JQHgehKhzLoiXQg6UXGJWcJxs80hdt0qLyBCy6Y
0RuxQIxVBkq7FG5NHyWnufoRZSCPw5RhjoyjvXeFZS0nKOSJxkCEm1nX00sP
qMSiMFaaKKVuvzEPp4MVs4o1GIi6FMOtek57lbYWnmPoEbi5nKFDtYAOO0M8
V6CtRsAYsnygHoqScQWw16/WGRfv0azSAYwP/QFh4CQpeyvUIweLfWDxUcWy
jSP6yDzcBlH/CvvDTWwd6ckIvth+QneSG/F0UPcNCZO/QM3SOHmXoXHicOPu
iYKp4t0N3lwZXQZvRqXrC6yaqU8Ok4Y+Shy+2EsmTbT6JXdhk0ngXgOGid4x
OLyEK2fVai/ZJswQ+zjouSr5EB65h6p15dydKUeHEqF7TV3/bm3kdKyRZf7e
h56D5yVAsCJYFIdx2IwOL7sE5CSvYpIeYEWcInvNH7yYhf/QcXBKI5Kx0vC9
Mm0FbtRA3Xrj01miZ1/SlJdJ6o3rBF5Rdv5AdU9O/zjTdJ0u7liBeIM0Gcl7
GPCOig+3ubxT9LE0khRG3ThZmKbYYSd+Q8daqcVb4NNd6XZ0nvfF/Xc/JAVt
hl5sTOMSa2u3CSDE1jGcJQZKM6c5p4eHzZSUBi9L/H1W1kPJHI6eM0Z86LUy
h5seEv5bc8j5jpod5DlDBMBwKpAdAYQDWGovR2cO3OvVcq4RYAizWDHNBLsH
gDsNjH08OJgGEDpkdqR7abNLQ7iTW7q03BHzTRzsyBfD4DIRz1QRshJI2NN6
kbFyOwngP8l543tu1TN+DtCVI4xOGoHhako6LGzbMbAih/SUbQA9pM/PIi7N
wqw6NYWsTYSwbX2opESx1HUvvezlhXTkGYmGxV0VWR8sDLsqpmMYVzLjFYGW
AB0v1FZOqbTq/fVrpMpL5gOtWEHQTjqSZMTY0rGISRvPD/YspWcOyuj4dEy5
tQSJUk5D/mAkFk8lYWZEC1mCuK1EB9Gu4bTDCjGMkquYwHycDa5+nvp8hOdB
h5+R+jloZaaBj9kYRQ68CLtsBIgRAeZIM55nLUz+VsyNwpqP7gxocsy93JdS
dC41Pj2MPrQldvzQf8IRUrqLlVEao+Zsmoc7o6x+UR2qUJAKQVPhbCQbbIWr
EgLEUL/ZOvJH60edfdwK8yKBLRaMylP/97//xzjUpBsELL/H5z35pw23b0Zw
aj/jQ7IRhyDwfMQqEM7oBBajpmzkPohO/OGYS2G2JUCQwJxk6zEKZKtlZMrC
7F2gE4QIyb5VD+6jWnzGtfiHBMZC8yQXcLBzXroJGxzLd8tVYVcNSsGG6Lu4
91DxF6G0CtWd8zjclfYFlFkItEa8Mg0RisTINOQPqYdn3DhEGUJQ6mPJMFL6
D9TV1i56bl9GEEPngoT7DKxNZi6oMaWimwFeWUSOTTF7RYgu3AFkQG621JaR
YQ/eHErGyXw+h//RivNLGnUlg+bBHKadn0gLnVx5x9rjyz/mM6Rk7uoZF0sm
hewcg1X1GXnIt/j2ythJ6SRsdCWJlCtYhcGxYQ+lMMLzz8w8QFBBCdGe2Ylo
Mt3AZQockaUDFULaXdomvZ/1erObiwFzz9W5AMZUgjLaJ3lhgiwcxzEEedvH
Fz9abh7GWZ2KXlbI4K1bLlNUQ027NLaLrT4SIjSGoJH5BOHFHkv62s9xuuLo
fFKTsTKxq/xBjuxrzsJyOSveVzj5Np0Jfzf/Np4if3fCRF8jKX50mYcrW1AP
hXBPIXyc1SLJlqhRojqrvymn5h42DecSQuAVTuIYjU1p+ZJmolfpWDFLYC8/
CBygLwBobbGe5fntDaAV4TC+CRmTKlMYHTby8eiYEN57dXsdFPJYrgRhNDq/
1lHe3jXhiM5liSbk44gGUjYac6NSboNiWcmL6NeMFLMsR3YcUKGw2Zv8TMeb
o5gaIZx4hePo/kdWrI85FOaCb67/OlW3/3Q7VXIv6950XUAf3M4ZuVVA9GTQ
NF1MZE5QQj9JkRX7XCDmwpd21QenZ/RpOkbgBxzQNOt4Nny1LzVPW131vLfc
9gD/4eQihslt6Mllp5IvfbjmExvJk9KuGL0s6KCKjhYhbDk9yS5+jK9mhnaB
q5b00ZQV5fIsM7ytWQcdWfwj1SLwy6l7HbZ9WJWGnV1fe9OFzjHWG+o77+dC
p/F41wxX07g+hr1GHonatzFBQJYL1OAgz6D6dJ8nHqBQKxWCzgxXjihWM3oQ
Aq80M5fouOgARVh9+q0Dq3QZCQ9O852ACx9INsOYnI+IBWKSy9a1ibeTPoOc
cmdglVOHFHkVRLvXKzPUO74gU4bLkQ9e8g3UkBifPX+MPMAHvJz0EtDq9Moj
KaPBkvrRErvhh1pM76wwcqf3kru+UBfkeT8g+NbsXG80S0sWm0yGw/yjZsc2
iYTLsJ2W1CEcZlbduNsSClko11WPuMJCJs4elqfjJMwwVz/GxjGvkuRDixSr
s03v1+n+4vNHdH8RBatHUaIwN0WsWv/g2uyA3MS7WFnJrel6QbgeKHcL0qE7
CySpiB3+YeBtPaScdW5GkkqM8EiOM7S38Qw8njJwyo0w6zO5Jx5EDOnH5zfu
AsvNRNuCHMvR5cqpIjWwz7aZcAnvHZ89E3QKeqSLSGIxOWeg2cXAhyLxocdv
yRTjloWINMwo/pMJDgSR0hcOuVzCK7qUe5bSfPNJS5w2UN33ZJmjmw7ZfEdo
xVviiHVjmNIhURHZ5IrMrLXO+/EPA/iUoykRV8SVxO1Hg0Vknv1Ygfyg93xN
JCYzpjhp01EW1pmQAuRWqE4MJOnVjdsZPpDwfb0Jl97j2d9VdsqUcfbxIl66
obACTuDlDjBauKmZTtdytjQ7T5ND3862o0OAwPPXdN1w44jskDO1sb2z+swX
Daqcwe0Emg6Q/Mg6RydyIVMG0PWG6P3ZRWTXkV7DsZq6GdjjG8KuwLBEDQ/J
LJ1iHyoF3mzo2CTCX76jkG480P0FQZAQGsVr0GWgxOQMgVo+OTLUOR+ebqcE
ki37IVqeiX7p7WYTDyb4CGNWZjKGWzY5Q56jurm67OJs+YUcEUvuAciBS25O
/El3DRLjH68BH+IxKfJjTuEAPN1/s2eaVXXTFfOH0wHNpIPUBbk+X00L9Y/v
mceWmYua/MxH3xVdRA3S+/8crlKI1tJvd5qtbV1TJ3enDcwWuuKg8ck1RmQQ
tbWblo8tkgKgwiBJYscO+7AzaXw/RpQfCpbA/HA/gHflp/e1cXr0OrNk4WiB
L2hTScpzxnD5gZvoyurIXcvdMQFjoS3cD9wA3RiTG0FZ48O17Rh+P5xT9Nii
G0img42nGh76DT6xrKBSPhMyKROu6RyBlz6+3ByJrKXhX4LIjTu+8TWi85dc
24ZedHTSmznjwQ4DoM6KgNzh4x/i+HTReYnuJ+8ox5hmIAn80BjHYyjhig4x
/hjf5805/JzejD32AYGec47x12738CnoLqgJHZr0UOrzjVB5Cx1x6AOFiEnw
hrSeaw5u8UuPiXMaIXaQ3frQcJHrPay3cU0pWrSmQKeOr4/r6hi4P5TeU9qI
IJkJchUGYgeEkhtRE5bkbi5YJP99ySL8yA3gP1zbtG1JfZwkyBf74XdIUnjC
vfn/NSwzGKolBE0WgNV9PxocIIIQIAEjhGs8w/Hlebh/JT4ymdy+uOABl2dv
z46/HF01p59aNU5GDj9noB9jLnRxR5OcFXeN26EjWMnB0eTXUyl8pvzHE/b9
k098aRoLCRfp2s8Nwn/+BwY/js8UPgAA

-->

</rfc>
