idnits 2.17.1 draft-iab-dns-choices-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 529), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 152 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 (October 11, 2004) is 7131 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: 'RFC2606' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 457, 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 normative reference: RFC 2916 (Obsoleted by RFC 3761) ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft R. Austein 4 Expires: April 11, 2005 IAB 5 October 11, 2004 7 Design Choices When Expanding DNS 8 draft-iab-dns-choices-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 11, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This note discusses how to extend the DNS with new data for a new 42 application. DNS extension discussion too often circulate around 43 reuse of the TXT record. This document lists different mechanisms to 44 accomplish the extension to DNS, and comes to the conclusion use of a 45 new RR Type is the best solution. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 4 52 3.1 Place selectors inside the RDATA . . . . . . . . . . . . . 4 53 3.2 Add a prefix to the owner name . . . . . . . . . . . . . . 4 54 3.3 Add a suffix to the owner name . . . . . . . . . . . . . . 5 55 3.4 Add a new Class . . . . . . . . . . . . . . . . . . . . . 5 56 3.5 Add a new Resource Record Type . . . . . . . . . . . . . . 6 57 4. Conclusion (why adding a new RR type is the answer) . . . . . 7 58 5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 9 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 63 Intellectual Property and Copyright Statements . . . . . . . . 12 65 1. Introduction 67 The DNS stores multiple categories of data. The two most commonly 68 used categories are infrastructure data for the DNS system itself (NS 69 and SOA records) and data which have to do with mappings between 70 domain names and IP addresses (A, AAAA and PTR). There are other 71 categories as well, some of which are tied to specific applications 72 like email (MX), while others are generic record types used to convey 73 information for multiple protocols (SRV, NAPTR). 75 When storing data in the DNS for a new application, the data are 76 usually tied to a "normal" domain name, so the application can query 77 for the data it wants, while minimizing the impact on existing 78 applications. 80 Historically, extension of DNS to store data for applications tied to 81 a domain name has been done in different ways at different times. MX 82 records were created as a new resource record type specifically 83 designed to support electronic mail. SRV records are a generic type 84 which use a prefixing scheme in combination with a base domain name. 85 Records associated with ENUM use a suffixing scheme. NAPTR records 86 add selection data inside the RDATA. It is clear the way of adding 87 new data to the DNS has been inconsistent, and the purpose of this 88 document is to attempt to clarify the implications of each of these 89 methods, both for the applications that use them and for the rest of 90 the DNS system. 92 2. Background 94 See RFC 2929 [RFC2929] for a brief summary of DNS query structure. 95 Readers interested in the full story should start with the base DNS 96 specification in RFC 1035 [RFC1035], and continue with the various 97 documents which update, clarify, and extend the base specification. 99 When composing a query into the DNS system, the parameters actually 100 used by the protocol are a triple: a DNS name, a DNS class, and a DNS 101 record type. Every resource record (RR) matching a particular name, 102 type and class is said to belong to the same resource record set 103 (RRset), and the whole RRset is always returned to the client which 104 queries for it. Splitting an RRset is a protocol violation, because 105 it results in coherency problems with the DNS caching mechanism. 107 Note however that this requirement has nothing to do with the MTU 108 size and choice of UDP or TCP as the transport protocol. The whole 109 RRset always has to be returned, and if it doesn't fit in the MTU in 110 UDP, TCP has to be used to not break this RRset atomic requirement. 112 3. Extension mechanisms 114 The DNS protocol is intended to be extensible to support new kinds of 115 data. This section examines the various ways in which this sort of 116 extension can be accomplished. 118 3.1 Place selectors inside the RDATA 120 For a given query name, one might choose to have a single RRset (all 121 sharing the same name, type, and class) shared by multiple 122 applications, and have the different applications use selectors 123 within the RR data (RDATA) to determine which records are intended 124 for which applications. This sort of selector mechanism is usually 125 referred to "subtyping", because it is in effect creating an 126 additional type subsystem within a single DNS RR type. 128 Examples of subtyping include NAPTR RRs (see RFC 2916 [RFC2916]) and 129 the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was 130 updated by RFC 3445 [RFC3445]). 132 All DNS subtyping schemes share a common weakness: With subtyping 133 schemes it is impossible for a client to query for just the data it 134 wants. Instead, the client must fetch the entire RRset, then select 135 the RRs in which it is interested. Furthermore, since DNSSEC 136 signatures operate on complete RRsets, the entire RRset must be 137 re-signed if any RR in it changes. As a result, each application 138 that uses a subtyped RR incurs higher overhead than any of the 139 applications would have incurred had they not been using a subtyping 140 scheme. The fact the RRset is always passed around as an indivisible 141 unit increases the risk the RRset will not fit in a UDP packet, which 142 in turn increases the risk that the client will have to retry the 143 query with TCP, which substantially increases the load on the name 144 server. More precisely: Having one query fail over to TCP is not a 145 big deal, but since the typical ratio of clients to servers in the 146 DNS system is very high, having a substantial number of DNS messages 147 fail over to TCP it will cause the relevant name servers to be 148 overloaded by TCP overhead. 150 The final result of using a subtyping scheme might be that the zone 151 administrator has to choose which of the services tied to one domain 152 name can actually be used, because not all of them can be announced 153 at the same time. 155 3.2 Add a prefix to the owner name 157 By adding an application-specific prefix to a domain name, we will 158 get different name/class/type triples, and therefore different 159 RRsets. The problem with adding prefixes has to do with wildcards, 160 especially if one has records like 162 *.example.com. IN MX 1 mail.example.com. 164 and one wants records tied to those names. Suppose one creates the 165 prefix "_mail". One would then have to say something like 167 _mail.*.example.com. IN X-FOO A B C D 169 but DNS wildcards only work with the "*" as the leftmost token in the 170 domain name. 172 Even when a specific prefix is chosen, the data will still have to be 173 stored in some RR type. This RR type can either be a "kitchen-sink 174 record" or a new RR type. This implies that some other mechanism has 175 to be applied as well, with implications detailed in other parts of 176 this note (see also draft-ietf-dnsext-wcard-clarify [wcardclarify] 177 regarding use of wildcards and DNS). 179 3.3 Add a suffix to the owner name 181 Adding a suffix to a domain name changes the name/class/type triple, 182 and therefore the RRset. The query name can be set to exactly the 183 data one wants, and the size of the RRset is minimized. The problem 184 with adding a suffix is that it creates a parallel tree within the IN 185 class. There will be no technical mechanism to ensure that the 186 delegation for "example.com" and "example.com._bar" are made to the 187 same organization. Furthermore, data associated with a single entity 188 will now be stored in two different zones, such as "example.com" and 189 "example.com._bar", which, depending on who controls "_bar", can 190 create new synchronization and update authorization issues. 192 Even when using a different name, the data will still have to be 193 stored in some RR type. This RR type can either be a "kitchen-sink 194 record" or a new RR type. This implies that some other mechanism has 195 to be applied as well, with implications detailed in other parts of 196 this note. 198 In RFC 2163 [RFC2163] an infix token is inserted directly below the 199 TLD, but the result is the same as adding a suffix to the owner name 200 (and because of that creation of a new TLD). 202 3.4 Add a new Class 204 DNS zones are class-specific, in the sense that all the records in 205 that zone share the same class as the zone's SOA record, and the 206 existence of a zone in one class does not guarantee the existence of 207 the zone in any other class. In practice, only the IN class has ever 208 seen widespread deployment, and the administrative overhead of 209 deploying an additional class would almost certainly be prohibitive. 211 Nevertheless, one could in theory use the DNS class mechanism to 212 distinguish between different kinds of data. However, since the DNS 213 delegation tree (represented by NS RRs) is itself tied to a specific 214 class, attempting to resolve a query by crossing a class boundary may 215 produce unexpected results, because there is no guarantee that the 216 name servers for the zone in the new class will be the same as the 217 name servers in the IN class. The MIT Hesiod system used a scheme 218 like this for storing data in the HS class, but only on a very small 219 scale (within a single institution), and with an administrative fiat 220 requiring that the delegation trees for the IN and HS trees be 221 identical. 223 Even when using a different class, the data will still have to be 224 stored in some RR type or another. This RR type can either be a 225 "kitchen-sink record" or a new RR type. This implies that some other 226 mechanism has to be applied as well, with implications detailed in 227 other parts of this note. 229 3.5 Add a new Resource Record Type 231 When adding a new Resource Record type to the system, entities in 232 four different roles have to be able to handle the new type: 234 1. There must be a way to insert the new resource records into the 235 zone of the Primary Master name server. For some server 236 implementations, the user interface only accepts record types 237 which it understands (perhaps so that the implementation can 238 attempt to validate the data). Other implementations allow the 239 zone administrator to enter an integer for the resource record 240 type code and the RDATA in Base64 or hexadecimal encoding (or 241 even as raw data). RFC 3597 [RFC3597] specifies a standard 242 generic encoding for this purpose. 243 2. A slave authoritative name server must be able to do a zone 244 transfer, receive the data from some other authoritative name 245 server, and serve data from the zone even though the zone 246 includes records of unknown types. Historically, some 247 implementations have had problems parsing stored copies of the 248 zone file after restarting, but those problems have not been seen 249 for a few years. 250 3. A full service resolver will cache the records which are 251 responses to queries. As mentioned in RFC 3597 [RFC3597],there 252 are various pitfalls where a recursive name server might end up 253 having problems. 254 4. The application must be able to get the record with a new 255 resource record type. The application itself may understand the 256 RDATA, but the resolver library might not. Support for a generic 257 interface for retrieving arbitrary DNS RR types has been a 258 requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2). 259 Some stub resolver library implementations neglect to provide 260 this functionality and cannot handle unknown RR types, but 261 implementation of a new stub resolver library is not particularly 262 difficult, and open source libraries that already provide this 263 functionality are available. 265 4. Conclusion (why adding a new RR type is the answer) 267 By now, the astute reader will be wondering about how to use the 268 issues presented so far. We will now attempt to clear up the 269 reader's confusion by following the thought processes of a typical 270 application designer who wishes to store stuff in the DNS, showing 271 how such a designer almost inevitably hits upon the idea of just 272 using TXT RR, and why this is a bad thing, and instead why a new RR 273 type is to be allocated. 275 A typical application designer is not interested in the DNS for its 276 own sake, but rather as a distributed database in which application 277 data can be stored. As a result, the designer of a new application 278 is usually looking for the easiest way to add whatever new data the 279 application needs to the DNS in a way that naturally associates the 280 data with a DNS name. 282 As explained in Section 3.4, using the DNS class system as an 283 extension mechanism is not really an option, and in fact most users 284 of the system don't even realize that the mechanism exists. As a 285 practical matter, therefore any extension is likely to be within the 286 IN class. 288 Adding a new RR type is the technically correct answer from the DNS 289 protocol standpoint (more on this below), doing so requires some DNS 290 expertise, due to the issues listed in Section 3.5. As a result, 291 this option is usually considered too hard. 293 The application designer is thus left with the prospect of reusing 294 some existing DNS type within the IN class, but when the designer 295 looks at the existing types, almost all of them have well-defined 296 semantics, none of which quite match the needs of the new 297 application. This has not completely prevented proposals to reuse 298 existing RR types in ways incompatible with their defined semantics, 299 but it does tend to steer application designers away from this 300 approach. 302 RR Type 40 was registered for the SINK record type. This RR Type was 303 discussed in the DNSIND working group of the IETF, and it was decided 304 at the 46th IETF to not move the I-D forward to become an RFC. 305 Reason was the risk for large RR sets and the ability for application 306 creators to use the SINK RR Type instead of registering a new RR 307 Type. 309 Eliminating all of the above leaves the TXT RR type in the IN class. 310 The TXT RDATA format is free form text, and there are no existing 311 semantics to get in the way. Furthermore, the TXT RR can obviously 312 just be used as a bucket in which to carry around data to be used by 313 some higher level parser, perhaps in some human readable programming 314 or markup language. Thus, for many applications, TXT RRs are the 315 "obvious" choice. Unfortunately, this conclusion, while 316 understandable, is also wrong, for several reasons. 318 The first reason why TXT RRs are not well suited to such use is 319 precisely the lack of defined semantics that make them so attractive. 320 Arguably, the TXT RR is misnamed, and should have been called the 321 Local Container record, because the lack of defined semantics means 322 that a TXT RR means precisely what the data producer says it means. 323 This is fine, so long as TXT RRs are being used by human beings or by 324 private agreement between data producer and data consumer. However, 325 it becomes a problem once one starts using them for standardized 326 protocols in which there is no prior relationship between data 327 producer and data consumer. Reason for this is that there is nothing 328 to prevent collisions with some other incompatible use of TXT RRs. 329 This is even worse than the general subtyping problem described in 330 Section 3.1, because TXT RRs don't even have a standardized selector 331 field in which to store the subtype. RFC1464 [RFC1464] tried, but it 332 was not a success. At best a definition of a subtype is reduced to 333 hoping that whatever scheme one has come up with will not accidently 334 conflict with somebody else's subtyping scheme, and that it will not 335 be possible to mis-parse one application's use of TXT RRs as data 336 intended for a different application. Any attempt to come up with a 337 standardized format within the TXT RR format would be at least 338 fifteen years too late even if it were put into effect immediately. 340 Using one of the naming modifications discussed in Section 3.2 and 341 Section 3.3 would address the subtyping problem, but each of these 342 approaches brings in new problems of its own. The prefix approach 343 (such as SRV RRs use) does not work well with wildcards, which is a 344 particular problem for mail-related applications, since MX RRs are 345 probably the most common use of DNS wildcards. The suffix approach 346 doesn't have wildcard issues, but, as noted previously, it does have 347 synchronization and update authorization issues, since it works by 348 creating a second subtree in a different part of the global DNS name 349 space. 351 The next reason why TXT RRs are not well suited to protocol use has 352 to do with the limited data space available in a DNS message. As 353 alluded to briefly in Section 3.1, typical DNS query traffic patterns 354 involve a very large number of DNS clients sending queries to a 355 relatively small number of DNS servers. Normal path MTU discovery 356 schemes do little good here, because, from the server's perspective, 357 there isn't enough repeat traffic from any one client for it to be 358 worth retaining state. UDP-based DNS is an idempotent query, whereas 359 TCP-based DNS requires the server to keep state (in the form of TCP 360 connection state, usually in the server's kernel) and roughly triples 361 the traffic load. Thus, there's a strong incentive to keep DNS 362 messages short enough to fit in a UDP datagram, preferably a UDP 363 datagram short enough not to require IP fragmentation. 365 Subtyping schemes are therefore again problematic, because they 366 produce larger RRsets than necessary, but verbose text encodings of 367 data are also wasteful, since the data they hold can usually be 368 represented more compactly in a resource record designed specifically 369 to support the application's particular data needs. If the data that 370 need to be carried are so large that there is no way to make them fit 371 comfortably into the DNS regardless of encoding, it is probably 372 better to move the data somewhere else, and just use the DNS as a 373 pointer to the data, as with NAPTR. 375 5. Conclusion and Recommendation 377 Given the problems detailed in Section 4, it is worth reexamining the 378 oft-jumped-to conclusion that specifying a new RR type is hard. 379 Historically, this was indeed the case, but recent surveys suggest 380 that support for unknown RR types [RFC3597] is now widespread, and 381 that lack of support for unknown types is mostly an issue for 382 relatively old software that would probably need to be upgraded in 383 any case as part of supporting a new application. One should also 384 remember that deployed DNS software today should support DNSSEC, and 385 software recent enough to do so will have higher chance of being able 386 to also support RFC3597. 388 Of all the issues detailed in Section 3.5, provisioning the data is 389 in some respects the most difficult. The problem here is less the 390 authoritative name servers themselves than the front-end systems used 391 to enter (and perhaps validate) the data. Hand editing does not work 392 well for maintenance of large zones, so some sort of tool is 393 necessary, and the tool may not be tightly coupled to the name server 394 implementation itself. Note, however, that this provisioning problem 395 exists to some degree with any new form of data to be stored in the 396 DNS, regardless of data format, RR type, or naming scheme. Adapting 397 front-end systems to support a new RR type may be a bit more 398 difficult than reusing an existing type, but this appears to be a 399 minor difference in degree rather than a difference in kind. 401 Given the various issues described in this note, we believe that: 402 o there is no magic solution which allows a completely painless 403 addition of new data to the DNS, but 404 o on the whole, the best solution is still to use the DNS type 405 mechanism designed for precisely this purpose, and 406 o of all the alternate solutions, the "obvious" approach of using 407 TXT RRs is almost certainly the worst. 409 6. IANA Considerations 411 This document does not require any IANA actions. 413 7. Security Considerations 415 DNS RRsets can be signed using DNSSEC. DNSSEC is almost certainly 416 necessary for any application mechanism that stores authorization 417 data in the DNS itself. DNSSEC signatures significantly increase the 418 size of the messages transported, and because of this, the DNS 419 message size issues discussed in Section 3.1 and Section 4 are more 420 serious than they might at first appear. 422 Adding new RR types (as discussed in Section 3.5) might conceivably 423 trigger bugs and other bad behavior in software which is not 424 compliant with RFC 3597 [RFC3597], but most such software is old 425 enough and insecure enough that it should be updated for other 426 reasons in any case. Basic API support for retrieving arbitrary RR 427 types has been a requirement since 1989 (see RFC 1123 [RFC1123]). 429 Any new protocol that proposes to use the DNS to store data used to 430 make authorization decisions would be well advised not only to use 431 DNSSEC but also to encourage upgrades to DNS server software recent 432 enough not to be riddled with well-known exploitable bugs. Because 433 of this, support for new RR Types will not be as hard as people might 434 think at first. 436 8 References 438 [RFC1035] Mockapetris, P., "Domain names - implementation and 439 specification", STD 13, RFC 1035, November 1987. 441 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 442 and Support", STD 3, RFC 1123, October 1989. 444 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 445 Arbitrary String Attributes", RFC 1464, May 1993. 447 [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER 448 Conformant Global Address Mapping (MCGAM)", RFC 2163, 449 January 1998. 451 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 452 RFC 2535, March 1999. 454 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 455 Names", BCP 32, RFC 2606, June 1999. 457 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 458 2671, August 1999. 460 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 461 2000. 463 [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain 464 Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 465 September 2000. 467 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 468 Resource Record (RR)", RFC 3445, December 2002. 470 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 471 (RR) Types", RFC 3597, September 2003. 473 [wcardclarify] 474 Halley, B. and E. Lewis, 475 "draft-ietf-dnsext-wcard-clarify-02.txt, Clarifying the 476 Role of Wild Card Domains in the Domain Name System, work 477 in progress", September 2003. 479 Authors' Addresses 481 Patrik Faltstrom 482 IAB 484 EMail: paf@cisco.com 486 Rob Austein 487 IAB 489 EMail: sra@isc.org 491 Intellectual Property Statement 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Disclaimer of Validity 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 520 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 521 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 522 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Copyright Statement 527 Copyright (C) The Internet Society (2004). This document is subject 528 to the rights, licenses and restrictions contained in BCP 78, and 529 except as set forth therein, the authors retain all their rights. 531 Acknowledgment 533 Funding for the RFC Editor function is currently provided by the 534 Internet Society.