Integration of DNS Domain Names into Application Environments: Motivations and Considerations
draft-sheth-dns-integration-02

Internet Engineering Task Force                                 S. Sheth
Internet-Draft                                                 A. Kaizer
Intended status: Informational                             Verisign Labs
Expires: 21 April 2025                                        B. Newbold
                                                            Bluesky, PBC
                                                              N. Johnson
                                                                ENS Labs
                                                         18 October 2024

     Integration of DNS Domain Names into Application Environments:
                     Motivations and Considerations
                     draft-sheth-dns-integration-02

Abstract

   This document reviews the motivations and considerations for
   integrating DNS domain names into an application environment and
   provides terminology to establish a shared understanding of what a
   DNS integration may entail.

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 21 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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

Sheth, et al.             Expires 21 April 2025                 [Page 1]
Internet-Draft        DNS Domain Name Integrations          October 2024

   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.  Intended Audience . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Motivations to use DNS Domain Names . . . . . . . . . . . . .   6
     3.1.  Global Consistency and Universal Acceptance . . . . . . .   6
     3.2.  Stability . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Flexibility . . . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Verifiability . . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  Reputation and Brand  . . . . . . . . . . . . . . . . . .   7
   4.  Qualities of a DNS Integration  . . . . . . . . . . . . . . .   7
     4.1.  Domain Name Lifecycle . . . . . . . . . . . . . . . . . .   8
     4.2.  Domain Control Validation . . . . . . . . . . . . . . . .   8
     4.3.  Completeness  . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Synchronization . . . . . . . . . . . . . . . . . . . . .   9
     4.5.  DNS Protocol Evolution  . . . . . . . . . . . . . . . . .   9
     4.6.  Identifier Attribution  . . . . . . . . . . . . . . . . .   9
     4.7.  Variety of DNS Management User Interfaces . . . . . . . .  10
     4.8.  DNS Record Support  . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Appendix A.  Integration Lessons Learned  . . . . . . . . . . . .  12
     A.1.  Bluesky and AT Protocol . . . . . . . . . . . . . . . . .  12
     A.2.  Ethereum Name Service . . . . . . . . . . . . . . . . . .  13
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document reviews motivations and considerations for integrating
   a domain name from the global DNS into an application environment.
   Section 2.1 of [RFC1034] notes that the term "domain name" has a long
   and varied history, however this document is targeted at domain names
   from the "global DNS" as defined in [RFC2826] and [RFC9499], i.e.,
   the DNS namespace as managed and governed by ICANN's multistakeholder
   model.  As such, other systems that use a domain name-based syntax
   that are not part of the global DNS are not the focus although such
   systems may find portions of this document applicable.  The rest of
   this document proceeds under this framing.

Sheth, et al.             Expires 21 April 2025                 [Page 2]
Internet-Draft        DNS Domain Name Integrations          October 2024

   Domain names have long been used as identifiers in applications.  In
   the early days, domain names were associated with Teletype Network
   (TELNET) hosts, File Transfer Protocol (FTP) servers, and email
   services.  Later, domain names were adopted for web browsing.  More
   recently, blockchain applications, decentralized protocols, and
   social media platforms have emerged as new use cases for DNS domain
   names.  How a DNS domain name is enabled for use as an identifier in
   each of these applications is known as a DNS integration.

   DNS integrations can be navigational or notational in nature.  A
   navigational integration consults information about the application
   environment that is stored in the DNS zone of a DNS domain name,
   e.g., to determine how to interact with a target destination.
   Examples of navigational integrations include FTP and web services
   (via A and/or AAAA records presenting the server's Internet Protocol
   address or through the use of HTTPS or SVCB record types) and email
   services (via a MX record providing the names of the email servers
   associated with a domain name).

   A notational integration is a claim that a DNS domain name is
   associated with some object or resource by an application environment
   itself.  Examples of notational integrations include domain validated
   certificates for the web and other applications and badges on social
   media platforms stating that a profile is associated with a DNS
   domain name.

   Some application environments employ both navigational and notational
   integrations, e.g., web browsing, where a client determines how to
   interact with a web server via information stored in the DNS, then
   verifies that it is interacting with the intended server by
   validating the server's certificate and other public-key
   infrastructure information.

   A key difference between navigational and notational approaches is
   where the data about the integration exists.  In navigational
   approaches, authoritative data or a pointer to such data (e.g.,
   CNAME) is in the DNS zone.  As a result, these integrations are
   eventually consistent based on the data stored in the DNS.

   Notational approaches, however, maintain information about the
   application environment's association with the DNS domain name into
   their own authoritative data.  This, in turn, introduces the
   challenge of keeping the application environment's data synchronized
   with the status of the domain name in the global DNS.  For example,
   if the DNS domain name is deleted, how does the notational
   integration eventually recognize this change and reflect it in its
   own data?

