idnits 2.17.1 draft-iab-dns-choices-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 23, 2006) is 6388 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2671' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 613, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- 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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft Cisco 4 Intended status: Informational October 23, 2006 5 Expires: April 26, 2007 7 Design Choices When Expanding DNS 8 draft-iab-dns-choices-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This note discusses how to extend the DNS with new data for a new 42 application. DNS extension discussion too often circulates around 43 reuse of the TXT record. This document lists different mechanisms to 44 accomplish the extension to DNS, and comes to the conclusion that the 45 use of a new RR Type is the best solution. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Place selectors inside the RDATA . . . . . . . . . . . . . 4 53 3.2. Add a prefix to the owner name . . . . . . . . . . . . . . 5 54 3.3. Add a suffix to the owner name . . . . . . . . . . . . . . 6 55 3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 6 56 3.5. Add a new Resource Record Type . . . . . . . . . . . . . . 7 57 4. Conclusion (why adding a new RR type is the answer) . . . . . 8 58 5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 10 59 6. New Resource Record Type . . . . . . . . . . . . . . . . . . . 11 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 records) and data which have to do with mappings between 74 domain names and IP addresses (A, AAAA and PTR). There are other 75 categories as well, some of which are tied to specific applications 76 like email (MX), while others are generic record types used to convey 77 information for multiple protocols (SRV, NAPTR). 79 When storing data in DNS for a new application, the data are usually 80 tied to a "normal" domain name, so the application can query for the 81 data it wants, while minimizing the impact on existing applications. 83 Historically, extending DNS to store data for applications tied to a 84 domain name has been done in different ways at different times. MX 85 records were created as a new resource record type specifically 86 designed to support electronic mail. SRV records are a generic type 87 which use a prefixing scheme in combination with a base domain name. 88 Records associated with ENUM use a suffixing scheme. NAPTR records 89 add selection data inside the RDATA. It is clear the way of adding 90 new data to the DNS has been inconsistent, and the purpose of this 91 document is to attempt to clarify the implications of each of these 92 methods, both for the applications that use them and for the rest of 93 the DNS system. 95 Many parts of this document talk about use of wildcards, and many 96 people might think use of wildcards is not something that happens 97 today. In reality thoug, wildcards are in use, especially for some 98 specific usages like MX records. Because of this, the choice have to 99 be made with existence of wildcards in mind. 101 Another overall issue that have to be taken into account is what the 102 new data in DNS is to describe. In some cases it might be completely 103 new data. In other cases it might be meta-data that is tied to data 104 that already exists in DNS. An example of new data is key 105 information for SSH and data used for fighting spam (meta data that 106 is connected to the MX record). If the new data has connection to 107 data that already exists in DNS, an analysis should be made as to 108 whether having (for example) A record and SSH key information in 109 different zones is a problem, and if it is, whether the owner for the 110 records by design must be the same for both records. 112 This document does not talk about what one should store in DNS. It 113 also doesn't discuss whether DNS is used for service discovery, or 114 whether DNS is (also) used for storage of data specific for the 115 service. In general, DNS is a protocol that apart from holding 116 metadata that makes DNS itself function (NS, SOA, DS RR Types etc) 117 only holds references to where services are located (SRV, NAPTR, A, 118 AAAA RR types). 120 2. Background 122 See RFC 2929 [RFC2929] for a brief summary of DNS query structure. 123 Readers interested in the full story should start with the base DNS 124 specification in RFC 1035 [RFC1035], and continue with the various 125 documents which update, clarify, and extend the base specification. 127 When composing a query against the DNS system, the parameters 128 actually used by the protocol are a triple: a DNS name, a DNS class, 129 and a DNS record type. Every resource record (RR) matching a 130 particular name, type and class is said to belong to the same 131 resource record set (RRSet), and the whole RRSet is always returned 132 to the client which queries for it. Splitting an RRSet is a protocol 133 violation, because it results in coherency problems with the DNS 134 caching mechanism. 136 Note that most of the discussions around MTU size is about the size 137 of the whole DNS packet, and not about the size of an RRSet 138 explicitly. A DNS packet is to fit in the MTU size when using UDP, 139 or else a truncated response is given back from the server (at which 140 point the client can reissue the query over TCP). 142 3. Extension mechanisms 144 The DNS protocol is intended to be extensible to support new kinds of 145 data. This section examines the various ways in which this sort of 146 extension can be accomplished. 148 3.1. Place selectors inside the RDATA 150 For a given query name, one might choose to have a single RRSet (all 151 sharing the same name, type, and class) shared by multiple 152 applications, and have the different applications use selectors 153 within the RR data (RDATA) to determine which records are intended 154 for which applications. This sort of selector mechanism is usually 155 referred to "subtyping", because it is in effect creating an 156 additional type subsystem within a single DNS RR type. 158 Examples of subtyping include NAPTR RRs (see RFC 3761 [RFC3761]) and 159 the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was 160 updated by RFC 3445 [RFC3445]). 162 All DNS subtyping schemes share a common weakness: With subtyping 163 schemes it is impossible for a client to query for just the data it 164 wants. Instead, the client must fetch the entire RRSet, then select 165 the RRs in which it is interested. Furthermore, since DNSSEC 166 signatures operate on complete RRSets, the entire RRSet must be re- 167 signed if any RR in it changes. As a result, each application that 168 uses a subtyped RR incurs higher overhead than any of the 169 applications would have incurred had they not been using a subtyping 170 scheme. The fact the RRSet is always passed around as an indivisible 171 unit increases the risk the RRSet will not fit in a UDP packet, which 172 in turn increases the risk that the client will have to retry the 173 query with TCP, which substantially increases the load on the name 174 server. More precisely: Having one query fail over to TCP is not a 175 big deal, but since the typical ratio of clients to servers in the 176 DNS system is very high, having a substantial number of DNS messages 177 fail over to TCP may cause the queried name servers to be overloaded 178 by TCP overhead. 180 To conclude, because of the limitations of the size of one RRSet is 181 that not all services tied to a domain can be announced, but instead 182 selected (by the zone administrator). This because all of them can 183 not be announced at the same time. 185 3.2. Add a prefix to the owner name 187 By adding an application-specific prefix to a domain name, we get 188 different name/class/type triples, and therefore different RRSets. 189 One problem with adding prefixes has to do with wildcards, especially 190 if one has records like 192 *.example.com. IN MX 1 mail.example.com. 194 and one wants records tied to those names. Suppose one creates the 195 prefix "_mail". One would then have to say something like 197 _mail.*.example.com. IN X-FOO A B C D 199 but DNS wildcards only work with the "*" as the leftmost token in the 200 domain name. 202 Even when a specific prefix is chosen, the data will still have to be 203 stored in some RR type. This RR type can either be a record type 204 that can store arbitrary data or a new RR type. This implies that 205 some other selection mechanism has to be applied as well, such as 206 ability to distinguish between the records in an RR set given they 207 have the same RR type (see also draft-ietf-dnsext-wcard-clarify 208 [wcardclarify] regarding use of wildcards and DNS). Because of this, 209 one needs both register a unique prefix and define what RR type is to 210 be used for this specific service. 212 If the record has some relationship with another record in the zone, 213 the fact the two records can be in different zones might have 214 implications on the trust the application have in the records. 215 Example: 217 example.com. IN MX 10 mail.example.com. 218 _foo.example.com. IN X-BAR "metadata for the mail service" 220 In this example, the two records might be in two different zones, and 221 because of this signed by two different organizations when using 222 DNSSEC. 224 3.3. Add a suffix to the owner name 226 Adding a suffix to a domain name changes the name/class/type triple, 227 and therefore the RRSet. In this case, since the query name can be 228 set to exactly the data one wants the size of the RRSet is minimized. 229 The problem with adding a suffix is that it creates a parallel tree 230 within the IN class. Further, there is no technical mechanism to 231 ensure that the delegation for "example.com" and "example.com._bar" 232 are made to the same organization. Furthermore, data associated with 233 a single entity will now be stored in two different zones, such as 234 "example.com" and "example.com._bar", which, depending on who 235 controls "_bar", can create new synchronization and update 236 authorization issues. 238 One way of solving the administrative issues is by using the DNAME 239 resource record type specified in RFC 2672 [RFC2672]. 241 Even when using a different name, the data will still have to be 242 stored in some RR type. This RR type can either be a "kitchen-sink 243 record" or a new RR type. This implies that some other mechanism has 244 to be applied as well, with implications detailed in other parts of 245 this note. 247 In RFC 2163 [RFC2163] an infix token is inserted directly below the 248 TLD, but the result is the same as adding a suffix to the owner name 249 (and because of that creation of a new TLD). 251 3.4. Add a new Class 253 DNS zones are class-specific in the sense that all the records in 254 that zone share the same class as the zone's SOA record and the 255 existence of a zone in one class does not guarantee the existence of 256 the zone in any other class. In practice, only the IN class has ever 257 seen widespread deployment, and the administrative overhead of 258 deploying an additional class would almost certainly be prohibitive. 260 Nevertheless, one could in theory use the DNS class mechanism to 261 distinguish between different kinds of data. However, since the DNS 262 delegation tree (represented by NS RRs) is itself tied to a specific 263 class, attempting to resolve a query by crossing a class boundary may 264 produce unexpected results, because there is no guarantee that the 265 name servers for the zone in the new class will be the same as the 266 name servers in the IN class. The MIT Hesiod system used a scheme 267 like this for storing data in the HS class, but only on a very small 268 scale (within a single institution), and with an administrative fiat 269 requiring that the delegation trees for the IN and HS trees be 270 identical. 272 Even when using a different class, the data will still have to be 273 stored in some RR type or another. This RR type can either be a 274 "kitchen-sink record" or a new RR type. This implies that some other 275 mechanism has to be applied as well, with implications detailed in 276 other parts of this note. 278 3.5. Add a new Resource Record Type 280 When adding a new Resource Record type to the system, entities in 281 four different roles have to be able to handle the new type: 283 1. There must be a way to insert the new resource records into the 284 zone of the Primary Master name server. For some server 285 implementations, the user interface only accepts record types 286 which it understands (perhaps so that the implementation can 287 attempt to validate the data). Other implementations allow the 288 zone administrator to enter an integer for the resource record 289 type code and the RDATA in Base64 or hexadecimal encoding (or 290 even as raw data). RFC 3597 [RFC3597] specifies a standard 291 generic encoding for this purpose. 292 2. A slave authoritative name server must be able to do a zone 293 transfer, receive the data from some other authoritative name 294 server, and serve data from the zone even though the zone 295 includes records of unknown types. Historically, some 296 implementations have had problems parsing stored copies of the 297 zone file after restarting, but those problems have not been seen 298 for a few years. 299 3. A full service resolver will cache the records which are 300 responses to queries. As mentioned in RFC 3597 [RFC3597],there 301 are various pitfalls where a recursive name server might end up 302 having problems. 303 4. The application must be able to get the record with a new 304 resource record type. The application itself may understand the 305 RDATA, but the resolver library might not. Support for a generic 306 interface for retrieving arbitrary DNS RR types has been a 307 requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2). 309 Some stub resolver library implementations neglect to provide 310 this functionality and cannot handle unknown RR types, but 311 implementation of a new stub resolver library is not particularly 312 difficult, and open source libraries that already provide this 313 functionality are available. 315 4. Conclusion (why adding a new RR type is the answer) 317 By now, the astute reader will be wondering how to use the issues 318 presented so far. We will now attempt to clear up the reader's 319 confusion by following the thought processes of a typical application 320 designer who wishes to store data in DNS, showing how such a designer 321 almost inevitably hits upon the idea of just using TXT RR, and why 322 this is a bad thing, and instead why a new RR type is to be 323 allocated. 325 The overall problem with most solutions has to do with two main 326 issues: 327 o No semantics to prevent collision with other use 328 o Space considerations (in the DNS message) 330 A typical application designer is not interested in the DNS for its 331 own sake, but rather as a distributed database in which application 332 data can be stored. As a result, the designer of a new application 333 is usually looking for the easiest way to add whatever new data the 334 application needs to the DNS in a way that naturally associates the 335 data with a DNS name. 337 As explained in Section 3.4, using the DNS class system as an 338 extension mechanism is not really an option, and in fact most users 339 of the system don't even realize that the mechanism exists. As a 340 practical matter, therefore any extension is likely to be within the 341 IN class. 343 Adding a new RR type is the technically correct answer from the DNS 344 protocol standpoint (more on this below), but doing so requires some 345 DNS expertise, due to the issues listed in Section 3.5. As a result, 346 this option is usually considered. Note that according to RFC2929 347 [RFC2929], some types require IETF Consensus, while others only 348 require a specification. 350 The application designer is thus left with the prospect of reusing 351 some existing DNS type within the IN class, but when the designer 352 looks at the existing types, almost all of them have well-defined 353 semantics, none of which quite match the needs of the new 354 application. This has not completely prevented proposals to reuse 355 existing RR types in ways incompatible with their defined semantics, 356 but it does tend to steer application designers away from this 357 approach. 359 RR Type 40 was registered for the SINK record type. This RR Type was 360 discussed in the DNSIND working group of the IETF, and it was decided 361 at the 46th IETF to not move the I-D forward to become an RFC. 362 Reason was the risk for large RR sets and the ability for application 363 creators to use the SINK RR Type instead of registering a new RR 364 Type. 366 Eliminating all of the above leaves the TXT RR type in the IN class. 367 The TXT RDATA format is free form text, and there are no existing 368 semantics to get in the way. Furthermore, the TXT RR can obviously 369 just be used as a bucket in which to carry around data to be used by 370 some higher level parser, perhaps in some human readable programming 371 or markup language. Thus, for many applications, TXT RRs are the 372 "obvious" choice. Unfortunately, this conclusion, while 373 understandable, is also wrong, for several reasons. 375 The first reason why TXT RRs are not well suited to such use is 376 precisely the lack of defined semantics that make them so attractive. 377 Arguably, the TXT RR is misnamed, and should have been called the 378 Local Container record, because the lack of defined semantics means 379 that a TXT RR means precisely what the data producer says it means. 380 This is fine, so long as TXT RRs are being used by human beings or by 381 private agreement between data producer and data consumer. However, 382 it becomes a problem once one starts using them for standardized 383 protocols in which there is no prior relationship between data 384 producer and data consumer. Reason for this is that there is nothing 385 to prevent collisions with some other incompatible use of TXT RRs. 386 This is even worse than the general subtyping problem described in 387 Section 3.1, because TXT RRs don't even have a standardized selector 388 field in which to store the subtype. RFC1464 [RFC1464] tried, but it 389 was not a success. At best a definition of a subtype is reduced to 390 hoping that whatever scheme one has come up with will not accidently 391 conflict with somebody else's subtyping scheme, and that it will not 392 be possible to mis-parse one application's use of TXT RRs as data 393 intended for a different application. Any attempt to come up with a 394 standardized format within the TXT RR format would be at least 395 fifteen years too late even if it were put into effect immediately. 397 Using one of the naming modifications discussed in Section 3.2 and 398 Section 3.3 would address the subtyping problem, but each of these 399 approaches brings in new problems of its own. The prefix approach 400 (such as SRV RRs use) does not work well with wildcards, which is a 401 particular problem for mail-related applications, since MX RRs are 402 probably the most common use of DNS wildcards. The suffix approach 403 doesn't have wildcard issues, but, as noted previously, it does have 404 synchronization and update authorization issues, since it works by 405 creating a second subtree in a different part of the global DNS name 406 space. 408 The next reason why TXT RRs are not well suited to protocol use has 409 to do with the limited data space available in a DNS message. As 410 alluded to briefly in Section 3.1, typical DNS query traffic patterns 411 involve a very large number of DNS clients sending queries to a 412 relatively small number of DNS servers. Normal path MTU discovery 413 schemes do little good here, because, from the server's perspective, 414 there isn't enough repeat traffic from any one client for it to be 415 worth retaining state. UDP-based DNS is an idempotent query, whereas 416 TCP-based DNS requires the server to keep state (in the form of TCP 417 connection state, usually in the server's kernel) and roughly triples 418 the traffic load. Thus, there's a strong incentive to keep DNS 419 messages short enough to fit in a UDP datagram, preferably a UDP 420 datagram short enough not to require IP fragmentation. 422 Subtyping schemes are therefore again problematic, because they 423 produce larger RRSets than necessary, but verbose text encodings of 424 data are also wasteful, since the data they hold can usually be 425 represented more compactly in a resource record designed specifically 426 to support the application's particular data needs. If the data that 427 need to be carried are so large that there is no way to make them fit 428 comfortably into the DNS regardless of encoding, it is probably 429 better to move the data somewhere else, and just use the DNS as a 430 pointer to the data, as with NAPTR. 432 5. Conclusion and Recommendation 434 Given the problems detailed in Section 4, it is worth reexamining the 435 oft-jumped-to conclusion that specifying a new RR type is hard. 436 Historically, this was indeed the case, but recent surveys suggest 437 that support for unknown RR types [RFC3597] is now widespread, and 438 that lack of support for unknown types is mostly an issue for 439 relatively old software that would probably need to be upgraded in 440 any case as part of supporting a new application. One should also 441 remember that deployed DNS software today should support DNSSEC, and 442 software recent enough to do so will have higher chance of being able 443 to also support RFC3597. 445 Of all the issues detailed in Section 3.5, provisioning the data is 446 in some respects the most difficult. The problem here is less the 447 authoritative name servers themselves than the front-end systems used 448 to enter (and perhaps validate) the data. Hand editing does not work 449 well for maintenance of large zones, so some sort of tool is 450 necessary, and the tool may not be tightly coupled to the name server 451 implementation itself. Note, however, that this provisioning problem 452 exists to some degree with any new form of data to be stored in DNS, 453 regardless of data format, RR type, or naming scheme. Adapting 454 front-end systems to support a new RR type may be a bit more 455 difficult than reusing an existing type, but this appears to be a 456 minor difference in degree rather than a difference in kind. 458 Given the various issues described in this note, we believe that: 459 o there is no magic solution which allows a completely painless 460 addition of new data to the DNS, but 461 o on the whole, the best solution is still to use the DNS type 462 mechanism designed for precisely this purpose, and 463 o of all the alternate solutions, the "obvious" approach of using 464 TXT RRs is almost certainly the worst. 465 This especially for the two reasons outlined above (lack of semantics 466 and its implications, and size leading to the need to use TCP). 468 6. New Resource Record Type 470 Creation of a new resource record type is specified in RFC 2929 471 [RFC2929]. Terminology is from RFC 2434 [RFC2434]. It is specified 472 in RFC 2929 that not only standards track documents can specify new 473 resource record types. Also experimental or informational RFC is ok, 474 and for some numbers "...RFC or other permanent and readily available 475 reference...". 477 The following are the rules applicable at the time of writing from 478 BCP 42 and BCP 26 for various ranges of Resource Record Types. 480 Type number 1-32767 require IETF Consensus: 482 IETF Consensus - New values are assigned through the IETF 483 consensus process. Specifically, new assignments are made via 484 RFCs approved by the IESG. Typically, the IESG will seek input on 485 prospective assignments from appropriate persons (e.g., a relevant 486 Working Group if one exists). 488 Examples: A record is number 1, and AXFR number 252. 490 Type number 32768-65279 require specification: 492 Specification Required - Values and their meaning must be 493 documented in an RFC or other permanent and readily available 494 reference, in sufficient detail so that interoperability between 495 independent implementations is possible. 497 No Resource Record types are registered in this range. 499 Type number 65280-65535 is for private use: 501 Private Use - For private or local use only, with the type and 502 purpose defined by the local site. No attempt is made to prevent 503 multiple sites from using the same value in different (and 504 incompatible) ways. There is no need for IANA to review such 505 assignments and assignments are not generally useful for 506 interoperability. 508 Resource records in this range is not registered centrally at 509 IANA, and collissions may exist. 511 7. IANA Considerations 513 This document does not require any IANA actions. 515 8. Security Considerations 517 DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly 518 necessary for any application mechanism that stores authorization 519 data in DNS. DNSSEC signatures significantly increase the size of 520 the messages transported, and because of this, the DNS message size 521 issues discussed in Section 3.1 and Section 4 are more serious than 522 they might at first appear. 524 Adding new RR types (as discussed in Section 3.5) might conceivably 525 trigger bugs and other bad behavior in software which is not 526 compliant with RFC 3597 [RFC3597], but most such software is old 527 enough and insecure enough that it should be updated for other 528 reasons in any case. Basic API support for retrieving arbitrary RR 529 types has been a requirement since 1989 (see RFC 1123 [RFC1123]). 531 Any new protocol that proposes to use the DNS to store data used to 532 make authorization decisions would be well advised not only to use 533 DNSSEC but also to encourage upgrades to DNS server software recent 534 enough not to be riddled with well-known exploitable bugs. Because 535 of this, support for new RR Types will not be as hard as people might 536 think at first. 538 9. Acknowledgements 540 This document has been created during a number of years, with input 541 from many people. The question on how to expand and use the DNS is 542 sensitive, and a document like this can not please everyone. The 543 goal is instead to describe the architecture, and given this IAB have 544 based a number of recommendations. 546 People that have helped include: Dean Andersson, Loa Andersson, Mark 547 Andrews, Rob Austein, Roy Badami, Dan Bernstein, Alex Bligh, 548 Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie 549 Daigle, Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, 550 Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, 551 Eric Hall, Philip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, 552 Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Peter 553 Koch, Olaf Kolkman, Ben Laurie, William Leibzon, John Levine, Edward 554 Lewis, David MacQuigg, Allison Manking, Bill Manning, David Meyer, 555 Pekka Nikander, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan 556 Rosenberg, Anders Rundgren, Miriam Sapiro, Pekka Savola, Chip Sharp, 557 James Snell, Michael Thomas, Paul Vixie, Sam Weiler, Florian Weimer, 558 Bert Wijnen, Dan Wing 560 Members of the IAB when this document was made available were: 561 Bernard Aboba, Loa Andesson, Brian Carpender, Leslie Daigle, Elwyn 562 Davies, Kevin Fall, Olaf Kolkman, Kurtis Lindqvist, David Meyer, 563 David Oran, Eric Rescorla, Lixia Zhang. 565 10. References 567 10.1. Normative References 569 [RFC1035] Mockapetris, P., "Domain names - implementation and 570 specification", STD 13, RFC 1035, November 1987. 572 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 573 Arbitrary String Attributes", RFC 1464, May 1993. 575 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 576 RFC 2535, March 1999. 578 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 579 RFC 2671, August 1999. 581 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 582 (RR) Types", RFC 3597, September 2003. 584 10.2. Informative References 586 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 587 and Support", STD 3, RFC 1123, October 1989. 589 [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER 590 Conformant Global Address Mapping (MCGAM)", RFC 2163, 591 January 1998. 593 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 594 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 595 October 1998. 597 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 598 Names", BCP 32, RFC 2606, June 1999. 600 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 601 RFC 2672, August 1999. 603 [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, 604 "Domain Name System (DNS) IANA Considerations", BCP 42, 605 RFC 2929, September 2000. 607 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 608 an On-line Database", RFC 3232, January 2002. 610 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 611 Resource Record (RR)", RFC 3445, December 2002. 613 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 614 Considered Useful", BCP 82, RFC 3692, January 2004. 616 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 617 Resource Identifiers (URI) Dynamic Delegation Discovery 618 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 620 [wcardclarify] 621 Lewis, E., "draft-ietf-dnsext-wcard-clarify-11.txt, The 622 Role of Wild Card Domains in the Domain Name System, work 623 in progress", March 2006. 625 Author's Address 627 Patrik Faltstrom 628 Cisco 630 Email: paf@cisco.com 632 Full Copyright Statement 634 Copyright (C) The Internet Society (2006). 636 This document is subject to the rights, licenses and restrictions 637 contained in BCP 78, and except as set forth therein, the authors 638 retain all their rights. 640 This document and the information contained herein are provided on an 641 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 642 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 643 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 644 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 645 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 646 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 648 Intellectual Property 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; nor does it represent that it has 655 made any independent effort to identify any such rights. Information 656 on the procedures with respect to rights in RFC documents can be 657 found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use of 662 such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository at 664 http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at 670 ietf-ipr@ietf.org. 672 Acknowledgment 674 Funding for the RFC Editor function is provided by the IETF 675 Administrative Support Activity (IASA).