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