Sheth, et al.             Expires 21 April 2025                 [Page 3]
Internet-Draft        DNS Domain Name Integrations          October 2024

   The risks of a DNS integration not maintaining synchronization with
   the DNS domain name depends on use case and context.  In a social
   media environment, users might be misled into trusting another user
   based on the DNS domain name the integration claims they are
   associated with.  In a blockchain environment, payments might go to
   the incorrect target destination.  For web certificates the browser
   might trust a certificate for a DNS domain name that is no longer
   accurate because the domain name has been deleted or re-registered by
   a different registrant, and erroneously establish a secure connection
   with a server still operated by the previous registrant of the domain
   name.  (The web's navigational integration mitigates the latter risk
   because the DNS information about the application environment will be
   updated to the new registrant's when the domain name is re-
   registered, but the certificate itself is still out of
   synchronization.)

   Given the ever-increasing number of application environments using or
   proposing their own DNS integrations that might encounter such
   challenges, there is a need to define and advise on how application
   environments can enable domain names for use as identifiers in a way
   that avoids or mitigates these challenges.  The approaches that are
   most appropriate will vary based on the type of application
   environment, its operational environment, and its users' security
   objectives.

   A "responsible" DNS integration can be defined as one that takes
   these concerns into account and addresses them in its design and
   selection of DNS integrations.  While the techniques will vary, the
   overall goal for responsible DNS integrations is to allow a DNS
   domain name to be used within an application environment in a way
   that provides a consistent user experience (unique identifier across
   environments) and extends the security, stability, and resiliency of
   the global DNS.

   In support of the development of best practices for responsible DNS
   integration, this document reviews some of the qualities and
   considerations that DNS integrations should account for in order to
   provide a responsible DNS integration.  It does so by reviewing
   motivations, use cases, and challenges based on existing DNS
   integrations.  This document does not currently propose techniques
   that could be standardized for performing such integrations, but may
   do so after feedback from the community.

1.1.  Intended Audience

   This document is for everyone who wants a globally unique naming
   system that avoids user confusion, i.e., the global DNS as described
   in [RFC2826].

Sheth, et al.             Expires 21 April 2025                 [Page 4]
Internet-Draft        DNS Domain Name Integrations          October 2024

   This document's discussion applies to both navigational and
   notational integrations, however some qualities and considerations
   may apply more to one type of integration.  This document may be
   treated as providing a list of criteria that can be used to evaluate
   an integration and identify challenges that should be addressed to
   avoid synchronization related concerns.

   Example DNS integration use cases include, but are not limited to:
   social media, digital wallets, content authentication, etc.  This
   document is not limited in scope to these use cases.  Any DNS
   integration using one of the following mechanisms should consider the
   qualities and considerations described in this document:

   *  Integrations that prove domain control by following
      [I-D.ietf-dnsop-domain-verification-techniques]
   *  Integrations that store data associated with the DNS domain name
      in the domain name's zone
   *  Integrations that store data associated with the DNS domain name
      outside of the DNS, e.g., on a well-known endpoint of a web server
      or on a blockchain

   Given the above, the intended audience includes both the application
   environment providing an integration and the users of an integration
   who may want to evaluate an integration before using it.

