idnits 2.17.1 draft-iab-dns-choices-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2009) is 5522 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-05 -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) -- Obsolete informational reference (is this intentional?): RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IAB 3 Internet-Draft P. Faltstrom, Ed. 4 Intended status: Informational R. Austein, Ed. 5 Expires: September 8, 2009 P. Koch, Ed. 6 March 7, 2009 8 Design Choices When Expanding DNS 9 draft-iab-dns-choices-08 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 8, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This note discusses how to extend the DNS with new data for a new 48 application. DNS extension discussions too often focus on reuse of 49 the TXT Resource Record Type. This document lists different 50 mechanisms to extend the DNS, and concludes that the use of a new DNS 51 Resource Record Type is the best solution. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Place selectors inside the RDATA of existing Resource 59 Record Types . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Add a prefix to the owner name . . . . . . . . . . . . . . 6 61 3.3. Add a suffix to the owner name . . . . . . . . . . . . . . 7 62 3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 7 63 3.5. Add a new Resource Record Type . . . . . . . . . . . . . . 8 64 4. Zone boundaries are invisible to applications . . . . . . . . 9 65 5. Why adding a new Resource Record Type is the preferred 66 solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Conclusion and Recommendation . . . . . . . . . . . . . . . . 13 68 7. Creating A New Resource Record Type . . . . . . . . . . . . . 14 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 11. IAB Members at the time of this writing . . . . . . . . . . . 16 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 The DNS stores multiple categories of data. The two most commonly 81 used categories are infrastructure data for the DNS system itself (NS 82 and SOA Resource Records) and data which have to do with mappings 83 between domain names and IP addresses (A, AAAA and PTR Resource 84 Records). There are other categories as well, some of which are tied 85 to specific applications like email (MX Resource Records), while 86 others are generic Resource Record Types used to convey information 87 for multiple protocols (SRV and NAPTR Resource Records). 89 When storing data in the DNS for a new application, the goal must be 90 to store data in such a way that the application can query for the 91 data it wants, while minimizing both the impact on existing 92 applications and the amount of extra data transferred to the client. 93 This implies that a number of design choices have to be made, where 94 the most important is to ensure that a precise selection of what data 95 to return must be made already in the query. A query consists of the 96 triple {Owner, Resource Record Type, Resource Record Class}. 98 Historically, extending DNS to store application data tied to a 99 domain name has been done in different ways at different times. MX 100 Resource Records were created as a new Resource Record Type 101 specifically designed to support electronic mail. SRV records are a 102 generic type which use a prefixing scheme in combination with a base 103 domain name. NAPTR records add selection data inside the RDATA. It 104 is clear that the methods used to add new data types to the DNS have 105 been inconsistent, and the purpose of this document is to attempt to 106 clarify the implications of each of these methods, both for the 107 applications that use them and for the rest of the DNS. 109 This document talks extensively about use of DNS wildcards. Many 110 people might think use of wildcards is not something that happens 111 today. In reality though, wildcards are in use, especially for 112 certain application-specific data such as MX Resource Records. 113 Because of this, the choice has to be made with existence of 114 wildcards in mind. 116 Another overall issue that must be taken into account is what the new 117 data in the DNS are to describe. In some cases they might be 118 completely new data. In other cases they might be metadata tied to 119 data that already exist in the DNS. Examples of new data are key 120 information for SSH and data used for authenticating the sender of 121 email messages (metadata tied to MX Resource Records). If the new 122 data are tied to data that already exist in the DNS, an analysis 123 should be made as to whether having (for example) address records and 124 SSH key information in different DNS zones is a problem or if it is a 125 bonus, and if it is a problem, whether the specification must require 126 all of the related data to be in the same zone. One specific 127 difference between having the records in the same zone or not has to 128 do with maintenance of the records. If they are in the same zone, 129 the same maintainer (from a DNS perspective) manages the two records. 130 Specifically, they must be signed with the same DNSSEC keys if DNSSEC 131 is in use. 133 This document does not talk about what one should store in the DNS. 134 It also doesn't discuss whether DNS should be used for service 135 discovery, or whether DNS should be used for storage of data specific 136 to the service. In general, DNS is a protocol that, apart from 137 holding metadata that makes the DNS itself function (NS, SOA, DNSSEC 138 Resource Record Types, etc), only holds references to service 139 locations (SRV, NAPTR, A, AAAA Resource Record Types) -- though there 140 are exceptions, such as MX Resource Records. 142 2. Background 144 See RFC 5395 [RFC5395] for a brief summary of DNS query structure. 145 Readers interested in the full story should start with the base DNS 146 specification in RFC 1035 [RFC1035], and continue with the various 147 documents that update, clarify, and extend the base specification. 149 When composing a DNS query, the parameters used by the protocol are a 150 triple: a DNS name, a DNS class, and a DNS Resource Record Type. 151 Every Resource Record matching a particular name, class and type is 152 said to belong to the same Resource Record Set (RRSet), and the whole 153 RRSet is always returned to the client that queries for it. 154 Splitting an RRSet is a protocol violation (sending a partial RRSet, 155 not truncating the DNS response), because it can result in coherency 156 problems with the DNS caching mechanism. See RFC 2181 section 5 157 [RFC2181] for more information. 159 Some discussions around extensions to the DNS include arguments 160 around MTU size. Note that most discussions about DNS and MTU size 161 are about the size of the whole DNS packet, not about the size of a 162 single RRSet. 164 Almost all DNS query traffic is carried over UDP, where a DNS message 165 must fit within a single UDP packet. DNS response messages are 166 almost always larger than DNS query messages, so message size issues 167 are almost always about responses, not queries. The base DNS 168 specification limits DNS messages over UDP to 512 octets; EDNS0 169 [RFC2671] specifies a mechanism by which a client can signal its 170 willingness to receive larger responses, but deployment of EDNS0 is 171 not universal, in part because of firewalls that block fragmented UDP 172 packets or EDNS0. If a response message won't fit in a single 173 packet, the name server returns a truncated response, at which point 174 the client may retry using TCP. DNS queries over TCP are not subject 175 to this length limitation, but TCP imposes significantly higher per- 176 query overhead on name servers than UDP. It is also the case that 177 the policies in deployed firewalls far too often are such that it 178 blocks DNS over TCP, so using TCP might not in reality be an option. 179 There are also risks (although possibly small) that a change of 180 routing while a TCP flow is open creates problems when the DNS 181 servers are deployed in an anycast environment. 183 3. Extension mechanisms 185 The DNS protocol is intended to be extensible to support new kinds of 186 data. This section examines the various ways in which this sort of 187 extension can be accomplished. 189 3.1. Place selectors inside the RDATA of existing Resource Record Types 191 For a given query name, one might choose to have a single RRSet (all 192 Resource Records sharing the same name, class and type) shared by 193 multiple applications, and have the different applications use 194 selectors within the Resource Record data (RDATA) to determine which 195 records are intended for which applications. This sort of selector 196 mechanism is usually referred to "subtyping", because it is in effect 197 creating an additional type subsystem within a single DNS Resource 198 Record Type. 200 Examples of subtyping include NAPTR Resource Records [RFC3761] and 201 the original DNSSEC KEY Resource Record Type [RFC2535] (which was 202 later updated by RFC 3445 [RFC3445]). 204 All DNS subtyping schemes share a common weakness: With subtyping 205 schemes it is impossible for a client to query for just the data it 206 wants. Instead, the client must fetch the entire RRSet, then select 207 the Resource Records in which it is interested. Furthermore, since 208 DNSSEC signatures operate on complete RRSets, the entire RRSet must 209 be re-signed if any Resource Record in it changes. As a result, each 210 application that uses a subtyped Resource Record incurs higher 211 overhead than any of the applications would have incurred had they 212 not been using a subtyping scheme. The fact the RRSet is always 213 passed around as an indivisible unit increases the risk the RRSet 214 will not fit in a UDP packet, which in turn increases the risk that 215 the client will have to retry the query with TCP, which substantially 216 increases the load on the name server. More precisely: having one 217 query fail over to TCP is not a big deal, but since the typical ratio 218 of clients to servers in today's deployed DNS is very high, having a 219 substantial number of DNS messages fail over to TCP may cause the 220 queried name servers to be overloaded by TCP overhead. 222 Because of the size limitations, using a subtyping scheme to list a 223 large number of services for a single domain name risks triggering 224 truncation and fallback to TCP, which may in turn force the zone 225 administrator to announce only a subset of available services. 227 3.2. Add a prefix to the owner name 229 By adding an application-specific prefix to a domain name, we get a 230 different name/class/type triple, and therefore a different RRSet. 231 One problem with adding prefixes has to do with wildcards, especially 232 if one has records like 234 *.example.com. IN MX 1 mail.example.com. 236 and one wants records tied to those names. Suppose one creates the 237 prefix "_mail". One would then have to say something like 239 _mail.*.example.com. IN X-FOO A B C D 241 but DNS wildcards only work with the "*" as the leftmost token in the 242 domain name (see also RFC 4592 [RFC4592]). 244 There have been proposals to deal with the problem that DNS wild- 245 cards are always terminal records. These proposals introduce an 246 additional set of trade-offs that would need to be taken into account 247 when assessing which extension mechanism to choose. Aspects of extra 248 response time needed to perform the extra queries, costs of pre- 249 calculation of possible answers, or the costs induced to the system 250 as a whole come to mind. At the time of writing none of these 251 proposals has been published as standards-track RFCs. 253 Even when a specific prefix is chosen, the data will still have to be 254 stored in some Resource Record Type. This Resource Record Type can 255 either be a new Resource Record Type or an existing Resource Record 256 Type that has an appropriate format to store the data. One also 257 might need some other selection mechanism, such as the ability to 258 distinguish between the records in an RRSet given they have the same 259 Resource Record Type. Because of this, one needs to both register a 260 unique prefix and define what Resource Record Type is to be used for 261 this specific service. 263 If the record has some relationship with another record in the zone, 264 the fact that the two records can be in different zones might have 265 implications on the trust the application has in the records. For 266 example: 268 example.com. IN MX 10 mail.example.com. 269 _foo.example.com. IN X-BAR "metadata for the mail service" 271 In this example, the two records might be in two different zones, and 272 as a result might be administered by two different organisations, and 273 signed by two different entities when using DNSSEC. For these two 274 reasons, using a prefix has recently become a very interesting 275 solution for many protocol designers. In some cases when using TXT 276 records (e.g. DomainKeys Identified Mail Signatures [RFC4871]), in 277 other cases when adding new Resource Record Types (SRV). 279 3.3. Add a suffix to the owner name 281 Adding a suffix to a domain name changes the name/class/type triple, 282 and therefore the RRSet. In this case, since the query name can be 283 set to exactly the data one wants the size of the RRSet is minimized. 284 The problem with adding a suffix is that it creates a parallel tree 285 within the IN class. Further, there is no technical mechanism to 286 ensure that the delegation for "example.com" and "example.com._bar" 287 are made to the same organization. Furthermore, data associated with 288 a single entity will now be stored in two different zones, such as 289 "example.com" and "example.com._bar", which, depending on who 290 controls "_bar", can create new synchronization and update 291 authorization issues. 293 One way of solving the administrative issues is by using the DNAME 294 Resource Record Type specified in RFC 2672 [RFC2672]. 296 Even when using a different name, the data will still have to be 297 stored in some Resource Record Type that has an appropriate format to 298 store the data. This implies that one might have to mix the prefix 299 based selection mechanism with some other mechanism so that the right 300 Resource Record can be found out of many in a potential larger RRSet. 302 In RFC 2163 [RFC2163] an infix token is inserted directly below the 303 TLD, but the result is equivalent to adding a suffix to the owner 304 name (instead of creating a TLD, one is creating a second level 305 domain). 307 3.4. Add a new Class 309 DNS zones are class-specific in the sense that all the records in 310 that zone share the same class as the zone's SOA record and the 311 existence of a zone in one class does not guarantee the existence of 312 the zone in any other class. In practice, only the IN class has ever 313 seen widespread deployment, and the administrative overhead of 314 deploying an additional class would almost certainly be prohibitive. 316 Nevertheless, one could in theory use the DNS class mechanism to 317 distinguish between different kinds of data. However, since the DNS 318 delegation tree (represented by NS Resource Records) is itself tied 319 to a specific class, attempting to resolve a query by crossing a 320 class boundary may produce unexpected results because there is no 321 guarantee that the name servers for the zone in the new class will be 322 the same as the name servers in the IN class. The MIT Hesiod system 323 [Dyer 87] used a scheme like this for storing data in the HS class, 324 but only on a very small scale (within a single institution), and 325 with an administrative fiat requiring that the delegation trees for 326 the IN and HS trees be identical. The use of the HS class for such 327 storage of non-sensitive data was over time replaced by use of the 328 Lightweight Directory Access Protocol (LDAP) [RFC4511]. 330 Even when using a different class, the data will still have to be 331 stored in some Resource Record Type that has an appropriate format to 332 store the data. 334 3.5. Add a new Resource Record Type 336 When adding a new Resource Record Type to the system, entities in 337 four different roles have to be able to handle the new Type: 339 1. There must be a way to insert the new Resource Records into the 340 zone of the Primary Master name server. For some server 341 implementations, the user interface only accepts Resource Record 342 Types which it understands (perhaps so that the implementation 343 can attempt to validate the data). Other implementations allow 344 the zone administrator to enter an integer for the Resource 345 Record Type code and the RDATA in Base64 or hexadecimal encoding 346 (or even as raw data). RFC 3597 [RFC3597] specifies a standard 347 generic encoding for this purpose. 348 2. A slave authoritative name server must be able to do a zone 349 transfer, receive the data from some other authoritative name 350 server, and serve data from the zone even though the zone 351 includes records of unknown Resource Record Types. Historically, 352 some implementations have had problems parsing stored copies of 353 the zone file after restarting, but those problems have not been 354 seen for a few years. Some implementations use an alternate 355 mechanism (e.g., LDAP) to transfer Resource Records in a zone, 356 and are primarily used within corporate environments; in this 357 case name servers must be able to transfer new Resource Record 358 Types using whatever mechanism is used. However, today this 359 alternative mechanism may not support unknown Resource Record 360 Types. Hence, in Internet environments, unknown Resource Record 361 Types are supported, but in corporate environments they are 362 problematic. 364 3. A caching resolver (most commonly a recursive name server) will 365 cache the records which are responses to queries. As mentioned 366 in RFC 3597 [RFC3597], there are various pitfalls where a 367 recursive name server might end up having problems. 368 4. The application must be able to get the RRSet with a new Resource 369 Record Type. The application itself may understand the RDATA, 370 but the resolver library might not. Support for a generic 371 interface for retrieving arbitrary DNS Resource Record Types has 372 been a requirement since 1989 (see RFC 1123 [RFC1123] Section 373 6.1.4.2). Some stub resolver library implementations neglect to 374 provide this functionality and cannot handle unknown Resource 375 Record Types, but implementation of a new stub resolver library 376 is not particularly difficult, and open source libraries that 377 already provide this functionality are available. 379 Historically, adding a new Resource Record Type has been very 380 problematic. The review process has been cumbersome, DNS servers 381 have not been able to handle new Resource Record Types, and firewalls 382 have dropped queries or responses with Resource Record Types that are 383 unknown to the firewall. This is for example one of the reasons the 384 ENUM standard reuses the NAPTR Resource Record, a decision that today 385 might have gone to creating a new Resource Record Type instead. 387 Today, there is a requirement that DNS software handle unknown 388 Resource Record Types, and investigations have shown that software 389 that is deployed in general does support it, except in some alternate 390 mechanisms for transferring Resource Records such as LDAP as noted 391 above. Also, the approval process for new Resource Record Types has 392 been updated [RFC5395] so the effort that is needed for various 393 Resource Record Types is more predictable. 395 4. Zone boundaries are invisible to applications 397 Regardless of the possible choices above we have seen a number of 398 cases where the application made assumptions about the structure of 399 the namespace and the location where specific information resides. 400 We take a small sidestep to argue against such approaches. 402 The DNS namespace is a hierarchy, technically speaking. However, 403 this only refers to the way names are built from multiple labels. 404 DNS hierarchy neither follows nor implies administrative hierarchy. 405 Because of that, it cannot be assumed that data attached to a node in 406 the DNS tree is valid for the whole subtree. Technically, there are 407 zone boundaries partitioning the namespace, and administrative 408 boundaries (or policy boundaries) may even exist elsewhere. 410 The false assumption has lead to an approach called "tree climbing", 411 where a query that does not receive a positive response (either the 412 requested RRSet was missing or the name did not exist) is retried by 413 repeatedly stripping off the leftmost label (climbing towards the 414 root) until the root domain is reached. Sometimes these proposals 415 try to avoid the query for the root or the TLD level, but still this 416 approach has severe drawbacks: 418 o Technically, the DNS was built as a query - response tool without 419 any search capability [RFC3467]. Adding the search mechanism 420 imposes additional burden on the technical infrastructure, in the 421 worst case on TLD and root name servers. 422 o For reasons similar to those outlined in RFC 1535 [RFC1535], 423 querying for information in a domain outside the control of the 424 intended entity may lead to incorrect results and may also put 425 security at risk. Finding the exact policy boundary is impossible 426 without an explicit marker which does not exist at present. At 427 best, software can detect zone boundaries (e.g., by looking for 428 SOA Resource Records), but some TLD registries register names 429 starting at the second level (e.g., CO.UK), and there are various 430 other "registry" types at second, third or other level domains 431 that cannot be identified as such without policy knowledge 432 external to the DNS. 434 To restate, the zone boundary is purely a boundary that exists in the 435 DNS for administrative purposes, and applications should be careful 436 not to draw unwarranted conclusions from zone boundaries. A 437 different way of stating this is that the DNS does not support 438 inheritance, e.g. a wildcard MX RRSet for a TLD will not be valid for 439 any subdomain of that particular TLD. 441 5. Why adding a new Resource Record Type is the preferred solution 443 By now, the astute reader might be wondering what conclusions to draw 444 from the issues presented so far. We will now attempt to clear up 445 the reader's confusion by following the thought processes of a 446 typical application designer who wishes to store data in the DNS. 447 We'll show how such a designer almost inevitably hits upon the idea 448 of just using a TXT Resource Record, why this is a bad thing, and why 449 a new Resource Record Type should be allocated instead. And we'll 450 also explain how the reuse of an existing resource record, including 451 TXT, can be made less harmful. 453 The overall problem with most solutions has to do with two main 454 issues: 455 o No semantics to prevent collision with other use 456 o Space considerations in the DNS message 458 A typical application designer is not interested in the DNS for its 459 own sake, but rather regards it as a distributed database in which 460 application data can be stored. As a result, the designer of a new 461 application is usually looking for the easiest way to add whatever 462 new data the application needs to the DNS in a way that naturally 463 associates the data with a DNS name and does not require major 464 changes to DNS servers. 466 As explained in Section 3.4, using the DNS class system as an 467 extension mechanism is not really an option, and in fact most users 468 of the system don't even realize that the mechanism exists. As a 469 practical matter, therefore any extension is likely to be within the 470 IN class. 472 Adding a new Resource Record Type is the technically correct answer 473 from the DNS protocol standpoint (more on this below), but doing so 474 requires some DNS expertise, due to the issues listed in Section 3.5. 475 Consequently, this option is often rejected. Note that according to 476 RFC 5395 [RFC5395], some Types require IETF Consensus, while others 477 only require a specification. 479 There is a drawback to defining new RR types that is worth 480 mentioning. The Resource Record Type (RRTYPE) is a 16 bit value and 481 hence is a limited resource. In order to prevent hoarding the 482 registry has a review based allocation policy [RFC5395], however this 483 may not be sufficient if extension of the DNS by addition of new RR 484 types takes up significantly and the registry starts nearing 485 completion. In that case the trade-offs with respect to choosing an 486 extension mechanism may need to change. 488 The application designer is thus left with the prospect of reusing 489 some existing DNS Type within the IN class, but when the designer 490 looks at the existing Types, almost all of them have well-defined 491 semantics, none of which quite match the needs of the new 492 application. This has not completely prevented proposals from 493 reusing existing Resource Record Types in ways incompatible with 494 their defined semantics, but it does tend to steer application 495 designers away from this approach. 497 For example, Resource Record Type 40 was registered for the SINK 498 Resource Record Type. This Resource Record Type was discussed in the 499 DNSIND working group of the IETF, and it was decided at the 46th IETF 500 to not move the I-D forward to become an RFC because of the risk of 501 encouraging application designers to use the SINK Resource Record 502 Type instead of registering a new Resource Record Type, which would 503 result in infeasibly large SINK RRsets. 505 Eliminating all of the above leaves the TXT Resource Record Type in 506 the IN class. The TXT RDATA format is free form text, and there are 507 no existing semantics to get in the way. Some attempts have been 508 made, for example in draft-cheshire-dnsext-dns-sd 509 [I-D.cheshire-dnsext-dns-sd], to specify a structured format for TXT 510 Resource Record Types, but no such attempt has reached RFC status. 511 Furthermore, the TXT Resource Record can obviously just be used as a 512 bucket in which to carry around data to be used by some higher level 513 parser, perhaps in some human readable programming or markup 514 language. Thus, for many applications, TXT Resource Records are the 515 "obvious" choice. Unfortunately, this conclusion, while 516 understandable, is also problematic, for several reasons. 518 The first reason why TXT Resource Records are not well suited to such 519 use is precisely what makes them so attractive: the lack of pre- 520 defined common syntax or structure. As a result, each application 521 that uses them creates its own syntax/structure, and that makes it 522 difficult to reliably distinguish one application's record from 523 others, and for its parser to avoid problems when it encounters other 524 TXT records. 526 Arguably, the TXT Resource Record is misnamed, and should have been 527 called the Local Container record, because a TXT Resource Record 528 means only what the data producer says it means. This is fine, so 529 long as TXT Resource Records are being used by human beings or by 530 private agreement between data producer and data consumer. However, 531 it becomes a problem once one starts using them for standardized 532 protocols in which there is no prior relationship between data 533 producer and data consumer. If TXT records are used without one of 534 the naming modifications discussed earlier (and in some cases even if 535 one uses such naming mechanisms), there is nothing to prevent 536 collisions with some other incompatible use of TXT Resource Records. 538 This is even worse than the general subtyping problem described in 539 Section 3.1, because TXT Resource Records don't even have a 540 standardized selector field in which to store the subtype. RFC 1464 541 [RFC1464] tried, but it was not a success. At best a definition of a 542 subtype is reduced to hoping that whatever scheme one has come up 543 with will not accidently conflict with somebody else's subtyping 544 scheme, and that it will not be possible to mis-parse one 545 application's use of TXT Resource Records as data intended for a 546 different application. Any attempt to impose a standardized format 547 within the TXT Resource Record format would be at least fifteen years 548 too late even if it were put into effect immediately; at best, one 549 can restrict the syntax that a particular application uses within a 550 TXT Resource Record and accept the risk that unrelated TXT Resource 551 Record uses will collide with it. 553 Using one of the naming modifications discussed in Section 3.2 and 554 Section 3.3 would address the subtyping problem, (and have been used 555 in combinations with reuse of TXT record, such as for the dns/txt 556 lookup mechanism in DKIM) but each of these approaches brings in new 557 problems of its own. The prefix approach (that for example SRV 558 Resource Records use) does not work well with wildcards, which is a 559 particular problem for mail-related applications, since MX Resource 560 Records are probably the most common use of DNS wildcards. The 561 suffix approach doesn't have wildcard issues, but, as noted 562 previously, it does have synchronization and update authorization 563 issues, since it works by creating a second subtree in a different 564 part of the global DNS name space. 566 The next reason why TXT Resource Records are not well suited to 567 protocol use has to do with the limited data space available in a DNS 568 message. As alluded to briefly in Section 3.1, typical DNS query 569 traffic patterns involve a very large number of DNS clients sending 570 queries to a relatively small number of DNS servers. Normal path MTU 571 discovery schemes do little good here because, from the server's 572 perspective, there isn't enough repeat traffic from any one client 573 for it to be worth retaining state. UDP-based DNS is an idempotent 574 query, whereas TCP-based DNS requires the server to keep state (in 575 the form of TCP connection state, usually in the server's kernel) and 576 roughly triples the traffic load. Thus, there's a strong incentive 577 to keep DNS messages short enough to fit in a UDP datagram, 578 preferably a UDP datagram short enough not to require IP 579 fragmentation. 581 Subtyping schemes are therefore again problematic because they 582 produce larger Resource RRSets than necessary, but verbose text 583 encodings of data are also wasteful, since the data they hold can 584 usually be represented more compactly in a Resource Record designed 585 specifically to support the application's particular data needs. If 586 the data that need to be carried are so large that there is no way to 587 make them fit comfortably into the DNS regardless of encoding, it is 588 probably better to move the data somewhere else, and just use the DNS 589 as a pointer to the data, as with NAPTR. 591 6. Conclusion and Recommendation 593 Given the problems detailed in Section 5, it is worth reexamining the 594 oft-jumped-to conclusion that specifying a new Resource Record Type 595 is hard. Historically, this was indeed the case, but recent surveys 596 suggest that support for unknown Resource Record Types [RFC3597] is 597 now widespread in the public Internet, and because of that the DNS 598 infrastructure can handle new Resource Record Types. The lack of 599 support for unknown Types remains an issue for relatively old 600 provisioning software and in corporate environments. 602 Of all the issues detailed in Section 3.5, provisioning the data is 603 in some respects the most difficult. Investigations with zone 604 transfers show that the problem is less difficult for the 605 authoritative name servers themselves than the front-end systems used 606 to enter (and perhaps validate) the data. Hand editing does not work 607 well for maintenance of large zones, so some sort of tool is 608 necessary, and the tool may not be tightly coupled to the name server 609 implementation itself. Note, however, that this provisioning problem 610 exists to some degree with any new form of data to be stored in the 611 DNS, regardless of data format, Resource Record type (even if TXT 612 Resource Record Types are in use), or naming scheme. Adapting front- 613 end systems to support a new Resource Record Type may be a bit more 614 difficult than reusing an existing type, but this appears to be a 615 minor difference in degree rather than a difference in kind. 617 Given the various issues described in this note, we believe that: 618 o there is no magic solution which allows a completely painless 619 addition of new data to the DNS, but 620 o on the whole, the best solution is still to use the DNS Resource 621 Record Type mechanism designed for precisely this purpose, 622 whenever possible, and 623 o of all the alternate solutions, the "obvious" approach of using 624 TXT Resource Records for arbitrary names is almost certainly the 625 worst, especially for the two reasons outlined above (lack of 626 semantics and its implementations, and size leading to the need to 627 use TCP). 629 7. Creating A New Resource Record Type 631 The process for creating a new Resource Record Type is specified in 632 RFC 5395 [RFC5395]. 634 8. IANA Considerations 636 This document does not require any IANA actions. 638 9. Security Considerations 640 DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly 641 necessary for any application mechanism that stores authorization 642 data in the DNS. DNSSEC signatures significantly increase the size 643 of the messages transported, and because of this, the DNS message 644 size issues discussed in Section 3.1 and Section 5 are more serious 645 than they might at first appear. 647 Adding new Resource Record Types (as discussed in Section 3.5) can 648 create two different kinds of problems. In DNS software and in 649 applications. In the DNS software, it might conceivably trigger bugs 650 and other bad behavior in software that is not compliant with RFC 651 3597 [RFC3597], but most such DNS software is old enough and insecure 652 enough that it should be updated for other reasons in any case. In 653 applications and provisioning software, the changes for the new 654 features that need the new data in DNS can be updated to understand 655 the structure of the new data format (regardless of whether a new 656 Resource Record Type is used or some other mechanism is chosen. 657 Basic API support for retrieving arbitrary Resource Record Types has 658 been a requirement since 1989 [RFC1123]. 660 Any new protocol that proposes to use the DNS to store data used to 661 make authorization decisions would be well advised not only to use 662 DNSSEC but also to encourage upgrades to DNS server software recent 663 enough not to be riddled with well-known exploitable bugs. 665 10. Acknowledgements 667 This document has been created during a number of years, with input 668 from many people. The question on how to expand and use the DNS is 669 sensitive, and a document like this can not please everyone. The 670 goal is instead to describe the architecture and tradeoffs, and make 671 some recommendations about best practices. 673 People that have helped include: Dean Andersson, Mark Andrews, John 674 Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein, 675 Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies, 676 Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert 677 Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric 678 Hall, Philip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, 679 Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Olaf 680 Kolkman, Ben Laurie, William Leibzon, John Levine, Edward Lewis, 681 David MacQuigg, Allison Manking, Bill Manning, David Meyer, Pekka 682 Nikander, Mans Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, 683 Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten 684 Strotmann, Pekka Savola, Chip Sharp, James Snell, Michael Thomas, 685 Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing. 687 11. IAB Members at the time of this writing 689 Loa Andersson 690 Gonzalo Camarillo 691 Stuart Cheshire 692 Russ Housley 693 Olaf Kolkman 694 Gregory Lebovitz 695 Barry Leiba 696 Kurtis Lindqvist 697 Andrew Malis 698 Danny McPherson 699 David Oran 700 Dave Thaler 701 Lixia Zhang 703 12. References 705 12.1. Normative References 707 [RFC1035] Mockapetris, P., "Domain names - implementation and 708 specification", STD 13, RFC 1035, November 1987. 710 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 711 Arbitrary String Attributes", RFC 1464, May 1993. 713 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 714 RFC 2535, March 1999. 716 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 717 RFC 2671, August 1999. 719 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 720 (RR) Types", RFC 3597, September 2003. 722 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 723 Considerations", BCP 42, RFC 5395, November 2008. 725 12.2. Informative References 727 [Dyer 87] Dyer, S. and F. Hsu, "Hesiod, Project Athena Technical 728 Plan - Name Service", Version 1.9, April 1987. 730 [I-D.cheshire-dnsext-dns-sd] 731 Cheshire, S. and M. Krochmal, "DNS-Based Service 732 Discovery", draft-cheshire-dnsext-dns-sd-05 (work in 733 progress), September 2008. 735 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 736 and Support", STD 3, RFC 1123, October 1989. 738 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 739 With Widely Deployed DNS Software", RFC 1535, 740 October 1993. 742 [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER 743 Conformant Global Address Mapping (MCGAM)", RFC 2163, 744 January 1998. 746 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 747 Specification", RFC 2181, July 1997. 749 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 750 RFC 2672, August 1999. 752 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 753 Resource Record (RR)", RFC 3445, December 2002. 755 [RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", 756 RFC 3467, February 2003. 758 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 759 Resource Identifiers (URI) Dynamic Delegation Discovery 760 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 762 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 763 (LDAP): The Protocol", RFC 4511, June 2006. 765 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 766 System", RFC 4592, July 2006. 768 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 769 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 770 Signatures", RFC 4871, May 2007. 772 Authors' Addresses 774 Internet Architecture Board 776 Email: iab@iab.org 777 Patrik Faltstrom (editor) 779 Email: paf@cisco.com 781 Rob Austein (editor) 783 Email: sra@isc.org 785 Peter Koch (editor) 787 Email: pk@denic.de