--- /dev/null
+\r
+\r
+Network Working Group J. Yao\r
+Internet-Draft X. Lee\r
+Intended status: Standards Track CNNIC\r
+Expires: December 14, 2010 P. Vixie\r
+ Internet Software Consortium\r
+ June 15, 2010\r
+\r
+\r
+ Bundle DNS Name Redirection\r
+ draft-yao-dnsext-bname-02.txt\r
+\r
+Abstract\r
+\r
+ This document defines a new DNS Resource Record called "BNAME", which\r
+ provides the capability to map itself and its subtree of the DNS name\r
+ space to another domain. It differs from the CNAME record which only\r
+ maps a single node of the DNS name space, from the DNAME which only\r
+ maps the subtree of the DNS name space to another domain.\r
+\r
+Status of this Memo\r
+\r
+ This Internet-Draft is submitted in full conformance with the\r
+ provisions of BCP 78 and BCP 79.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF). Note that other groups may also distribute\r
+ working documents as Internet-Drafts. The list of current Internet-\r
+ Drafts is at http://datatracker.ietf.org/drafts/current/.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months\r
+ and may be updated, replaced, or obsoleted by other documents at any\r
+ time. It is inappropriate to use Internet-Drafts as reference\r
+ material or to cite them other than as "work in progress."\r
+\r
+ This Internet-Draft will expire on December 14, 2010.\r
+\r
+Copyright Notice\r
+\r
+ Copyright (c) 2010 IETF Trust and the persons identified as the\r
+ document authors. All rights reserved.\r
+\r
+ This document is subject to BCP 78 and the IETF Trust's Legal\r
+ Provisions Relating to IETF Documents\r
+ (http://trustee.ietf.org/license-info) in effect on the date of\r
+ publication of this document. Please review these documents\r
+ carefully, as they describe your rights and restrictions with respect\r
+ to this document. Code Components extracted from this document must\r
+ include Simplified BSD License text as described in Section 4.e of\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 1]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ the Trust Legal Provisions and are provided without warranty as\r
+ described in the Simplified BSD License.\r
+\r
+ This document may contain material from IETF Documents or IETF\r
+ Contributions published or made publicly available before November\r
+ 10, 2008. The person(s) controlling the copyright in some of this\r
+ material may not have granted the IETF Trust the right to allow\r
+ modifications of such material outside the IETF Standards Process.\r
+ Without obtaining an adequate license from the person(s) controlling\r
+ the copyright in such materials, this document may not be modified\r
+ outside the IETF Standards Process, and derivative works of it may\r
+ not be created outside the IETF Standards Process, except to format\r
+ it for publication as an RFC or to translate it into languages other\r
+ than English.\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 3. The BNAME Resource Record . . . . . . . . . . . . . . . . . . 4\r
+ 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4\r
+ 3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4\r
+ 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5\r
+ 4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 7\r
+ 5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 8\r
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9\r
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9\r
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9\r
+ 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9\r
+ 9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 9\r
+ 9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 9\r
+ 9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 9\r
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10\r
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10\r
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 11\r
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 2]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+1. Introduction\r
+\r
+ More and more internationalized domain name labels [RFC3490] appear\r
+ in the DNS trees. Some labels [RFC3743] are equivalent in some\r
+ languages. The internet users want them to be identical in the DNS\r
+ resolution. For example, color.exmaple.com==colour.example.com. The\r
+ BNAME represents for bundle names. This document defines a new DNS\r
+ Resource Record called "BNAME", which provides the capability to map\r
+ an entire tree of the DNS name space to another domain. It means\r
+ that the BNAME redirects both itself and its descendants to its\r
+ owner. The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,\r
+ only the descendants. The domain name that owns a DNAME record is\r
+ allowed to have other resource record types at that domain name. The\r
+ domain name that owns a BNAME record is not allowed to have other\r
+ resource record types at that domain name unless they are the DNSSEC\r
+ related resource record types defined in [RFC4033], [RFC4034],\r
+ [RFC4035] and [RFC5155]. A server MAY refuse to load a zone that has\r
+ data at a sub-domain of a domain name owning a BNAME RR or that has\r
+ other data except the DNSSEC related resource record types and BNAME\r
+ at that name. BNAME is a singleton type, meaning only one BNAME is\r
+ allowed per name except the DNSSEC related resource record types.\r
+ Resolvers, servers and zone content administrators should be cautious\r
+ that usage of BNAME or its combination with CNAME or DNAME may lead\r
+ to form loops. The loops should be avoided.\r
+\r
+1.1. Terminology\r
+\r
+ All the basic terms used in this specification are defined in the\r
+ documents [RFC1034], [RFC1035] and [RFC2672].\r
+\r
+\r
+2. Motivation\r
+\r
+ In some languages, some characters have the variants, which look\r
+ differently or very similar but are identical in the meaning. For\r
+ example, Chinese character U+56FD and its variant U+570B look\r
+ differently, but are identical in the meaning. If Internationalized\r
+ Domain Label" or "IDL" [RFC3743] are composed of variant characters,\r
+ we regard this kind of IDL as the IDL variant. If these IDL variants\r
+ are put into the DNS for resolution, they are expected to be\r
+ identical in the DNS resolution. More comprehensible example is that\r
+ we expect color.exmaple.com to be equivalent with the\r
+ colour.exmaple.com in the DNS resolution. The BNAME Resource Record\r
+ and its processing rules are conceived as a solution to this\r
+ equivalence problem. Without the BNAME mechanism, current mechanisms\r
+ such as DNAME or CNAME are not enough capable to solve all the\r
+ problems with the emergence of internationalized domain names. The\r
+ internationalized domain names may have alias or equivalence of the\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 3]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ original one. The BNAME solution provides the solution to both ASCII\r
+ alias names and internationalized domain alias names.\r
+\r
+\r
+3. The BNAME Resource Record\r
+\r
+3.1. Format\r
+\r
+ The BNAME RR has mnemonic BNAME and type code xx (decimal). It is\r
+ not class-sensitive. Its RDATA is comprised of a single field,\r
+ <target>, which contains a fully qualified domain name that must be\r
+ sent in uncompressed form [RFC1035], [RFC3597]. The <target> field\r
+ MUST be present. The presentation format of <target> is that of a\r
+ domain name [RFC1035]. The wildcards in the BNAME RR SHOULD NOT be\r
+ used.\r
+\r
+ <owner> <ttl> <class> BNAME <target>\r
+\r
+ The effect of the BNAME RR is the substitution of the record's\r
+ <target> for its owner name, as a suffix of a domain name. This\r
+ substitution has to be applied for every BNAME RR found in the\r
+ resolution process, which allows fairly lengthy valid chains of BNAME\r
+ RRs.\r
+\r
+3.2. The BNAME Substitution\r
+\r
+ A BNAME substitution is performed by replacing the suffix labels of\r
+ the name being sought matching the owner name of the BNAME resource\r
+ record with the string of labels in the RDATA field. The matching\r
+ labels end with the root label in all cases. Only whole labels are\r
+ replaced.\r
+\r
+3.3. The BNAME Rules\r
+\r
+ There are two rules which governs the use of BNAMEs in a zone file.\r
+ The first one is that there SHOULD be no descendants under the owner\r
+ of the BNAME. The second one is that no resource records can co-\r
+ exist with the BNAME for the same name except the DNSSEC related\r
+ resource record types. It means that if a BNAME RR is present at a\r
+ node N, there MUST be no other data except the DNSSEC related\r
+ resource record types at N and no data at any descendant of N. This\r
+ restriction applies only to records of the same class as the BNAME\r
+ record.\r
+\r
+\r
+4. Query Processing\r
+\r
+ To exploit the BNAME mechanism the name resolution algorithms\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 4]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ [RFC1034] must be modified slightly for both servers and resolvers.\r
+ Both modified algorithms incorporate the operation of making a\r
+ substitution on a name (either QNAME or SNAME) under control of a\r
+ BNAME record. This operation will be referred to as "the BNAME\r
+ substitution".\r
+\r
+4.1. Processing by Servers\r
+\r
+ For a server performing non-recursive service steps 3.a, 3.c and 4 of\r
+ section 4.3.2 [RFC1034] are changed to check for a BNAME record, and\r
+ to return certain BNAME records from zone data and the cache. When\r
+ preparing a response, a server performing a BNAME substitution will\r
+ in all cases include the relevant BNAME RR in the answer section. A\r
+ CNAME RR is synthesized and included in the answer section. This\r
+ will help the client to reach the correct DNS data. The provided\r
+ synthesized CNAME RR, MUST have\r
+\r
+\r
+ The same CLASS as the QCLASS of the query,\r
+\r
+ TTL equal to the corresponding BNAME RR,\r
+\r
+ An <owner> equal to the QNAME in effect at the moment the BNAME RR\r
+ was encountered, and\r
+\r
+ An RDATA field containing the new QNAME formed by the action of\r
+ the BNAME substitution.\r
+\r
+\r
+ The revised server algorithm is:\r
+\r
+\r
+ 1. Set or clear the value of recursion available in the response\r
+ depending on whether the name server is willing to provide\r
+ recursive service. If recursive service is available and\r
+ requested via the RD bit in the query, go to step 5, otherwise\r
+ step 2.\r
+\r
+ 2. Search the available zones for the zone which is the nearest\r
+ ancestor to QNAME. If such a zone is found, go to step 3,\r
+ otherwise step 4.\r
+\r
+ 3. Start matching down, label by label, in the zone. The matching\r
+ process can terminate several ways:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 5]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ a. If the whole of QNAME is matched, we have found the node.\r
+\r
+ If the data at the node is a CNAME, and QTYPE doesn't match\r
+ CNAME, copy the CNAME RR into the answer section of the\r
+ response, change QNAME to the canonical name in the CNAME RR,\r
+ and go back to step 1.\r
+\r
+ If the data at the node is a BNAME, and QTYPE doesn't\r
+ match BNAME, copy the BNAME RR and also a corresponding,\r
+ synthesized CNAME RR into the answer section of the\r
+ response, change QNAME to the name carried as RDATA in\r
+ the BNAME RR, and go back to step 1.\r
+\r
+ Otherwise, copy all RRs which match QTYPE into the answer\r
+ section and go to step 6.\r
+\r
+ b. If a match would take us out of the authoritative data, we have\r
+ a referral. This happens when we encounter a node with NS RRs\r
+ marking cuts along the bottom of a zone.\r
+\r
+ Copy the NS RRs for the subzone into the authority section of\r
+ the reply. Put whatever addresses are available into the\r
+ additional section, using glue RRs if the addresses are not\r
+ available from authoritative data or the cache. Go to step 4.\r
+\r
+ c. If at some label, a match is impossible (i.e., the\r
+ corresponding label does not exist), look to see whether the\r
+ last label matched has a BNAME record.\r
+\r
+\r
+ If a BNAME record exists at that point, copy that record into\r
+ the answer section. If substitution of its <target> for its\r
+ <owner> in QNAME would overflow the legal size for a <domain-\r
+ name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise\r
+ perform the substitution and continue. The server SHOULD\r
+ synthesize a corresponding CNAME record as described above and\r
+ include it in the answer section. Go back to step 1.\r
+\r
+ If there was no BNAME record, look to see if the "*" label\r
+ exists.\r
+\r
+ If the "*" label does not exist, check whether the name we are\r
+ looking for is the original QNAME in the query or a name we\r
+ have followed due to a CNAME. If the name is original, set an\r
+ authoritative name error in the response and exit. Otherwise\r
+ just exit.\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 6]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+\r
+ If the "*" label does exist, match RRs at that node against\r
+ QTYPE. If any match, copy them into the answer section, but\r
+ set the owner of the RR to be QNAME, and not the node with the\r
+ "*" label. Go to step 6.\r
+\r
+\r
+ 4. Start matching down in the cache. If QNAME is found in the cache,\r
+ copy all RRs attached to it that match QTYPE into the answer\r
+ section. If QNAME is not found in the cache but a BNAME record is\r
+ present at QNAME, copy that BNAME record into the\r
+ answer section. If there was no delegation from authoritative\r
+ data, look for the best one from the cache, and put it in the\r
+ authority section. Go to step 6.\r
+\r
+ 5. Use the local resolver or a copy of its algorithm (see resolver\r
+ section of this memo) to answer the query. Store the results,\r
+ including any intermediate CNAMEs and BNAMEs, in the answer\r
+ section of the response.\r
+\r
+ 6. Using local data only, attempt to add other RRs which may be\r
+ useful to the additional section of the query. Exit.\r
+\r
+\r
+\r
+ Note that there will be at most one ancestor with a BNAME as\r
+ described in step 4 unless some zone's data is in violation of the\r
+ no-descendants limitation in section 3. An implementation might take\r
+ advantage of this limitation by stopping the search of step 3c or\r
+ step 4 when a BNAME record is encountered.\r
+\r
+\r
+4.2. Processing by Resolvers\r
+\r
+ A resolver or a server providing recursive service must be modified\r
+ to treat a BNAME as somewhat analogous to a CNAME. The resolver\r
+ algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d\r
+ as 4.e and insert a new 4.d. The complete algorithm becomes:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 7]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ 1. See if the answer is in local information, and if so return it to\r
+ the client.\r
+\r
+ 2. Find the best servers to ask.\r
+\r
+ 3. Send them queries until one returns a response.\r
+\r
+ 4. Analyze the response, either:\r
+\r
+ a. if the response answers the question or contains a name error,\r
+ cache the data as well as returning it back to the client.\r
+\r
+ b. if the response contains a better delegation to other servers,\r
+ cache the delegation information, and go to step 2.\r
+\r
+ c. if the response shows a CNAME and that is not the answer\r
+ itself, cache the CNAME, change the SNAME to the canonical name\r
+ in the CNAME RR and go to step 1.\r
+\r
+ d. if the response shows a BNAME and that is not the answer\r
+ itself, cache the BNAME. If substitution of the BNAME's\r
+ <target> for its <owner> in the SNAME would overflow the legal\r
+ size for a <domain-name>, return an implementation-dependent\r
+ error to the application; otherwise perform the substitution\r
+ and go to step 1.\r
+\r
+ e. if the response shows a server failure or other bizarre\r
+ contents, delete the server from the SLIST and go back to step\r
+ 3.\r
+\r
+\r
+ A resolver or recursive server which understands BNAME records but\r
+ sends non-extended queries MUST augment step 4.c by deleting from the\r
+ reply any CNAME records which have an <owner> which is a subdomain of\r
+ the <owner> of any BNAME record in the response.\r
+\r
+\r
+5. BNAME in DNSSEC\r
+\r
+ With the deployment of DNSSEC, more and more servers and resolvers\r
+ will support DNSSEC. In order to make BNAME valid in DNSSEC\r
+ verification, the DNSSEC enabled resolvers and servers MUST support\r
+ BNAME. The synthesized CNAME in the answer section for the BNAME\r
+ will never be signed. DNSSEC validators MUST understand BNAME,\r
+ verify the BNAME and then checking that the CNAME was properly\r
+ synthesized in order to verify the synthesized CNAME. In any\r
+ negative response, the NSEC or NSEC3 [RFC5155] record type bit map\r
+ SHOULD be checked to see that there was no BNAME that could have been\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 8]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ applied. If the BNAME bit in the type bit map is set and the query\r
+ type is not BNAME, then BNAME substitution should have been done.\r
+\r
+\r
+6. IANA Considerations\r
+\r
+ IANA is requested to assignment the number to XX.\r
+\r
+\r
+7. Security Considerations\r
+\r
+ Both ASCII domain name labels and non-ASCII ones have some aliases.\r
+ We can bundle the domain name labels and their aliases through BNAME\r
+ in the DNS resolutions. The name labels and their aliases in the\r
+ particular languages are only known by those who know these\r
+ languages. Those labels may be regarded as different ones by those\r
+ who don't know those languages. Those who do not know the aliases\r
+ should only use the familar ones. The applications will not know the\r
+ aliases unless they are properly configured.\r
+\r
+\r
+8. Acknowledgements\r
+\r
+ Because the BNAME is very similar to DNAME, the authors learn a lot\r
+ from [RFC2672]. Many ideas are from the discussion in the DNSOP and\r
+ DNSEXT mailling list. Thanks a lot to all in the list. Many\r
+ important comments and suggestions are contributed by many members of\r
+ the DNSEXT and DNSOP WGs. The authors especially thanks the\r
+ following ones:Niall O'Reilly, Glen Zorn for improving this document.\r
+\r
+\r
+9. Change History\r
+\r
+ [[anchor14: RFC Editor: Please remove this section.]]\r
+\r
+9.1. draft-yao-dnsext-bname: Version 00\r
+\r
+ o Bundle DNS Name Redirection\r
+\r
+9.2. draft-yao-dnsext-bname: Version 01\r
+\r
+ o Improve the algorithm\r
+ o Improve the text\r
+\r
+9.3. draft-yao-dnsext-bname: Version 02\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 9]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ o Add the DNSSEC discussion\r
+ o Improve the text\r
+\r
+\r
+10. References\r
+\r
+10.1. Normative References\r
+\r
+ [ASCII] American National Standards Institute (formerly United\r
+ States of America Standards Institute), "USA Code for\r
+ Information Interchange", ANSI X3.4-1968, 1968.\r
+\r
+ [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",\r
+ RFC 2671, August 1999.\r
+\r
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",\r
+ STD 13, RFC 1034, November 1987.\r
+\r
+ [RFC1035] Mockapetris, P., "Domain names - implementation and\r
+ specification", STD 13, RFC 1035, November 1987.\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,\r
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",\r
+ RFC 2136, April 1997.\r
+\r
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",\r
+ RFC 2671, August 1999.\r
+\r
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",\r
+ RFC 2672, August 1999.\r
+\r
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,\r
+ "Internationalizing Domain Names in Applications (IDNA)",\r
+ RFC 3490, March 2003.\r
+\r
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record\r
+ (RR) Types", RFC 3597, September 2003.\r
+\r
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO\r
+ 10646", RFC 3629, November 2003.\r
+\r
+ [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint\r
+ Engineering Team (JET) Guidelines for Internationalized\r
+ Domain Names (IDN) Registration and Administration for\r
+ Chinese, Japanese, and Korean", RFC 3743, April 2004.\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 10]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.\r
+ Rose, "DNS Security Introduction and Requirements",\r
+ RFC 4033, March 2005.\r
+\r
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.\r
+ Rose, "Resource Records for the DNS Security Extensions",\r
+ RFC 4034, March 2005.\r
+\r
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.\r
+ Rose, "Protocol Modifications for the DNS Security\r
+ Extensions", RFC 4035, March 2005.\r
+\r
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS\r
+ Security (DNSSEC) Hashed Authenticated Denial of\r
+ Existence", RFC 5155, March 2008.\r
+\r
+10.2. Informative References\r
+\r
+ [RFC2672bis]\r
+ Rose, S. and W. Wijngaards, "Update to DNAME Redirection\r
+ in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-\r
+ 17.txt, 6 2009.\r
+\r
+\r
+Authors' Addresses\r
+\r
+ Jiankang YAO\r
+ CNNIC\r
+ No.4 South 4th Street, Zhongguancun\r
+ Beijing\r
+\r
+ Phone: +86 10 58813007\r
+ Email: yaojk@cnnic.cn\r
+\r
+\r
+ Xiaodong LEE\r
+ CNNIC\r
+ No.4 South 4th Street, Zhongguancun\r
+ Beijing\r
+\r
+ Phone: +86 10 58813020\r
+ Email: lee@cnnic.cn\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 11]\r
+\f\r
+Internet-Draft bname June 2010\r
+\r
+\r
+ Paul Vixie\r
+ Internet Software Consortium\r
+ 950 Charter Street\r
+ Redwood City, CA\r
+\r
+ Phone: +1 650 779 7001\r
+ Email: vixie@isc.org\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Yao, et al. Expires December 14, 2010 [Page 12]\r
+\f\r
+\r
+\r
projects / thirdparty / bind9.git / commitdiff