2.  Terminology

   This document uses the terminology from [RFC9499] as a baseline.
   Additional terms applicable to DNS integrations are provided here in
   alphabetical order:

   *  Application environment: An application, platform, or protocol
   *  DNS integration: How a DNS domain name is enabled for use as an
      identifier in an application environment
   *  Navigational integration: Consults information about the
      application environment that is stored in the DNS zone of a DNS
      domain name
   *  Notational integration: Consults information about the DNS domain
      name that is stored in the application environment
   *  Responsible DNS integration: Takes into account qualities and
      considerations that provide a consistent user experience and
      extends the security, stability, and resiliency of the global DNS
   *  Synchronization: The property that an object integrated into an
      application environment aligns with its state in its original
      environment

Sheth, et al.             Expires 21 April 2025                 [Page 5]
Internet-Draft        DNS Domain Name Integrations          October 2024

3.  Motivations to use DNS Domain Names

   Application environments might be motivated to integrate with the
   global DNS for various reasons: global consistency, universal
   acceptance, human-readable identifiers, stability, flexibility,
   verifiability, and to utilize the reputation registrants may have
   already developed around their use of a DNS domain name.

   This section briefly describes these reasons, however additional
   motivations likely exist.  References to specific examples are used
   to illustrate the general point, while the appendix contains case
   studies that describe specific integrations.

3.1.  Global Consistency and Universal Acceptance

   Application environments might integrate DNS domain names because
   they want globally consistent, human-friendly identifiers that have
   (near) universal acceptance throughout deployed software and
   infrastructure.  Challenges can occur in namespaces that lack (near)
   universal acceptance, such as those described in ICANN's [OCTO-034].

3.2.  Stability

   The global DNS has developed a technical, social, and policy
   infrastructure over decades that has led to a stable and reliable
   naming and resolution system.  Section 4.8 of [RFC9518] also notes
   that an application environment may prefer to avoid technical and
   governance complications related to implementing a naming function of
   its own by leveraging the existing stability of the DNS protocol.

3.3.  Flexibility

   The global DNS provides the administrator of a namespace technical
   flexibility for how to use it.  Examples of this flexibility include
   which DNS provider to use (including the option to self-host), which
   DNS records to set, and which subdomains to delegate (if any).

   One specific example of this flexibility is how Bluesky can issue
   subdomains as a user's handle on Bluesky.  When users sign up for a
   Bluesky account, they can opt to be given a handle under the
   *.bsky.social domain space.  Bluesky can provide this flexibility
   because the DNS allows for it.

Sheth, et al.             Expires 21 April 2025                 [Page 6]
Internet-Draft        DNS Domain Name Integrations          October 2024

3.4.  Verifiability

   DNS provides cryptographic verifiability of DNS zone data through
   DNSSEC.  DNSSEC is the standards-defined way of digitally signing and
   verifying DNS data.  For some application environments, such as those
   being used for payment use cases, this verifiability might be
   important to ensuring that funds are being referred to the
   appropriate target.

   One example of verifiability is how Ethereum Name Service uses DNSSEC
   data to validate DNS resource records associated with the given DNS
   domain name.  Once validated, these records are used by Ethereum Name
   Service clients to support Ethereum Name Service use cases, such as
   routing payments.

3.5.  Reputation and Brand

   Individuals and institutions that have registered a DNS domain name
   can build a reputation around that DNS domain name over time.  DNS
   domain names may be considered as part of a brand, e.g., when the DNS
   domain name is also the name of the company.  In such cases, enabling
   the registrant to expand the use of their existing DNS domain name
   into new application environments adds an alternative to creating
   separate identities on each platform as they can continue to build or
   leverage their reputation and brand around their existing DNS domain
   name.

   Additionally, if a user is familiar with a DNS domain name and sees
   that DNS domain name in a well designed DNS integration, then the
   user might have a reasonable assurance that it is the same DNS domain
   name as they can resolve in the global DNS, e.g., via web browsing.
   This can benefit the integrating application environment as users who
   identify familiar DNS domain names can quickly bootstrap their
   existing familiarity into this new context.

