| Internet-Draft | DNS Domain Name Integrations | January 2025 |
| Sheth, et al. | Expires 20 July 2025 | [Page] |
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.¶
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 20 July 2025.¶
Copyright (c) 2025 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 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.¶
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 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.¶
Domain names from the global DNS 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 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 consider 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 extends the security, stability, and resiliency of the global DNS.¶
Failure to account for the considerations described in this document may result in user confusion, name collisions between an application and the global DNS, or other security related concerns. For example, an application providing a DNS integration that does not account for the domain name lifecycle will become mis-aligned with the global DNS if an integrated domain name is deleted or is transferred. At that point, the domain name will be controlled by different parties in the global DNS and the application providing a DNS integration -- an undesirable outcome.¶
In support of the development of responsible DNS integrations, this document reviews qualities and considerations that DNS integrations should account for. Applications providing a DNS integration may use this document as a checklist that, if accounted for, can decrease outcomes that could negatively impact the security of the application and the global DNS.¶
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].¶
This document can best be realized by applications that provide DNS integrations. There are many ways to provide a DNS integration, including but not limited to:¶
Given the above, any application providing an integration using these or similar approaches is the intended audience for this document.¶
This document uses the terminology from [RFC9499] as a baseline. Additional terms applicable to DNS integrations are provided here in alphabetical order:¶
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 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.¶
Application environments might integrate 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].¶
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.¶
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.¶
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 domain name. Once validated, these records are used by Ethereum Name Service clients to support Ethereum Name Service use cases, such as routing payments.¶
Individuals and institutions that have registered a domain name can build a reputation around that domain name over time. Domain names may be considered as part of a brand, e.g., when the domain name is also the name of the company. In such cases, enabling the registrant to expand the use of their existing 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 domain name.¶
Additionally, if a user is familiar with a domain name and sees that domain name in a well designed DNS integration, then the user might have a reasonable assurance that it is the same 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 domain names can quickly bootstrap their existing familiarity into this new context.¶
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 and are out of scope for this document.¶
A DNS integration should account for the 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 which could lead to confusion.¶
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 validation 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 which could be confusing. This could lead to a security risk which may break end user trust.¶
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 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 domain names may lead to inadvertent exclusion which could also lead to registrant confusion.¶
A DNS integration should provide mechanisms to handle cases where an integrated 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 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 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 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.¶
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.¶
A designer of a DNS integration should not assume a domain name is a persistent identifier that always associates to the same registrant. Domain names may be deleted and re-registered or be transferred, which might result in the previous registrant no longer being associated with the 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.¶
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 have mechanisms in place to handle and recover from such issues, including allowing a registrant to re-integrate the domain name.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶
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.¶
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.¶
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.¶
ENS integrates DNS names to provide a unified namespace across blockchain and traditional applications. This expands ENS's usefulness by incorporating the millions of existing DNS names into the system, allowing people to use familiar identifiers that are already associated with their organization.¶
The primary challenges have revolved around reliably identifying public suffixes, and identifying the authorized user for a domain. Early versions of the integration made unfounded assumptions, such as the ownership of nic.tld form domains. This draft will help future implementers avoid such pitfalls.¶
The authors would like to acknowledge the following individuals for their contributions to this document: TBD.¶