RFC 5507

Design Choices When Expanding the DNS 🎀

okay bestie, this one is an IAB doc, filed as RFC 5507 💅. It's Informational, which means it shares information and doesn't set an Internet standard ✨. It came out in April 2009, edited by P. Faltstrom, R. Austein, and P. Koch 🫶. The header doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🌸.

---

Status of This Memo 🦋

this memo gives info to the Internet community 💖. it does not specify an Internet standard of any kind, and distribution is unlimited ✨.

Copyright Notice 🌈

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

this doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the date it was published. You can find those at http://trustee.ietf.org/license-info. please actually read them, because they explain your rights and restrictions for this document 📜🙈.

Abstract 🧚

okay so this note is about how to extend the DNS with new data for a brand new application 🍓. DNS extension talks way too often get stuck on reusing the TXT Resource Record Type 😭. This doc lists different ways to extend the DNS, and its conclusion is that a new DNS Resource Record Type is the best move 👑.

Table of Contents 📚

   1. Introduction ....................................................3
   2. Background ......................................................4
   3. Extension Mechanisms ............................................5
      3.1. Place Selectors inside the RDATA of Existing
           Resource Record Types ......................................5
      3.2. Add a Prefix to the Owner Name .............................6
      3.3. Add a Suffix to the Owner Name .............................7
      3.4. Add a New Class ............................................8
      3.5. Add a New Resource Record Type .............................8
   4. Zone Boundaries are Invisible to Applications ...................9
   5. Why Adding a New Resource Record Type Is the Preferred
      Solution .......................................................10
   6. Conclusion and Recommendation ..................................14
   7. Creating a New Resource Record Type ............................14
   8. Security Considerations ........................................15
   9. Acknowledgements ...............................................15
   10. IAB Members at the Time of This Writing .......................16
   11. References ....................................................16
      11.1. Normative References .....................................16
      11.2. Informative References ...................................16

1. Introduction ✨

the DNS holds lots of different categories of data 🌸. The two biggest ones are infrastructure data for the DNS itself (NS and SOA Resource Records) and data about mapping domain names to IP addresses (A, AAAA, and PTR Resource Records) 💅. There are others too! Some are tied to specific apps like email (MX Resource Records), and some are generic types that carry info for multiple protocols (SRV and NAPTR Resource Records) 🦋.

when you're storing data in the DNS for a new app, the goal is to store it so the app can ask for exactly the data it wants 🎯. You also want to keep the impact on existing apps low, plus keep the extra data sent to the client small 🫶. That means a bunch of design choices have to get made, and the biggest one is making sure a precise selection of what to return is already decided in the query 💖. a query is a triple: {Owner (or name), Resource Record Class, Resource Record Type} ✨.

extending the DNS to store app data tied to a domain name has been done in different ways at different times, honestly it's a little chaotic 😭. MX Resource Records were made as a new Resource Record Type built specifically for electronic mail 💌. SRV records are a generic type that uses a prefixing scheme together with a base domain name 🧚. NAPTR records add selection data inside the RDATA 🔥. The methods used to add new data types have been inconsistent, so this doc tries to clear up what each method implies, both for the apps that use it and for the rest of the DNS 🌈.

this doc talks a lot about DNS wildcards 🙈. Lots of people think wildcards aren't really a thing anymore, but they're totally in use, especially for app-specific data like MX Resource Records 💀. So the choice has to be made with wildcards in mind, periodt 💅.

another big thing to think about is what the new data is actually describing 🔍. Sometimes it's completely new data, and sometimes it's metadata tied to data already in the DNS 🎀. Examples of new data are key info for the Secure SHell (SSH) Protocol, and data used to authenticate the sender of email messages (metadata tied to MX Resource Records) 💜. If the new data is tied to data already in the DNS, you should analyze whether having (for example) address records and SSH key info in different DNS zones is a problem or a bonus ✨. If it's a problem, you should check whether the spec must require all the related data to be in the same zone 🤔. One specific difference between same-zone and different-zone is maintenance: if they're in the same zone, the same maintainer (from a DNS perspective) manages both records 🫶. And they must be signed with the same DNSSEC keys if DNSSEC is in use 🔐.