4.  Qualities of a DNS Integration

   This section provides qualities that a DNS integration should account
   for in their specification design.  Failure to account for these
   might lead to negative outcomes, such as user confusion or name
   collisions that could provide complications to both the global DNS
   and application environments using a given DNS integration.  The
   exact risks depend on the context and design of the integration.

Sheth, et al.             Expires 21 April 2025                 [Page 7]
Internet-Draft        DNS Domain Name Integrations          October 2024

4.1.  Domain Name Lifecycle

   A DNS integration should account for DNS domain name lifecycle
   events.  Some examples of lifecycle events include expiration, change
   in DNSSEC status, or technical changes that affect the integration
   such as the removal of an expected resource record.  Such lifecycle
   events might result in a change of control or status of the DNS
   domain name compared to when it was originally integrated that could
   require one of the parties involved in the DNS integration to take
   some action to stay synchronized with the state of the DNS domain
   name in the global DNS.

   Failure to account for the DNS domain name lifecycle might result in
   a DNS integration allowing users other than the current registrant of
   the DNS domain name to control the DNS domain name in the integration
   which could lead to confusion.

4.2.  Domain Control Validation

   A DNS integration should implement validation checks to ensure only
   the DNS registrant or an authorized party associated with the DNS
   domain name can establish the integration.  Some examples of domain
   control validation include storing data in DNS
   [I-D.ietf-dnsop-domain-verification-techniques] or storing evidence
   on a server referenced by a DNS domain name, e.g., at a well-known
   endpoint as described in [RFC8615].

   Failure to perform validation might result in a DNS integration
   allowing users other than the current registrant of the DNS domain
   name to control the DNS domain name in the integration which could be
   confusing.  This could lead to a security risk which may break end
   user trust.

4.3.  Completeness

   A DNS integration should allow any DNS domain name that meets the
   integration's technical criteria to be integrated.  Not doing so
   excludes DNS domain names from participation for non-technical
   reasons, which could lead to registrant confusion if they are not
   able to associate their DNS domain name.

   DNS integrations should also be aware that global DNS domain names
   are not limited to ASCII characters, e.g., as described in [RFC5890].
   Failure to account for such DNS domain names may lead to inadvertent
   exclusion which could also lead to registrant confusion.

Sheth, et al.             Expires 21 April 2025                 [Page 8]
Internet-Draft        DNS Domain Name Integrations          October 2024

4.4.  Synchronization

   A DNS integration should provide mechanisms to handle cases where an
   integrated DNS domain name is no longer synchronized.  How often to
   execute such mechanisms will vary by DNS integration and the use
   cases supported.  For example, a DNS integration that supports
   financial use cases may check more often than a DNS integration that
   shows a verification of domain control badge on a social media
   profile.

   In general, the entity providing the DNS integration is primarily
   responsible for ensuring synchronization with the global DNS.  A DNS
   integration can allow other users to invoke one or more mechanisms,
   but this should not be solely relied upon as there are no guarantees
   that users will do so.  For example, if a DNS domain name expires the
   registrant that originally interacted with the DNS integration may
   not be interested, aware, or available to invoke the mechanisms to
   remove the DNS domain name.

   A designer of a DNS integration should also be cognizant that
   executing these mechanisms too frequently may result in rate
   limiting.  This may also occur if multiple integrated DNS domain
   names share the same infrastructure which increases the potential
   that rate limits would be triggered.  Consequently, a DNS integration
   should account for this potential in their mechanisms.

4.5.  DNS Protocol Evolution

   A designer of a DNS integration should be aware that the DNS protocol
   will evolve over time and such evolutions might impact their DNS
   integration.  For example, DNSSEC algorithms have changed over time
   as new algorithms are added, and existing algorithms are deprecated.
   Failure to account for such changes might pose a security risk, lead
   to user confusion, or cause a lack of interoperability with the
   current state of the global DNS.

4.6.  Identifier Attribution

   A designer of a DNS integration should not assume a DNS domain name
   is a persistent identifier that always associates to the same DNS
   registrant.  DNS domain names may be deleted and re-registered or be
   transferred, which might result in the previous registrant no longer
   being associated with the DNS domain name.  DNS integrations should
   account for such changes in control to avoid potential confusion,
   e.g., content being mis-attributed to the current registrant that
   belonged to a previous registrant.

