idnits 2.17.1 draft-iab-dns-choices-01.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 564. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 580), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 == Line 177 has weird spacing: '...hem can be an...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2005) is 6989 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 492, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 514, 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 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: 9 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Faltstrom 2 Internet-Draft R. Austein 3 Expires: September 5, 2005 IAB 4 March 7, 2005 6 Design Choices When Expanding DNS 7 draft-iab-dns-choices-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 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 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 62 8.2 Informative References . . . . . . . . . . . . . . . . . . . 12 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . 13 66 1. Introduction 68 The DNS stores multiple categories of data. The two most commonly 69 used categories are infrastructure data for the DNS system itself (NS 70 and SOA records) and data which have to do with mappings between 71 domain names and IP addresses (A, AAAA and PTR). There are other 72 categories as well, some of which are tied to specific applications 73 like email (MX), while others are generic record types used to convey 74 information for multiple protocols (SRV, NAPTR). 76 When storing data in the DNS for a new application, the data are 77 usually tied to a "normal" domain name, so the application can query 78 for the data it wants, while minimizing the impact on existing 79 applications. 81 Historically, extending DNS to store data for applications tied to a 82 domain name has been done in different ways at different times. MX 83 records were created as a new resource record type specifically 84 designed to support electronic mail. SRV records are a generic type 85 which use a prefixing scheme in combination with a base domain name. 86 Records associated with ENUM use a suffixing scheme. NAPTR records 87 add selection data inside the RDATA. It is clear the way of adding 88 new data to the DNS has been inconsistent, and the purpose of this 89 document is to attempt to clarify the implications of each of these 90 methods, both for the applications that use them and for the rest of 91 the DNS system. 93 Many parts of this document talk about use of wildcards, and many 94 people might think use of wildcards is not something that happens 95 today. In reality thoug, wildcards are in use, especially for some 96 specific usages like MX records. Because of this, the choice have to 97 be made with existence of wildcards in mind. 99 Another overall issue that have to be taken into account is what the 100 new data in DNS is to describe. In some cases it might be completely 101 new data. In other cases it might be meta-data that is tied to data 102 that already exists in the DNS. Example of new data is key 103 information for SSH and data used for fighting spam (meta data that 104 is connected to the MX record). If the new data has connection to 105 data that already exists in DNS, an analysis should be made whether 106 having (for example) A record and SSH key information in different 107 zones is a problem, and if it is, whether the owner for the records 108 by design must be the same for both records. 110 This document do not talk about what one should store in DNS. 111 Whether DNS is used for service discovery, or whether DNS is (also) 112 used for storage of application specific data. In general, DNS is a 113 protocol that part from holding metadata that makes DNS itself 114 function (NS, SOA, DS RR Types etc) only holds references to where 115 services are located (SRV, NAPTR, A, AAAA RR types). 117 2. Background 119 See RFC 2929 [RFC2929] for a brief summary of DNS query structure. 120 Readers interested in the full story should start with the base DNS 121 specification in RFC 1035 [RFC1035], and continue with the various 122 documents which update, clarify, and extend the base specification. 124 When composing a query into the DNS system, the parameters actually 125 used by the protocol are a triple: a DNS name, a DNS class, and a DNS 126 record type. Every resource record (RR) matching a particular name, 127 type and class is said to belong to the same resource record set 128 (RRSet), and the whole RRSet is always returned to the client which 129 queries for it. Splitting an RRSet is a protocol violation, because 130 it results in coherency problems with the DNS caching mechanism. 132 Note however that this requirement has nothing to do with the MTU 133 size and choice of UDP or TCP as the transport protocol. The whole 134 RRSet always has to be returned, and if it doesn't fit in the MTU in 135 UDP, TCP has to be used to not break this RRSet atomic requirement. 137 3. Extension mechanisms 139 The DNS protocol is intended to be extensible to support new kinds of 140 data. This section examines the various ways in which this sort of 141 extension can be accomplished. 143 3.1 Place selectors inside the RDATA 145 For a given query name, one might choose to have a single RRSet (all 146 sharing the same name, type, and class) shared by multiple 147 applications, and have the different applications use selectors 148 within the RR data (RDATA) to determine which records are intended 149 for which applications. This sort of selector mechanism is usually 150 referred to "subtyping", because it is in effect creating an 151 additional type subsystem within a single DNS RR type. 153 Examples of subtyping include NAPTR RRs (see RFC 3761 [RFC3761]) and 154 the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was 155 updated by RFC 3445 [RFC3445]). 157 All DNS subtyping schemes share a common weakness: With subtyping 158 schemes it is impossible for a client to query for just the data it 159 wants. Instead, the client must fetch the entire RRSet, then select 160 the RRs in which it is interested. Furthermore, since DNSSEC 161 signatures operate on complete RRSets, the entire RRSet must be 162 re-signed if any RR in it changes. As a result, each application 163 that uses a subtyped RR incurs higher overhead than any of the 164 applications would have incurred had they not been using a subtyping 165 scheme. The fact the RRSet is always passed around as an indivisible 166 unit increases the risk the RRSet will not fit in a UDP packet, which 167 in turn increases the risk that the client will have to retry the 168 query with TCP, which substantially increases the load on the name 169 server. More precisely: Having one query fail over to TCP is not a 170 big deal, but since the typical ratio of clients to servers in the 171 DNS system is very high, having a substantial number of DNS messages 172 fail over to TCP it will cause the relevant name servers to be 173 overloaded by TCP overhead. 175 The final result of using a subtyping scheme might be that the zone 176 administrator has to choose which of the services tied to one domain 177 name can actually be used, because not all of them can be announced 178 at the same time. 180 3.2 Add a prefix to the owner name 182 By adding an application-specific prefix to a domain name, we will 183 get different name/class/type triples, and therefore different 184 RRSets. One problem with adding prefixes has to do with wildcards, 185 especially if one has records like 187 *.example.com. IN MX 1 mail.example.com. 189 and one wants records tied to those names. Suppose one creates the 190 prefix "_mail". One would then have to say something like 192 _mail.*.example.com. IN X-FOO A B C D 194 but DNS wildcards only work with the "*" as the leftmost token in the 195 domain name. 197 Even when a specific prefix is chosen, the data will still have to be 198 stored in some RR type. This RR type can either be a record type 199 that can store arbitrary data or a new RR type. This implies that 200 some other selection mechanism has to be applied as well, such as 201 ability to distinguish between the records in an RR set given they 202 have the same RR Type (see also draft-ietf-dnsext-wcard-clarify 203 [wcardclarify] regarding use of wildcards and DNS). Because of this 204 one need to register both a unique prefix and define what RR type is 205 to be used for this specific service. 207 If the record has some relationship with another record, the fact the 208 original record and this with a prefix can be in different zones 209 might have implications on the trust in the application have on the 210 records. Example: 212 example.com. IN X-FOO "some good thing" 213 _foo.example.com. IN X-BAR "why the good thing is good" 215 In this example, the two records might be in two different zones, and 216 because of this signed by two different organizations when using 217 DNSSEC. 219 3.3 Add a suffix to the owner name 221 Adding a suffix to a domain name changes the name/class/type triple, 222 and therefore the RRSet. The query name can be set to exactly the 223 data one wants, and the size of the RRSet is minimized. The problem 224 with adding a suffix is that it creates a parallel tree within the IN 225 class. There will be no technical mechanism to ensure that the 226 delegation for "example.com" and "example.com._bar" are made to the 227 same organization. Furthermore, data associated with a single entity 228 will now be stored in two different zones, such as "example.com" and 229 "example.com._bar", which, depending on who controls "_bar", can 230 create new synchronization and update authorization issues. 232 Even when using a different name, the data will still have to be 233 stored in some RR type. This RR type can either be a "kitchen-sink 234 record" or a new RR type. This implies that some other mechanism has 235 to be applied as well, with implications detailed in other parts of 236 this note. 238 In RFC 2163 [RFC2163] an infix token is inserted directly below the 239 TLD, but the result is the same as adding a suffix to the owner name 240 (and because of that creation of a new TLD). 242 3.4 Add a new Class 244 DNS zones are class-specific, in the sense that all the records in 245 that zone share the same class as the zone's SOA record, and the 246 existence of a zone in one class does not guarantee the existence of 247 the zone in any other class. In practice, only the IN class has ever 248 seen widespread deployment, and the administrative overhead of 249 deploying an additional class would almost certainly be prohibitive. 251 Nevertheless, one could in theory use the DNS class mechanism to 252 distinguish between different kinds of data. However, since the DNS 253 delegation tree (represented by NS RRs) is itself tied to a specific 254 class, attempting to resolve a query by crossing a class boundary may 255 produce unexpected results, because there is no guarantee that the 256 name servers for the zone in the new class will be the same as the 257 name servers in the IN class. The MIT Hesiod system used a scheme 258 like this for storing data in the HS class, but only on a very small 259 scale (within a single institution), and with an administrative fiat 260 requiring that the delegation trees for the IN and HS trees be 261 identical. 263 Even when using a different class, the data will still have to be 264 stored in some RR type or another. This RR type can either be a 265 "kitchen-sink record" or a new RR type. This implies that some other 266 mechanism has to be applied as well, with implications detailed in 267 other parts of this note. 269 3.5 Add a new Resource Record Type 271 When adding a new Resource Record type to the system, entities in 272 four different roles have to be able to handle the new type: 274 1. There must be a way to insert the new resource records into the 275 zone of the Primary Master name server. For some server 276 implementations, the user interface only accepts record types 277 which it understands (perhaps so that the implementation can 278 attempt to validate the data). Other implementations allow the 279 zone administrator to enter an integer for the resource record 280 type code and the RDATA in Base64 or hexadecimal encoding (or 281 even as raw data). RFC 3597 [RFC3597] specifies a standard 282 generic encoding for this purpose. 283 2. A slave authoritative name server must be able to do a zone 284 transfer, receive the data from some other authoritative name 285 server, and serve data from the zone even though the zone 286 includes records of unknown types. Historically, some 287 implementations have had problems parsing stored copies of the 288 zone file after restarting, but those problems have not been seen 289 for a few years. 290 3. A full service resolver will cache the records which are 291 responses to queries. As mentioned in RFC 3597 [RFC3597],there 292 are various pitfalls where a recursive name server might end up 293 having problems. 294 4. The application must be able to get the record with a new 295 resource record type. The application itself may understand the 296 RDATA, but the resolver library might not. Support for a generic 297 interface for retrieving arbitrary DNS RR types has been a 298 requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2). 299 Some stub resolver library implementations neglect to provide 300 this functionality and cannot handle unknown RR types, but 301 implementation of a new stub resolver library is not particularly 302 difficult, and open source libraries that already provide this 303 functionality are available. 305 4. Conclusion (why adding a new RR type is the answer) 307 By now, the astute reader will be wondering about how to use the 308 issues presented so far. We will now attempt to clear up the 309 reader's confusion by following the thought processes of a typical 310 application designer who wishes to store stuff in the DNS, showing 311 how such a designer almost inevitably hits upon the idea of just 312 using TXT RR, and why this is a bad thing, and instead why a new RR 313 type is to be allocated. 315 A typical application designer is not interested in the DNS for its 316 own sake, but rather as a distributed database in which application 317 data can be stored. As a result, the designer of a new application 318 is usually looking for the easiest way to add whatever new data the 319 application needs to the DNS in a way that naturally associates the 320 data with a DNS name. 322 As explained in Section 3.4, using the DNS class system as an 323 extension mechanism is not really an option, and in fact most users 324 of the system don't even realize that the mechanism exists. As a 325 practical matter, therefore any extension is likely to be within the 326 IN class. 328 Adding a new RR type is the technically correct answer from the DNS 329 protocol standpoint (more on this below), but doing so requires some 330 DNS expertise, due to the issues listed in Section 3.5. As a result, 331 this option is usually considered too hard. Note that according to 332 RFC2929 [RFC2929], some types require IETF Consensus, while others 333 only require a specification. 335 The application designer is thus left with the prospect of reusing 336 some existing DNS type within the IN class, but when the designer 337 looks at the existing types, almost all of them have well-defined 338 semantics, none of which quite match the needs of the new 339 application. This has not completely prevented proposals to reuse 340 existing RR types in ways incompatible with their defined semantics, 341 but it does tend to steer application designers away from this 342 approach. 344 RR Type 40 was registered for the SINK record type. This RR Type was 345 discussed in the DNSIND working group of the IETF, and it was decided 346 at the 46th IETF to not move the I-D forward to become an RFC. 347 Reason was the risk for large RR sets and the ability for application 348 creators to use the SINK RR Type instead of registering a new RR 349 Type. 351 Eliminating all of the above leaves the TXT RR type in the IN class. 352 The TXT RDATA format is free form text, and there are no existing 353 semantics to get in the way. Furthermore, the TXT RR can obviously 354 just be used as a bucket in which to carry around data to be used by 355 some higher level parser, perhaps in some human readable programming 356 or markup language. Thus, for many applications, TXT RRs are the 357 "obvious" choice. Unfortunately, this conclusion, while 358 understandable, is also wrong, for several reasons. 360 The first reason why TXT RRs are not well suited to such use is 361 precisely the lack of defined semantics that make them so attractive. 362 Arguably, the TXT RR is misnamed, and should have been called the 363 Local Container record, because the lack of defined semantics means 364 that a TXT RR means precisely what the data producer says it means. 365 This is fine, so long as TXT RRs are being used by human beings or by 366 private agreement between data producer and data consumer. However, 367 it becomes a problem once one starts using them for standardized 368 protocols in which there is no prior relationship between data 369 producer and data consumer. Reason for this is that there is nothing 370 to prevent collisions with some other incompatible use of TXT RRs. 371 This is even worse than the general subtyping problem described in 372 Section 3.1, because TXT RRs don't even have a standardized selector 373 field in which to store the subtype. RFC1464 [RFC1464] tried, but it 374 was not a success. At best a definition of a subtype is reduced to 375 hoping that whatever scheme one has come up with will not accidently 376 conflict with somebody else's subtyping scheme, and that it will not 377 be possible to mis-parse one application's use of TXT RRs as data 378 intended for a different application. Any attempt to come up with a 379 standardized format within the TXT RR format would be at least 380 fifteen years too late even if it were put into effect immediately. 382 Using one of the naming modifications discussed in Section 3.2 and 383 Section 3.3 would address the subtyping problem, but each of these 384 approaches brings in new problems of its own. The prefix approach 385 (such as SRV RRs use) does not work well with wildcards, which is a 386 particular problem for mail-related applications, since MX RRs are 387 probably the most common use of DNS wildcards. The suffix approach 388 doesn't have wildcard issues, but, as noted previously, it does have 389 synchronization and update authorization issues, since it works by 390 creating a second subtree in a different part of the global DNS name 391 space. 393 The next reason why TXT RRs are not well suited to protocol use has 394 to do with the limited data space available in a DNS message. As 395 alluded to briefly in Section 3.1, typical DNS query traffic patterns 396 involve a very large number of DNS clients sending queries to a 397 relatively small number of DNS servers. Normal path MTU discovery 398 schemes do little good here, because, from the server's perspective, 399 there isn't enough repeat traffic from any one client for it to be 400 worth retaining state. UDP-based DNS is an idempotent query, whereas 401 TCP-based DNS requires the server to keep state (in the form of TCP 402 connection state, usually in the server's kernel) and roughly triples 403 the traffic load. Thus, there's a strong incentive to keep DNS 404 messages short enough to fit in a UDP datagram, preferably a UDP 405 datagram short enough not to require IP fragmentation. 407 Subtyping schemes are therefore again problematic, because they 408 produce larger RRSets than necessary, but verbose text encodings of 409 data are also wasteful, since the data they hold can usually be 410 represented more compactly in a resource record designed specifically 411 to support the application's particular data needs. If the data that 412 need to be carried are so large that there is no way to make them fit 413 comfortably into the DNS regardless of encoding, it is probably 414 better to move the data somewhere else, and just use the DNS as a 415 pointer to the data, as with NAPTR. 417 5. Conclusion and Recommendation 419 Given the problems detailed in Section 4, it is worth reexamining the 420 oft-jumped-to conclusion that specifying a new RR type is hard. 421 Historically, this was indeed the case, but recent surveys suggest 422 that support for unknown RR types [RFC3597] is now widespread, and 423 that lack of support for unknown types is mostly an issue for 424 relatively old software that would probably need to be upgraded in 425 any case as part of supporting a new application. One should also 426 remember that deployed DNS software today should support DNSSEC, and 427 software recent enough to do so will have higher chance of being able 428 to also support RFC3597. 430 Of all the issues detailed in Section 3.5, provisioning the data is 431 in some respects the most difficult. The problem here is less the 432 authoritative name servers themselves than the front-end systems used 433 to enter (and perhaps validate) the data. Hand editing does not work 434 well for maintenance of large zones, so some sort of tool is 435 necessary, and the tool may not be tightly coupled to the name server 436 implementation itself. Note, however, that this provisioning problem 437 exists to some degree with any new form of data to be stored in the 438 DNS, regardless of data format, RR type, or naming scheme. Adapting 439 front-end systems to support a new RR type may be a bit more 440 difficult than reusing an existing type, but this appears to be a 441 minor difference in degree rather than a difference in kind. 443 Given the various issues described in this note, we believe that: 444 o there is no magic solution which allows a completely painless 445 addition of new data to the DNS, but 446 o on the whole, the best solution is still to use the DNS type 447 mechanism designed for precisely this purpose, and 449 o of all the alternate solutions, the "obvious" approach of using 450 TXT RRs is almost certainly the worst. 452 6. IANA Considerations 454 This document does not require any IANA actions. 456 7. Security Considerations 458 DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly 459 necessary for any application mechanism that stores authorization 460 data in the DNS itself. DNSSEC signatures significantly increase the 461 size of the messages transported, and because of this, the DNS 462 message size issues discussed in Section 3.1 and Section 4 are more 463 serious than they might at first appear. 465 Adding new RR types (as discussed in Section 3.5) might conceivably 466 trigger bugs and other bad behavior in software which is not 467 compliant with RFC 3597 [RFC3597], but most such software is old 468 enough and insecure enough that it should be updated for other 469 reasons in any case. Basic API support for retrieving arbitrary RR 470 types has been a requirement since 1989 (see RFC 1123 [RFC1123]). 472 Any new protocol that proposes to use the DNS to store data used to 473 make authorization decisions would be well advised not only to use 474 DNSSEC but also to encourage upgrades to DNS server software recent 475 enough not to be riddled with well-known exploitable bugs. Because 476 of this, support for new RR Types will not be as hard as people might 477 think at first. 479 8. References 481 8.1 Normative References 483 [RFC1035] Mockapetris, P., "Domain names - implementation and 484 specification", STD 13, RFC 1035, November 1987. 486 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 487 Arbitrary String Attributes", RFC 1464, May 1993. 489 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 490 RFC 2535, March 1999. 492 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 493 2671, August 1999. 495 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 496 (RR) Types", RFC 3597, September 2003. 498 8.2 Informative References 500 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 501 and Support", STD 3, RFC 1123, October 1989. 503 [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER 504 Conformant Global Address Mapping (MCGAM)", RFC 2163, 505 January 1998. 507 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 508 Names", BCP 32, RFC 2606, June 1999. 510 [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain 511 Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 512 September 2000. 514 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 515 an On-line Database", RFC 3232, January 2002. 517 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 518 Resource Record (RR)", RFC 3445, December 2002. 520 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 521 Resource Identifiers (URI) Dynamic Delegation Discovery 522 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 524 [wcardclarify] 525 Halley, B. and E. Lewis, 526 "draft-ietf-dnsext-wcard-clarify-05.txt, The Role of Wild 527 Card Domains in the Domain Name System, work in progress", 528 September 2003. 530 Authors' Addresses 532 Patrik Faltstrom 533 IAB 535 EMail: paf@cisco.com 537 Rob Austein 538 IAB 540 EMail: sra@isc.org 542 Intellectual Property Statement 544 The IETF takes no position regarding the validity or scope of any 545 Intellectual Property Rights or other rights that might be claimed to 546 pertain to the implementation or use of the technology described in 547 this document or the extent to which any license under such rights 548 might or might not be available; nor does it represent that it has 549 made any independent effort to identify any such rights. Information 550 on the procedures with respect to rights in RFC documents can be 551 found in BCP 78 and BCP 79. 553 Copies of IPR disclosures made to the IETF Secretariat and any 554 assurances of licenses to be made available, or the result of an 555 attempt made to obtain a general license or permission for the use of 556 such proprietary rights by implementers or users of this 557 specification can be obtained from the IETF on-line IPR repository at 558 http://www.ietf.org/ipr. 560 The IETF invites any interested party to bring to its attention any 561 copyrights, patents or patent applications, or other proprietary 562 rights that may cover technology that may be required to implement 563 this standard. Please address the information to the IETF at 564 ietf-ipr@ietf.org. 566 Disclaimer of Validity 568 This document and the information contained herein are provided on an 569 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 570 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 571 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 572 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 573 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 576 Copyright Statement 578 Copyright (C) The Internet Society (2005). This document is subject 579 to the rights, licenses and restrictions contained in BCP 78, and 580 except as set forth therein, the authors retain all their rights. 582 Acknowledgment 584 Funding for the RFC Editor function is currently provided by the 585 Internet Society.