this doc does not talk about what you should store in the DNS 🙅‍♀️. It also doesn't discuss whether the DNS should be used for service discovery, or for storing data specific to the service 🌸. Generally, the DNS is a protocol that holds metadata to make the DNS itself work (NS, SOA, DNSSEC Resource Record Types, etc.), and it only holds references to service locations (SRV, NAPTR, A, AAAA Resource Record Types) 💅. There are exceptions though, like MX Resource Records 🦋.

2. Background 📖

see RFC 5395 [RFC5395] for a quick summary of the DNS query structure 💖. If you want the full story, start with the base DNS spec in RFC 1035 [RFC1035] and then keep going through the docs that update, clarify, and extend it 🧚.

when you compose a DNS query, the protocol parameters are a {owner, class, type} triple ✨. Every Resource Record matching that triple belongs to the same Resource Record Set (RRSet), and the whole RRSet is always returned to whoever asked for it 🎀. Splitting an RRSet is a protocol violation (sending a partial RRSet instead of truncating the DNS response), because it can cause coherency problems with DNS caching 😭. See Section 5 of [RFC2181] for more info 📚.

some discussions about extending the DNS bring up MTU size 📏. Just note that most MTU conversations are about the size of the whole DNS packet, not the size of a single RRSet 💅.

almost all DNS query traffic goes over UDP, where a DNS message has to fit in a single UDP packet 🦋. DNS responses are almost always bigger than queries, so size issues are almost always about responses, not queries 🌈. The base DNS spec limits DNS messages over UDP to 512 octets 🔢. EDNS0 [RFC2671] specifies a way for a client to signal that it's willing to receive bigger responses, but EDNS0 isn't universally deployed, partly because of firewalls that block fragmented UDP packets or EDNS0 🧱. If a response won't fit in a single packet, the name server returns a truncated response, and then the client may retry using TCP 🔁. DNS queries over TCP aren't subject to this length limit, but TCP adds a lot more per-query overhead on name servers than UDP does 🫠. Also, the policies in deployed firewalls are way too often set to block DNS over TCP, so TCP might not be an option in reality 🙅‍♀️. There are also risks (although possibly small) that a routing change while a TCP flow is open creates problems when DNS servers are deployed in an anycast environment 🌊.

3. Extension Mechanisms 🛠️

the DNS protocol is meant to be extensible so it can support new kinds of data 💖. This section looks at the different ways that extension can happen 🧚.

3.1. Place Selectors inside the RDATA of Existing Resource Record Types 🎀

for a given query name, you might choose to have a single RRSet (all Resource Records sharing the same {owner, class, type} triple) shared by multiple apps, with each app using selectors inside the Resource Record data (RDATA) to figure out which records are meant for it 🫶. This kind of selector mechanism is usually referred to as "subtyping", because it effectively creates an extra type subsystem inside a single DNS Resource Record Type 🌸.

examples of subtyping include NAPTR Resource Records [RFC3761] and the original DNSSEC KEY Resource Record Type [RFC2535] (which was later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]) 🔐.

all DNS subtyping schemes share one big weakness 😭: with subtyping, a client can't query for just the data it wants. Instead, it has to fetch the entire RRSet and then pick out the Resource Records it's interested in 💔. Since DNSSEC signatures operate on complete RRSets, the entire RRSet has to be re-signed if any Resource Record in it changes 🔏. So each app using a subtyped Resource Record ends up with more overhead than it would have had without subtyping 📈. The RRSet is always passed around as one indivisible unit, which raises the risk that it won't fit in a UDP packet 🧩. That then raises the risk the client has to retry the query over TCP, which really increases the load on the name server 🚨. More precisely: one query failing over to TCP is no big deal, but the typical ratio of clients to servers in today's DNS is very high, so a lot of DNS messages failing over to TCP can overload the name servers with TCP overhead 🥲.

because of the size limits, using subtyping to list a large number of services for a single domain name risks truncation and fallback to TCP 🫣. That could in turn force the zone administrator to announce only a subset of the available services 🙈.

3.2. Add a Prefix to the Owner Name ✨

okay so, adding an application-specific prefix to a domain name gives you a different {owner, class, type} triple, which means a different RRSet 💖 the problem is that prefixes get messy with wildcards, especially if you have records like:

*.example.com. IN MX 1 mail.example.com.

and you want records tied to those names too. say you make the prefix _mail. you'd end up writing something like:

_mail.*.example.com. IN X-FOO A B C D