Sheth, et al.             Expires 21 April 2025                 [Page 9]
Internet-Draft        DNS Domain Name Integrations          October 2024

   Additionally, DNS domain names may be exposed to temporary
   interruptions such as system downtime, DNS hijacking, or web server
   compromise.  Such events may unexpectedly change who can utilize the
   DNS domain name or impact the ability of a DNS integration from
   checking the status of the DNS domain name.  DNS integrations should
   have mechanisms in place to handle and recover from such issues,
   including allowing a registrant to re-integrate the DNS domain name.

4.7.  Variety of DNS Management User Interfaces

   A DNS integration might request a user follow certain actions to
   enable the integration.  For example, a TXT record might need to be
   set or DNSSEC might need to be configured.  However, each DNS
   management user interface might expose how to achieve the required
   actions in different ways.  This introduces friction to the
   integration process as the user might only know what they need to do
   -- e.g., add a TXT record -- but not necessarily how to do it.
   Integrations might provide advice for how to perform such actions for
   some interfaces, but it is not feasible to do so for all.

4.8.  DNS Record Support

   A DNS integration might utilize certain record types but these types
   might not be widely supported.  For example, new DNS record types
   will take time to be rolled out to DNS providers or a DNS provider
   might opt not to support a particular record type.  In such cases, a
   registrant would need to change to a new DNS provider that could
   support the required record type.

   Some DNS resolvers might fail when encountering new or unexpected
   record types.  In such cases, a different resolver would need to be
   utilized or the integration would need to directly handle resolution
   to ensure reliable access to the data stored in the DNS zone.

5.  IANA Considerations

   This document has no IANA actions.

6.  Security Considerations

   This document does not introduce new protocol artifacts with security
   considerations, however, DNS integrations should account for general
   DNS related issues including confusable characters such as those
   discussed in Section 4.4 of [RFC5890] and resource capacity
   considerations.

Sheth, et al.             Expires 21 April 2025                [Page 10]
Internet-Draft        DNS Domain Name Integrations          October 2024

   Resource capacity in a DNS integration impacts who is capable of
   performing the necessary steps to participate in or validate the
   integration.  For example, if an integration requires DNSSEC then
   some clients might not be able to perform the necessary cryptographic
   operations on their own such as IoT devices or human users performing
   manual validation.  DNS integrations should be cognizant of this
   potential gap in capabilities and how it could impact their DNS
   integration.

   Minimizing conflicts between the global DNS and applications that
   integrate with the global DNS is one of the goals of this document.
   While all sources of potential conflict cannot be enumerated, this
   effort should improve the security posture of both the global DNS and
   integrating applications through highlighting considerations to
   account for when providing a DNS integration.

7.  Informative References

   [I-D.ietf-dnsop-domain-verification-techniques]
              Sahib, S. K., Huque, S., Wouters, P., and E. Nygren,
              "Domain Control Validation using DNS", Work in Progress,
              Internet-Draft, draft-ietf-dnsop-domain-verification-
              techniques-04, 3 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              domain-verification-techniques-04>.

   [OCTO-034] Durand, A. D., "Challenges with Alternative Name Systems",
              27 April 2022,
              <https://www.icann.org/en/system/files/files/octo-
              034-27apr22-en.pdf>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC2826]  IAB, "IAB Technical Comment on the Unique DNS Root",
              RFC 2826, DOI 10.17487/RFC2826, May 2000,
              <https://www.rfc-editor.org/info/rfc2826>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

Sheth, et al.             Expires 21 April 2025                [Page 11]
Internet-Draft        DNS Domain Name Integrations          October 2024

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/info/rfc9499>.

   [RFC9518]  Nottingham, M., "Centralization, Decentralization, and
              Internet Standards", RFC 9518, DOI 10.17487/RFC9518,
              December 2023, <https://www.rfc-editor.org/info/rfc9518>.

Appendix A.  Integration Lessons Learned

