Integration of DNS Domain Names into Application Environments: Motivations and Considerations
draft-ietf-dnsop-integration-04

Internet Engineering Task Force                                 S. Sheth
Internet-Draft                                                 A. Kaizer
Intended status: Informational                             Verisign Labs
Expires: 25 January 2027                                      B. Newbold
                                                          Bluesky Social
                                                              N. Johnson
                                                                ENS Labs
                                                            24 July 2026

     Integration of DNS Domain Names into Application Environments:
                     Motivations and Considerations
                    draft-ietf-dnsop-integration-04

Abstract

   This document describes considerations when integrating a DNS domain
   name into an application environment.  Goals of this document include
   minimizing conflicts between the global DNS and applications that
   integrate with the global DNS, providing a consistent user experience
   (unique identifier across environments), and avoiding impacts to the
   security, stability, and resiliency of the global DNS.  While all
   sources of potential concern cannot be enumerated in one document,
   accounting for at least the considerations discussed here should
   improve the security posture of both the global DNS and integrating
   applications.

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 25 January 2027.

Copyright Notice

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

Sheth, et al.            Expires 25 January 2027                [Page 1]
Internet-Draft        DNS Domain Name Integrations             July 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Intended Audience . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Considerations for a DNS Integration  . . . . . . . . . . . .   4
     3.1.  Domain Name Lifecycle . . . . . . . . . . . . . . . . . .   4
     3.2.  Domain Control Validation . . . . . . . . . . . . . . . .   5
     3.3.  Completeness  . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Synchronization Mechanisms  . . . . . . . . . . . . . . .   6
     3.5.  DNS Protocol Evolution  . . . . . . . . . . . . . . . . .   6
     3.6.  Variety of DNS Management User Interfaces . . . . . . . .   6
     3.7.  DNS Record Type Support . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Integration Lessons Learned  . . . . . . . . . . . .   8
     A.1.  ATP and Bluesky . . . . . . . . . . . . . . . . . . . . .   9
     A.2.  Ethereum Name Service . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document describes considerations when integrating a DNS domain
   name into an application environment.  While the considerations may
   apply to other systems that use a domain-name based syntax, 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.  The rest of this
   document proceeds under this framing.

Sheth, et al.            Expires 25 January 2027                [Page 2]
Internet-Draft        DNS Domain Name Integrations             July 2026

   Domain names from the global DNS have long been used as identifiers
   in applications.  In the early days, domain names were associated
   with 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 domain
   names.  How a domain name is enabled for use as an identifier in each
   of these applications is known as a DNS integration.

   Given the ever-increasing number of application environments using or
   proposing their own DNS integrations, there is a need to raise
   awareness about considerations that such applications should account
   for in order to provide a "responsible" DNS integration.  A
   responsible DNS integration can be defined as one that allows a
   domain name to be used within an application environment in a way
   that provides a consistent user experience (unique identifier across
   environments) and avoids impacting the security, stability, and
   resiliency of the global DNS.

   In support of the development of responsible DNS integrations, this
   document describes some considerations that DNS integrations should
   account for.  While all sources of potential concern cannot be
   enumerated in one document, accounting for at least the
   considerations discussed here should improve the security posture of
   applications as they integrate with the global DNS.

1.1.  Intended Audience

   This document is targeted at developers of applications that provide
   or are considering an integration with the global DNS, e.g., to use
   domain names as an identifier in their application.  Applications
   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 domain name.

   This document does not prescribe specific mechanisms about how to
   perform a DNS integration, but rather provides considerations that
   apply broadly to DNS integrations.

   Applications may find value in using this document as a checklist
   that, if ensuring each consideration is accounted for, can decrease
   outcomes that could negatively impact the application and the global
   DNS.