but DNS wildcards only work when the * is the leftmost token in the domain name (see also RFC 4592 [RFC4592]). not great 😭

there have been proposals to fix the fact that DNS wildcards are always terminal records 🔧 but they come with their own trade-offs you'd have to weigh when picking an extension mechanism. think extra response time for the extra queries, the cost of pre-calculating possible answers, or the costs to the system as a whole 💅 and as of writing, none of these proposals has been published as Standards Track RFCs.

even with a specific prefix, the data still has to live in some Resource Record Type 🎀 that can be a brand-new type or an existing one with a format that fits. you might also need some other selection mechanism, like a way to tell apart records in an RRSet when they share the same Resource Record Type. so you need to do two things: register a unique prefix and define which Resource Record Type gets used for that specific service 🧚

also, if records have a relationship with each other in the zone, the fact that they can sit in different zones might change how much the application trusts them 👀 for example:

example.com.      IN MX    10 mail.example.com.
_foo.example.com. IN X-BAR "metadata for the mail service"

in this example, the two records might live in two different zones, get administered by two different organizations, and get signed by two different entities when using DNSSEC. for those two reasons, prefixes have recently become a super popular solution for lots of protocol designers 🌈 in some cases, e.g., DomainKeys Identified Mail Signatures [RFC4871], TXT records have been used. in others, like SRV, entirely new Resource Record Types have been added 🦋

---

3.3. Add a Suffix to the Owner Name 🍓

adding a suffix to a domain name changes the {owner, class, type} triple, and so the RRSet too. the upside is that since the query name can be set to exactly the data you want, the size of the RRSet gets minimized ✨ the catch is that it creates a parallel tree within the IN class 😬 and there's no technical mechanism to make sure the delegation for "example.com" and "example.com._bar" goes to the same organization. on top of that, data about a single entity ends up stored in two different zones, like "example.com" and "example.com._bar", and depending on who controls "_bar", that can cause new synchronization and update authorization issues 💀

one way to solve the administrative issues is to use the DNAME Resource Record Type specified in RFC 2672 [RFC2672] 🫶

even with a different name, the data still has to be stored in some Resource Record Type with an appropriate format 💜 so you might have to mix the prefix-based selection mechanism with some other mechanism, so the right Resource Record can be found among many in a potentially larger RRSet.

in RFC 2163 [RFC2163], an infix token is inserted directly below the Top-Level Domain (TLD). but the result is equivalent to adding a suffix to the owner name, since instead of creating a TLD, you're creating a second level domain 🌸

---

3.4. Add a New Class 🦋

DNS zones are class-specific 🎀 all the records in a zone share the same class as the zone's SOA record, and a zone existing in one class doesn't guarantee it exists in any other class. in practice, only the IN class has ever seen widespread deployment, and the admin overhead of deploying an extra class would almost certainly be prohibitive 😩

sure, in theory you could use the DNS class mechanism to tell different kinds of data apart 🤔 but the DNS delegation tree (represented by NS Resource Records) is itself tied to a specific class. so trying to resolve a query by crossing a class boundary might give you unexpected results, because there's no guarantee the name servers for the zone in the new class are the same as the ones in the IN class 🙈 the MIT Hesiod system [Dyer87] used a scheme like this for storing data in the HS class, but only on a very small scale (within a single institution), and with an administrative fiat requiring the delegation trees for the IN and HS trees to be identical. over time, using the HS class for storing non-sensitive data got replaced by the Lightweight Directory Access Protocol (LDAP) [RFC4511] 🌈

even with a different class, the data still has to be stored in some Resource Record Type that has an appropriate format ✨

---

3.5. Add a New Resource Record Type 👑

when you add a new Resource Record Type to the system, entities in four different roles have to be able to handle it 🧚

