idnits 2.17.1 draft-ietf-idn-iptr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 45 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 27 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 31: '...he problem of how an IP address SHOULD...' RFC 2119 keyword, line 86: '... CNAME MUST continue to work for IPTR...' RFC 2119 keyword, line 93: '...olving IPTR type MUST have the followi...' RFC 2119 keyword, line 96: '...IPTR, the corresponding IDNs SHOULD be...' RFC 2119 keyword, line 99: '...ers in the label MUST be encoded using...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The "foo1.example" in following samples MAY or MAY NOT be represented in the same characters. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: will exist also. And "foo2.example" MUST be different from "foo1.example", if they are in signed with same LANGUAGE. Or a "Syntax Error" SHOULD be sent back, when an administrator config-ures the zone files. Furthermore "foo2.example" in the samples above MAY or MAY NOT be represented in the same characters. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 57, but not defined == Unused Reference: 'IDNREQ' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'ISO 639' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'ISO 3166' is defined on line 409, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'IDNREQ' -- Possible downref: Normative reference to a draft: ref. 'IDNE' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 639' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Hongbo Shi 3 draft-ietf-idn-iptr-01.txt Waseda University 4 17 November 2000 Jiang Ming Liang 5 Expires: 17 May 2001 i-DNS.net 7 Internationalized PTR Resource Record (IPTR) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This draft attempts to address the problem of how an IP address SHOULD 32 be properly mapped to a set of Internationalized Domain Names(IDNs). 33 It is currently unspecified how a PTR record can be used for this 34 purpose. In addition, the syntax of the PTR resource record may be 35 too restrictive for such a mapping in a more culturally meaningful 36 context. This document suggests a new TYPE called IPTR using EDNS0 37 and a mechanism to combined language information with such a mapping. 39 1. Introduction 41 Reverse mapping is a very important and essential function in the DNS. 42 In today's Domain Name System, PTR RRs are used to support address- 43 to-domain mappings. However, a current PTR RR does not provide support 44 for proper address-to-IDN mappings, without certain modifications. 45 Modifying the PTR structure will also affect the current reverse 46 mapping architecture. This document describes a new RR TYPE named IPTR 47 to provide address-to-IDN mappings and it also specifies that on 48 receiving of a IPTR query a name server should respond with all the 49 corresponding IPTR RRs in one response. In short, "one IP several 50 IDNs". 52 1.1 Terminology 54 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 55 and "MAY" in this document are to be interpreted as described in RFC 56 2119 [RFC2119]. 58 1.2 Background and Designs 60 When Internationalized Domain Names come into wide use, an Internet 61 host is likely to have domain names in different languages. In 62 today's Internet, even thought the [RFC2181] redefine the 63 consideration of PTR, because of the design of the PTR mapping 64 algorithm and implementation of most resolvers, IP address to domain 65 names mapping is still limited to "one IP one domain name". 67 For example, BIND treats PTRs specially so that the normal sorting 68 preference (e.g. cyclic/random) doesn't apply. But as usual, "fixed" 69 order is always used. So a client that is querying a BIND server and 70 doesn't look beyond the first PTR RR, no matter how many times it 71 queries the name. In other words, PTR RRset is different from A RRset, 72 where the first record in the RRset might differ from query to query. 74 This is more restrictive in a world of IDNs, for choosing some names 75 in a particular language. Briefly, according to the use of PTR, it is 76 no meaning of returning an IDN in an unknown language. 78 The authors also believe that putting language information into 79 address-to-name mappings will be benifitial to future applications. 81 The design purpose of the IPTR RR type is to provide a mechanism that 82 can map an IP address to the corresponding IDN per language. It also 83 means that IPTR suggests a new mapping algorithm for the reverse 84 mapping by using an language information. 86 CNAME MUST continue to work for IPTR as it works now for PTR records. 88 The behavior of a resolver on the use of IPTR will be specified in a 89 seperate draft or a later version of this draft. 91 1.3 Functional Description 93 DNS query and responses involving IPTR type MUST have the following 94 properties: 96 - When the QTYPE is IPTR, the corresponding IDNs SHOULD be 97 returned in one response. 99 - The characters in the label MUST be encoded using UTF-8 100 [RFC2279]. 102 - The entire label MUST be encoded EDNS [RFC2671]. 104 - An exceptional handling of PTR for the IDN is REQUIRED. 106 2. IPTR definition 108 The structure of an IPTR RR is somewhat like the MX RR. In addtion to 109 the IP address in the IN-ADDR.ARPA domain and the domain name field 110 (similar to a PTR RR), a new field called LANGUAGE has been defined. 111 A domain name in an IPTR RR MUST be encoded in UTF8. And IDN in this 112 document MUST be NAMEPREPPED. [NAMEPREP] Below is an example of an 113 IPTR RR: 115 1.2.3.4.IN-ADDR.ARPA. IPTR "LANGUAGE" "name-in-utf8" 117 [RFC1766] describes the ISO 639/ISO 3166 conventions. A language name 118 is always written in lower case, while country codes are written in 119 upper case. At here, the "LANGUAGE" field in an IPTR RR SHOULD be done 120 in a case-insensitive manner and MUST follow the conventions defined 121 in [RFC1766]. 123 For Example: 125 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name-in-utf8" 126 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name-in-utf8" 127 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-JP" "name-in-utf8" 128 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name-in-utf8" 130 The notion of canonical names and aliases described in 3.6.2 131 [RFC1034], and 10.2 [RFC2181] MUST be preserved for IPTR record types. 132 An IPTR RR SHOULD be limited to one primary IDN per LANGUAGE, similar 133 to the a PTR RR. 135 3. IPTR on IPv6 136 Mapping IPv6 to IDNs can be similarly supported. This document recom- 137 mands to continue using the IP6.INT domain defined in [RFC1886] for 138 IPTR mappings. For example, the lookup corresponding to the address 139 4321:0:1:2:3:4:567:89ab would be: 140 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. 141 IPTR "LANGUAGE" "name-in-utf8" 143 4. Packet format for IPTR 145 EDNS0[RFC2671] is REQUIRED to implement IPTR. 147 0 1 2 3 4 148 bits 0 1 2 3 4 5 6 7 8 9 0 1...9 0...8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 ... 149 +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+ 150 |0 1| ELT | LANGUAGE | Size | IDN label... | 151 +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+ 153 LANGUAGE: An argument for IPTR to define the kind of language 154 used in the following IDN label. The size is 2 octets. 155 ELT: To be defined in [IDNE]. 157 5. Coexistence 159 5.1 IDN Consideration 161 IPTR described above is based on "a set of IDNs", strictly speaking, a 162 set of canonical IDNs. On the other hand, confusion about IDN, such as 163 "IDN MUST exist with ASCII domain name" has led to a belief that PTR 164 record should have exactly RRs in its RRSet. In short, the phenomenon 165 "IDN ONLY" will exist. Thus, the exceptional handling of PTR is 166 REQUIRED. 168 On the other hand, IDN is still RECOMMENDED to exist with more than 169 one ASCII domain name. 171 5.2 PTR Extension 173 In the case of "IDN ONLY", if IPTR RR is not NULL, PTR RR MUST contain 174 a domain name in ACE to coexist with those IDN unaware systems. Else a 175 "Syntax Error" message SHOULD be sent back, when an administrator con- 176 figures DNS zone files. 178 5.3 IPTR and PTR 180 It is a kind of backward compatible handle for those IDN unaware sys- 181 tems that can not provide the IPTR function. Besides, if a client can 182 not find the corresponding LANGUAGE IDN finally, then the correspond- 183 ing PTR RR SHOULD be used as the answer. 185 6. IPTR query/response 187 When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs 188 SHOULD be returned in one response. DNS messages are limited to 512 189 octets or less in size when sent over UDP. Therefore, if all the RRs 190 cannot fit in one UDP packet, this draft describe two solutions. One 191 is for recent environment and the other is for the near future. 193 6.1 Transport 195 Today, DNS queries and responses are carried in UDP datagrams or over 196 TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be 197 returned in one response. The size of a DNS message could exceed 512 198 octets, when multiple RRs are present. Therefore, this draft makes the 199 two following recommendations. 201 - "Use UDP first, if UDP is not large enough then change to TCP" is 202 RECOMMENDED. 204 The server MUST send back the response with the TC bit set. Then 205 the resolver SHOULD resend the query using TCP on server port 206 53(decimal). This behavior is consistent with the current DNS 207 specification [RFC1035]. 209 - In future, EDNS0 is REQUIRED to send large packets. 211 Then, before a client send a query to ask for IPTR record, it 212 MUST query the server whether it knows the EDNS0 first. If the 213 server knows EDNS0, then the client MAY send the IPTR query. 214 Else, unfortunally, the client MUST change the QTYPE to PTR. 216 Hence, the size of the UDP payload is no longer limited to 512 217 octets any more. 219 6.2 Standard sample 221 A resolver who wants to find the IDNs corresponding to an IP 222 address 1.2.3.4 whould pursue a query of the form QTYPE=IPTR, 223 QCLASS=IN, QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive: 225 +------------------------------------------------------+ 226 Header | OPCODE=SQUERY, RESPONSE, AA | 227 +------------------------------------------------------+ 228 Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR | 229 +------------------------------------------------------+ 230 Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" | 231 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name2-in-utf8" | 232 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-JP" "name3-in-utf8" | 233 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name4-in-utf8" | 234 +------------------------------------------------------+ 235 Authority | ... | 236 +------------------------------------------------------+ 237 Additional | ... | 238 +------------------------------------------------------+ 240 7. IPTR Usage 242 The "foo1.example" in following samples MAY or MAY NOT be 243 represented in the same characters. 245 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8" 246 IPTR "zh-CN" "[foo1.example] in utf8" 247 IPTR "ja-JP" "[foo1.example] in utf8" 248 IPTR "ko-KR" "[foo1.example] in utf8" 250 Moreover, 252 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8" 253 IPTR "zh-TW" "[foo2.example] in utf8" 254 ... 255 IPTR "zh-CN" "[foo1.example] in utf8" 256 IPTR "zh-CN" "[foo2.example] in utf8" 257 ... 258 IPTR "ja-JP" "[foo1.example] in utf8" 259 IPTR "ja-JP" "[foo2.example] in utf8" 260 ... 261 IPTR "ko-KR" "[foo1.example] in utf8" 262 IPTR "ko-KR" "[foo2.example] in utf8" 263 ... 265 will exist also. And "foo2.example" MUST be different from 266 "foo1.example", if they are in signed with same LANGUAGE. Or a 267 "Syntax Error" SHOULD be sent back, when an administrator config- 268 ures the zone files. Furthermore "foo2.example" in the samples 269 above MAY or MAY NOT be represented in the same characters. 271 Thus, 273 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8" 274 IPTR "zh-TW" "[samefoo.sample] in utf8" 276 occurs a "Syntax Error". 278 And, 280 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8" 281 IPTR "zh-TW" "[difffoo.sample] in utf8" 282 IPTR "zh-CN" "[samefoo.sample] in utf8" 283 IPTR "ja-JP" "[samefoo.sample] in utf8" 284 IPTR "ko-KR" "[samefoo.sample] in utf8" 286 is allowed. 288 8. Open Issues 290 1. Is it necessary to let a IDN aware server to send back all of 291 the corresponding IDNs to a resolver? Meanings, 293 +------------------------------------------------------+ 294 Header | OPCODE=SQUERY, RESPONSE, AA | 295 +------------------------------------------------------+ 296 Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR | 297 +------------------------------------------------------+ 298 Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" | 299 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name2-in-utf8" | 300 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name3-in-utf8" | 301 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name4-in-utf8" | 302 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name5-in-utf8" | 303 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name6-in-utf8" | 304 +------------------------------------------------------+ 305 Authority | ... | 306 +------------------------------------------------------+ 307 Additional | ... | 308 +------------------------------------------------------+ 310 Or, just using current fixed/cyclic/random options to return 311 one of the corresponding IDNs per LANGUAGE? In short, "one IP 312 one IDN per LANGUAGE". Such like 313 +------------------------------------------------------+ 314 Header | OPCODE=SQUERY, RESPONSE, AA | 315 +------------------------------------------------------+ 316 Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR | 317 +------------------------------------------------------+ 318 Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" | 319 | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name4-in-utf8" | 320 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name5-in-utf8" | 321 | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name6-in-utf8" | 322 +------------------------------------------------------+ 323 Authority | ... | 324 +------------------------------------------------------+ 325 Additional | ... | 326 +------------------------------------------------------+ 328 2. If QTYPE is IPTR, should an IDN aware server send all of the 329 corresponding IDNs to the resolver? Is this kind of behavior 330 friendly to implent the resolver? How about letting a server 331 just feedback the corresponding PTR record, if a server 332 doesn't find the corresponding LANGUAGE IDN that a client 333 requires. 335 In the following case, it is wasteful to return all the 336 corresponding IDNs to the clients. 338 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8" 339 IPTR "zh-TW" "[foo2.example] in utf8" 340 ... 341 IPTR "zh-CN" "[foo1.example] in utf8" 342 IPTR "zh-CN" "[foo2.example] in utf8" 343 ... 344 IPTR "ja-JP" "[foo1.example] in utf8" 345 IPTR "ja-JP" "[foo2.example] in utf8" 346 ... 347 IPTR "ko-KR" "[foo1.example] in utf8" 348 IPTR "ko-KR" "[foo2.example] in utf8" 349 ... 351 The benefit of the IPTR is introducing LANGUAGE. It SHOULD be 352 used in query from clients, then servers can select minimum 353 size of corresponding IDNs. For working this effectively, you 354 should introduce default LANGUAGE if no corresponding LANGUAGE 355 exists. The default MUST be ASCII. So that default IPTR can be 356 natural extension of PTR. I.E. 358 4.3.2.1.in-addr.arpa. IN PTR ASCII-domain-name 360 is equivalent to 362 4.3.2.1.in-addr.arpa. IN IPTR "default" ASCII-domain-name 364 Of course, ASCII includes ACE. 366 3. According to the consideration above, how about the following 367 thinking? That means a response MAY include not only a 368 corresponding IDN in a specific LANGUAGE but also the LANGUAGE 369 tags of the corresponding IDNs. And the client will load these 370 LANGUAGE tags in the DNS cache for the next IPTR query. 372 References 374 [IDNREQ] Zita Wenzel & James Seng, "Requirements of International- 375 ized Domain Names", draft-ietf-idn-requirements. 377 [IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain 378 names using EDNS", draft-ietf-idn-idne. 380 [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of Interna- 381 tionalized Host Names", draft-ietf-idn-nameprep. 383 [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 384 November 1987, RFC1034 386 [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND 387 SPECIFICATION", November 1987, RFC1035 389 [RFC1766] H. Alvestrand, "Tags for the Identification of 390 Languages", March 1999, RFC 1766 392 [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP 393 version 6", December 1995, RFC1886 395 [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specifica- 396 tion", July 1997, RFC2181 398 [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO 399 10646", January 1998, RFC 2279. 401 [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", 402 August 1999, RFC 2671. 404 [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names 405 of languages - The International Organization for Standardization, 406 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology 407 (principles and coordination). 409 [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of 410 names of countries - The International Organization for Standardi- 411 zation, 3rd edition, 1988-08-15. 413 Acknowledgements 415 James Seng and Yoshiro Yoneya have given many comments in our e- 416 mail discussions. Harald Alvestrand, Mark Davis have given many 417 suggestions in the idn-wg mailing list discussions. And there are 418 also a lot of people who have given us their comments in the idn-wg 419 and BIND-user mailing list discussions. 421 Authors' Information 423 Hongbo Shi 424 Waseda University 425 3-4-1 Okubo, Shinjyuku-ku 426 Tokyo, 169-8555 Japan 427 shi@goto.info.waseda.ac.jp 429 Jiang Ming Liang 430 i-DNS.net 431 8 Temasek Boulevard 432 #24-02 Suntec Tower Three 433 Singapore 038988 434 jiang@i-DNS.net