Sheth, et al.            Expires 25 January 2027                [Page 3]
Internet-Draft        DNS Domain Name Integrations             July 2026

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 domain name is enabled for use as an
      identifier in an application environment
   *  Responsible DNS integration: Takes into account qualities and
      considerations that provide a consistent user experience and
      avoids impacting the security, stability, and resiliency of the
      global DNS
   *  Synchronization: The property that a domain name integrated into
      an application environment aligns with its state in the global DNS

3.  Considerations for a DNS Integration

   This section provides considerations that a DNS integration should
   account for in their specification design.  Failure to account for
   such considerations may result in user confusion, name collisions
   between an application and the global DNS, or other security related
   concerns.  The exact risks depend on the context and design of the
   integration and are out of scope for this document.

   While each integration may have unique considerations, Appendix A
   looks at how the considerations listed here relate to two different
   protocols: Authenticated Transfer Protocol (ATP) and Ethereum Name
   Service.  Reviewing that may help contextualize how other DNS
   integrations are approaching these topics.

3.1.  Domain Name Lifecycle

   A DNS integration should account for 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 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 domain name in the global
   DNS.

   Failure to account for the domain name lifecycle might result in a
   DNS integration allowing users other than the current registrant of
   the domain name to control the domain name in the integration.  This
   could lead to confusion and security risks which may break end user
   trust.

Sheth, et al.            Expires 25 January 2027                [Page 4]
Internet-Draft        DNS Domain Name Integrations             July 2026

3.2.  Domain Control Validation

   A DNS integration should implement validation checks to ensure only
   the DNS registrant or an authorized party associated with the 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 domain name, e.g., at a well-known
   endpoint as described in [RFC8615].

   Failure to perform domain control validation results in the same
   challenges as described in Section 3.1.

3.3.  Completeness

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

   DNS integrations should be aware that the list of valid global DNS
   TLDs can change, so should not hard code a list of accepted TLDs.  If
   applications want a list of currently valid TLDs, they can use a
   routinely updated list such as that provided by IANA [IANA-TLD].
   Failure to account for new TLDs may lead to inadvertent exclusion
   which could also lead to registrant and user confusion.

   When interacting with non-technical users, applications should
   present and accept domain names in Unicode "u-label" format
   [RFC5890].  In the DNS wire format, applications should only use
   domain names that conform to the "Preferred Name Syntax" [RFC1034] or
   the Attrleaf syntax [RFC8553].  Applications should store and display
   names only in fully-qualified form without the final ".", unless they
   also require access to network-local search domains [RFC3397].

   Displaying, normalizing, comparing, encoding, and decoding of domain
   names requires special processing, and cannot rely on generic string
   operations alone.  In the user interface, applications should take
   care to prevent potential attacks related to visually similar
   characters as described in Section 4.4 of [RFC5890].  Other security
   risks include improper use of case-sensitive comparison and failure
   to reject names whose labels contain non-preferred characters.

Sheth, et al.            Expires 25 January 2027                [Page 5]
Internet-Draft        DNS Domain Name Integrations             July 2026

3.4.  Synchronization Mechanisms

   A DNS integration should provide documented mechanisms to handle
   cases where an integrated domain name is no longer synchronized,
   e.g., because a lifecycle event occurred as discussed in Section 3.1.
   Documented mechanisms provide clarity to users about what they need
   to do to maintain an integration while also ensuring the application
   providing an integration is taking steps to ensure alignment with the
   global DNS.

   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 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.

   Additionally, 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 domain name
   or impact the ability of a DNS integration from checking the status
   of the domain name.  DNS integrations should consider how to handle
   and recover from such issues, including allowing a registrant to re-
   integrate the domain name.

3.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.

3.6.  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 can provide advice for how to perform such actions for
   some interfaces, but it is not feasible to do so for all.

Sheth, et al.            Expires 25 January 2027                [Page 6]
Internet-Draft        DNS Domain Name Integrations             July 2026

3.7.  DNS Record Type Support

   A DNS integration might utilize record types that are not widely
   supported at DNS providers.  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.  To avoid such
   challenges, a DNS integration should provide alternatives, such as a
   different record type that is expected to be more broadly deployed to
   ensure users can participate.

