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