1. there has to be a way to insert the new Resource Records into the zone at the Primary Master name server 📝 some server implementations only accept Resource Record Types the user interface understands (maybe so they can validate the data). others let the zone admin enter an integer for the Resource Record Type code and the RDATA in Base64 or hexadecimal encoding (or even as raw data). RFC 3597 [RFC3597] specifies a standard generic encoding for this purpose.
2. a slave authoritative name server has to be able to do a zone transfer, receive the data from some other authoritative name server, and serve data from the zone even when the zone includes records of unknown Resource Record Types 🫠 historically, some implementations had problems parsing stored copies of the zone file after restarting, but those problems haven't been seen for a few years. some implementations use an alternate mechanism (e.g., LDAP) to transfer Resource Records in a zone, and those are mainly used within corporate environments. in that case, name servers have to be able to transfer new Resource Record Types using whatever mechanism is in use. however, today this alternative mechanism may not support unknown Resource Record Types. so basically, in Internet environments unknown Resource Record Types are supported, but in corporate environments they're a problem 😤
3. a caching resolver (most commonly a recursive name server) will cache the records that are responses to queries. as mentioned in RFC 3597 [RFC3597], there are various pitfalls where a recursive name server might end up having problems 💀
4. the application has to be able to get the RRSet with a new Resource Record Type 🔍 the application itself may understand the RDATA, but the resolver library might not. support for a generic interface for retrieving arbitrary DNS Resource Record Types has been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]). some stub resolver library implementations skip this functionality and can't handle unknown Resource Record Types. but implementing a new stub resolver library isn't particularly difficult, and open source libraries that already provide this functionality are available 🫶

historically, adding a new Resource Record Type has been very problematic 😭 the review process was cumbersome, DNS servers weren't able to handle new Resource Record Types, and firewalls dropped queries or responses with Resource Record Types they didn't know about. this is, for example, one of the reasons the ENUM standard reuses the NAPTR Resource Record, a decision that today might have gone toward creating a new Resource Record Type instead 🙃

today, there's a requirement that DNS software handle unknown Resource Record Types 🎉 and investigations have shown that deployed software generally does support it, except in some alternate transfer mechanisms like LDAP, as noted above. also, the approval process for new Resource Record Types has been updated [RFC5395], so the effort needed for various Resource Record Types is more predictable 💖

---

4. Zone Boundaries are Invisible to Applications 🙈

regardless of the choices above, we've seen a bunch of cases where the application made assumptions about the structure of the namespace and where specific information lives. so we're taking a little sidestep to argue against those approaches 💅

the DNS namespace is a hierarchy, technically speaking 🌳 but that only refers to the way names are built from multiple labels. the DNS hierarchy neither follows nor implies an administrative hierarchy 🤯 so you can't assume that data attached to a node in the DNS tree is valid for the whole subtree. technically, zone boundaries partition the namespace, and administrative boundaries (or policy boundaries) may even exist elsewhere 🧩

this false assumption has led to an approach called "tree climbing" 🧗 where a query that doesn't get a positive response (either the requested RRSet was missing or the name didn't exist) gets retried by repeatedly stripping off the leftmost label (climbing towards the root) until the root domain is reached. sometimes these proposals try to skip the query for the root or the TLD level, but this approach still has serious drawbacks 🚩

• technically, the DNS was built as a query-response tool without any search capability [RFC3467]. adding a search mechanism piles extra burden onto the technical infrastructure, and in the worst case that burden lands on TLD and root name servers 😵
• for reasons similar to those outlined in RFC 1535 [RFC1535], querying for information in a domain outside the control of the intended entity may lead to incorrect results and may also put security at risk 🚨 finding the exact policy boundary is impossible without an explicit marker, and no such marker exists at present. at best, software can detect zone boundaries (e.g., by looking for SOA Resource Records), but some TLD registries register names starting at the second level (e.g., CO.UK), and there are various other "registry" types at second, third, or other level domains that can't be identified as such without policy knowledge external to the DNS 🫣

to restate it: the zone boundary is purely a boundary that exists in the DNS for administrative purposes, so applications should be careful not to draw unwarranted conclusions from zone boundaries 🎀 another way of putting it is that the DNS doesn't support inheritance. for example, an MX RRSet for a TLD won't be valid for any subdomain of that particular TLD 💜

5. Why Adding a New Resource Record Type Is the Preferred Solution 🦋

okay so by now the astute reader is probably like "wait, what do I even do with all this?" 🤔 so let's follow the brain of a typical application designer who wants to store data in the DNS. we'll see how they almost inevitably land on just using a TXT Resource Record, why that's a bad vibe, and why a brand new Resource Record Type should get allocated instead. we'll also cover how reusing an existing Resource Record (TXT included) can be made less harmful 💅

the overall problem with most solutions comes down to two main issues:

• No semantics to prevent collision with other use 💥
• Space considerations in the DNS message 📦