4.  IANA Considerations

   This document has no IANA actions.

5.  Security Considerations

   This document does not introduce new protocol artifacts with security
   considerations, however, DNS integrations should account for general
   DNS related issues and resource capacity considerations.

   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.

6.  Informative References

   [ENS-NIC]  Verisign, "Ethereum Name Service (ENS) Root Change Issue",
              12 April 2019, <https://www.verisign.com/assets/labs/ens-
              root-change-issues-5.2020.pdf>.

Sheth, et al.            Expires 25 January 2027                [Page 7]
Internet-Draft        DNS Domain Name Integrations             July 2026

   [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>.

   [IANA-TLD] IANA, "IANA List of TLDs", 7 April 2026,
              <https://data.iana.org/TLD/tlds-alpha-by-domain.txt>.

   [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>.

   [RFC3397]  Aboba, B. and S. Cheshire, "Dynamic Host Configuration
              Protocol (DHCP) Domain Search Option", RFC 3397,
              DOI 10.17487/RFC3397, November 2002,
              <https://www.rfc-editor.org/info/rfc3397>.

   [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>.

   [RFC8553]  Crocker, D., "DNS Attrleaf Changes: Fixing Specifications
              That Use Underscored Node Names", BCP 222, RFC 8553,
              DOI 10.17487/RFC8553, March 2019,
              <https://www.rfc-editor.org/info/rfc8553>.

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

   [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>.

Appendix A.  Integration Lessons Learned

Sheth, et al.            Expires 25 January 2027                [Page 8]
Internet-Draft        DNS Domain Name Integrations             July 2026

A.1.  ATP and Bluesky

   Bluesky is a social media application built on the Authenticated
   Transfer Protocol (ATP).  In ATP, the Decentralized Identifier (DID)
   framework is used for persistent account identifiers.  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.  The handle-to-DID
   direction can be verified using either DNS TXT records or an HTTPS
   well-known endpoint, both of which align with the guidance in
   Section 3.2.  ATP handles, as used in Bluesky, are a DNS Integration.

   DNS was chosen as the handle namespace for reasons of efficiency,
   cost effectiveness, and technical maturity - considerations which
   overlap with those in Section 1.1.

   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 ATP network is design to accommodate billions of
   accounts, and DNS has 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 efficiently and at low marginal cost.

   Bluesky is a small company developing a novel network protocol.  DNS
   is a mature and broadly adopted technology.  Developers are already
   familiar with DNS, and DNS works with existing software and
   infrastructure.  The DNS system is financially sustainable with an
   international multi-stakeholder governance structure, which means
   developers can build on it with confidence.

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

   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 perennial
   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.

Sheth, et al.            Expires 25 January 2027                [Page 9]
Internet-Draft        DNS Domain Name Integrations             July 2026

   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 (aligning with Section 3.3).  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 (though the diversity of such interfaces can be
   a user documentation challenge, as discussed in Section 3.6).
   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 (as described in Sections 3.1
   and 3.4).  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 ATP handle specification text
   largely defers to IETF DNS standards, with the goal of maintaining
   compatibility as norms and best practices evolve over time (aligning
   with Section 3.5).

A.2.  Ethereum Name Service

   ENS integrates DNS names to provide a unified namespace across
   blockchain and traditional applications.  By incorporating existing
   DNS names, ENS lets people reuse familiar, already-reputable
   identifiers across both environments - a motivation that overlaps
   with several in Section 1.1, including human-readable identifiers,
   universal acceptance, and reuse of the reputation a registrant has
   already established.  Two integration paths exist: an on-chain DNSSEC
   import, in which a registrant submits a DNSSEC proof of a TXT record
   under their name to claim the equivalent ENS name, and a TLD-operator
   opt-in, in which the operator of a TLD enables the entire TLD within
   ENS.  Both are DNS integrations in the sense of this document.

   Domain control validation relies exclusively on DNSSEC.  To establish
   or update an integration, a party submits the DNSSEC chain of trust
   for a TXT record under the name; the chain is verified on-chain, and
   the record's contents bind the name to an Ethereum address.  This
   stores control evidence in DNS, aligning with the guidance in
   Section 3.2.  ENS does not currently offer a non-DNSSEC validation
   path such as an HTTPS well-known endpoint, so the integration's reach
   is limited to names whose zones are DNSSEC-signed.

   Because any party can submit a newer DNSSEC proof, and a newer proof
   supersedes an older one, the on-chain state can be re-synchronized
   with the global DNS by anyone at any time (aligning with Sections 3.1
   and 3.4).  When control of a name changes, a new registrant re-
   establishes the integration by submitting a proof of their own
   record.  One limitation shapes this behavior: ENS does not currently

Sheth, et al.            Expires 25 January 2027               [Page 10]
Internet-Draft        DNS Domain Name Integrations             July 2026

   support NSEC (negative) proofs, so the non-existence or removal of a
   record cannot be proven on-chain.  A stale positive claim therefore
   persists until a newer positive proof replaces it, rather than being
   revoked when the underlying record is deleted or the name lapses.
   Implementers should be aware that synchronization is driven by
   submission of newer positive proofs rather than by detection of
   removal.

   ENS does not hard-code a list of accepted TLDs: any TLD present in
   the DNS root can be imported with a valid DNSSEC proof, consistent
   with Section 3.3's caution against fixed TLD lists.  The registrable
   boundary is determined by an extensible on-chain mechanism that can
   be upgraded - for example, to recognize multi-label public suffixes
   such as second-level ccTLD registries - rather than by a hard-coded
   assumption.  Completeness is not yet total, however: although ENS
   supports Unicode names generally, on-chain decoding of Punycode
   (A-labels) is unavailable, so IDNA names cannot presently be
   imported.  This is a known gap of the kind Section 3.3 warns about,
   where non-ASCII names may be inadvertently excluded.

   The primary historical challenges have revolved around reliably
   identifying public suffixes and identifying the authorized party for
   a name.  Early versions of the integration made unfounded assumptions
   - most notably treating ownership of a nic.tld-form domain as
   evidence of authority over the corresponding TLD - an invalid
   control-validation heuristic of the kind Section 3.2 is intended to
   prevent [ENS-NIC].  TLD-operator integrations are now gated by manual
   verification of the operator rather than by such automated inference.
   This draft should help future implementers avoid similar pitfalls.

   The DNSSEC dependency also intersects with record and interface
   support.  While the TXT record itself is broadly supported, enabling
   DNSSEC is not offered by every registrar and is exposed
   inconsistently across DNS management interfaces, introducing the kind
   of friction described in Sections 3.6 and 3.7.  Unlike integrations
   that can fall back to a more widely deployed record type, ENS has no
   viable non-DNSSEC alternative, so names without DNSSEC remain
   excluded.  Finally, because on-chain verification supports a fixed
   set of DNSSEC algorithms, ENS must track DNS protocol evolution
   directly: as algorithms proceed through their lifecycle, support for
   them must be added to or removed from the on-chain verifier (aligning
   with Section 3.5).

Appendix B.  Change Log

      00: Initial draft of the document as adopted by DNSOP

Sheth, et al.            Expires 25 January 2027               [Page 11]
Internet-Draft        DNS Domain Name Integrations             July 2026

      01: Incorporating initial feedback from call for adoption and
      early ARTART/SECDIR reviews

      02: Streamlined considerations, revised introduction based on
      feedback from DNSDIR and mailing list comments

      03: Incorporating appendix updates to refer to considerations
      section

      04: Incorporating updated completeness text

Acknowledgements

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

Authors' Addresses

   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 Social
   Email: bryan@blueskyweb.xyz
   URI:   https://bsky.social/about

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

Sheth, et al.            Expires 25 January 2027               [Page 12]