dnsextDNSEXT Working Group B. Halley Internet Draft NominumE. Lewis INTERNET DRAFT NeuStar Expiration Date: MarchApril 2005 October 2004 E. Lewis ARIN September 2003Clarifying the Role of Wild Card Domains in the Domain Name System draft-ietf-dnsext-wcard-clarify-02.txtdraft-ietf-dnsext-wcard-clarify-03.txt Status of this Memo This documentBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is an Internet-Draftaware have been or will be disclosed, and is subject to all provisionsany of which he or she becomes aware will be disclosed, in accordance with Section 106 of RFC2026.RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view thehttp://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 11, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and not to significantly alter neitherthe spirit noror intent of that definition. Table of Contents Abstract ................................................ 11 Introduction ............................................ 2 1.1 Document Limits ......................................... 3 1.2 Existence ............................................... 4 1.3 An Example .............................................. 4 1.4 Empty Non-terminals ..................................... 5 1.5 Terminology ............................................. 6 2 Defining the Wild Card Domain Name ...................... 7 3 Defining Existence ...................................... 8 4 Impact of a Wild CardIn a Query or in RDATA ............ 8 5 Impact of a Wild Card Domain On a Response .............. 9 6 Considerations with Special Types ....................... 12 6.1 SOA RR's at a Wild Card Domain Name ..................... 12 6.2 NS RR's at a Wild Card Domain Name ...................... 12 6.3 CNAME RR's at a Wild Card Domain Name ................... 13 6.4 DNAME RR's at a Wild Card Domain Name ................... 13 7 Security Considerations ................................. 14 8 References .............................................. 14 9 Others Contributing to This Document .................... 14 10 Editors ................................................. 15 Appendix A: Subdomains of Wild Card Domain Names ........ 16 Full Copyright Statement ................................ 18 Acknowledgement ......................................... 18 1. Introduction The first section of this document will give a crisp overview of what is begin defined, as well asRFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the motivation rewordingsynthesis of ananswers from special records called wildcards. The original definitions are incomplete. This document clarifies and making a change to bringdescribes the specification in line with implementations. Examples are includedwildcard synthesis by adding to help orientthe reader. Wild card domain namesdiscussion and making limited modifications. Modifications are defined in Section 4.3.3. of RFC 1034 as "instructions for synthesizing RRs." [RFC1034]. The meaning of this ismade only where necessary to close inconsistencies that a specific, special domain name is usedhave led to construct responses in instancesinteroperability issues. 1.1 Motivation Over time many implementations have diverged in whichdifferent ways from the query nameoriginal definition, or at least what had been intended. Although there is not otherwise represented in a zone. A wild card domain name has a specific range of influence on query names (QNAMEs) withinclearly a given class, which is rooted at the domain name containingneed to clarify the wild card label, and is limited by explicit entries, zone cuts and empty non-terminal domains (see section 1.3original documents in light of this document). Note that a wild card domain name has no special impact onthis, the searchimpetus for a query type (QTYPE). If a domain name is found that matchesthis document lay in the QNAME (exact or a wild card) butengineering of the QTYPE is not found at that point,DNS security extensions [RFC TBD]. With an unclear definition of wildcards the proper response is that theredesign of authenticated denial became entangled. Although this document is no data available. The search does not continue on to seek other wild cards that might matchmotivated by DNSSEC and the QTYPE. To illustrate,need to have a wild card owning an MX RR does not 'cover' other names in the zone that own an A RR. There are certain special case RR types that will be singled outseparate document passed for discussion,the SOA RR, NS RR, CNAME RR, and DNAME RR. Whysake of DNSSEC, other motivations have risen. The renewed understanding of wildcards gained is thisworthy of being documented. 1.2 The Original Definition This document needed? Empirical evidence suggests that the words inis intended to not make changes. To reinforce this, sections of RFC 1034 are not clear enough. There exist a number of implementations that have strayed (each differently) from that definition. There also exists a misconceptionrepeated verbatim for convenience of operators thatthe wild card can be usedreader, to addhelp in comparison of old and new text. There are a specific RR type to all names, such as the MX RR example cited above.few passages which are changed. This document is also needed as input to effortsmay seem to extend DNS, such ascontradict the DNS Security Extensions [RFC 2535]. Lackgoal of a clear base specification has proven to result in extension documents that have unpredictable consequences. (This is true in general,not just for DNS.) Another reason this clarification is needed is to answer questions regarding authenticated denialchanging the original specification, but the changes herein are required because of existence, a service introducedinconsistencies with the wording in RFC 1034. The beginning of the DNS Security Extensions [RFC 2535]. Priordiscussion ought to start with the work leading up to this document, it had been feared that a large numberdefinition of proof records (NXTs) might be neededthe term "wildcard" as it appears in each reply because ofRFC 1034, section 4.3.3. # In the unknown number of potential wild card domains that were thoughtprevious algorithm, special treatment was given to RRs with owner # names starting with the label "*". Such RRs are called wildcards. # Wildcard RRs can be applicable. One outcomethought of this fearas instructions for synthesizing RRs. # When the appropriate conditions are met, the name server creates RRs # with an owner name equal to the query name and contents taken from the # wildcard RRs. This passage appears after the algorithm in which they are used is a now discontinued document solving a problem thatpresented. The terminology is now knownnot to exist. I.e., this clarification hasconsistent, the impact of defending against unwarranted protocol surgery. Itword "wildcard" is not "yet another" effortclearly defined to just rewrite the early specifications forbe a resource record. In the sake of purity. Althoughnext sentence the effortterm is shifted to definebe an adjective, the DNS Security Extensions has prompted this document,first step on the clarifications herein relatepath to basic DNS only. No DNS Security Extensions considerations are mentioned inoverloading the document. 1.1. Document Limits This document limits itselfterm. Wildcard has also been used to reinforcingrefer to domain names that begin with a "*". 1.3 The Clarification The clarification effort can be divided into three sections. One is the conceptsuse of new terminology to better describe wildcards. Changes to words in RFC 1034. In the effort to do this, a few issues1034 that have been discussed that change parts of what is in RFC 1034. The discussions have been held within the DNS Extensions Working Group. Briefly, the issues raised include: - The lackresulted by discovering conflicting concepts are presented. Descriptions of clarityspecial type records in the definitioncontext of domain name existencebeing wildcards is discussed. 1.3.1 New Terms The term "wildcard" has become so overloaded it is virtually useless as a description. A few new terms will be introduced to be more descriptive. The new terms that will be introduced are: Asterisk Label - Implications ofa wild card domain name owning anylabel consisting of the following resource record sets: DNAME [RFC 2672], CNAME, NS,an asterisk ("*") and SOAno other characters. Wild Card Domain Name - Whether RFC 1034 meant to allow special processing of CNAME RR's owned by wild card domain names 1.2. Existence The notion thata domain name 'exists' will arise numerous timeswhose least significant label (first when reading left to right) is an asterisk label. Other labels might also be asterisk labels. Source of Synthesis - a Wild Card Domain Name when it is consulted in this discussion. RFC 1034 raisesthe issuefinal paragraph of existencestep 3, part c of RFC 1034's 4.3.2 algorithm. Closest Encloser - in a numberRFC 1034's 4.3.2 algorithm, the name at which the last match was possible in step 3, part c. This is the longest sequence of places, usuallyexactly matching labels from the root downward in reference to non-existenceboth the sought name (QNAME) and oftenin reference to processing involving wild card domain names. RFC 1034 contains algorithms that describe how domain names impactthe preparation of an answerzone being examined. Label Match - two labels are equivalent if the label type and does define wild cards as a means of synthesizing answers. Because of this a discussion on wild card domain names has to start withlabel length are the issue of existence. To help clarifysame bit sequence and if the topic of wild cards, a positive definition of existence is needed. Complicating matters, though,name is the realization that existencelabel is relative. To an authoritative server, a domain name exists ifequivalent bit wise after down casing all of the domain name playsASCII characters. [Ed note: do we still call them ASCII?] These terms will be more fully described as needed later. These terms will be used to describe a role followingfew changes to the algorithmswords in RFC 1034. A summary of preparing a response. To a resolver, a domain name exists ifthe changes appear next and will be fully covered in later sections. 1.3.2 Changed Text The definition of "existence" is changed, superficially, to exclude empty domains that have no subdomains with resource records. This change will not be apparent to implementations, it is needed to make descriptions more concise. In RFC 1034, there is any data available correspondingtext that seems to the name. The difference between thebar having two Asterisk Labels in a Wild Card Domain Name. There is no further discussion, no prescribed error handling, nor enforcement described. In this document, the synthesisuse of records accordingsuch names will be discouraged, but implementations will have to a wild card. For the purposes of this document,account for the pointpossibility of viewsuch a name's use. The actions when a Source of Synthesis owns a CNAME RR are changed to mirror the actions if an authoritative server is adopted. A domainexact match name owns a CNAME RR. This is saidan addition to exist if it plays a rolethe words in RFC 1034, section 4.3.2, step 3, part c. 1.3.3 Considerations with Special Types This clarification will describe in some detail the executionsemantics of wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's, wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards. Understanding these types in the context of wildcards has been clouded because these types incur special processing if they are the result of an exact match. By the algorithmsdefinition in RFC 1034. 1.3. An Example For example, consider this wild card domain name: *.example. Any query name under example. is a candidate to1034, there can be matched (answered) by this wild card, i.e., to have an response returnedno empty, non-terminal "wildcards", but in the algorithm, it is possible that an empty non-terminal is synthesized fromsought as the wild card's RR sets. Although any name ispotential owner of a candidate, not all queries will match. To further illustrate this, consider this zone: $ORIGIN example. @ IN SOA NS NS * TXT "this"wildcard." This is a wild card" MX 10 mailhost.example. host1 A 10.0.0.1 _ssh._tcp.host1 SRV _ssh._tcp.host2 SRV subdel NS The following queries would be synthesized from the wild card: QNAME=host3.example. QTYPE=MX, QCLASS=INone example of why the answer will be a "host3.example. IN MX ..." QNAME=host3.example. QTYPE=A, QCLASS=INordering of the answer will reflect "no error, but no data" because therediscussion in RFC 1034 is no A RR set at '*'confusing. 1.4 Standards Terminology The following queries would not be synthesized from the wild card: QNAME=host1.example., QTYPE=MX, QCLASS=IN because host1.example. exists QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN because _tcp.host1.example. exists (without data) QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN because host2.example. exists (without data) QNAME=host.subdel.example., QTYPE=A, QCLASS=IN because subdel.example. existskey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and is a zone cut To the server, the following domains"OPTIONAL" in this document are consideredto existbe interpreted as described in the zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2, and subdel. To a resolver, many more domains appeardocument entitled "Key words for use in RFCs to exist viaIndicate Requirement Levels." [RFC2119] Quotations of RFC 1034 (as has already been done once above) are denoted by a '#' in the synthesisleftmost column. 2 "Wildcard" The context of the wild card. 1.4. Empty Non-terminals Empty non-terminals are domain names that own no data but have subdomains. This is defined in section 3.1 of RFC 1034: # The domainwildcard concept involves the algorithm by which a name space isserver prepares a tree structure. Each noderesponse (in RFC 1034's section 4.3.2) and leaf onthe # tree correspondsway in which a resource record (set) is identified as being a source of synthetic data (section 4.3.3). Tackling the latter first, there are two objectives in defining a means to identify a resource record set (which may be empty). The domain # system makes no distinctions between the usesas a source of synthesis. First is the interior nodes and # leaves, and this memo uses the term "node"desire to refermaintain all DNS data in a consistent manner. Avoiding the need for implementations to both.have many internal data structures is a good thing. Not that this means limiting quantity, but rather types of data. The parenthesized "which may be empty" specifiessecond objective impacts interoperability, that empty non- terminalsis a master server of one implementation has to be able to send the synthesis instructions to the slaves. Although there are explicitly recognized. Accordingalternatives to the definitionuse of existencezone transfers via port 53, a truly interoperable record synthesis approach has to be able to insert the synthesis instructions into a zone transfer. The objectives in this document, empty non-terminals do exist atdescribing the server. Carefully readingsynthesis of records in the above paragraph can lead to an interpretation that all possible domains exist - upcontext of the name server algorithm include knowing when to employ the suggested limitprocess of 255 octets for a domain name [RFC 1035]. For example, www.example. may have an A RR,synthesis and as far as is practically concerned,how the synthesis is carried out. 2.1 Identifying a leafwildcard To provide a more accurate description of the domain tree. But"wildcards", the definition can be takenhas to mean that sub.www.example. also exists, albeitstart with no data. By extension, all possible domains exist, froma discussion of the root on down. As RFC 1034 also defines "an authoritative name error indicatingdomain names that appear as owners. 2.1.1 Wild Card Domain Name and Asterisk Label A "Wild Card Domain Name" is defined by having its initial label be: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) The first octet is the name does not exist" in section 4.3.1, thisnormal label type and length for a 1 octet long label, the second octet is notthe intent ofASCII representation [RFC 20] for the original document. RFC1034's wording'*' character. In RFC 1034, ASCII encoding is assumed to be clarified by addingthe following paragraph:character encoding. A node is considered to have an impact on the algorithmsdescriptive name of 4.3.2 if it isa leaf node with any resource sets orlabel equaling that value is an interior node, with or without a"Asterisk Label." RFC 1034's definition of wildcard would be "a resource set, that hasrecord owned by a subdomain thatWild Card Domain Name." This is a leaf node with amentioned to help maintain some orientation between this clarification and RFC 1034. Keep in mind, that in "Clarifications to the DNS Specification" [RFC 2181] the name of the basic unit of DNS data became the resource set. A QNAMErecord set (RRSet) and QCLASS matching an existing node never resultsnot the resource record. 2.1.2 Variations on Wild Card Domain Names RFC 1034 and RFC 1035 do not explicitly mention the case in which a response return code of authoritativedomain name error.might be something like "the*.example.com." The terminology in the above paragraphinterpretation is chosen to remain as close tothat this domain name in the original document. The term "with" isa alternate formzone would only match queries for "owning" in this case, hence "a leaf node owning resources sets, or an interior node, owning or"the*.example.com" and not owninghave any resource set, that has a leaf node owning a resource setother role. An asterisk ('*') occurring other than as the sole character in a subdomain,"label is the proper interpretationsimply a character forming part of the middle sentence. Aslabel and has no special meaning. This is not an aside,Asterisk Label, simply a label an "authoritative name error" has been called NXDOMAINasterisk in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAINit. The same is true for "**.example.com." and "*the.example.com." [Ed note: the mnemonic assignedabove paragraph reads too strong. The intent ought to be that such an error by at least one implementationnames do not fall under the rules of DNS. As this mnemonicwildcards. The intent is specificnot to implementations, itbar any future attempts to define other forms of synthesis - nor is avoided inthe remainder of this document. 1.5. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document areintent to be interpreted as described in the document entitled "Key words for useencourage them.] The interpretation of a wild card domain specification which is not a leaf domain is not clearly defined in RFCsRFC 1034. E.g., sub.*.example., is not discussed, not barred. In wanting to Indicate Requirement Levels." [RFC2119] Requirements are denoted by paragraphs that begin with withminimize changes from the following convention: 'R'<sect>.<count>. Quotations of RFC 1034 (as has already been done once above)original specification, such names are denotedpermitted. Although "sub.*.example." is not a Wild Card Domain Name, "*.example." is. RRSets used to synthesize records can be owned by a '#' in the leftmost column. 2. Defining theWild Card Domain Name A wild card domain name is defined by having the initial label be: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) This defines domain names that may play a role in being a wild card,that is, being a source for synthesized answers.has subdomains. 2.1.3 Non-terminal Wild Card Domain names conforming to this definition that appear in queries and RDATA sections do not have any special role. These cases will be described in more detail inNames In section 4.3.3, the following sections. R2.1 A domain name thatis to be interpreted as a wild card MUST begin with a label of '0000 0001 0010 1010' in binary.stated: # .......................... The first octetowner name of the wildcard RRs is of # the normal label type and length forform "*.<anydomain>", where <anydomain> is any domain name. # <anydomain> should not contain other * labels...................... This covers names like "*.foo.*.example." The pre-RFC2119 wording uses "should not" which has an ambiguous meaning. The specification does not proscribe actions upon seeing such a 1 octet long label,name, such as whether or not a zone containing the second octet isname should fail to be served. What if a dynamic update (RFC2136) requested to add the ASCII representation [RFC 20] forname to the '*' character. In RFC 1034, ASCII encodingzone? The failure semantics are not defined. The recommendation is assumedthat implementations ought to be the character encoding. Inanticipate the master file formats usedappearance of such names but generally discourage their use in RFCs, a "*"operations. No standards statement, such as "MAY NOT" or "SHOULD NOT" is made here. The interpretation of this is, when seeking a legal representationWild Card Domain Name for the wild card label. Even ifpurposes of record synthesis, an implementation ought not to check the "*" is escaped, itdomain name for subdomains. It is still interpreted as the wild card when itpossible that a Wild Card Domain Name is an empty non-terminal. (See the only character inupcoming sections on empty non-terminals.) In this case, the label. R2.2 A server MUST treat a wild card domain namelookup will terminate as the basis of synthesized answers regardless ofwould any "escape" sequencesempty non-terminal match. 2.2 Existence Rules The notion that a domain name 'exists' arises numerous times in discussions about the input format.wildcard concept. RFC 1034 and RFC 1035 ignoreraises the caseissue of existence in whicha domain name might be "the*.example.com." The interpretation isnumber of places, usually in reference to non-existence and in reference to processing involving wildcards. RFC 1034 contains algorithms that thisdescribe how domain name in a zone would only match queries for "the*.example.com"names impact the preparation of an answer and not have any other role. Note: By virtuedoes define wildcards as a means of synthesizing answers. Because of this definition, a wild card domain name may have a subdomain. The subdomain (or sub-subdomain) itself may also bea wild card. E.g., *.*.example. is a wild card, so is *.sub.*.example. Morediscussion on this is given in Appendix A. 3. Defining Existence As described inwildcards needs to cover a definition of existence. To help clarify the Introduction,topic of wild cards, a precisepositive definition of existence is needed. R3.1 AnComplicating matters, though, is the realization that existence is relative. To an authoritative server MUST treatserver, a domain name as existing duringexists if the execution ofdomain name plays a role following the algorithms in RFC 1034 when theof preparing a response. To a resolver, a domain name conformsexists if there is any data available corresponding to the following definition.name. The difference between the two is the synthesis of records according to a wildcard. For the purposes of this document, the point of view of an authoritative server is more interesting. A domain name is definedsaid to exist if the domain name owns data and/or has a subdomain that exists. Note that atit plays a zone boundary,role in the domain name owns data, includingexecution of the NS RR set. At the delegating server, the NS RR set is not authoritative, but that is of no consequence here. The domain name owns data, therefore, it exists. R3.2 An authoritative server MUST treat a domain name that has neither a resource record set nor an existing subdomain as non- existent when executing the algorithmalgorithms in section 4.3.2. ofRFC 1034. 2.2.1. An Example To illustrate what is meant by existence consider this complete zone: $ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "this is a wild card" *.example. 3600 MX 10 host1.example. host1.example. 3600 A note on terminology.184.108.40.206 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net. A domain transcends zones, i.e., all DNS data is inlook at the rootdomain but segmented into zones of control. In this document, there are references to a "domain name"names in the context of existing "in a zone." In this usage,a domain nametree structure is helpful: | -------------example------------ / / \ \ / / \ \ / / \ \ * host1 host2 subdel | | | | _tcp _tcp | | | | _ssh _ssh The following queries would be synthesized from the root of a domain, notwild card: QNAME=host3.example. QTYPE=MX, QCLASS=IN the entire domain. The domain's root point is said to "exist inanswer will be a zone" if"host3.example. IN MX ..." QNAME=host3.example. QTYPE=A, QCLASS=IN the zoneanswer will reflect "no error, but no data" because there is authoritative for the name.no A RR sets existing in a domain need not be owned byset at '*.example.' QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN the domain's root domain name,answer will be "foo.bar.example. IN TXT ..." because bar.example. does not exist, but are owned by other domain names in the domain. 4. Impact of a Wild Card In a Query or in RDATA When a wild card domain name appears in a question, e.g., the query name is "*.example.",the response in no way differswildcard does. The following queries would not be synthesized from any other query. In other words,the wild card label incard: QNAME=host1.example., QTYPE=MX, QCLASS=IN because host1.example. exists QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN because *.example. exists QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN because _tcp.host1.example. exists (without data) QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN because host2.example. exists (without data) QNAME=host.subdel.example., QTYPE=A, QCLASS=IN because subdel.example. exists (and is a QNAME has no special meaning, and query processingzone cut) To the server, all of the domains in the tree exist. The resolver will proceed using '*' as a literal query name. R4.1 A wild cardget answers to some names off the tree, thanks to synthesis. 2.2.2 Empty Non-terminals Empty non-terminals are domain names that own no resource records but have subdomains which do. This is defined in section 3.1 of RFC 1034: # The domain name acting asspace is a QNAME MUST be treated as any other QNAME, there MUST be no special processing accorded it. Iftree structure. Each node and leaf on the # tree corresponds to a wild cardresource set (which may be empty). The domain name appears in# system makes no distinctions between the RDATAuses of a CNAME RR or any other RRthe interior nodes and # leaves, and this memo uses the term "node" to refer to both. The parenthesized "which may be empty" specifies that has a domain nameempty non- terminals are explicitly recognized. According to the definition of existence in it,this document, empty non-terminals do exist at the same rule applies. Inserver. Pedantically reading the above paragraph can lead to an interpretation that all possible domains exist - up to the instancesuggested limit of 255 octets for a CNAME RR, the wild carddomain name [RFC 1035]. For example, www.example. may have an A RR, and as far as is used in the same mannerpractically concerned, is a leaf of as being the original QNAME. For other RR's, rules vary regarding what is done withthe domain name(s) appearing in them, intree. But the definition can be taken to mean that sub.www.example. also exists, albeit with no case doesdata. By extension, all possible domains exist, from the wild card hold special meaning. R4.2 A wild card domainroot on down. As RFC 1034 also defines "an authoritative name appearing in any RR's RDATA MUST be treated as any other domainerror indicating that the name does not exist" in that situation, there MUST be no special processing accorded it. 5. Impactsection 4.3.1, this is not the intent of a Wild Card Domain On a Response The descriptionthe original document. 2.2.3 Yet Another Definition of how wild cards impact response generationExistence RFC1034's wording is in RFC 1034, section 4.3.2. That passage contains the algorithm followedclarified by a server in constructing a response. Within that algorithm, step 3, part 'c' definesthe behavior offollowing paragraph: A node is considered to have an impact on the wild card. The algorithmalgorithms of 4.3.2 if it is directly quoted in lines that begina leaf node with any resource sets or an interior node (with or without a '#' sign. Commentary is interleaved. Thereresource set) that has a subdomain that is a documentation issue deserving some explanation.leaf node with a resource set. A QNAME and QCLASS matching an existing node never results in a response code of authoritative name error (RCODE==3). The algorithmterminology in RFC 1034, section 4.3.2.the above paragraph is not intendedchosen to be pseudo code, i.e., it's steps are not intendedremain as close to be followedthat in strict order.the original document. The "algorithm"term "with" is a suggestion. As such, in step 3, parts a, b, and c, do not have to be implementedalternate form for "owning" in this case, hence "a leaf node owning resources sets, or an interior node, owning or not owning any resource set, that order. Another issue needing explanation is that RFC 1034 ishas a full standard. Thereleaf node owning a resource set as a subdomain," is another RFC, RFC 2672, which makes, or proposes an adjustment to RFC 1034's section 4.3.2 forthe sakeproper interpretation of the DNAME RR. RFC 2672 is a proposed standard. The dilemmamiddle sentence. As an aside, an "authoritative name error", response code (RCODE) 3, has been called NXDOMAIN in writing these clarifications is knowing which document is the one being clarified. Fortunately, the difference between RFC 1034 andsome RFCs, such as RFC 2672 is not significant with respect to wild card synthesis, so this document will continue to state that it2136 [RFC 2136]. NXDOMAIN is clarifying RFC 1034. If RFC 2672 progresses alongthe standards track, it will need to refermnemonic assigned to modifying RFC 1034's algorithm as amended here. The contextsuch an error by at least one implementation of part 'c' is thatDNS. Summarizing the searchdiscussion on existence in non-RFC1034 words: An authoritative server is progressing label by label through the QNAME. (Note thatto treat a domain name as existing during the data being searched isexecution of the authoritative dataalgorithms in RFC 1034 when the server,domain name conforms to the cachefollowing definition. A domain name is searched in step 4.) Step 3's part 'a' covers the case thatdefined to exist if the QNAMEdomain name owns data or has been matched in full, regardless of the presence ofa CNAME RR. Step 'b' covers crossing a cut point, resulting in a referral. Allsubdomain that is left is to look for the wild card. Step 3 of the algorithm also assumesexists, or both. Note that the search is looking in theat a zone closest toboundary, the answer, i.e., indomain name owns data, including the same class as QCLASS and as close toNS RR set. At the authority as possible on this server. Ifdelegating server, the zoneNS RR set is not the authority, then a referral is given, possibly one indicating lameness. # c. If at some label, a matchauthoritative, but that is impossible (i.e., the # corresponding label does not exist), look to see if a # the "*" label exists.of no consequence here. The above paragraph refers to finding thedomain name that existsowns data, therefore, it exists. 2.3 When does a Wild Card Domain Name not own a wildcard (record) When a Wild Card Domain Name appears in a message's query section, no special processing occurs. Asterisk Labels in such a context only Label Matches other Asterisk Labels in the existing zone and that most enclosestree when the QNAME. Such4.3.2 algorithm is being followed. When a domain name will markWild Card Domain Name appears in the boundaryresource data of candidate wild card domain names that might be used to synthesize an answer. (Remembera record, no special processing occurs. An Asterisk Label in that at this point, if the most enclosing name is the same as the QNAME, part 'a' would have recordedcontext literally means just an exact match.)asterisk. 3. Impact of a Wild Card Domain On a Response The existencedescription of the enclosing name means that nohow wild card name highercards impact response generation is in RFC 1034, section 4.3.2. That passage contains the tree isalgorithm followed by a candidate to answer the query. Once the closest enclosing node is identified, there's the matter of what exists below it. It may have subdomains, but none will be closer toserver in constructing a response. Within that algorithm, step 3, part 'c' defines the QNAME. Onebehavior of the subdomains just might be awild card. If it exists, thisThe algorithm is the only wild card eligible to be used to synthesize an answer for the query. Even if the closest enclosing node conforms to the syntax ruledirectly quoted in section 2 for beinglines that begin with a wild card domain name, the closest enclosing node'#' sign. Commentary is interleaved. There is not eligible to be a source ofa synthesized answer.documentation issue deserving some explanation. The only wild card domain name thatalgorithm in RFC 1034, section 4.3.2. is a candidatenot intended to synthesize an answer willbe the "*" subdomain of the closest enclosing domain name. Three possibilities can happen. The "*" subdomain does not exist, the "*" subdomain does but doespseudo code, i.e., it's steps are not have an RR set of the same type as the QTYPE, or it exists and has the desired RR set. For the sake of brevity, the closest enclosing node can be referredintended to as the "closest encloser." The closest encloser is the most important conceptbe followed in this clarification. Describing the closest encloserstrict order. The "algorithm" is a bit tricky, but it is an easy concept. To find the closest encloser, yousuggestion. As such, in step 3, parts a, b, and c, do not have to first locate the zonebe implemented in that order. Another issue needing explanation is the authority for the query name. This eliminates the need to be concernedthat the closest encloserRFC 1034 is a cut point. In addition, we can assume too that the query name does not exist, hence the closest encloserfull standard. There is not equalanother RFC, RFC 2672, which makes, or proposes an adjustment to RFC 1034's section 4.3.2 for the query name. We can assume away these two cases because they are handled in steps 2, 3a and 3bsake of section 4.3.2.'s algorithm. Whatthe DNAME RR. RFC 2672 is lefta proposed standard. The dilemma in writing these clarifications is knowing which document is to identifythe existing domain nameone being clarified. Fortunately, the difference between RFC 1034 and RFC 2672 is not significant with respect to wild card synthesis, so this document will continue to state that would have been upit is clarifying RFC 1034. If RFC 2672 progresses along the tree (closerstandards track, it will need to refer to modifying RFC 1034's algorithm as amended here. 3.1 Step 2 Step 2 of the root) fromRFC 1034's section 4.3.2 reads: # 2. Search the query name. Knowing that an exact match is impossible, if thereavailable zones for the zone which is a "*" label descending fromthe unique closest encloser, thisnearest # ancestor to QNAME. If such a zone is found, go to step 3, # otherwise step 4. In this step, the one and only wild card from which an answer can be synthesizedmost appropriate zone for the query. To illustrate, usingresponse is chosen. There are two reasons to repeat this. One is that this means all of step 3 is done within the example in section 1.2context of this document,a zone, which will constrain the following chart shows QNAMEsdiscussion. The other is the though behind synthesizing entire zones and the closest enclosers. In Appendix A there is another chart showing unusual cases. QNAME Closest Encloseruse of Wild Card Source host3.example. example. *.example. _telnet._tcp.host1.example. _tcp.host1.example. no wild card _telnet._tcp.host2.example. host2.example. no wild card _telnet._tcp.host3.example. example. *.example. _chat._udp.host3.example. example. *.example. Note that host1.subdel.example.Domain Names to do so. 3.2 Step 3 Step 3 is dominated by three parts, labelled a, b, and c. But the beginning of the Step is important and needs explanation. # 3. Start matching down, label by label, in a subzone, sothe search for it endszone. The # matching process can terminate several ways: The word matching in a referralthis care refers to Label Matching. The concept is based in part 'b', thus does not enter into finding a closest encloser.the view of the zone as the tree of existing names. The fact that a closest encloser willQuery Name is considered to be an ordered sequence of labels - as if the only superdomain that can havename were a candidate wild card will have an impact when it comespath from the root to designing authenticated denialthe owner of existence proofs. # Ifthe "*" label doesdesired data. The process of Label Matching ends in one of three choices, the parts a, b, and c. Once one of the parts is chosen, the other parts are not exist, check whetherconsidered. (E.g., do not execute part c and then change the name # weexecution path to finish in part b.) The process of Label Matching is also done independent of the Query Type. Parts a and b are lookingnot an issue for isthis clarification as they do not relate to record synthesis. Part a generally covers a situation in which all of the original QNAMElabels in the query # or asearch (query) name wehave followed due to a CNAME. Ifbeen matched down the tree, e.g., the sought name # is original, setexists as an authoritative name errorexact Label Match. Part b generally covers a situation in which any label in the # responsesought name Label Matches a tree label and exit. Otherwise just exit.the tree label has a NS RRSet. 3.3 Part 'c' The above passage says that if therecontext of part 'c' is not even a wild card domain name to match at this point (failing to find an explicit answer elsewhere), we are to return an authoritativethat the process of Label Matching the labels in the sought name error at this point. If we were followinghas resulted in a CNAME, the specificationsituation in which there is unclear, but seems to imply that a no error return codenothing corresponding in the tree. It is appropriate, with justas if the CNAME RR (or sequence of CNAME RRs) inlookup has "fallen off the answer section.tree." # c. If at some label, a match is impossible (i.e., the "*"# corresponding label does exist, match RRs at that nodenot exist), look to see if a # against QTYPE. If any match, copy them intothe answer # section, but set"*" label exists. To help describe the ownerprocess of looking "to see is a the RR[sic] label exists" a term has been coined to be QNAME, and # not the node withdescribe the "*" label. Go to step 6. This final paragraph coverslast label matched. The term is "Closest Encloser." 3.3.1 Closest Encloser and the roleSource of Synthesis The "Closest Encloser" is the QTYPEnode in the process. Notezone's tree of existing domain names that if no resource record set matchesis has the QTYPEmost matching labels with the resultsought name. Each match is that no dataa "Label Match" and the order of the labels is copied, butalso the search still ceases ("Go to step 6."). Insame. The Closest Encloser is an existing name in the following section,zone, it may be an empty non-terminal, it may even be a suggested changeWild Card Domain Name itself. In no circumstances is madethe Closest Encloser the used to this, undersynthesize records though. A "Source of Synthesis" is defined in the heading "CNAME RRs atcontext of a lookup process as the Wild Card Domain Name." 6. Considerations with Special Types ForName immediately descending from the purposesClosest Encloser provided the Wild Card Domain Name exists. A Source of this section, "special" means thatSynthesis does not guarantee having a record induces processing at the server beyond simple lookup. The special types in this section are SOA, NS, CNAME, and DNAME. SOA is special because it is used asRRSet to use for synthesis, a zone marker and hasSource of Synthesis may even be an impact on step 2empty non-terminal. If a Source of Synthesis exists, it will be the algorithm in 4.3.2. NS denotes a cut point and hasWild Card Domain Name that is identified by an impactAsterisk Label below the Closest Encloser. E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>." If the Source of Synthesis does not exist (not on step 3b. CNAME redirectsthe query anddomain tree), there will be no wildcard synthesis The important concept is mentioned in steps 3a and 3b. DNAMEthat for any given lookup process, there is a "CNAME generator." 6.1. SOA RR'sat a Wild Card Domain Namemost one place at which wildcard synthetic records can be obtained. If the ownerSource of an SOA record conforms toSynthesis does not exist, the basic rules of owning an SOA RR (meaninglookup terminates, the lookup does not look for other wildcard records. Other terms have been coined on the mailing list in the past. E.g., it has been said that existing names block the application of wildcard records. This is still an appropriate viewpoint, but replacing this notion with the apexClosest Encloser and Source of a zone)Synthesis the impact ondepiction of the search algorithmwildcard process is notclearer. 3.3.2 Closest Encloser and Source of Synthesis Examples To illustrate, using the example zone in section 3c (where records are synthesized) as would be expected. The impact is really in step 22.2.1 of this document, the algorithm,following chart shows QNAMEs and the choiceclosest enclosers. QNAME Closest Encloser Source of zone. We areSynthesis host3.example. example. *.example. _telnet._tcp.host1.example. _tcp.host1.example. no longer talking about whether or not an SOA RR can be synthesized in a response because we are shifting attention to step 2. We are now talking about what it means for a name server to synthesize a zone for a response. To date,source _telnet._tcp.host2.example. host2.example. no implementation has done this. Thinking ahead though, anyone choosing to pursue this would have to be awaresource _telnet._tcp.host3.example. example. *.example. _chat._udp.host3.example. example. *.example. The fact that a server would have to be able to distinguish between queries for data itclosest encloser will have to synthesize and queries that ought tobe treated as if they were prompted by a lame delegation. It is not a protocol error tothe only superdomain that can have an SOA RR owned bya candidate wild card domain name, just as it is not an error towill have zone name be syntactically equivalentan impact when it comes to a domain name. However, this situation requires careful considerationdesigning pre-calculated authenticated denial of how a server choosesexistence proofs. 3.3.3 Non-existent Source of Synthesis In RFC 1034: # If the appropriate zone"*" label does not exist, check whether the name # we are looking for an answer. And an SOA RRis not able to be synthesized asthe original QNAME in step 3c. 6.2. NS RR's atthe query # or a Wild Card Domain Name Complimentaryname we have followed due to the issue of an SOA RR owned bya wild card domainCNAME. If the name # is original, set an authoritative name error in the issue of NS RR's owned# response and exit. Otherwise just exit. The above passage is clear, evidenced by a wild card domain name. In this instance, each machine being referred to inthe RDATAlack of discussion and mis-implementation of it over the NS RR hasyears. It is included for completeness only. (No attempt is made to be ablere-interpret it lest a mistake in editing leads to understand the impact of this on step 2, the choosing ofconfusion.) 3.3.4 Type Matching RFC 1034 concludes part c with this: # If the authoritative zone. Referring to"*" label does exist, match RRs at that node # against QTYPE. If any match, copy them into the same machine in such a NS RR will probably not work well. This is becauseanswer # section, but set the server may become confused as to whetherowner of the query name oughtRR to be answered by the zone owningQNAME, and # not the NS RR in question or a synthesized zone. (It isn't known in advance thatnode with the query name will invoke"*" label. Go to step 6. This final paragraph covers the wild card synthesis.) The statusrole of other RR's owned by a wild card domain name is the same as ifthe owner name was not a wild card domain name. I.e., when there is a NS RR at a wild card domain name, other records are treated as being belowQTYPE in the zone cut. Is it not a protocol error to havelookup process. Based on implementation feedback and similarities between step a NS RR owned byand step c a wild card domian name, complimentarychange to the case of a SOA RR. However, forthis to work, an implementation has to know how to synthesize a zone. 6.3. CNAME RR's atpassage a Wild Card Domain Name The issue of CNAME RR's owned by wild card domain nameschange has prompted a suggestedbeen made. The change is to add the last paragraph of step 3c of the algorithm in 4.3.2. The changed text is this:following text: If the "*" label does exist and if thedata at the nodesource of synthesis is a CNAMECNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, setresponse changing the owner of the CNAME RRname to bethe QNAME, and thenchange QNAME to the canonical name in the CNAME RR, and go back to step 1. IfThis is essentially the "*" label does exist and either QTYPE issame text in step a covering the processing of CNAME orRRSets. 4. Considerations with Special Types Five types of RRSets owned by a Wild Card Domain Name have caused confusion. Four explicit types causing confusion are SOA, NS, CNAME, DNAME, and the datafifth type - "none." 4.1. SOA RR's at a Wild Card Domain Name A Wild Card Domain Name owning an SOA RRSet means that the nodedomain is at the root of the zone (apex). The domain can not be a CNAME, then match RRs atSource of Synthesis because that is, but definition, a descendent node against QTYPE. If any match, copy them into(of the answer section, but setClosest Encloser) and a zone apex is at the ownertop of the RR to be QNAME, andzone. Although a Wild Card Domain Name can not the node with the "*" label. Gobe a Source of Synthesis, there is no reason to step 6. Apologies ifforbid the above isn't clear, butownership of an attempt was made to stitch together the passage using just the phrases in section 3aSOA RRSet. This means that zones with names like "*.<Parent Zone>.", and 3c of the algorithm so as to preserve the original flavor. In case the passage as suggested isn't clear enough, the intent iseven "*.<Parent Sublabels>.<Parent Zone>." Step 2 (section 3.1) does not provide a means to make "landing" atspecify a wild card name and findingmeans to synthesize a CNAMEzone. Therefore, according to the same as if this happened as a result ofrules there, the only way in which a direct match. I.e., Findingzone that has a CNAME at thename matched in step 3cwhich is supposed to have the same impact as finding the CNAME in step 3a. 6.4. DNAME RR's ata Wild Card Domain Name The specification of the DNAME RR, whichis atif the proposed level of standardization,QNAME is not as mature as the full standardin RFC 1034. Because of this, ora domain below the reason for this is, there appears to bezone's name. E.g., if *.example. has an SOA record, then only a host of issues with that definition and it's rewritequery like QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another example, a QNAME of the algorithmwww.*.example. would also result in 4.3.2. Forpassing through the time being, when it comes to wild card processing issues,zone. 4.2. NS RR's at a DNAME can be considered to beWild Card Domain Name The semantics of a CNAME synthesizer. A DNAME atWild Card Domain Name ownership of a wild card domain nameNS RRSet has been unclear. Looking through RFC 1034, the recommendation is effectivelyto have the NS RRSet act the same asa CNAMEany non-special type, e.g., like an A RR. If the NS RRSet in question is at a wild card domainthe top of the zone, i.e., the name also owns an SOA RRSet, the QNAME equals the zone name. 7. Security ConsiderationsThis document is refiningwould trigger part 'a' of Step 3. In any other case, the specifications to make it more likely that security canWild Card Domain Name owned NS RRSet would be added to DNS. No functional additions are being made, just refining what is considered properthe only RRSet (prior to allowchanges instituted by DNSSEC) at the DNS, security ofnode by DNS rules. If the DNS, and extendingQNAME equals the DNS toWild Card Domain Name or is a subdomain of it, then the node would be more predictable. 8. References Normative References [RFC 20] ASCII Formatconsidered in part 'b' of Step 3. Note that there is no synthesis of records in the authority section because part 'b' does not account for Network Interchange, V.G. Cerf, Oct-16-1969 [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, Nov-01-1987 [RFC 1035] Domain Names - Implementation and Specification, P.V Mockapetris, Nov-01-1987 [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S Bradner, March 1997 Informative References [RFC 2136] Dynamic Updates insynthesis. The referral returned would have the Wild Card Domain Name System (DNS UPDATE), P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 9. Others Contributing to This Document Others who have directly caused text to appearin the document: Paul Vixie and Olaf Kolkman. Many others have indirect influences on the content. 10. Editors Name: Bob Halley Affiliation: Nominum, Inc. Address: 2385 Bay Road, Redwood City, CA 94063 USA Phone: +1-650-381-6016 EMail: Bob.Halley@nominum.com Name: Edward Lewis Affiliation: ARIN Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA Phone: +1-703-227-9854 Email: firstname.lastname@example.org Comments on this document can be sent toauthority section, unchanged. If the editors orQNAME is not the mailing list forsame as the DNSEXT WG, email@example.com. Appendix A: Subdomains ofWild Card Domain Names In reading the definitionName nor a subdomain of section 2 carefully, it is possible to rationalize unusual names as legal. In the example given, *.example. could have subdomainsit, then part 'c' of *.sub.*.example. and even the more direct *.*.example. (The implication hereStep 3 has been triggered. Once part 'c' is that these domain names own explicit resource records sets.) Although defining these namesentered, there is not easyno reverting to justify, itpart 'b' - i.e., once an NS RRSet is importantsynthesized it does not mean that implementions account forthe possibility. This section will give some further guidence on handling these names. The first thingserver has to realizeconsider the name delegated away. I.e., the server is not synthesizing a record (the NS RRSet) that by all definitions, subdomains of wild card domain names are legal. In analyzing them, one realizes that they cause no harm by their existence. Because of this, they are allowed to exist, i.e., there are no special case rules made to disallow them. The reason formeans the server does not preventing these names is thathave the prevention would just introduce more code pathsright to put into implementations.synthesize. 4.3. CNAME RR's at a Wild Card Domain Name The conceptissue of "closest enclosing" existing names is important to keep in mind. It is also important to realize that aCNAME RR's owned by wild card domain name can benames has prompted a closest enclosersuggested change to the last paragraph of a query name. For example, if *.*.example. is definedstep 3c of the algorithm in 4.3.2. The changed text appears in section 3.3.4 of this document. 4.4. DNAME RR's at a zone, andWild Card Domain Name The specification of the query nameDNAME RR, which is a.*.example., thenat the closest enclosing domain nameproposed level of standardization, is *.example. Keepnot as mature as the full standard in mind thatRFC 1034. Because of this, or the closest encloser is not eligiblereason for this is, there appears to be a source of synthesized answers, just the subdomaina number of it that has the first label "*". To illustrate this, the following chart shows some matches. Assumeissues with that the names *.example., *.*.example.,definition and *.sub.*.example. are definedit's rewrite of the algorithm in 4.3.2. For the zone. QNAME Closest Encloser Wild Card Source a.example. example. *.example. b.a.example. example. *.example. a.*.example. *.example. *.*.example. b.a.*.example. *.example. *.*.example. b.a.*.*.example. *.*.example. no wild card a.sub.*.example. sub.*.example. *.sub.*.example. b.a.sub.*.example. sub.*.example. *.sub.*.example. a.*.sub.*.example. *.sub.*.example. notime being, when it comes to wild card *.a.example. example. *.example. a.sub.b.example. example. *.example. Recall that the closest encloser itself cannotprocessing issues, a DNAME can be considered to be the wild card. Therefore the match for b.a.*.*.example. has no applicable wild card. Finally, ifa queryCNAME synthesizer. A DNAME at a wild card domain name is sub.*.example., any answer available will come from an exact name match for sub.*.example. Noeffectively the same as a CNAME at a wild card synthesisdomain name. 4.5 Empty Non-terminal Wild Card Domain Name If a Source of Synthesis is performedan empty non-terminal, then the response will be one of no error in this case. Full Copyright Statement Copyright (C) The Internet Society 2003. All Rights Reserved.the return code and no RRSet in the answer section. 5. Security Considerations This document and translations ofis refining the specifications to make it maymore likely that security can be copied and furnishedadded to DNS. No functional additions are being made, just refining what is considered proper to others,allow the DNS, security of the DNS, and derivative works that comment on or otherwise explain it or assist in its implementation mayextending the DNS to be prepared, copied, publishedmore predictable. 6. References Normative References [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, Nov-01-1987 [RFC 1035] Domain Names - Implementation and distributed,Specification, P.V Mockapetris, Nov-01-1987 [RFC 2119] Key Words for Use in whole orRFCs to Indicate Requirement Levels, S Bradner, March 1997 Informative References [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 7. Others Contributing to This Document Others who have been editors of this document: Bob Halley and Robert Elz. Others who have directly caused text to appear in part, without restriction of any kind, provided thatthe above copyright noticedocument: Paul Vixie and this paragraph are includedOlaf Kolkman. Many others have indirect influences on the content. 8. Editor Name: Edward Lewis Affiliation: NeuStar Address: tbd Phone: tbd Email: tbd (please send comments to namedroppers) Comments on all such copies and derivative works. However,this document itself may notcan be modified in any way, such as by removing the copyright notice or referencessent to the Internet Societyeditors or other Internet organizations, except as needed forthe purpose of developing Internet standards in which case the proceduresmailing list for copyrights defined inthe DNSEXT WG, firstname.lastname@example.org. 9. Trailing Boilerplate Copyright (C) The Internet Standards process must be followed, or as requiredSociety (2004). This document is subject to translate it into languages other than English. The limited permissions granted above are perpetualthe rights, licenses and will not be revoked byrestrictions contained in BCP 78 and except as set forth therein, the Internet Society or its successors or assigns.authors retain all their rights. This document and the information contained herein isare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expiration This document expires on or about 11 April 2005.