a typical app designer isn't into the DNS for its own sake 🙄 they see it as a distributed database where application data can live. so the designer is usually hunting for the easiest way to add whatever new data the app needs to the DNS, in a way that naturally links the data to a DNS name, and without needing major changes to DNS servers 🫶

as explained in Section 3.4, using the DNS class system as an extension mechanism is not really an option 🚫 and honestly most people using the system don't even realize that mechanism exists 😭 so in practice, any extension is likely to live within the IN class.

adding a new Resource Record Type is the technically correct answer from the DNS protocol standpoint (more on this below) 🧠 but it does require some DNS expertise, because of the issues listed in Section 3.5. so this option gets rejected a lot 😩 note that according to RFC 5395 [RFC5395], some Types require IETF Consensus, while others only require a specification 📜

there's a drawback to defining new RR types that's worth mentioning ⚠️ the Resource Record Type (RRTYPE) is a 16-bit value, so it's a limited resource 🍓 to prevent hoarding, the registry has a review-based allocation policy [RFC5395]. however, this may not be enough if extending the DNS with new RR types starts eating up a lot of space and the registry nears completion. in that case, the trade-offs around choosing an extension mechanism may need to change 🔄

so the application designer is left with reusing some existing DNS Types within the IN class 🤷‍♀️ but when they look at the existing Types, almost all of them have well-defined semantics, and none of those quite match what the new app needs. this hasn't stopped proposals from reusing existing Resource Record Types in ways that clash with their defined semantics, but it does tend to steer designers away from that approach 🙅‍♀️

for example, Resource Record Type 40 was registered for the SINK Resource Record Type. this one was discussed in the DNSIND working group of the IETF, and at the 46th IETF it was decided not to move the I-D forward to become an RFC 🚫 the worry was that it would encourage application designers to use SINK instead of registering a new Resource Record Type, which would result in infeasibly large SINK RRsets 💀

so after all that elimination, the TXT Resource Record Type in the IN class is what's left 🎀 TXT RDATA is free-form text, and there are no existing semantics in the way ✨ some attempts have been made, for example in [DNSEXT-DNS-SD], to specify a structured format for TXT Resource Record Types, but none of them have reached RFC status 😔 also, the TXT Resource Record can obviously just be used as a bucket for carrying data around, to be used by some higher-level parser, maybe in some human-readable programming or markup language 📦 so for many applications, TXT Resource Records are the "obvious" choice 👀 unfortunately, that conclusion, while understandable, is also problematic, for several reasons 😬

the first reason TXT Resource Records aren't well suited to this is the exact same thing that makes them so attractive: there's no pre-defined common syntax or structure 🤪 so every application that uses them makes up its own syntax and structure. that makes it hard to reliably tell one application's record apart from others, and hard for a parser to avoid problems when it hits other TXT records 🥴

arguably, the TXT Resource Record is misnamed and should have been called the Local Container record, because a TXT Resource Record only means what the data producer says it means 🗣️ that's totally fine as long as TXT Resource Records are used by humans or by private agreement between producer and consumer 💖 but it becomes a real problem once you use them for standardized protocols where producer and consumer have no prior relationship 🚨 if TXT records are used without one of the naming modifications discussed earlier (and in some cases even with them), there's nothing stopping collisions with some other incompatible use of TXT Resource Records 💔

this is even worse than the general subtyping problem described in Section 3.1, because TXT Resource Records don't even have a standardized selector field to store the subtype in 😱 RFC 1464 [RFC1464] tried, but it wasn't a success 🥲 at best, a subtype definition ends up just hoping that whatever scheme you came up with won't accidentally conflict with somebody else's subtyping scheme, and that nobody can mis-parse one application's TXT Resource Records as data meant for a different application 🙏 any attempt to impose a standardized format inside the TXT Resource Record format would be at least fifteen years too late, even if it were put into effect immediately 🕰️ at best, you can restrict the syntax a particular application uses within a TXT Resource Record and accept the risk that unrelated TXT Resource Record uses will collide with it 🫠

using one of the naming modifications discussed in Section 3.2 and Section 3.3 would address the subtyping problem (and it has been combined with reuse of TXT records, like the dns/txt lookup mechanism in Domain Keys Identified Mail (DKIM)) 🔑 but each of those approaches brings its own new problems 😤 the prefix approach (which SRV Resource Records use, for example) doesn't work well with wildcards 🃏 that's a particular problem for mail-related applications, since MX Resource Records are probably the most common use of DNS wildcards 📬 the suffix approach doesn't have wildcard issues, but, as noted previously, it does have synchronization and update authorization issues, since it works by creating a second subtree in a different part of the global DNS namespace 🌍

