RFC 6950
Architectural Considerations on Application Features in the DNS
Architectural Considerations on Application Features in the DNS ✨
Okay so this one's from the Internet Architecture Board (IAB) 🏛️, which is giving very official, very important energy. It's RFC 6950, published in October 2013, and it's marked as Informational 📄. It's not a Standards Track spec, so nobody has to implement it. It's more like a really good guidebook 📖. The authors are J. Peterson (NeuStar, Inc.), O. Kolkman (NLnet Labs), H. Tschofenig (Nokia Siemens Networks), and B. Aboba (Skype) 🫶. The ISSN is 2070-1721. It doesn't list any Obsoletes or Updates lines, so it doesn't replace or change any other RFC 💅.
Abstract
Bestie, so many Internet apps lean on the Domain Name System (DNS) 🌐. Lots of them use it to find services for a domain. Some take identifiers that aren't domain names, convert them into a format the DNS can handle, and then grab app data or service location info from the DNS 🦋. Fancy app designs that treat the DNS as a foundation have raised questions about whether the DNS should be an application platform at all 🤔. This doc looks at what happens architecturally when you use the DNS for certain app features. It also gives future app designers guidance on where the DNS's limits are and when they should think about a different design 💜.
Status of This Memo
Quick note: this document is not an Internet Standards Track specification. It's published for information only 🎀.
It's a product of the Internet Architecture Board (IAB) and holds info the IAB thought was worth keeping on the permanent record ✨. It represents the consensus of the Internet Architecture Board (IAB). Documents the IAB approves for publication are not a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 🔥.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6950 🌸.
Copyright Notice
Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈.
Table of Contents
1. Motivation ......................................................2
2. Overview of DNS Application Usages ..............................4
2.1. Locating Services in a Domain ..............................5
2.2. NAPTR and DDDS .............................................6
2.3. Arbitrary Data in the DNS ..................................8
3. Challenges for the DNS .........................................10
3.1. Compound Queries ..........................................10
3.1.1. Responses Tailored to the Originator ...............12
3.2. Using DNS as a Generic Database ...........................14
3.2.1. Large Data in the DNS ..............................14
3.3. Administrative Structures Misaligned with the DNS .........16
3.3.1. Metadata about Tree Structure ......................18
3.4. Domain Redirection ........................................20
4. Private DNS and Split Horizon ..................................21
5. Principles and Guidance ........................................23
6. Security Considerations ........................................25
7. IAB Members at the Time of Approval ............................26
8. Acknowledgements ...............................................26
9. Informative References .........................................271. Motivation 💖
The Domain Name System (DNS) has been the go-to for turning domain names into Internet Protocol addresses for ages 🌈. That makes the Internet way easier to use, because it adds a handy layer of indirection between names and the lower-layer protocol bits ✨. [RFC0974] documented another use: finding an application service in a domain through the Mail Exchange (MX) Resource Record. These records help email addressed to a domain find the mail service for that domain that the zone administrator approved 📬.
The seminal MX record became the prototype for other DNS resource records that supported applications tied to a domain name 🧚. The SRV Resource Record [RFC2052] was a more general way to locate services in a domain, with a weighting system and selection among transports 🎀. The Naming Authority Pointer (NAPTR) Resource Record (originally described in [RFC2168]) is the big one here. Especially once it grew into the more general Dynamic Delegation Discovery System (DDDS) [RFC3401] framework, it gave everyone a generic way to store application data in the DNS 🔥. Mainly, it uses a client-side algorithm that turns a string into a domain name, which the DNS can then resolve to find NAPTR records 💅. That made it possible to resolve identifiers without traditional host components through the DNS. The best-known example is telephone numbers, resolved by the DDDS application ENUM 📞. More recent work, like DomainKeys Identified Mail (DKIM) [RFC6376], lets application security features be advertised through the DNS using the TXT Resource Record 🔐.
So the scope of application usage of the DNS has grown over time 📈. Lots of environments need things like confidentiality, and as more contexts rely on the DNS, some application protocols have wanted to stretch the DNS to cover those capabilities 🌸. But some proposed uses of, and extensions to, the DNS have drifted away from both the DNS architecture and the DNS protocol 😭. Take confidentiality. In the global public DNS, turning domain names into IP addresses is an exchange of public information, with no expectation of confidentiality 👀. So the underlying query/response protocol has no encryption mechanism. Usually, any security an application or service needs gets invoked after the DNS query, once the resolved service has been contacted 🛡️. The only place the DNS can keep confidential records is a private DNS environment (including split-horizon DNS), where the querier's identity is assured through some outside policy. There, the DNS can give distinct answers to private and public users 🦋. For load-balancing or other optimizations, a DNS server might return different addresses for queries from different sources, or even no response at all. See Section 3.1.1 for details 💜.
This document is guidance for application designers and application protocol designers who want to use the DNS to support features in their apps 🫶. It gives an overview of how applications have used the DNS in the past, plus a look at proposed new usages. It names concerns and trade-offs, and it answers the question, "Should I store this information in the DNS, or use some other means?" whenever that comes up during protocol development 🤔. These guidelines remind protocol designers what the DNS is good at and what it's bad at, so they can more easily decide which features the DNS should provide for their app 👑.
The guidance here complements the guidance on extending the DNS in [RFC5507] ✨. [RFC5507] covers the preferred ways to add new information to the DNS's underlying syntax, like defining new resource records or adding prefixes or suffixes to labels 🍓. This document looks at the broader implications of apps that rely on the DNS to build certain features, whether by extending the DNS or by simply reusing existing protocol capabilities 🌈. Those implications can touch how applications invoke the resolver; how name servers, resolvers, or caches behave; extensions to the underlying DNS protocol; the operational responsibilities of zone administrators; security; and the overall architecture of names 🧠. When existing DNS protocol fields get used in ways their designers didn't intend for new applications, those applications may demand further changes and extensions that are fundamentally at odds with what the DNS is good at 💀.
2. Overview of DNS Application Usages 🌟
[RFC0882] identifies the original, fundamental connection between the DNS and applications 🏛️. It starts by explaining how the interdomain scope of applications creates "formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment". That problem pushed the "mapping between host names... and ARPA Internet addresses" away from one global table (the original "hosts" file) and toward a "distributed database that performs the same function" 🗂️. [RFC0882] also imagined ways to find the resources tied to mailboxes in a domain. Without those extensions, someone trying to send mail to a foreign domain had no discovery mechanism to locate the right host in the remote domain to connect to 📬.
A special-purpose service discovery mechanism could be built for every application protocol that needed this 🙃. But the universal support for the DNS encourages folks to install these features into its public tree instead of inventing something new 🫶. So over time, several other applications started using DNS resource records to locate services in a domain or to store application data associated with a domain in the DNS 💜. This section gives examples of the various types of DNS usage by applications to date ✨.
2.1. Locating Services in a Domain ✨
okay so the MX Resource Record is the simplest example of an application advertising its domain-level resources in the Domain Name System 💖. An MX record holds the domain name of a server that receives mail for the administrative domain in question 📬, and that domain name still has to be resolved to one or more IP addresses through the DNS before you can actually reach the mail server. Naming conventions could kinda do a similar job (a host named mail.example.com, for example 🙈), but making a brand new resource record is so much better. You can put multiple MX records under the same name to designate backup resources or to load-balance across several servers (see [RFC1794]). These perks are hard to capture with naming conventions (see [RFC4367], though more recently DNS-based Service Discovery (DNS-SD) [RFC6763] codifies service instance naming conventions for use across applications to locate services in a domain) 🧚.
The MX record is a huge upgrade over naming conventions for service location, but it's still specific to one application 😤. So the general MX approach got a glow-up into the Service (SRV) Resource Record (originally described in [RFC2052]) 👑. SRV lets DNS resolvers ask for particular services and underlying transports (for example, HTTP running over Transport Layer Security (TLS) [RFC2818]), and it tells them a host name and port where that service lives in a given domain. It also has a weighting mechanism to load-balance across several instances of a service 💅.
Relying on MX and SRV records has big implications for how applications manage identifiers and how they pass domain names to resolvers 🫶. Email identifiers like user@domain depend on MX records so you can just write a "domain" part instead of making the app guess which host handles mail for that domain 📧. Naming conventions are still everywhere ("www.example.com") for things like web browsing, but SRV lets apps query for an application-specific protocol and transport in the domain 🌸. For the Lightweight Directory Access Protocol (LDAP), the SRV service name matches the URL scheme of the identifier the app invoked (e.g., when ldap://example.com is the identifier, the SRV query passed to the resolver is for _ldap._tcp.example.com) 🦋. For other applications, the SRV service name the app passes to the resolver may be implicit in the identifier rather than explicit. Either way, the app hands that service name to the DNS to find the host of the service for the domain, the port where the service resides on that host, additional locations or ports for load-balancing and fault tolerance, and related application features 🎀.
Locating specific services for a domain was the first major thing applications started doing with the DNS beyond simple name resolution 🔥. SRV took MX's precedent and generalized it, so service location is available to any application, not just mail. Applications that acquire MX (or SRV) records might need further queries or transformations to reach an eventual domain name that resolves to the IP addresses for the service. So [RFC1034] allowed that the Additional (data) section of DNS responses may contain the corresponding address records for the names of services designated by the MX record ✨. This optimization requires support in the authoritative server and the resolver. It's an early example of how application features require changes to DNS operation 🧚. It's also an extension that can't be universally relied on 💀: many DNS resolver implementations will ignore the addresses in the additional section of DNS answers because of the trustworthiness issues described in [RFC2181].
2.2. NAPTR and DDDS 🦋
The NAPTR Resource Record evolved to fill a need during the move from Uniform Resource Locators (URLs) to the more mature Uniform Resource Identifier (URI) [RFC3986] framework, which also incorporated Uniform Resource Names (URNs) 🌈. Unlike URLs, URNs usually don't convey enough semantics internally to resolve through the DNS, so a separate URI-transformation mechanism is needed to turn these into domain names 🔄. That lets identifiers with no recognizable domain component be treated as domain names for name resolution. Once a transformation results in a domain name, applications can retrieve NAPTR records under that name in the DNS 💖. NAPTR records are way richer and more complex than MX or SRV records 🤯. A NAPTR record has two weighting mechanisms ("order" and "preference"), a "service" field to designate the application the record describes, and then two translation fields: a "replacement" field or a "regexp" (regular expression) field, only one of which appears in a given NAPTR record (see [RFC2168]). A "replacement", like NAPTR's ancestor the PTR record, just designates another domain name where you'd look for records associated with this service in the domain 👉. The "regexp", on the other hand, allows regular expression transformations on the original URI to turn it into an identifier the DNS can resolve 🧠.
As the abstract of [RFC2915] says, "This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax" 🫢. Any sort of hierarchical identifier can be encoded as a domain name, so the DNS has historically been used to resolve identifiers that were never meant as names for an Internet host. A prominent early example is the in-addr domain [RFC0883], where IPv4 addresses get encoded as domain names by a string preparation algorithm that reverses the octets and treats each octet as a label in a domain name -- so, for example, the address 192.0.2.1 became 1.2.0.192.in-addr.arpa. That let resolvers query the DNS to learn the name(s) associated with an IPv4 address 🔍. The same mechanism has been applied to IPv6 addresses [RFC3596] and other kinds of identifiers that lack a domain component. Eventually this idea connected with work on a system for resolving telephone numbers on the Internet, known as ENUM (originally described in [RFC2916]) 📞. ENUM borrowed from an earlier proposal, the tpc.int domain [RFC1530], which encoded telephone numbers as domain names with a string preparation algorithm that reversed the digits and treated each digit as a label in a domain name -- so, for example, the number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM system, the special domain e164.arpa was reserved for use in place of tpc.int 🌸.
In the more mature form of the NAPTR standard, within the Dynamic Delegation Discovery System (DDDS) [RFC3401] framework, the initial transformation of an identifier (such as a telephone number) into a domain name is called the "First Well Known Rule" 🧩. The address-reversing mechanism, where a query name is formed by reversing an IPv4 address and prepending it to the in-addr.arpa domain, is generalized for NAPTR use: each application defines a "First Well Known Rule" that translates a specific resource into a query name 💡. This flexibility has inspired a bunch of proposals beyond ENUM to encode and resolve unorthodox identifiers in the DNS 🪄. As long as the identifiers transformed by the "First Well Known Rule" have some meaningful structure and aren't overly lengthy, virtually anything can be an input for the DDDS structure, for example civic addresses 🏡. Though [RFC3402] stipulates about the identifier that "The lexical structure of this string must imply a unique delegation path", there's no requirement that the identifier be hierarchical, nor that the points of delegation in the domain name created by the "First Well Known Rule" correspond to any points of administrative delegation inherent in the identifier's structure 🤷♀️.
This ability to look up names "which are not in domain name syntax" doesn't change the underlying DNS protocol, since the names generated by the DDDS algorithm are still just domain names 💅. It does change the context in which applications pass names to resolvers, though, and it can potentially require very different operational practices from zone administrators (see Section 3.3) 🧑💻. In terms of DNS query results, the presence of the "regexp" field in NAPTR records enabled unprecedented flexibility in the types of identifiers applications could resolve with the DNS 🌈. Since the output of the regular expression frequently took the form of a URI (in ENUM resolution, for example, a telephone number might be converted into a SIP URI [RFC3261]), anything that could be encoded as a URI might be the result of resolving a NAPTR record. As the next section explores, that essentially means arbitrary data 😭🫶
2.3. Arbitrary Data in the DNS ✨
okay so URIs can basically wrap up almost any data 🎁 the most extreme example is a data URL [RFC2397]. so the NAPTR record that comes back might not be a domain name that gets resolved to IP addresses and contacted for some application. it could be a literal result that the application just consumes 👀
originally, as discussed in [RFC2168], the regular expression field in NAPTR was supposed to be way more chill. the "regexp" field held a "substitution expression that is applied to the original URI in order to construct the next domain name to lookup", so it could "change the host that is contacted to resolve a URI" or be a way of "changing the path or host once the URL has been assigned". but the regex tools NAPTR authors have access to give them way more power to mess with the input string 💅 so applications started using NAPTR for way wilder transformations that didn't match any of those original goals 😭
according to [RFC3402], the output of DDDS is totally application-specific: "the Application must define what the expected output of the Terminal Rule should be". the example in that document is looking up automobile parts by putting in a part number and getting back info about the manufacturer 🚗🔧
historically speaking, NAPTR wasn't the first to store arbitrary data in the DNS 🕰️ way back, [RFC0882] noted that "it is unlikely that all users of domain names will be able to agree on the set of resources or resource information that names will be used to retrieve", so it doesn't really restrict what DNS records can carry. they might hold "host addresses, mailbox data, and other as yet undetermined information". then [RFC1035] defined the TXT record, a way to store arbitrary strings in the DNS. [RFC1035] also specifically says a TXT contains "descriptive text" and that "the semantics of the text depends on the domain where it is found". TXT records have long been the quick way for new applications to store data tied to a domain name, since adding data this way needs no registration process at all 🎀
[RFC1464] tried putting name/value pairs into the TXT record structure, so applications could tell apart different chunks of data inside one TXT record. which is so far from just "descriptive text" as TXT was originally defined 🙈 this way an application that wants to store extra data in the DNS can do it without registering a new resource record type. but [RFC5507] points out it is "difficult to reliably distinguish one application's record from others, and for its parser to avoid problems when it encounters other TXT records" 💀
TXT's open policies have made standardizing application use of it a bit of a checkered past 😬 still, TXT has been used as the technical solution for loads of applications. recently, DKIM [RFC6376] dodged the TXT ambiguity problem by storing keys under a specialized DNS naming structure that includes the component "_domainkeys". that component keeps the TXT scoped strictly to DKIM use 🔐
storing keys in the DNS became the preferred DKIM solution for a few reasons. email applications already query the DNS during ordinary operations. the public keys tied to email need wide public distribution. and email identifiers contain a domain component that applications can easily use to consult the DNS 📬 if the application had to negotiate DKIM support with mail servers, it would open up bid-down attacks (where attackers misrepresent that DKIM is unsupported on the originating side). those aren't possible when the DNS delivers the keys, provided that DNSSEC [RFC4033] guarantees the authenticity of the data 🛡️
however, there are potential issues with storing large data in the DNS, as discussed in Section 3.2.1 🥲 there are also DKIM namespace conventions that complicate the use of DNS wildcards (as discussed in Section 6.1.2 of [RFC6376] and in more general terms in [RFC5507]). and if prefixes are used to identify the TXT records an application uses, wildcards might cause leakages that other applications will need to detect 🙃
3. Challenges for the DNS 🧚
okay this part is where things get spicy 🌶️ the methods from the last section for turning arbitrary identifiers into domain names, and for returning arbitrary data in response to DNS queries, are both big departures from the DNS's basic job of translating host names to IP addresses. but neither one actually changes the underlying semantics of the DNS 🤔
now think about it: if the URIs DDDS returns can be base-64-encoded binary data in a data URL, the DNS could effectively implement the entire application feature set of any simple query-response protocol 🤯 basically, the DDDS framework treats the DNS as a generic database. the DDDS framework was actually designed to work with any sort of underlying database. as [RFC3403] says, the DNS is only one potential database for DDDS to use. whether the DNS can support the features some DDDS applications need is a much more complicated question 😵💫
as the following subsections will show, relying on the DNS as a generic database leads to extra requirements you'd expect from a database access protocol. these include authentication of the source of queries so they can be compared to access control lists, formulating complex relational queries, and asking questions about the structure of the database itself 🗂️ the global public DNS wasn't designed to provide these properties, and extending the DNS protocols to include them could cause a fundamental change to its model. ultimately, this document concludes that efforts to retrofit these capabilities into the DNS would be better spent selecting, or if necessary inventing, other Internet services with broader powers than the DNS 🦋 so if an application protocol designer wants these properties from a database, that's generally a good sign that the DNS cannot, or can only partly, meet the application's needs 🚩
since many of these new requirements came out of the ENUM space, the following sections use ENUM as an illustrative example. however, any application using the DNS as a feature-rich database could easily end up with similar requirements 💜
3.1. Compound Queries 🎰
traditionally, DNS RRsets are uniquely identified by domain name, resource record type, and class. DNS queries are based on this 3-tuple, and the replies are resource record sets that are to be treated as atomic data elements (see [RFC2181]). to applications, the DNS has traditionally behaved like an exact-match query-response lookup mechanism. outside the DNS space, though, there are plenty of query-response applications that need a compound or relational search. these take more than one factor into account when formulating a response, or use no single factor as a key to the database 🔍
for example, in telephony, call routing often takes into account lots of factors besides the dialed number. these include originating trunk groups, interexchange carrier selection, number portability data, time of day, and so on. all of them are considered at once when generating a route 📞 in its original conception, ENUM hoped to get around the traditional Public Switched Telephone Network (PSTN) and route directly to Internet-enabled devices. but the infrastructure ENUM effort, which supports moving traditional carrier routing functions to the Internet, aims for feature parity with traditional number routing 🔁 however, [RFC3402] explicitly states that "it is an assumption of the DDDS that the lexical element used to make a delegation decision is simple enough to be contained within the Application Unique String itself. The DDDS does not solve the case where a delegation decision is made using knowledge contained outside the AUS and the Rule (time of day, financial transactions, rights management, etc.)". so some thought has gone into ways to append additional data to ENUM queries, giving the DNS server enough info to return a suitable URI (see Section 3.1.1) 🧩
from a purely syntactical standpoint, though, domain names don't allow this kind of rich structure 😤 several workarounds have tried to bake these features into DNS queries. for example, the domain name itself could be combined with the additional parameters. you could take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and prepend a trunk group identifier to it, for example, of the form tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. in this particular case a DNS server can stick to its traditional behavior when locating resource records. but encoding extra parameters this way is syntactically dubious 🫠 this is especially true if more than one additional parameter is required, and because the parameters are optional, the application may need multiple queries just to check whether it has the complete information it needs to do its job 😩
as an alternative, it has been proposed that additional query parameters be piggybacked as Extension Mechanisms for DNS (EDNS(0)) extensions (see [RFC6891]). this might be problematic for three reasons 🙅♀️ first, supporting EDNS(0) extensions requires significant changes to name server behavior. these changes need to be supported by the authoritative and recursive name servers the application relies on, and they might be very hard to roll out on a global scale. second, the original stated applicability of EDNS(0), as [RFC2671] states, was to "a particular transport level message and not to any actual DNS data". because of that, the OPT Resource Records it specifies are never to be forwarded. using EDNS(0) for compound queries, however, clearly aims to discriminate actual DNS data rather than facilitate transport-layer handling 🚚 third, [RFC6891] also specifies that "OPT RRs MUST NOT be cached, forwarded, or stored" (see the next paragraph). for these reasons, this memo recommends against crafting compound DNS queries by using EDNS(0) 🚫
the implications of these compound queries for recursion and caching are potentially serious ⚠️ the logic an authoritative server uses to respond to a compound query may not be understood by any recursive servers or caches. intermediaries that naively assume the response was selected based on the domain name, type, and class alone might serve responses to queries in a different way than the authoritative server intends. so if EDNS(0) were used this way, its attributes would not be transitive. and if that wasn't considered where intermediaries are involved, which is normally the case in the global DNS, brokenness might occur 💥
3.1.1. Responses Tailored to the Originator
okay so this one is the MOST important subcase of compound queries 👑 like, responses tailored to who is asking, where the DNS has to get some kind of administrative identity from the originator 🫶 but first we have to separate it from the cases where the source IP address (or something similar) is only used to serve a location-specific name 🌸 for those, which generally lack security implications, relying on stuff like the source IP is lowkey fine ✨ like if you're making a web portal that's customized to the region of the client, it's not a security breach if the client sees the localized portal of the wrong country 💅 recursive resolvers can obscure which network the DNS client is on, so a recent proposal suggested a new DNS query parameter that recursive resolvers fill in to keep the originating IP address (see [EDNS-CLIENT-IP]) 🦋 BUT, aside from purely cosmetic uses, these approaches have known limitations because of private IP addresses, VPNs, and so on 😭 they hide the source IP and give you the IP of an intermediary that could be very far from the originating endpoint 💀 implementing something like the one described in [EDNS-CLIENT-IP] would need big changes in how recursive resolvers AND the authoritative servers operate (since the authoritative servers would be relying on the original source IP to pick resource records), plus a fundamental change to caching behavior too 🙈 so it can't be rolled out in an incremental, unilateral fashion, it could only succeed if it's implemented bilaterally (by the authoritative server and the recursive resolver) 🥲 that's a seriously big barrier to deployment, bestie
in other deployments that are in use today, including ones based on the BIND "views" feature, the source IP address is used to grant access to a selected, and potentially sensitive, set of resource records 👀 trusting the source IP of a DNS query has security implications that have stopped most solutions like this from being standardized (see [RFC6269]), though the practice is still super widespread in "split horizon" private DNS deployments (see Section 4) 🌈 these usually lean on an underlying security layer, like a physical network, a clear perimeter at a network perimeter point (with network-layer anti-spoofing countermeasures), or an IPsec VPN, to stop anyone from spoofing the source IP address 🔒 and these deployments DO have a confidentiality requirement: info meant for a constrained audience (like inside an enterprise) shouldn't leak out to the public Internet 😱 even though those internal resources may use private IP addresses that shouldn't be useful on the public Internet anyway, sometimes the leak would reveal topology or other info the name server admin wants to keep private 🙈 more recently, TSIG [RFC2845] has been used to select among "views" in BIND 🍓 that's a stronger level of security than just trusting the source IP address, BUT typically lots of users share the same secret to access a given view, and TSIG doesn't give confidentiality to DNS messages either 💀 so without network-layer separation between users of different views, eavesdroppers could capture the DNS queries and responses 👁️
the use of source IP addresses to pick DNS resource records has widespread acceptance in the field, even though the standards community hasn't accepted it 🧚 some applications go even further and propose extending the DNS to add an application-layer identifier of the originator 😤 for example, [EDNS-OPT-CODE] provides a SIP URI in an EDNS(0) parameter ✨ honestly, passing application-layer info about the originator's administrative identity through the DNS is a weak authentication mechanism, and the DNS server makes an authorization decision based on it before sharing resource records 🫠 this can kind of approximate a per-resource-record confidentiality mechanism, where only a specific set of originators gets to see certain records, or where the same name gives completely different resource record sets depending on who asked 🦋 BUT without any underlying cryptographic security, this mechanism has to rely on external layers (like VPNs) for security instead of giving any direct assurance 😩 once again, caching, forwarding, and recursion create big challenges for applications that try to offload this responsibility to the DNS 🚧 matching even the simplest application-layer authentication mechanisms would likely need a major rearchitecture of the DNS 🏗️ not gonna lie, that's a LOT
3.2. Using DNS as a Generic Database
so as we already said, applications can use something like the "First Well Known Rule" of DDDS to turn an arbitrary string into a domain name, and then get arbitrary data back from the DNS 💖 that data can live in TXT RRs, in the "regexp" of NAPTRs, or even in custom records 🎀 some query-response applications, though, need queries and responses that just fall outside the syntactic capabilities of the DNS 🙃 for example, domain names have to be made of labels that don't exceed 63 octets, and the total length of the encoded name may not exceed 255 octets 📏 applications that use label characters outside the traditional ASCII set may run into problems too (however, see the discussion in [RFC6055], Section 3 for definitive guidance on the use of non-ASCII in the DNS) 🌍 so the DNS therefore cannot be a completely generic database 🥹 similar concerns apply to the size of DNS responses, periodt 💅
3.2.1. Large Data in the DNS
ok so the "data" URL spec [RFC2397] says it is "only useful for short values" 🤨 unfortunately it gives no particular guidance about what "short" might mean 🙄 some applications today use really large data URLs (containing a megabyte or more of data) as workarounds in environments where only URIs can syntactically appear (for example, in Apple iOS, to pass objects between applications) 📱 the meaning of "short" in an application context is probably very different from how we should understand it in a DNS message ✨ looking at a typical public DNS deployment, [RFC5507] observes that "there's a strong incentive to keep DNS messages short enough to fit in a UDP datagram, preferably a UDP datagram short enough not to require IP fragmentation" 🫶 and while EDNS(0) allows for mechanisms to negotiate DNS message sizes larger than the traditional 512 octets, there is a high risk that a long payload will cause UDP fragmentation, especially when the DNS message already carries DNSSEC information 😬 if EDNS(0) isn't available, or the negotiated EDNS(0) packet size is too small to fit the data, or UDP fragments get dropped, the DNS may (eventually) fall back to TCP 🔁 TCP lets DNS responses be quite long, BUT it requires stateful operation of servers, which can get costly in deployments where servers only have fleeting connections to many clients 🥴 ultimately, there are forms of data an application might store in the DNS that exceed reasonable limits, like, in the ENUM context, base-64-encoded mp3 files of custom ringtones 🎶 bestie no
designs that rely on storing large amounts of data within DNS RRs also need to minimize the potential damage achievable in a reflection attack (see [RFC4732], Section 3) 🚨 in that attack, the attacker sends UDP-only DNS queries with a forged source address, and the victim receives the response 🎯 the attacker relies on amplification, where a small query generates a large response aimed at the victim 📈 where the responder supports EDNS(0), an attacker may set the requester maximum payload size to a larger value while querying for a large resource record, such as a certificate [RFC4398] 😈 so the combo of large data stored in DNS RRs and responders that support large payload sizes has the potential to increase the damage achievable in a reflection attack 💀
since a reflection attack can be launched from any network that doesn't implement source address validation, these attacks are hard to eliminate unless source address validation is ubiquitously deployed or "heavier" transport protocols like TCP are used 🛡️ the bandwidth that can be mustered in a reflective amplification attack directed by a botnet, reflecting off a recursive name server on a high-bandwidth network, is honestly sobering 😳 for example, if the responding resolver could be directed to generate a 10KB response in reply to a 50-octet query, then magnification of 200:1 would be attainable 🤯 that would let a botnet controlling 10000 hosts with 1 Mbps of bandwidth focus 200 Gbps of traffic on the victim, which is more than sufficient to congest any site on today's Internet 🌊
DNS reflection attacks typically use UDP queries, because it's prohibitively difficult to complete a TCP three-way handshake begun from a forged source address 🙅♀️ unless the attacker uses EDNS(0) [RFC6891] to enlarge the requester's maximum payload size, a response can only reach 576 octets before the truncate bit is set in the response 🧢 that limits the maximum magnification achievable from a DNS query that doesn't use EDNS(0) ✨ because the large disparity between query size and response size creates the amplification, techniques for mitigating that disparity should be further studied, though this is beyond the scope of this memo (for an analysis of the effects of limiting EDNS(0) responses while still accommodating DNSSEC, see [Lindsay]) 📚 for example, some implementations could limit EDNS(0) responses to a specific ratio compared to the request size, where the precise ratio can be configured on a per-deployment basis (taking into account DNSSEC response sizes) ⚖️ without some means of mitigating the potential for amplification, EDNS(0) could cause significant harm 🚫
in summary, there are two operational forces that tend to drive the practically available EDNS(0) sizes down: possible UDP fragmentation and minimizing amplification in case of reflection attacks 🪄 DNSSEC data will use a significant fraction of the available space in a DNS packet 🥱 so, appreciating that given the current DNSSEC and EDNS(0) deployment experience precise numbers are impossible to give, the generic payload available to other DNS data (given the premise that TCP fallback is to be minimized) is likely to be closer to several hundred octets than a few thousand octets 💜 that's the vibe, and I'm obsessed 🫶✨
3.3. Administrative Structures Misaligned with the DNS ✨
okay so the DDDS framework lets basically any alphanumeric data become a domain name through the "First Well Known Rule" 💅 but the delegation structure of the resulting domain name might not reflect any administrative division of responsibilities that was in the original data 🫠. [RFC3402] only asks that the "Application Unique String has some kind of regular, lexical structure that the rules can be applied to" 🎀. DDDS is first and foremost a delegation system though 👑, and its abstract literally says "Well-formed transformation rules will reflect the delegation of management of information associated with the string" 💖.
Telephone numbers in the United States are assigned and delegated in a pretty complicated way 🙈. Historically, the first six digits of a nationally specific number (called the "NPA/NXX") were a point of administrative delegation from the number assignment agency to a carrier 🍓. From those blocks of ten thousand numbers, the carrier would then delegate individual assignments of the last four digits (the "XXXX" portion) to particular customers 🌸. BUT after the rise of North American telephone number portability in the 1990s, that first point of delegation went away 💀. Now the delegation goes straight from the number authority to the carrier for each complete ten-digit number (NPA/NXX-XXXX). Technical details differ from nation to nation, but number portability systems with similar administrative delegations now exist worldwide 🌍.
So if you render these identifiers as domain names using the DDDS Rule for ENUM, you get one giant flat administrative domain 😭 with no points of administrative delegation from the country-code administrator (like 1.e164.arpa) all the way down to the ultimate assignee of a number. Assume one administrative domain is maintained inside one DNS zone holding potentially over five billion names, and scalability problems show up in a bunch of areas 📉. Caching's scalability depends on these points of delegation, because cached results at intermediate servers take the load off higher-tier servers 🧠. Without those delegations, the zone apex server has to carry the entire query load, just like in the telephone number example 😩. Worse, number portability also brings way more dynamism to number assignment. In some regions, updated assignees for ported numbers must propagate within fifteen minutes of a change in administration ⏰. Put those two problems together and caching the zone becomes extremely problematic 🥲. On top of that, the traditional DNS replication tools, like the zone transfer protocols AXFR [RFC1034] and IXFR [RFC1995], might not scale to zones with these dimensions and properties 🫣.
In practice, the biggest telephone number administrative domains are closer to 300M (that's the amount of telephone numbers currently allocated in the United States today, and it's still more than three times the number of .com domain names 🤯). You can ease some of the scalability issues above by artificially dividing the administrative domain into a hierarchy of DNS zones 🧩. Still, the fact that traditional DNS management tools no longer apply to the structures an application tries to provision in the DNS is a clue that the DNS might not be the right place for that application to store its data 🚩.
DDDS is the most obvious example, but the point is more generic 💜. For instance, if address portability were implemented for IP addresses and their administration became non-hierarchical, the same concerns would apply to in-addr.arpa names 🌐. This mapping problem can even happen with traditional domain names, where applications expect clients to infer or locate zone cuts 🔍. In the web context, for example, it can be hard for applications to tell whether two domains represent the same "site" when they're comparing security credentials with URLs (see Section 3.4 below for more on this) 🔐. This has also caused known problems figuring out the scope of web cookies. Applications have to infer where administrative domains end so they can grant cookies that are as narrowly scoped as possible 🍪.
In summary, the "First Well Known Rule" of DDDS turns arbitrary strings into domain names, but those names only play well with the DNS when the input strings have an administrative structure that maps to DNS delegations 🎯. Delegation implies some sort of hierarchical structure in the first place 🪜. Any mechanism that maps a hierarchical identifier into a domain name should be built so the resulting domain name does match the natural hierarchy of the original identifier 🫶. Telephone numbers, even in North America, have some hierarchical qualities (like the geographic areas matching their first three digits) 🗺️. But after number portability, those points stopped mapping onto an administrative delegation 💔. So if the input string to the DDDS doesn't have a hierarchical structure representing administrative delegations that can map onto the DNS distribution system, that string probably isn't a good candidate for translating into a domain name 🙅♀️.
3.3.1. Metadata about Tree Structure
there are also other ways the delegative structure of an identifier might not map well onto the DNS 🌸. Traditionally, DNS resolvers assume that when they get a domain name from an application, the name is complete, meaning it's not a fragment someone is still in the middle of typing ⌨️. For some communications systems, though, that assumption doesn't hold 🙃. ENUM use cases have surfaced a couple of optimization requirements to reduce unnecessary calls and queries 📞. Proposed solutions include metadata in the DNS that describes the contents and structure of ENUM DNS trees, helping applications handle incomplete queries or queries for domains that aren't in use 🧚.
The "send-n" proposal [ENUM-Send-N] was hoping to reduce the number of DNS queries sent in regions with variable-length numbering plans 💜. When a dialed number might have a variable length, a telephone switch usually can't predict when the dialed number is complete 😵💫. Only the numbering plan administrator knows how long a telephone number needs to be, and that could be a national regulator or, in open number plans, a private branch exchange 🏢. So a switch trying to resolve such a number through a system like ENUM might send a query for a number that has only been partially dialed, just to test whether it's complete 🤞. The send-n proposal puts a hint into the DNS to tell the telephone switch the minimum number of digits that must be collected. It does this by placing resource records in zones corresponding to incomplete telephone numbers, and those records say how many more digits are required 📝. Basically, they say how many steps down the DNS tree you have to take before querying the DNS again 🪜. Unsurprisingly, those boundaries line up with points of administrative delegation, where the parent in a number plan hands authority over to a child 👑. With this info, the application doesn't have to query the DNS every time a new digit is dialed. It can wait until it has collected enough digits to get a response ⏳. As an optimization, this saves the DNS server's resources. The call still can't complete until all the digits are collected, though, so this mechanism just cuts down the time the system waits before sending an ENUM query after collecting the final dialed digit ⏱️.
A tangentially related proposal, [ENUM-UNUSED], similarly places resource records in the DNS that tell the application it doesn't need to try reaching a number on the telephone network, because the number is unassigned 🙅♀️. A comparable general DNS mechanism would identify, for a domain name with no records in the DNS, whether that domain had been allocated by a registry to a registrant 🗂️. That's a different condition than a name just being unresolvable, per the semantics of NXDOMAIN 🧐.
Both proposals optimize application behavior by putting metadata in the DNS that predicts whether future queries or application invocations will succeed. They do this by identifying points of administrative delegation or assignment in the tree 🌳. In some ways, marking a point in the tree where a zone begins or ends has stuff in common with the traditional parent zone use of the NS record type 🫠. The difference is that instead of pointing to a child zone, these metadata proposals point to distant grandchildren 👶. This doesn't change resolver behavior as such (instead, it changes the way that applications invoke the resolver) 🔄. It does have implications for the practices zone administrators follow, though 📋. Metadata in one administrative domain would need to stay synchronized with the state of the resources it predicts in another administrative domain in the DNS namespace. Overlap dialing is a good example, where the carrier delegates to a zone controlled by an enterprise 🏬. When you're dealing with external resources tied to other namespaces, like number assignments in the PSTN or the databases of a registry operator, other synchronization requirements show up too. Keeping that sync going requires the DNS to have "semi-real time" updates, which can clash with the scale and caching mechanisms of the DNS 😬.
Putting metadata in the DNS can also raise questions about the authority and delegation model 🤔. Who gets to supply records for unassigned names? In the original but little-used e164.arpa root of ENUM, this would almost certainly be a numbering plan administrator 📚. It's way less clear who that would be in the more common and successful "infrastructure" ENUM models (see Section 4) 🏗️. Ultimately, these metadata proposals share some qualities with DNS redirection services offered by ISPs (for example, [DNS-REDIRECT]) that "help" web users who try to browse to sites that don't exist 🙋♀️. Similarly, metadata proposals like [ENUM-UNUSED] create DNS records for unallocated zones that redirect to a service provider's web page 🌐. But in the [DNS-REDIRECT] cases, at least the existence or non-existence of a domain name is a fact about the Internet namespace 🌍. It isn't a fact about an external namespace like the telephony E.164 namespace, which has to be synchronized with the DNS tree in the metadata proposals 🔗. In send-n, different leaf zones that administer telephone numbers of different lengths can only provision their hints at their own apex 📍. That gives an imperfect optimization. They can't install the hint themselves in a parent, both because they lack the authority and because different zones would want to provision contradictory data 🙅. The later the hint shows up in the tree, the less optimization you get 📉. So an application protocol designer managing identifiers whose administrative model doesn't map well onto the DNS namespace and delegation structure is better off implementing these features outside the DNS 🫶💅.
3.4. Domain Redirection ✨
okay so, most internet application services have a redirection feature 🦋 When you try to contact a service, it can point you to a different service instance, maybe in another domain, that's better suited to handle your request for whatever reason. In HTTP and SIP, this is done with 300 class responses that contain one or more URIs, which can say a resource has moved temporarily or permanently to another service. The DNS has a few tools that can do something similar at the DNS level, including the SRV record. So some applications, as an optimization, hand the redirection job off to the DNS 🧚 NAPTR can do this too, on a per-application basis, and lots of DNS resource records can do redirection on a per-domain basis 💅 This is iconic because it stops applications from wasting their own resources on something that could happen as part of a DNS lookup they already need to do before contacting the service. That's why, in some deployment architectures, this DNS-layer redirection is used for virtual hosting services 🌸
Now, the security side is where it gets a little spicy 😭 Doing domain redirection in the DNS has important consequences for application security. If DNSSEC isn't everywhere, applications have to blindly trust that their request hasn't been hijacked at the DNS layer and sent to a potentially malicious domain, unless some later application mechanism can give them the assurance they need. Compare that with application-layer protocols that support redirection, like HTTP and SIP. They have security mechanisms available, including TLS, that can use certificates to prove a 300 response came from the domain the originator was originally trying to reach 🔥
A bunch of applications have tried to add an after-the-fact security check that verifies the authority of a DNS delegation when DNSSEC isn't around. The spec for dereferencing SIP URIs ([RFC3263], reaffirmed in [RFC5922]) requires that, during TLS establishment, the site a SIP request eventually reaches presents a certificate that matches the original URI the user expected. That means a virtual hosting service has to have a certificate for the hosted domain 👑 (In other words, if example.com redirects to example.net in the DNS, this mechanism expects example.net to supply a certificate for example.com in TLS, following the HTTP precedent in [RFC2818].) The catch is that this restriction rules out a lot of hosting setups that are super common in the web world today 💀 [HARD-PROBLEM] digs into this problem space. [RFC6125] proposes a solution for all applications that use TLS. It relies on new application-specific identifiers in certificates, as does [RFC4985]); just note that supporting those certificates would need changes to existing certificate authority practices as well as application behavior 🙈 And if DNSSEC is in place, DNS-based Authentication of Named Entities (DANE) [RFC6394] offers another way to bind certificates to particular applications and services 🎀
All of these application-layer fixes are trying to mirror the delegation of administrative authority in the DNS, even though the DNS itself is the ultimate authority on how domains get delegated 🧠 (Note: changing the technical delegation structure by changing NS records in the DNS is not the same as administrative delegation, e.g., when a domain changes ownership.) Here's the tricky part: a static thing like a certificate doesn't line up well with a delegation in the DNS, because delegations aren't static. Revoking and reissuing a certificate every single time an administrative delegation changes is a lot of operational pain 😩 In environments where DNSSEC isn't available, the problems with securing DNS-layer redirections would be avoided by doing the redirections in the application layer instead. That does lead to design trade-offs involving performance, load, and related factors, but in these application environments, security properties typically take priority 🫶
4. Private DNS and Split Horizon 🌈
the classic view on whether domain names are unique in the DNS comes from [RFC2826], and it's giving very strict energy 💜
DNS names are designed to be globally unique, that is, for any one DNS name at any one time there must be a single set of DNS records uniquely describing protocol addresses, network resources and services associated with that DNS name. All of the applications deployed on the Internet which use the DNS assume this, and Internet users expect such behavior from DNS names.
[RFC2826] "does not preclude private networks from operating their own private name spaces" 🦋 but it does note that if private networks "wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy". There are all sorts of DNS deployments outside the global public DNS, like "split horizon" deployments and DNS usages on private (or virtual private) networks 🍓 In a split horizon, an authoritative server gives different responses to queries from the public Internet than it gives to internal resolvers. Some deployments tell internal queries apart from public ones by the source IP address, but the concerns in Section 3.1.1 about trusting source IP addresses still apply to those deployments 🙈 When the internal address space is private [RFC1918], it's both easier for the server to tell public from private, and harder for public entities to impersonate nodes in the private network 💅 Networks that are private physically, or logically through cryptographic tunnels, make these private deployments more secure 🔐 The most complex deployments like this use multiple virtual private networks to serve different answers for the same name to lots of distinct networks 🌸
The use cases behind split-horizon DNS usually involve restricting access to some network services, like intranet resources (internal web sites, development servers, or directories, for example), while keeping the ease of use that domain names give internal users ✨ For many of these resources, the split horizon wouldn't return answers to public resolvers at all, since those records are kept confidential from the public. In some cases, though, the same name (e.g., "mail.example.com") might resolve to one host internally and a different host externally 👀 The requirements for multiple-VPN private deployments are different, though. In that case, the authoritative server gives different, and confidential, answers to a set of resolvers querying for the same name 🤯 These sorts of use cases rarely come up for traditional domain names, since, as [RFC2826] says, users and applications expect a unique resolution for a name 🙃 But they can easily come up when other kinds of identifiers have been translated into "domain name syntax" by a mechanism like the "First Well Known Rule" of DDDS 📞 Telephone calls, for example, are traditionally routed through highly mediated networks. Finding a route for a call often means finding an appropriate intermediary based on the source network and location, rather than finding an endpoint (see the distinction between the Look-Up Function and Location Routing Function in [RFC5486]) 🗺️ Plus, the need for responses tailored to the originator, and for confidentiality, is easy to justify when the data the DNS returns is no longer "describing protocol addresses, network resources and services" [RFC2826], and is instead arbitrary data 🎀 Take ENUM: it was originally meant for deployment in the global public root of the DNS (under e164.arpa), but the need to keep telephone identifiers in the DNS quickly pushed operators into private deployments 📱
In private environments, deploying any necessary extensions is also easier than in the public DNS 🧚 For one, proprietary non-standard extensions and parameters can be integrated into DNS queries or responses more easily, since the resolver and server implementations can likely be controlled. Second, confidentiality and custom responses can be provided by deploying underlying physical or virtual private networks to shield the private tree from public queries, and by having effectively different virtual DNS trees for each administrative entity that might launch a query. Third, in these constrained environments, caching and recursive resolvers can be managed or eliminated to prevent any unexpected intermediary behavior 🫧 These private deployments play an important role in the marketplace, but there are risks in using techniques meant only for private and constrained environments as the basis of a standard solution 😬 When proprietary parameters or extensions get deployed in private environments, experience teaches us that those implementations will start interacting with the public DNS, and the private practices will leak 🚨
Leakage isn't a problem when using the mechanisms described in Sections 3.1, 3.2, and 3.5 (with private RR types) of [RFC5507]. Other extension mechanisms, though, might cause confusion or harm if they leak. The use of a dedicated suffix (Section 3.3 of [RFC5507]) in a private environment might cause confusion if it leaked to the public Internet, for example.
And this leakage isn't just hypothetical. It has actually happened with SIP 😭 SIP had a category of supposedly private extensions (the "P-" headers) that saw widespread success and use outside the constrained environments they were specifically designed for 💅 There's no reason to think that implementations with similar "private" extensions to the DNS protocols would end up any differently, and would not similarly wind up in use in public environments 🌍✨
5. Principles and Guidance ✨
okay so the whole reason the global public DNS works is that it's a distributed database that's loosely coherent and does lookup, not search 🌸 loose coherency just means answers line up within the limits of how data gets replicated between authoritative servers (the zone admin controls that part) and how recursive name servers cache stuff 💅 and lowkey this now also has to include load-balancing or similar stuff that depends on the source IP address of the resolver 👀 so app designers who want to use the DNS need to think hard about what their setup does to resolvers, intermediaries (caches and recursive resolvers included), and authoritative servers. no skipping this bestie 🫶
the DNS is probably a great match when your app's needs line up with these properties:
- Data stored in the DNS can be propagated and cached with normal DNS mechanisms, without intermediaries needing to understand any exceptional logic (anything beyond the name, type, and class of the query) that the authoritative server uses to build its responses 🧚
- Data stored in the DNS is indexed by keys that don't break the syntax or semantics of domain names 🎀
- Applications use the DNS to resolve complete names, not fragments 🍓
- Answers don't depend on an application-layer identity of whoever is doing the query 🔥
- In the end, applications use the DNS to help them talk to a service whose name gets resolved through the DNS 🦋
if any of those five properties doesn't apply to your data, seriously consider whether the DNS is the best place to actually store it 🙈 and on the flip side, if you're worrying about any of the following, those are big signs the DNS is NOT the right tool for the job 💀
- Populating metadata about domain boundaries within the tree. The points of administrative delegation in the DNS are something applications generally aren't aware of 😭
- Domain names derived from identifiers that don't share a semantic or administrative model that's compatible with the DNS 🌈
- Selective disclosure of data stored in and provided by the DNS 🔒
- DNS responses that don't fit into UDP packets, unless EDNS(0) is available. Even then, only with the caveats discussed in Section 3.2.1 ✨
when apps need these kinds of features, they're usually better served by independent application-layer protocols than by the DNS 💜 for example, the objects HTTP can carry in both queries and responses can easily hold the structure you need to manage compound queries 🌸 and lots of apps already use HTTP because middleboxes support it so widely 🫶 HTTP also has tons of ways to handle the authentication, authorization, and confidentiality stuff some features need, plus the redirection properties from Section 3.4 🔥 so the DNS and HTTP basically offer really different services and have different applicability. both are query-response protocols, but HTTP should not be doing the job of DNS, and DNS should not be doing the job of HTTP 💅 same deal with Diameter, LDAP, and other application-layer protocols, DNS should not be doing their job either 🙈 the overhead of any application-layer protocol might not fit every environment, obviously, but even where a lighter protocol is the right call, DNS usually isn't the only option 🦋
now, when the DNS's administrative delegations are a necessary part of building an application feature, there are different ways the DNS can bootstrap access to an independent application-layer protocol that's better at handling those queries 🧚 for example, NAPTR or URI [URI-RR] Resource Records can contain URIs, and those URIs can point to an external query-response service, like an HTTP service, where way more syntactically and semantically rich queries and answers can get exchanged ✨ any protocol designer thinking about where to put features has to do their own gap analysis and figure out whether some features are worth the potential cost in extra network state, latency, and so on 💖 some features just need heavier structures than others, and that's the tea 🍵
6. Security Considerations 💀
okay this part is SERIOUS bestie 😭 a lot of the concerns about how apps use the DNS in this document are security issues 🔒 the perceived need to authenticate the source of DNS queries (see Section 3.1.1) and to authorize access to particular resource records shows the fundamental security principles that come up whenever you offload certain application features onto the DNS 🙈 as Section 3.2.1 points out, large data in the DNS can be a way to generate reflection attacks 🚨 and without the remedies from that section (the ones about using EDNS(0) and TCP), having large sets of records (e.g., ANY queries) is not recommended 💀 Section 3.4 also talks about a redirection security problem that has shown up in a bunch of protocols (see [HARD-PROBLEM]) 🌈
DNSSEC can play a really important part in securing application redirection in the DNS, if it's deployed universally 🔐 but DNSSEC does NOT give a resolver a way to authenticate itself to a server 😭 it also doesn't provide a framework for servers to return selective answers based on the authenticated identity of resolvers, and it's not a confidential mechanism either 🙅♀️ some implementations might support authenticating users through TSIG, but only if the security association with a compliant server has been set up beforehand, and authentication usually isn't needed for queries in the global public DNS 🧚 still, DNSSEC's existing feature set is enough to secure most of the ways apps have traditionally used the DNS 💅 the deployment of DNSSEC ([RFC4033] and related specifications) is heartily encouraged 🫶 nothing in this document is meant to discourage implementing, deploying, or using Secure DNS Dynamic Updates [RFC3007] 🦋 though this document does recommend that large data in the DNS get treated according to the guidance in Section 3.2.1 🔥
7. IAB Members at the Time of Approval 👑
these are the Internet Architecture Board members at the time this doc was approved 🌸
- Bernard Aboba
- Jari Arkko
- Marc Blanchet
- Ross Callon
- Alissa Cooper
- Spencer Dawkins
- Joel Halpern
- Russ Housley
- David Kessens
- Danny McPherson
- Jon Peterson
- Dave Thaler
- Hannes Tschofenig
8. Acknowledgements 🫶
the IAB is so grateful for the comments and often spirited disagreements from Eric Osterweil, John Levine, Stephane Bortzmeyer, Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, Patrik Faltstrom, and Eliot Lear 💖 they really did the most 😭✨
9. Informative References ✨
okay bestie, this is the receipts section 🧾💅 every doc this one leans on is listed right here, so you can go check the sources yourself. some are finished RFCs, some are still "Work in Progress" drafts 🌸
[DNS-REDIRECT]
Creighton, T., Griffiths, C., Livingood, J., and R. Weber,
"DNS Redirect Use by Service Providers", Work in Progress,
October 2010.
[EDNS-CLIENT-IP]
Contavalli, C., van der Gaast, W., Leach, S., and D.
Rodden, "Client IP information in DNS requests", Work in
Progress, May 2010.
[EDNS-OPT-CODE]
Kaplan, H., Walter, R., Gorman, P., and M. Maharishi,
"EDNS Option Code for SIP and PSTN Source Reference Info",
Work in Progress, October 2011.
[ENUM-Send-N]
Bellis, R., "IANA Registrations for the 'Send-N'
Enumservice", Work in Progress, June 2008.
[ENUM-UNUSED]
Stastny, R., Conroy, L., and J. Reid, "IANA Registration
for Enumservice UNUSED", Work in Progress, March 2008.
[HARD-PROBLEM]
Barnes, R. and P. Saint-Andre, "High Assurance
Re-Direction (HARD) Problem Statement", Work in Progress,
July 2010.
[Lindsay] Lindsay, G., "DNSSEC and DNS Amplification Attacks",
April 2012.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, November 1983.
[RFC0883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, November 1983.
[RFC0974] Partridge, C., "Mail routing and the domain system",
STD 10, RFC 974, January 1986.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the
TPC.INT Subdomain: General Principles and Policy",
RFC 1530, October 1993.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform
Resource Identifiers using the Domain Name System",
RFC 2168, June 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4367] Rosenberg, J., Ed., and IAB, "What's in a Name: False
Assumptions about DNS Names", RFC 4367, February 2006.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
December 2006.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007.
[RFC5486] Malas, D., Ed., and D. Meyer, Ed., "Session Peering for
Multimedia Interconnect (SPEERMINT) Terminology",
RFC 5486, March 2009.
[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,
Ed., "Design Choices When Expanding the DNS", RFC 5507,
April 2009.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
February 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
September 2011.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
Authentication of Named Entities (DANE)", RFC 6394,
October 2011.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[URI-RR] Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record", Work in Progress,
July 2013.Authors' Addresses 🫶
the crew who wrote this one, with their contact details 💌
Jon Peterson
NeuStar, Inc.
EMail: jon.peterson@neustar.biz
Olaf Kolkman
NLnet Labs
EMail: olaf@nlnetlabs.nl
Hannes Tschofenig
Nokia Siemens Networks
EMail: Hannes.Tschofenig@gmx.net
Bernard Aboba
Skype
EMail: Bernard_aboba@hotmail.com📦 where this page comes from
- ietf: rfc6950 2013-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms