idnits 2.17.1 draft-iab-dns-choices-05.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 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 718. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 18, 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 1464 ** 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 -- 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: 4 errors (**), 0 flaws (~~), 2 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: Standards Track R. Austein, Ed. 5 Expires: August 21, 2008 P. Koch, Ed. 6 February 18, 2008 8 Design Choices When Expanding DNS 9 draft-iab-dns-choices-05 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 August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This note discusses how to extend the DNS with new data for a new 43 application. DNS extension discussions too often focus on reuse of 44 the TXT Resource Record Type. This document lists different 45 mechanisms to extend the DNS, and concludes that the use of a new DNS 46 Resource Record Type is the best solution. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Place selectors inside the RDATA of existing Resource 54 Record Types . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. Add a prefix to the owner name . . . . . . . . . . . . . . 5 56 3.3. Add a suffix to the owner name . . . . . . . . . . . . . . 6 57 3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 7 58 3.5. Add a new Resource Record Type . . . . . . . . . . . . . . 7 59 4. Zone boundaries are invisible to applications . . . . . . . . 8 60 5. Why adding a new Resource Record Type is the preferred 61 solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Conclusion and Recommendation . . . . . . . . . . . . . . . . 12 63 7. Creating A New Resource Record Type . . . . . . . . . . . . . 13 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 The DNS stores multiple categories of data. The two most commonly 76 used categories are infrastructure data for the DNS system itself (NS 77 and SOA Resource Records) and data which have to do with mappings 78 between domain names and IP addresses (A, AAAA and PTR Resource 79 Records). There are other categories as well, some of which are tied 80 to specific applications like email (MX Resource Records), while 81 others are generic Resource Record Types used to convey information 82 for multiple protocols (SRV and NAPTR Resource Records). 84 When storing data in the DNS for a new application, the data are 85 usually tied to a "normal" domain name, so that the application can 86 query for the data it wants, while minimizing the impact on existing 87 applications. 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. Records associated with ENUM use a suffixing scheme. 95 NAPTR records add selection data inside the RDATA. It is clear that 96 the methods used to add new data types to the DNS have been 97 inconsistent, and the purpose of this document is to attempt to 98 clarify the implications of each of these methods, both for the 99 applications that use them and for the rest of the DNS. 101 This document talks extensively about use of DNS wildcards. Many 102 people might think use of wildcards is not something that happens 103 today. In reality though, wildcards are in use, especially for 104 certain application-specific data such as MX Resource Records. 105 Because of this, the choice has to be made with existence of 106 wildcards in mind. 108 Another overall issue that must be taken into account is what the new 109 data in the DNS are to describe. In some cases they might be 110 completely new data. In other cases they might be metadata tied to 111 data that already exist in the DNS. An example of new data is key 112 information for SSH and data used for fighting spam (metadata tied to 113 MX Resource Records). If the new data are tied to data that already 114 exist in the DNS, an analysis should be made as to whether having 115 (for example) address records and SSH key information in different 116 DNS zones is a problem, and if it is, whether the specification must 117 require all of the related data to be in the same zone. 119 This document does not talk about what one should store in the DNS. 120 It also doesn't discuss whether DNS should be used for service 121 discovery, or whether DNS should be used for storage of data specific 122 for the service. In general, DNS is a protocol that, apart from 123 holding metadata that makes the DNS itself function (NS, SOA, DNSSEC 124 Resource Record Types, etc), only holds references to service 125 locations (SRV, NAPTR, A, AAAA Resource Record Types), but there are 126 exceptions (such as MX Resource Records). 128 2. Background 130 See [RFC2929] for a brief summary of DNS query structure. Readers 131 interested in the full story should start with the base DNS 132 specification in [RFC1035], and continue with the various documents 133 that update, clarify, and extend the base specification. 135 When composing a DNS query, the parameters used by the protocol are a 136 triple: a DNS name, a DNS class, and a DNS record Type. Every 137 Resource Record matching a particular name, type and class is said to 138 belong to the same "RRSet", and the whole RRSet is always returned to 139 the client that queries for it. Splitting an RRSet is a protocol 140 violation, because it results in coherency problems with the DNS 141 caching mechanism. 143 Some discussions around extensions to the DNS include arguments 144 around MTU size. Note that most discussions about DNS and MTU size 145 are about the size of the whole DNS packet, not about the size of a 146 single RRSet. 148 Almost all DNS query traffic is carried over UDP, where a DNS message 149 must fit within a single UDP packet. DNS response messages are 150 almost always larger than DNS query messages, so message size issues 151 are almost always about responses, not queries. The base DNS 152 specification limits DNS messages over UDP to 512 octets; EDNS0 153 [RFC2671] specifies a mechanism by which a client can signal its 154 willingness to receive larger responses, but deployment of EDNS0 is 155 not universal, in part because of firewalls that block fragmented UDP 156 packets or EDNS0. If a response message won't fit in a single 157 packet, the name server returns a truncated response, at which point 158 the client may retry using TCP. DNS queries over TCP are not subject 159 to this length limitation, but TCP imposes significantly higher per- 160 query overhead on name servers than UDP. It is also the case that 161 the policies in deployed firewalls far too often is such that it 162 blocks DNS over TCP, so using TCP might not in reality be an option. 163 There are also risks (although possibly small) that a change of 164 routing while a TCP flow is open create problems when the DNS servers 165 are deployed in an anycast environment. 167 3. Extension mechanisms 169 The DNS protocol is intended to be extensible to support new kinds of 170 data. This section examines the various ways in which this sort of 171 extension can be accomplished. 173 3.1. Place selectors inside the RDATA of existing Resource Record Types 175 For a given query name, one might choose to have a single RRSet (all 176 Resource Records sharing the same name, type, and class) shared by 177 multiple applications, and have the different applications use 178 selectors within the Resource Record data (RDATA) to determine which 179 records are intended for which applications. This sort of selector 180 mechanism is usually referred to "subtyping", because it is in effect 181 creating an additional type subsystem within a single DNS Resource 182 Record Type. 184 Examples of subtyping include NAPTR Resource Records (see [RFC3761]) 185 and the original DNSSEC KEY Resource Record Type ([RFC2535]) (before 186 it was updated by [RFC3445]). 188 All DNS subtyping schemes share a common weakness: With subtyping 189 schemes it is impossible for a client to query for just the data it 190 wants. Instead, the client must fetch the entire RRSet, then select 191 the Resource Records in which it is interested. Furthermore, since 192 DNSSEC signatures operate on complete RRSets, the entire RRSet must 193 be re-signed if any Resource Record in it changes. As a result, each 194 application that uses a subtyped Resource Record incurs higher 195 overhead than any of the applications would have incurred had they 196 not been using a subtyping scheme. The fact the RRSet is always 197 passed around as an indivisible unit increases the risk the RRSet 198 will not fit in a UDP packet, which in turn increases the risk that 199 the client will have to retry the query with TCP, which substantially 200 increases the load on the name server. More precisely: having one 201 query fail over to TCP is not a big deal, but since the typical ratio 202 of clients to servers in today's deployed DNS is very high, having a 203 substantial number of DNS messages fail over to TCP may cause the 204 queried name servers to be overloaded by TCP overhead. 206 Because of the size limitations, using a subtyping scheme to list a 207 large number of services for a single domain name risks triggering 208 truncation and fallback to TCP, which may in turn force the zone 209 administrator to announce only a subset of available services. 211 3.2. Add a prefix to the owner name 213 By adding an application-specific prefix to a domain name, we get a 214 different name/class/type triple, and therefore a different RRSet. 216 One problem with adding prefixes has to do with wildcards, especially 217 if one has records like 219 *.example.com. IN MX 1 mail.example.com. 221 and one wants records tied to those names. Suppose one creates the 222 prefix "_mail". One would then have to say something like 224 _mail.*.example.com. IN X-FOO A B C D 226 but DNS wildcards only work with the "*" as the leftmost token in the 227 domain name (see also [RFC4592]). 229 Even when a specific prefix is chosen, the data will still have to be 230 stored in some Resource Record Type. This Resource Record Type can 231 either be a record Type that has an appropriate format to store the 232 data or a new Resource Record Type. This implies that some other 233 selection mechanism has to be applied as well, such as ability to 234 distinguish between the records in an RRSet given they have the same 235 Resource Record Type. Because of this, one needs to both register a 236 unique prefix and define what Resource Record Type is to be used for 237 this specific service. 239 If the record has some relationship with another record in the zone, 240 the fact that the two records can be in different zones might have 241 implications on the trust the application has in the records. For 242 example: 244 example.com. IN MX 10 mail.example.com. 245 _foo.example.com. IN X-BAR "metadata for the mail service" 247 In this example, the two records might be in two different zones, and 248 because of this might be signed by two different organizations when 249 using DNSSEC. 251 3.3. Add a suffix to the owner name 253 Adding a suffix to a domain name changes the name/class/type triple, 254 and therefore the RRSet. In this case, since the query name can be 255 set to exactly the data one wants the size of the RRSet is minimized. 256 The problem with adding a suffix is that it creates a parallel tree 257 within the IN class. Further, there is no technical mechanism to 258 ensure that the delegation for "example.com" and "example.com._bar" 259 are made to the same organization. Furthermore, data associated with 260 a single entity will now be stored in two different zones, such as 261 "example.com" and "example.com._bar", which, depending on who 262 controls "_bar", can create new synchronization and update 263 authorization issues. 265 One way of solving the administrative issues is by using the DNAME 266 Resource Record Type specified in [RFC2672]. 268 Even when using a different name, the data will still have to be 269 stored in some Resource Record Type. This Resource Record Type can 270 either be a "kitchen-sink record" or a new Resource Record Type. 271 This implies that some other mechanism has to be applied as well, 272 with implications detailed in other parts of this note. 274 In [RFC2163] an infix token is inserted directly below the TLD, but 275 the result is equivalent to adding a suffix to the owner name 276 (instead of creating a TLD one is creating a second level domain). 278 3.4. Add a new Class 280 DNS zones are class-specific in the sense that all the records in 281 that zone share the same class as the zone's SOA record and the 282 existence of a zone in one class does not guarantee the existence of 283 the zone in any other class. In practice, only the IN class has ever 284 seen widespread deployment, and the administrative overhead of 285 deploying an additional class would almost certainly be prohibitive. 287 Nevertheless, one could in theory use the DNS class mechanism to 288 distinguish between different kinds of data. However, since the DNS 289 delegation tree (represented by NS Resource Records) is itself tied 290 to a specific class, attempting to resolve a query by crossing a 291 class boundary may produce unexpected results because there is no 292 guarantee that the name servers for the zone in the new class will be 293 the same as the name servers in the IN class. The MIT Hesiod system 294 used a scheme like this for storing data in the HS class, but only on 295 a very small scale (within a single institution), and with an 296 administrative fiat requiring that the delegation trees for the IN 297 and HS trees be identical. 299 Even when using a different class, the data will still have to be 300 stored in some Resource Record Type or another. This Resource Record 301 Type can either be a "kitchen-sink record" or a new Resource Record 302 Type. This implies that some other mechanism has to be applied as 303 well, with implications detailed in other parts of this note. 305 3.5. Add a new Resource Record Type 307 When adding a new Resource Record Type to the system, entities in 308 four different roles have to be able to handle the new Type: 310 1. There must be a way to insert the new Resource Records into the 311 zone of the Primary Master name server. For some server 312 implementations, the user interface only accepts record Types 313 which it understands (perhaps so that the implementation can 314 attempt to validate the data). Other implementations allow the 315 zone administrator to enter an integer for the Resource Record 316 Type code and the RDATA in Base64 or hexadecimal encoding (or 317 even as raw data). [RFC3597] specifies a standard generic 318 encoding for this purpose. 319 2. A slave authoritative name server must be able to do a zone 320 transfer, receive the data from some other authoritative name 321 server, and serve data from the zone even though the zone 322 includes records of unknown Types. Historically, some 323 implementations have had problems parsing stored copies of the 324 zone file after restarting, but those problems have not been seen 325 for a few years. 326 3. A caching resolver (most commonly a recursive name server) will 327 cache the records which are responses to queries. As mentioned 328 in [RFC3597],there are various pitfalls where a recursive name 329 server might end up having problems. 330 4. The application must be able to get the RRSet with a new Resource 331 Record Type. The application itself may understand the RDATA, 332 but the resolver library might not. Support for a generic 333 interface for retrieving arbitrary DNS Resource Record Types has 334 been a requirement since 1989 (see [RFC1123] Section 6.1.4.2). 335 Some stub resolver library implementations neglect to provide 336 this functionality and cannot handle unknown Resource Record 337 Types, but implementation of a new stub resolver library is not 338 particularly difficult, and open source libraries that already 339 provide this functionality are available. 341 4. Zone boundaries are invisible to applications 343 Regardless of the possible choices above we have seen a number of 344 cases where the application made assumptions about the structure of 345 the namespace and the location where specific information resides. 346 We take a small sidestep to argue against such approaches. 348 The DNS namespace is a hierarchy, technically speaking. However, 349 this only refers to the way names are built from multiple labels. 350 DNS hierarchy neither follows nor implies administrative hierarchy. 351 That said, it cannot be assumed that data attached to a node in the 352 DNS tree is valid for the whole subtree. Technically, there are zone 353 boundaries partitioning the namespace and administrative boundaries 354 (or policy boundaries) may even exist elsewhere. 356 The false assumption has lead to an approach called "tree climbing", 357 where a query that does not receive a positive response (either the 358 requested RRSet was missing or the name did not exist) is retried by 359 repeatedly stripping off the leftmost label (climbing towards the 360 root) until the root domain is reached. Sometimes these proposals 361 try to avoid the query for the root or the TLD level, but still this 362 approach has severe drawbacks: 364 o Technically, the DNS was built as a query - response tool without 365 any search capability [RFC3467]. Adding the search mechanism 366 imposes additional burden on the technical infrastructure, in the 367 worst case on TLD and root name servers. 368 o For reasons similar to those outlined in RFC 1535, querying for 369 information in a domain outside the control of the intended entity 370 may lead to incorrect results and may also put security at risk. 371 Finding the exact policy boundary is impossible without an 372 explicit marker which does not exist at present. At best, 373 software can detect zone boundaries (e.g., by looking for SOA 374 Resource Records), but some TLD registries register names starting 375 at the second level (e.g., CO.UK), and there are various other 376 "registry" types at second, third or other level domains that 377 cannot be identified as such without policy knowledge external to 378 the DNS. 380 To restate, the zone boundary is purely a boundary that exists in the 381 DNS for administrative purposes, and applications should be careful 382 not to draw unwarranted conclusions from zone boundaries. A 383 different way of stating this is that the DNS does not support 384 inheritance, e.g. a wildcard MX RRSet for a TLD will not be valid for 385 any subdomain of that particular TLD. 387 5. Why adding a new Resource Record Type is the preferred solution 389 By now, the astute reader might be be wondering what conclusions to 390 draw from all the issues presented so far. We will now attempt to 391 clear up the reader's confusion by following the thought processes of 392 a typical application designer who wishes to store data in the DNS, 393 showing how such a designer almost inevitably hits upon the idea of 394 just using TXT Resource Record, why this is a bad thing, and why a 395 new Resource Record Type should be allocated instead. 397 The overall problem with most solutions has to do with two main 398 issues: 399 o No semantics to prevent collision with other use 400 o Space considerations in the DNS message 402 A typical application designer is not interested in the DNS for its 403 own sake, but rather as a distributed database in which application 404 data can be stored. As a result, the designer of a new application 405 is usually looking for the easiest way to add whatever new data the 406 application needs to the DNS in a way that naturally associates the 407 data with a DNS name. 409 As explained in Section 3.4, using the DNS class system as an 410 extension mechanism is not really an option, and in fact most users 411 of the system don't even realize that the mechanism exists. As a 412 practical matter, therefore any extension is likely to be within the 413 IN class. 415 Adding a new Resource Record Type is the technically correct answer 416 from the DNS protocol standpoint (more on this below), but doing so 417 requires some DNS expertise, due to the issues listed in Section 3.5. 418 As a result, this option is usually not considered. Note that 419 according to [RFC2929], some Types require IETF Consensus, while 420 others only require a specification. 422 The application designer is thus left with the prospect of reusing 423 some existing DNS Type within the IN class, but when the designer 424 looks at the existing Types, almost all of them have well-defined 425 semantics, none of which quite match the needs of the new 426 application. This has not completely prevented proposals from 427 reusing existing Resource Record Types in ways incompatible with 428 their defined semantics, but it does tend to steer application 429 designers away from this approach. 431 For example, Resource Record Type 40 was registered for the SINK 432 record Type. This Resource Record Type was discussed in the DNSIND 433 working group of the IETF, and it was decided at the 46th IETF to not 434 move the I-D forward to become an RFC because of the risk of 435 encouraging application designers to use the SINK Resource Record 436 Type instead of registering a new Resource Record Type, which would 437 result in infeasibly large SINK RRsets. 439 Eliminating all of the above leaves the TXT Resource Record Type in 440 the IN class. The TXT RDATA format is free form text, and there are 441 no existing semantics to get in the way. Furthermore, the TXT 442 Resource Record can obviously just be used as a bucket in which to 443 carry around data to be used by some higher level parser, perhaps in 444 some human readable programming or markup language. Thus, for many 445 applications, TXT Resource Records are the "obvious" choice. 446 Unfortunately, this conclusion, while understandable, is also wrong, 447 for several reasons. 449 The first reason why TXT Resource Records are not well suited to such 450 use is precisely the lack of defined semantics that make them so 451 attractive. Arguably, the TXT Resource Record is misnamed, and 452 should have been called the Local Container record, because the lack 453 of defined semantics means that a TXT Resource Record means precisely 454 what the data producer says it means. This is fine, so long as TXT 455 Resource Records are being used by human beings or by private 456 agreement between data producer and data consumer. However, it 457 becomes a problem once one starts using them for standardized 458 protocols in which there is no prior relationship between data 459 producer and data consumer. The reason for this is that there is 460 nothing to prevent collisions with some other incompatible use of TXT 461 Resource Records. This is even worse than the general subtyping 462 problem described in Section 3.1, because TXT Resource Records don't 463 even have a standardized selector field in which to store the 464 subtype. [RFC1464] tried, but it was not a success. At best a 465 definition of a subtype is reduced to hoping that whatever scheme one 466 has come up with will not accidently conflict with somebody else's 467 subtyping scheme, and that it will not be possible to mis-parse one 468 application's use of TXT Resource Records as data intended for a 469 different application. Any attempt to impose a standardized format 470 within the TXT Resource Record format would be at least fifteen years 471 too late even if it were put into effect immediately; at best, one 472 can restrict the syntax that a particular application uses within a 473 TXT Resource Record and accept the risk that unrelated TXT Resource 474 Record uses will collide with it. 476 Using one of the naming modifications discussed in Section 3.2 and 477 Section 3.3 would address the subtyping problem, but each of these 478 approaches brings in new problems of its own. The prefix approach 479 (that for example SRV Resource Records use) does not work well with 480 wildcards, which is a particular problem for mail-related 481 applications, since MX Resource Records are probably the most common 482 use of DNS wildcards. The suffix approach doesn't have wildcard 483 issues, but, as noted previously, it does have synchronization and 484 update authorization issues, since it works by creating a second 485 subtree in a different part of the global DNS name space. 487 The next reason why TXT Resource Records are not well suited to 488 protocol use has to do with the limited data space available in a DNS 489 message. As alluded to briefly in Section 3.1, typical DNS query 490 traffic patterns involve a very large number of DNS clients sending 491 queries to a relatively small number of DNS servers. Normal path MTU 492 discovery schemes do little good here because, from the server's 493 perspective, there isn't enough repeat traffic from any one client 494 for it to be worth retaining state. UDP-based DNS is an idempotent 495 query, whereas TCP-based DNS requires the server to keep state (in 496 the form of TCP connection state, usually in the server's kernel) and 497 roughly triples the traffic load. Thus, there's a strong incentive 498 to keep DNS messages short enough to fit in a UDP datagram, 499 preferably a UDP datagram short enough not to require IP 500 fragmentation. 502 Subtyping schemes are therefore again problematic because they 503 produce larger Resource RRSets than necessary, but verbose text 504 encodings of data are also wasteful, since the data they hold can 505 usually be represented more compactly in a Resource Record designed 506 specifically to support the application's particular data needs. If 507 the data that need to be carried are so large that there is no way to 508 make them fit comfortably into the DNS regardless of encoding, it is 509 probably better to move the data somewhere else, and just use the DNS 510 as a pointer to the data, as with NAPTR. 512 6. Conclusion and Recommendation 514 Given the problems detailed in Section 5, it is worth reexamining the 515 oft-jumped-to conclusion that specifying a new Resource Record Type 516 is hard. Historically, this was indeed the case, but recent surveys 517 suggest that support for unknown Resource Record Types [RFC3597] is 518 now widespread, and that lack of support for unknown Types is mostly 519 an issue for relatively old software that would probably need to be 520 upgraded in any case as part of supporting a new application. One 521 should also remember that deployed DNS software today should support 522 DNSSEC, and software recent enough to do so will likely support both 523 unknown Resource Record Types [RFC3597] and EDNS0 [RFC2671]. 525 Of all the issues detailed in Section 3.5, provisioning the data is 526 in some respects the most difficult. The problem here is less 527 difficult for the authoritative name servers themselves than the 528 front-end systems used to enter (and perhaps validate) the data. 529 Hand editing does not work well for maintenance of large zones, so 530 some sort of tool is necessary, and the tool may not be tightly 531 coupled to the name server implementation itself. Note, however, 532 that this provisioning problem exists to some degree with any new 533 form of data to be stored in the DNS, regardless of data format, 534 Resource Record type, or naming scheme. Including the TXT Resource 535 Record Type. Adapting front-end systems to support a new Resource 536 Record type may be a bit more difficult than reusing an existing 537 type, but this appears to be a minor difference in degree rather than 538 a difference in kind. 540 Given the various issues described in this note, we believe that: 541 o there is no magic solution which allows a completely painless 542 addition of new data to the DNS, but 543 o on the whole, the best solution is still to use the DNS Resource 544 Record Type mechanism designed for precisely this purpose, and 545 o of all the alternate solutions, the "obvious" approach of using 546 TXT Resource Records is almost certainly the worst. 547 This especially for the two reasons outlined above (lack of semantics 548 and its implications, and size leading to the need to use TCP). 550 7. Creating A New Resource Record Type 552 The process for creating a new Resource Record Type is specified in 553 [I-D.ietf-dnsext-2929bis]. 555 8. IANA Considerations 557 This document does not require any IANA actions. 559 9. Security Considerations 561 DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly 562 necessary for any application mechanism that stores authorization 563 data in the DNS. DNSSEC signatures significantly increase the size 564 of the messages transported, and because of this, the DNS message 565 size issues discussed in Section 3.1 and Section 5 are more serious 566 than they might at first appear. 568 Adding new Resource Record Types (as discussed in Section 3.5) might 569 conceivably trigger bugs and other bad behavior in software that is 570 not compliant with [RFC3597], but most such software is old enough 571 and insecure enough that it should be updated for other reasons in 572 any case. Basic API support for retrieving arbitrary Resource Record 573 Types has been a requirement since 1989 (see [RFC1123]). 575 Any new protocol that proposes to use the DNS to store data used to 576 make authorization decisions would be well advised not only to use 577 DNSSEC but also to encourage upgrades to DNS server software recent 578 enough not to be riddled with well-known exploitable bugs. Because 579 of this, support for new Resource Record Types will not be as hard as 580 people might think at first. 582 10. Acknowledgements 584 This document has been created during a number of years, with input 585 from many people. The question on how to expand and use the DNS is 586 sensitive, and a document like this can not please everyone. The 587 goal is instead to describe the architecture and tradeoffs, and make 588 some recommendations about best practices. 590 People that have helped include: Dean Andersson, Loa Andersson, Mark 591 Andrews, John Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, 592 Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie 593 Daigle, Elwyn Davies, Mark Delany, Richard Draves, Martin Duerst, 594 Donald Eastlake, Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, 595 Olafur Gudmundsson, Eric Hall, Philip Hallam-Baker, Ted Hardie, Bob 596 Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren, 597 John Klensin, Olaf Kolkman, Ben Laurie, William Leibzon, John Levine, 598 Edward Lewis, David MacQuigg, Allison Manking, Bill Manning, Danny 599 McPherson, David Meyer, Pekka Nikander, Masataka Ohta, Douglas Otis, 600 Michael Patton, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, 601 Pekka Savola, Chip Sharp, James Snell, Dave Thaler, Michael Thomas, 602 Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing. 604 Members of the IAB when this document was made available were: Loa 605 Andersson, Leslie Daigle, Elwyn Davies, Kevin Fall, Russ Housley, 606 Olaf Kolkman, Barry Leiba, Kurtis Lindqvist, Danny McPherson, David 607 Oran, Eric Rescorla, Dave Thaler, and Lixia Zhang. 609 11. References 611 11.1. Normative References 613 [RFC1035] Mockapetris, P., "Domain names - implementation and 614 specification", RFC 1035, STD 13, November 1987. 616 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 617 Arbitrary String Attributes", RFC 1464, May 1993. 619 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 620 Extensions", RFC 2535, March 1999. 622 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 623 RFC 2671, August 1999. 625 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 626 (RR) Types", RFC 3597, September 2003. 628 11.2. Informative References 630 [I-D.ietf-dnsext-2929bis] 631 3rd, D., "Domain Name System (DNS) IANA Considerations", 632 draft-ietf-dnsext-2929bis-06 (work in progress), 633 August 2007. 635 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 636 and Support", RFC 1123, STD 3, October 1989. 638 [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER 639 Conformant Global Address Mapping (MCGAM)", RFC 2163, 640 January 1998. 642 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 643 RFC 2672, August 1999. 645 [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, 646 "Domain Name System (DNS) IANA Considerations", RFC 2929, 647 BCP 42, September 2000. 649 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 650 Resource Record (RR)", RFC 3445, December 2002. 652 [RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", 653 RFC 3467, February 2003. 655 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 656 Resource Identifiers (URI) Dynamic Delegation Discovery 657 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 659 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 660 System", RFC 4592, July 2006. 662 Authors' Addresses 664 Internet Architecture Board 666 Email: iab@iab.org 668 Patrik Faltstrom (editor) 670 Email: paf@cisco.com 672 Rob Austein (editor) 674 Email: sra@isc.org 676 Peter Koch (editor) 678 Email: pk@denic.de 680 Full Copyright Statement 682 Copyright (C) The IETF Trust (2008). 684 This document is subject to the rights, licenses and restrictions 685 contained in BCP 78, and except as set forth therein, the authors 686 retain all their rights. 688 This document and the information contained herein are provided on an 689 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 690 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 691 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 692 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 693 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 694 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 696 Intellectual Property 698 The IETF takes no position regarding the validity or scope of any 699 Intellectual Property Rights or other rights that might be claimed to 700 pertain to the implementation or use of the technology described in 701 this document or the extent to which any license under such rights 702 might or might not be available; nor does it represent that it has 703 made any independent effort to identify any such rights. Information 704 on the procedures with respect to rights in RFC documents can be 705 found in BCP 78 and BCP 79. 707 Copies of IPR disclosures made to the IETF Secretariat and any 708 assurances of licenses to be made available, or the result of an 709 attempt made to obtain a general license or permission for the use of 710 such proprietary rights by implementers or users of this 711 specification can be obtained from the IETF on-line IPR repository at 712 http://www.ietf.org/ipr. 714 The IETF invites any interested party to bring to its attention any 715 copyrights, patents or patent applications, or other proprietary 716 rights that may cover technology that may be required to implement 717 this standard. Please address the information to the IETF at 718 ietf-ipr@ietf.org. 720 Acknowledgment 722 Funding for the RFC Editor function is provided by the IETF 723 Administrative Support Activity (IASA).