A.1.  Bluesky and AT Protocol

   Bluesky is a social media application built on the atproto (AT
   Protocol) network.  In atproto, account identities are rooted in the
   Decentralized Identifier (DID) system, a W3C standard.  Most DIDs are
   not human readable, so every account is also associated with a domain
   name, referred to as a "handle".  Handles are for display only: they
   are not used in persistent references (URIs), and can change any time
   without breaking social graph connections.  The handle/DID
   relationship must be verified bi-directionally, and DNS TXT records
   are one mechanism to verify the handle-to-DID direction.  Bluesky
   handles are a DNS Integration.

   DNS was chosen as the handle namespace partially for technical
   maturity, efficiency, and cost reasons.  Registering a new handle
   needed to be fast (second-level latency), zero-cost, and reliable
   (near-zero downtime).  DNS meets all of these requirements.  The
   atproto network is design to accommodate billions of accounts, and
   DNS has also been shown to scale to hundreds of millions of
   registered domains without significant infrastructure burden.
   Service providers can use sub-domains as handles, and allocate them
   in large numbers even more efficiently.

   Bluesky is a small young company building a novel network protocol.
   DNS is a mature and broadly adopted technology, meaning developers
   are already familiar with it and have software implementations and
   infrastructure at hand.  The system is financially sustainable with a
   international multi-stakeholder governance structure, which means
   developers can build on it with confidence.

   DNS is global, distributed, and consistent which are important for a
   distributed network.  Independent service providers and software
   clients see the same view of the domain system, which means that end
   users will have a coherent experience regardless of provider or
   client.

Sheth, et al.             Expires 21 April 2025                [Page 12]
Internet-Draft        DNS Domain Name Integrations          October 2024

   Domain names are well established in society.  Domain names are
   conceptually familiar and recognizable to most network users.
   Policies, legal precedent, and dispute resolution procedures are
   mature across many jurisdictions.  These help address the perential
   challenges of impersonation and trademark disputes.  In particular,
   many culturally relevant institutions and individuals already have
   domain names with an established reputation.  The flexibility of DNS
   allows those existing domains to be reused in a new context.

   To maximize these benefits, it is important that handle validation is
   consistent and reproducible by any party.  Any valid domain name
   (hostname) can be used as a handle and that all handles are valid
   globally resolvable domain names.  This ensures that every network
   service can resolve any handle in the network, without requiring
   special DNS software.  Use of the TXT record type has broad support
   in both client software and in DNS management interfaces.  Limited
   use of caching helps reduce breakage due to short network service
   downtimes, while still ensuring that handle validity lifetime is tied
   to domain registration lifetime.  In other words, changes in domain
   control are reflected in changes on handle validity within a
   reasonable time window, reducing the chance of misattribution.  The
   atproto handle specification text largely defers to IETF DNS
   standards, with the goal of maintaining compatibility as norms and
   best practices evolve over time.

A.2.  Ethereum Name Service

   TO BE FILLED IN BY ENS

Appendix B.  Change Log

      00: Initial draft of the document.

      01: Change to informational based on feedback received during IETF
      120 conversations.

      02: Add the Bluesky section and update based on further feedback
      from the DNSOP community.

Acknowledgements

   The authors would like to acknowledge the following individuals for
   their contributions to this document: TBD.

Authors' Addresses

Sheth, et al.             Expires 21 April 2025                [Page 13]
Internet-Draft        DNS Domain Name Integrations          October 2024

   S. Sheth
   Verisign Labs
   12061 Bluemont Way
   Reston
   Email: ssheth@verisign.com
   URI:   https://www.verisignlabs.com/

   A. Kaizer
   Verisign Labs
   12061 Bluemont Way
   Reston
   Email: akaizer@verisign.com
   URI:   https://www.verisignlabs.com/

   B. Newbold
   Bluesky, PBC
   Email: bryan@blueskyweb.xyz
   URI:   https://bsky.social/about

   N. Johnson
   ENS Labs
   Email: nick@ens.domains

Sheth, et al.             Expires 21 April 2025                [Page 14]