idnits 2.17.1 draft-yao-dnsext-bname-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 23, 2016) is 2888 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: 'ASCII' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'EDNS0' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC3490' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC3743' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC2672bis' is defined on line 588, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) -- Duplicate reference: RFC2671, mentioned in 'RFC2671', was also mentioned in 'EDNS0'. ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Downref: Normative reference to an Informational RFC: RFC 3743 -- Duplicate reference: RFC2672, mentioned in 'RFC2672bis', was also mentioned in 'RFC2672'. -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft X. Lee 4 Intended status: Standards Track CNNIC 5 Expires: November 24, 2016 P. Vixie 6 CNNIC-Farsight Joint Laboratory 7 May 23, 2016 9 Bundled DNS Name Redirection 10 draft-yao-dnsext-bname-06.txt 12 Abstract 14 This document defines a new DNS Resource Record called "BNAME", which 15 provides the capability to map itself and its subtree of the DNS name 16 space to another domain. It differs from the CNAME record which only 17 maps a single node of the DNS name space, from the DNAME which only 18 maps the subtree of the DNS name space to another domain. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 24, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The BNAME Resource Record . . . . . . . . . . . . . . . . . . 3 70 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . 4 72 3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4 73 3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . 4 74 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5 76 4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8 77 5. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . . 9 78 6. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. BNAME-aware Resolvers . . . . . . . . . . . . . . . . . . 10 80 6.2. Compatibility with BNAME unaware resolvers . . . . . . . 10 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 84 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . 11 86 10.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . 11 87 10.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . 12 88 10.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . 12 89 10.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . 12 90 10.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . 12 91 10.7. draft-yao-dnsext-bname: Version 06 . . . . . . . . . . . 12 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 11.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 For some names, the internet users may want them to be identical in 100 the DNS resolution. For example, exmaple.ong==example.ngo, 101 cnnic.cn==cnnic.net.cn. The BNAME represents for bundle names. This 102 document defines a new DNS Resource Record called "BNAME", which 103 provides the capability to map an entire tree of the DNS name space 104 to another domain. It means that the BNAME redirects both itself and 105 its descendants to its owner. The DNAME [RFC6672] does not redirect 106 itself, only the descendants. The domain name that owns a DNAME 107 record is allowed to have other resource record types at that domain 108 name. The domain name that owns a BNAME record is not allowed to 109 have other resource record types at that domain name unless they are 110 the DNSSEC related resource record types defined in [RFC4033], 111 [RFC4034], [RFC4035] and [RFC5155]. A server MAY refuse to load a 112 zone that has data at a sub-domain of a domain name owning a BNAME RR 113 or that has other data except the DNSSEC related resource record 114 types and BNAME at that name. BNAME is a singleton type, meaning 115 only one BNAME is allowed per name except the DNSSEC related resource 116 record types. Resolvers, servers and zone content administrators 117 should be cautious that usage of BNAME or its combination with CNAME 118 or DNAME may lead to form loops. The loops should be avoided. 120 1.1. Terminology 122 All the basic terms used in this specification are defined in the 123 documents [RFC1034], [RFC1035] and [RFC2672]. 125 2. Motivation 127 CNAME can redirect itself to other name. DNAME can rediret its 128 children to other name. In practice, many names need redirect itself 129 and its children to another name. For example, we expect 130 exmaple.TLD1 to be identical with the example.TLD2 in the DNS 131 resolution. Without the BNAME mechanism, current mechanisms such as 132 DNAME or CNAME are not enough capable to redirect itself and its 133 children to another name at the same time. 135 3. The BNAME Resource Record 137 3.1. Format 139 The BNAME RR has mnemonic BNAME and type code xx (decimal). Its 140 RDATA is comprised of a single field, , which contains a 141 fully qualified domain name that must be sent in uncompressed form 142 [RFC1035], [RFC3597]. The field MUST be present. The 143 presentation format of is that of a domain name [RFC1035]. 144 The wildcards in the BNAME RR SHOULD NOT be used. 146 BNAME 148 The effect of the BNAME RR is the substitution of the record's 149 for its owner name, as a suffix of a domain name. This 150 substitution has to be applied for every BNAME RR found in the 151 resolution process, which allows fairly lengthy valid chains of BNAME 152 RRs. 154 3.2. The BNAME Substitution 156 A BNAME substitution is performed by replacing the suffix labels of 157 the name or the whole name being sought matching the owner name of 158 the BNAME resource record with the string of labels in the RDATA 159 field. The matching labels end with the root label in all cases. 160 Only whole labels are replaced. 162 3.3. The BNAME Rules 164 There are two rules which governs the use of BNAMEs in a zone file. 165 The first one is that there SHOULD be no descendants under the owner 166 of the BNAME. The second one is that no resource records can co- 167 exist with the BNAME for the same name except the DNSSEC related 168 resource record types. It means that if a BNAME RR is present at a 169 node N, there MUST be no other data except the DNSSEC related 170 resource record types at N and no data at any descendant of N. This 171 restriction applies only to records of the same class as the BNAME 172 record. 174 3.4. BNAME Examples 176 The table below shows some examples of the BNAME usage. 178 QNAME owner BNAME target result 179 ---------------- -------------- -------------- ----------------- 180 com. example.com. example.net. 181 com. com. net. net. 182 example.com. example.com. example.net. example.net. 183 a.example.com. example.com. example.net. a.example.net. 184 a.b.example.com. example.com. example.net. a.b.example.net. 185 ab.example.com. b.example.com. example.net. 186 bar.example.com. example.com. example.net. bar.example.net. 187 a.b.example.com. b.example.com. example.net. a.example.net. 188 a.example.com. example.com. b.example.net. a.b.example.net. 190 Table 1. BNAME Usage Examples. 192 If the owner name of the CNAME RR is regarded as the target of the MX 193 RR, it may cause some problems. Some mail servers may directly 194 connect the owner name of the CNAME instead of the name pointed by 195 CNAME for mail delivery and cause the undelivery of the mails. BNAME 196 has the similar problems with CNAME. This document specifies that 197 the owner name of the BNAME should not be the targets of some RRs 198 such as MX, SRV and PTR. In case that the owner name of the BNAME RR 199 is the target of some RRs, it should be cautious. 201 4. Query Processing 203 To exploit the BNAME mechanism the name resolution algorithms 204 [RFC1034] must be modified slightly for both servers and resolvers. 205 Both modified algorithms incorporate the operation of making a 206 substitution on a name (either QNAME or SNAME) under control of a 207 BNAME record. This operation will be referred to as "the BNAME 208 substitution". 210 4.1. Processing by Servers 212 For a server performing non-recursive service steps 3.a, 3.c and 4 of 213 section 4.3.2 [RFC1034] are changed to check for a BNAME record, and 214 to return certain BNAME records from zone data and the cache. 216 If the owner name of the bname is the suffix of the name queryed, or 217 same, when preparing a response, a server performing a BNAME 218 substitution will in all cases include the relevant BNAME RR in the 219 answer section. A CNAME RR is synthesized and included in the answer 220 section. This will help the client to reach the correct DNS data. 222 The server MUST know BNAME. The provided synthesized CNAME RR if 223 there has one, MUST have 225 The same CLASS as the QCLASS of the query, 227 TTL equal to the corresponding BNAME RR, 229 An equal to the QNAME in effect at the moment the BNAME RR 230 was encountered, and 232 An RDATA field containing the new QNAME formed by the action of 233 the BNAME substitution. 235 The revised server algorithm is: 237 1. Set or clear the value of recursion available in the response 238 depending on whether the name server is willing to provide 239 recursive service. If recursive service is available and 240 requested via the RD bit in the query, go to step 5, otherwise 241 step 2. 243 2. Search the available zones for the zone which is the nearest 244 ancestor to QNAME. If such a zone is found, go to step 3, 245 otherwise step 4. 247 3. Start matching down, label by label, in the zone. The matching 248 process can terminate several ways: 250 a. If the whole of QNAME is matched, we have found the node. 252 If the data at the node is a CNAME, and QTYPE doesn't match 253 CNAME, copy the CNAME RR into the answer section of the 254 response, change QNAME to the canonical name in the CNAME RR, 255 and go back to step 1. 257 If the data at the node is a BNAME, and QTYPE doesn't 258 match BNAME, copy the BNAME RR 259 and also a corresponding, 260 synthesized CNAME RR 261 into the answer section of the 262 response, change QNAME to the name carried as RDATA in 263 the BNAME RR, and go back to step 1. 265 Otherwise, copy all RRs which match QTYPE into the answer 266 section and go to step 6. 268 b. If a match would take us out of the authoritative data, we have 269 a referral. This happens when we encounter a node with NS RRs 270 marking cuts along the bottom of a zone. 272 Copy the NS RRs for the subzone into the authority section of 273 the reply. Put whatever addresses are available into the 274 additional section, using glue RRs if the addresses are not 275 available from authoritative data or the cache. Go to step 4. 277 c. If at some label, a match is impossible (i.e., the 278 corresponding label does not exist), look to see whether the 279 last label matched has a BNAME record. 281 If a BNAME record exists at that point, copy that record into 282 the answer section. If substitution of its for its 283 in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise 285 perform the substitution and continue. The server SHOULD 286 synthesize a corresponding CNAME record and include it in the 287 answer section. Go back to step 1. 289 If there was no BNAME record, look to see if the "*" label 290 exists. 292 If the "*" label does not exist, check whether the name we are 293 looking for is the original QNAME in the query or a name we 294 have followed due to a CNAME. If the name is original, set an 295 authoritative name error in the response and exit. Otherwise 296 just exit. 298 If the "*" label does exist, match RRs at that node against 299 QTYPE. If any match, copy them into the answer section, but 300 set the owner of the RR to be QNAME, and not the node with the 301 "*" label. Go to step 6. 303 4. Start matching down in the cache. If QNAME is found in the cache, 304 copy all RRs attached to it that match QTYPE or BNAME RR into the answer 305 section. If QNAME is not found in the cache but a BNAME record is 306 present at an ancestor of QNAME, copy that BNAME record into the 307 answer section. If there was no delegation from authoritative 308 data, look for the best one from the cache, and put it in the 309 authority section. Go to step 6. 311 5. Use the local resolver or a copy of its algorithm (see resolver 312 section of this memo) to answer the query. Store the results, 313 including any intermediate CNAMEs and BNAMEs, in the answer 314 section of the response. 316 6. Using local data only, attempt to add other RRs which may be 317 useful to the additional section of the query. Exit. 319 Note that there will be at most one ancestor with a BNAME as 320 described in step 4 unless some zone's data is in violation of the 321 no-descendants limitation of the owner of the BNAME. If 322 some descedants are found when a BNAME record is encountered, 323 the server can stop search of step 3c or 324 step 4. 326 4.2. Processing by Resolvers 328 A resolver or a server providing recursive service must be modified 329 to treat a BNAME as somewhat analogous to a CNAME. The resolver 330 algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d 331 as 4.e and insert a new 4.d. The complete algorithm becomes: 333 1. See if the answer is in local information, and if so return it to 334 the client. 336 2. Find the best servers to ask. 338 3. Send them queries until one returns a response. 340 4. Analyze the response, either: 342 a. if the response answers the question or contains a name error, 343 cache the data as well as returning it back to the client. 345 b. if the response contains a better delegation to other servers, 346 cache the delegation information, and go to step 2. 348 c. if the response shows a CNAME and that is not the answer 349 itself, cache the CNAME, change the SNAME to the canonical name 350 in the CNAME RR and go to step 1. 352 d. if the response shows a BNAME and that is not the answer 353 itself, cache the BNAME and the CNAME if there has one. 354 If substitution of the BNAME's 355 for its in the SNAME would overflow the legal 356 size for a , return an implementation-dependent 357 error to the application; otherwise perform the substitution 358 and go to step 1. 360 e. if the response shows a server failure or other bizarre 361 contents, delete the server from the SLIST and go back to step 362 3. 364 A resolver or recursive server which understands BNAME records but 365 sends non-extended queries MUST augment step 4.c by deleting from the 366 reply any CNAME records which have an which is a subdomain of 367 the of any BNAME record in the response. 369 5. Signaling of BNAME 371 A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can 372 be used to signal that the resolvers can understand BNAME. BNAME 373 aware resolvers can set the Understand-BNAME (UB bit) to receive a 374 response without the synthesized CNAME or DNAME. The UB bit is part 375 of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers MUST 376 set this in a query to know BNAME. 378 Below are Updated EDNS extended RCODE and Flags fields [RFC2671]: 380 +0 (MSB) +1 (LSB) 381 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 382 0: | EXTENDED-RCODE | VERSION | 383 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 384 2: |DO|UB| Z | 385 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 387 6. BNAME in DNSSEC 389 6.1. BNAME-aware Resolvers 391 With the deployment of DNSSEC, more and more servers and resolvers 392 will support DNSSEC. In order to make BNAME valid in DNSSEC 393 verification, the DNSSEC enabled resolvers and servers MUST support 394 BNAME. 396 The BNAME aware resolvers MUST set DO bit and UB bit when sending 397 DNSSEC queries to servers. The synthesized CNAME in the answer 398 section for the BNAME may not be signed if there has one. DNSSEC 399 validators MUST understand BNAME, verify the BNAME and then checking 400 that the CNAME was properly synthesized in order to verify the 401 synthesized CNAME. The BNAME enabled resolver (validator) should do 402 somewhat analogous to a CNAME for further query. 404 In any negative response, the NSEC or NSEC3 [RFC5155] record type bit 405 map SHOULD be checked to see that there was no BNAME that could have 406 been applied. If the BNAME bit in the type bit map is set and the 407 query type is not BNAME, then BNAME substitution should have been 408 done. 410 6.2. Compatibility with BNAME unaware resolvers 412 In order to have a compatibility with BNAME unaware resolvers, the 413 BNAME aware servers receiving queries from BNAME unaware resolvers 414 with DO bit set but no UB bit set should do the following things if 415 BNAME is put into the response and the query type is not BNAME: 417 o Issue the corresponding CNAME signature when querying the same 418 owner name with BNAME based on the question name, and put into the 419 answer section. 421 o Issue the corresponding DNAME and its signature when querying the 422 children of the same owner name of BNAME based on the question 423 name, and put into the answer section. 425 In order to satisfy the BNAME query, the server should prepares the 426 siganture of CNAME and DNAME of the owner name of the BNAME 427 beforehand. 429 The BNAME unaware resolvers with DNSSEC enabled are supposed to 430 neglect the BNAME RR. If the corresponding CNAME signature is found, 431 the validators will use it to verify the CNAME. If the corresponding 432 CNAME signature is not found, but the corresponding DNAME with 433 signature is found, the validators will use it to verify the CNAME. 435 7. IANA Considerations 437 This document updates the IANA registry "DOMAIN NAME SYSTEM 438 PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub- 439 registry "TYPES", by defining one new type. IANA is requested to 440 assign the number to BNAME. 442 8. Security Considerations 444 CNAME, DNAME, and BNAME may form a loop chain, which will cause the 445 unresolvable of some names. The BNAME should avoid point to some 446 name which is the owner name of CNAME or DNAME RRs. 448 9. Acknowledgements 450 Because the BNAME is very similar to DNAME, the authors learn a lot 451 from [RFC2672]. Many ideas are from the discussion in the DNSOP and 452 DNSEXT mailling list. Thanks a lot to all in the list. Many 453 important comments and suggestions are contributed by many members of 454 the DNSEXT and DNSOP WGs. The authors especially thanks the 455 following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George 456 Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving 457 this document. 459 10. Change History 461 [[CREF1: RFC Editor: Please remove this section.]] 463 10.1. draft-yao-dnsext-bname: Version 00 465 o Bundle DNS Name Redirection 467 10.2. draft-yao-dnsext-bname: Version 01 469 o Improve the algorithm 471 o Improve the text 473 10.3. draft-yao-dnsext-bname: Version 02 475 o Add the DNSSEC discussion 477 o Improve the text 479 10.4. draft-yao-dnsext-bname: Version 03 481 o Update the DNSSEC discussion 483 o Update the IANA consideration 485 10.5. draft-yao-dnsext-bname: Version 04 487 o Improve the text 489 10.6. draft-yao-dnsext-bname: Version 05 491 o add section: bname examples 493 o add section: Signaling of BNAME 495 10.7. draft-yao-dnsext-bname: Version 06 497 o redesign with DNSSEC verification 499 o Issue the corresponding CNAME signature when querying the same 500 owner name with BNAME based on the question name when UB is not 501 set 503 o Issue the corresponding DNAME and its signature when querying the 504 children of the same owner name of BNAME based on the question 505 name when UB is not set 507 11. References 509 11.1. Normative References 511 [ASCII] American National Standards Institute (formerly United 512 States of America Standards Institute), "USA Code for 513 Information Interchange", ANSI X3.4-1968, 1968. 515 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 516 RFC 2671, August 1999. 518 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 519 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 520 . 522 [RFC1035] Mockapetris, P., "Domain names - implementation and 523 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 524 November 1987, . 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, 528 DOI 10.17487/RFC2119, March 1997, 529 . 531 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 532 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 533 RFC 2136, DOI 10.17487/RFC2136, April 1997, 534 . 536 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 537 RFC 2671, DOI 10.17487/RFC2671, August 1999, 538 . 540 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 541 RFC 2672, DOI 10.17487/RFC2672, August 1999, 542 . 544 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 545 "Internationalizing Domain Names in Applications (IDNA)", 546 RFC 3490, March 2003. 548 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 549 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 550 2003, . 552 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 553 10646", RFC 3629, November 2003. 555 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 556 Engineering Team (JET) Guidelines for Internationalized 557 Domain Names (IDN) Registration and Administration for 558 Chinese, Japanese, and Korean", RFC 3743, 559 DOI 10.17487/RFC3743, April 2004, 560 . 562 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 563 Rose, "DNS Security Introduction and Requirements", 564 RFC 4033, DOI 10.17487/RFC4033, March 2005, 565 . 567 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 568 Rose, "Resource Records for the DNS Security Extensions", 569 RFC 4034, DOI 10.17487/RFC4034, March 2005, 570 . 572 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 573 Rose, "Protocol Modifications for the DNS Security 574 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 575 . 577 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 578 Security (DNSSEC) Hashed Authenticated Denial of 579 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 580 . 582 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 583 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 584 . 586 11.2. Informative References 588 [RFC2672bis] 589 Rose, S. and W. Wijngaards, "Update to DNAME Redirection 590 in the DNS", ietf-dnsext-rfc2672bis-dname-17.txt (work in 591 progress), 6 2009. 593 Authors' Addresses 595 Jiankang YAO 596 CNNIC 597 No.4 South 4th Street, Zhongguancun 598 Beijing 600 Phone: +86 10 58813007 601 Email: yaojk@cnnic.cn 603 Xiaodong LEE 604 CNNIC 605 No.4 South 4th Street, Zhongguancun 606 Beijing 608 Phone: +86 10 58813020 609 Email: xl@cnnic.cn 610 Paul Vixie 611 CNNIC-Farsight Joint Laboratory 612 4 South 4th Street,Zhongguancun,Haidian District 613 Beijing, Beijing 100190 614 China 616 Phone: +1 650 489 7919 617 Email: vixie@fsi.io