the next reason TXT Resource Records aren't well suited to protocol use has to do with the limited data space in a DNS message 📏 as mentioned briefly in Section 3.1, typical DNS query traffic involves a very large number of DNS clients sending queries to a relatively small number of DNS servers 🌐 normal path MTU discovery schemes don't do much good here, because from the server's point of view there isn't enough repeat traffic from any one client to make it worth keeping state 🙈 UDP-based DNS is an idempotent query, whereas TCP-based DNS requires the server to keep state (as TCP connection state, usually in the server's kernel) and roughly triples the traffic load 😵 so there's a strong incentive to keep DNS messages short enough to fit in a UDP datagram, ideally one short enough not to need IP fragmentation ✂️

subtyping schemes are therefore problematic again, because they produce larger Resource RRSets than necessary 📈 but verbose text encodings of data are also wasteful, since the data they hold can usually be represented much more compactly in a Resource Record designed specifically for the application's data needs 🪶 if the data is so large that there's no way to make it fit comfortably in the DNS regardless of encoding, it's probably better to move the data somewhere else and just use the DNS as a pointer to it, like with NAPTR 🧭

6. Conclusion and Recommendation 👑

given the problems detailed in Section 5, it's worth reexamining the oft-jumped-to conclusion that specifying a new Resource Record Type is hard 🤔 historically, that was indeed the case, but recent surveys suggest that support for unknown Resource Record Types [RFC3597] is now widespread on the public Internet 🌈 because of that, the DNS infrastructure can handle new Resource Record Types ✨ the lack of support for unknown Types is still an issue for relatively old provisioning software and in corporate environments 🏢

of all the issues detailed in Section 3.5, provisioning the data is in some ways the hardest 😩 investigations with zone transfers show the problem is less difficult for the authoritative name servers themselves than for the front-end systems used to enter (and maybe validate) the data 💻 hand editing doesn't work well for maintaining large zones, so some sort of tool is necessary, and that tool may not be tightly coupled to the name server implementation itself 🛠️ but note that this provisioning problem exists to some degree with any new form of data stored in the DNS, regardless of data format, Resource Record type (even if TXT Resource Record Types are in use), or naming scheme 🫶 adapting front-end systems to support a new Resource Record Type may be a bit harder than reusing an existing type, but that looks like a minor difference in degree rather than a difference in kind 💅

given the various issues described in this note, we believe that:

• there is no magic solution that allows a completely painless addition of new data to the DNS, but 🥲
• on the whole, the best solution is still to use the DNS Resource Record Type mechanism designed for precisely this purpose, whenever possible, and 💖
• of all the alternate solutions, the "obvious" approach of using TXT Resource Records for arbitrary names is almost certainly the worst, especially for the two reasons outlined above (lack of semantics and its implementations, and size leading to the need to use TCP) 🚫💀

7. Creating a New Resource Record Type 🎀

the process for creating a new Resource Record Type is specified in RFC 5395 [RFC5395] 📜🦋

8. Security Considerations 🔐

Okay bestie, security time, and this part is SERIOUS. DNS RRSets can be signed using DNSSEC 🔏. DNSSEC is almost certainly necessary for any application mechanism that stores authorization data in the DNS 😭. DNSSEC signatures make the messages way bigger, so the DNS message size issues from Sections 3.1 and 5 are more serious than they first look 💀.

Adding new Resource Record Types (as discussed in Section 3.5) can cause two different kinds of problems: one in the DNS software and one in applications ✨. In the DNS software, it could maybe trigger bugs and other bad behavior in software that isn't compliant with RFC 3597 [RFC3597]. But honestly, most of that DNS software is old and insecure enough that it should get updated for other reasons anyway 🧹. In applications and provisioning software, the changes for the new features that need the new data in the DNS can be updated to understand the structure of the new data format. This is true whether a new Resource Record Type is used or some other mechanism is chosen 🎀. Basic API support for retrieving arbitrary Resource Record Types has been a requirement since 1989 [RFC1123], so no excuses 👑.

Any new protocol that uses the DNS to store data for making authorization decisions should totally use DNSSEC. It should also encourage upgrades to DNS server software that's recent enough not to be riddled with well-known exploitable bugs. Not optional, babe 💅🚨

9. Acknowledgements 🫶

This document was created over a number of years, with input from many people 🌸. The question of how to expand and use the DNS is sensitive, and a document like this can not please everyone 🙈. So the goal instead is to describe the architecture and tradeoffs, and make some recommendations about best practices 📚.

People who helped include: Dean Anderson, Mark Andrews, John Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies, Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg, Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing 💜✨

10. IAB Members at the Time of This Writing 🌈

The IAB members at the time of writing were:

• Loa Andersson
• Gonzalo Camarillo
• Stuart Cheshire
• Russ Housley
• Olaf Kolkman
• Gregory Lebovitz
• Barry Leiba
• Kurtis Lindqvist
• Andrew Malis
• Danny McPherson
• David Oran
• Dave Thaler
• Lixia Zhang

---

11. References 📖

11.1. Normative References

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

[RFC2535]        Eastlake, D., "Domain Name System Security
                 Extensions", RFC 2535, March 1999.

[RFC2671]        Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
                 RFC 2671, August 1999.

[RFC3597]        Gustafsson, A., "Handling of Unknown DNS Resource
                 Record (RR) Types", RFC 3597, September 2003.

[RFC5395]        Eastlake, D., "Domain Name System (DNS) IANA
                 Considerations", BCP 42, RFC 5395, November 2008.

11.2. Informative References

[DNSEXT-DNS-SD]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                 Discovery", Work in Progress, September 2008.

[Dyer87]         Dyer, S. and F. Hsu, "Hesiod, Project Athena
                 Technical Plan - Name Service", Version 1.9,
                 April 1987.

[RFC1123]        Braden, R., "Requirements for Internet Hosts -
                 Application and Support", STD 3, RFC 1123,
                 October 1989.

[RFC1535]        Gavron, E., "A Security Problem and Proposed
                 Correction With Widely Deployed DNS Software",
                 RFC 1535, October 1993.

[RFC2163]        Allocchio, C., "Using the Internet DNS to Distribute
                 MIXER Conformant Global Address Mapping (MCGAM)",
                 RFC 2163, January 1998.

[RFC2181]        Elz, R. and R. Bush, "Clarifications to the DNS
                 Specification", RFC 2181, July 1997.

[RFC2672]        Crawford, M., "Non-Terminal DNS Name Redirection",
                 RFC 2672, August 1999.

[RFC3445]        Massey, D. and S. Rose, "Limiting the Scope of the
                 KEY Resource Record (RR)", RFC 3445, December 2002.

[RFC3467]        Klensin, J., "Role of the Domain Name System (DNS)",
                 RFC 3467, February 2003.

[RFC3761]        Faltstrom, P. and M. Mealling, "The E.164 to Uniform
                 Resource Identifiers (URI) Dynamic Delegation
                 Discovery System (DDDS) Application (ENUM)",
                 RFC 3761, April 2004.

[RFC4033]        Arends, R., Austein, R., Larson, M., Massey, D., and
                 S. Rose, "DNS Security Introduction and
                 Requirements", RFC 4033, March 2005.

[RFC4034]        Arends, R., Austein, R., Larson, M., Massey, D., and
                 S. Rose, "Resource Records for the DNS Security
                 Extensions", RFC 4034, March 2005.

[RFC4035]        Arends, R., Austein, R., Larson, M., Massey, D., and
                 S. Rose, "Protocol Modifications for the DNS
                 Security Extensions", RFC 4035, March 2005.

[RFC4511]        Sermersheim, J., "Lightweight Directory Access
                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4592]        Lewis, E., "The Role of Wildcards in the Domain Name
                 System", RFC 4592, July 2006.

[RFC4871]        Allman, E., Callas, J., Delany, M., Libbey, M.,
                 Fenton, J., and M. Thomas, "DomainKeys Identified
                 Mail (DKIM) Signatures", RFC 4871, May 2007.

Authors' Addresses 📬

Internet Architecture Board

EMail: iab@iab.org


Patrik Faltstrom (editor)

EMail: paf@cisco.com


Rob Austein (editor)

EMail: sra@isc.org


Peter Koch (editor)

EMail: pk@denic.de