RFC 6927

Variants in Second-Level Names Registered in Top-Level Domains

📅 published May 2013, from ietf

RFC 6927: Variants in Second-Level Names Registered in Top-Level Domains 🦋

Okay bestie, here's the header info first 💅

  • Stream: Independent Submission
  • Category: Informational
  • Date: May 2013
  • ISSN: 2070-1721
  • Authors: J. Levine (Taughannock Networks) and P. Hoffman (VPN Consortium)
  • Obsoletes/Updates: The title block doesn't list any RFCs being obsoleted or updated.

Abstract ✨

Okay so, Internationalized Domain Names for Applications (IDNA) gives us a way to map a subset of Unicode names into the DNS 🌸 Because of Unicode decisions, how things look, language and writing system habits, and history, people have often said there's more than one way to write what competent readers and writers see as the same host name 👀 Those different spellings are usually called "variants" 🦋 (The authors also point out that the IDNA community has lots of conflicting definitions for "variant", which is a whole mood 😭)

This document looks at how top-level domains have handled registering and provisioning domain names that have variants 💜 It's not an IETF product, it doesn't propose any method to make variants work "correctly", and it's not an intro to internationalization or IDNA. Just a survey, babe 🧚

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🌈

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅

More info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6927 🎀

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions regarding this document 🫶

Table of Contents 🌸

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Base Documents ..................................................5
4. Domain Practices of gTLDs .......................................6
   4.1. AERO .......................................................6
   4.2. ASIA .......................................................6
   4.3. BIZ ........................................................6
   4.4. CAT ........................................................6
   4.5. COM ........................................................7
   4.6. COOP .......................................................7
   4.7. INFO .......................................................7
   4.8. JOBS .......................................................7
   4.9. MOBI .......................................................7
   4.10. MUSEUM ....................................................8
   4.11. NAME ......................................................8
   4.12. NET .......................................................8
   4.13. ORG .......................................................8
   4.14. POST ......................................................9
   4.15. PRO .......................................................9
   4.16. TEL .......................................................9
   4.17. TRAVEL ...................................................10
   4.18. XXX ......................................................10
5. Domain Practices of ccTLDs .....................................10
   5.1. BG ........................................................10
   5.2. BR ........................................................10
   5.3. CL ........................................................10
   5.4. CN ........................................................10
   5.5. ES ........................................................11
   5.6. EU ........................................................11
   5.7. GR ........................................................11
   5.8. IL ........................................................11
   5.9. IR ........................................................11
   5.10. JP .......................................................11
   5.11. KR .......................................................12
   5.12. MY .......................................................12
   5.13. NZ .......................................................12
   5.14. PL .......................................................12
   5.15. RS .......................................................12
   5.16. RU .......................................................12
   5.17. SA .......................................................12
   5.18. SE .......................................................13
   5.19. TW .......................................................13
   5.20. UA .......................................................13
   5.21. VE .......................................................13
   5.22. XN--90A3AC ...............................................13
   5.23. XN--MGBERP4A5D4AR ........................................13
6. Acknowledgements ...............................................13
7. Security Considerations ........................................14
8. Informative References .........................................14

1. Introduction ✨

Okay so, IDNA [RFC5890] lets host names in the DNS [RFC1035] include characters from the Unicode repertoire 🌍 Some Unicode characters are considered "variants" of one another 👀 Because of the 20th century reform of Chinese writing, there's often more than one representation of what Chinese speakers see as the same character 🀄 Some languages written in Latin characters with accents and diacritical marks, called decorated characters, let you leave the decorations off in some situations. For example, French sometimes drops accents on capital letters, depending on country and culture 💅 Since it's hard to represent decorated characters in ASCII systems, lots of users have informally used undecorated characters in DNS host names, even when they aren't linguistically equivalent to the decorated versions 🙈

There's no single agreed-on definition of "variant" (I'm screaming 😭). In 2012, ICANN said that variants "occur when a single conceptual character can be identified with two or more different Unicode Code Points with graphic representations that may be visually similar" (this definition used to live at http://www.icann.org/en/resources/idn/variant-tlds). ICANN's IDN Variant Issues Project report [VIPREPORT] says that "[t]here is today no fully accepted definition for what may constitute a variant relationship between top-level labels". RFC 3743 [RFC3743] (an Informational RFC, not an IETF product) says the idea of variants is "wherein one conceptual character can be identified with several different Code Points in character sets for computer use" 🦋

Handling variant names has been a topic of lots of debate and research, with very little consensus on how to handle them or even which characters are variants of each other 🌈 Many people would love variant names to behave "the same", and "same" means a bunch of different things to different people. Sometimes it's textual similarity, like variants having matching DNS records. Sometimes it's functional similarity, like variant names resolving to the same web server. And sometimes it's user experience similarity, like names resolving to websites that aren't identical but humans perceive as equivalent ✨

This document gives a snapshot of variant handling in the top-level domains (TLDs) contracted by ICANN, which are the so-called gTLDs (generic TLDs) and sTLDs (sponsored TLDs), as of late 2012 💖 We picked these because ICANN requires each TLD to describe its IDN and variant practices, and the TLD zone files are available for inspection, so we can verify what actually goes into the zones 🔍 The document also includes a small sampling of so-called ccTLDs (country code TLDs, the TLDs made of two ASCII letters) where we could find information 🌸

Since "variant" can mean vastly different things to different people, there's also no agreement about when two zones are supposed to "behave the same". Also, the gTLDs and sTLDs might have different views of what variants are, and what they're required to report to ICANN about their policies 🫠

2. Terminology 📚

We use some terminology that has become generally agreed on when talking about variant names. We openly admit that this agreement isn't complete and the terminology keeps changing 🦋

Bundle: The IDN practices documents (see below) can identify sets of code points that are considered variants of each other using Language Variant Tables, defined in [RFC3743]. A set of names in which the characters in each position are variants is known as a bundle or, more technically, as an "IDL Package". The variant rules vary among languages, and for the same language they can vary among TLDs. Many languages don't define variant characters and therefore don't have bundles 🧁

Allocated: A name is allocated if sponsorship of that label in some zone has been granted. This is similar to what many people call "registered" 💜

Active: A name is active if it appears as an owner name in a zone. Most allocated names are active, but some aren't 👀

Blocked: Some names can't be registered at all. For example, some registries allow one name in a bundle to be registered and block the rest 🚫

Withheld: Some names can only be allocated under certain conditions. For example, some registries only permit the registrant of one name in a bundle to register or activate other names in the same bundle 🔐

Parallel NS: Multiple names in a bundle are provisioned in the TLD with identical NS records, so they're all handled by the same name servers 👯‍♀️

DNAME aliasing: The DNAME [RFC6672] DNS record creates a shadow tree of DNS records, roughly as though there were a CNAME in the shadow tree pointing to each name in the target tree. DNAMEs have been used both to provide resolution for several names in a bundle and to provide resolution for every name under a TLD 🌟

3. Base Documents ✨

okay so ICANN has put out a bunch of docs on variant management 🫶 the big ones are the "Guidelines for the Implementation of Internationalized Domain Names" in Version 1.0 [G1] and Version 3.0 [G3]. main character docs, honestly 💅

ICANN says that TLDs are supposed to register an IDN practices document with IANA for each language and/or script where the TLD takes IDN registrations, and those go in the IANA Repository of IDN Practices [IANAIDN] 📚 the practices document lists the Unicode characters that are allowed in names for that language or script, which characters count as equivalent, and which one in an equivalent group is preferred 🎀

ngl, some TLDs have been way more diligent than others about keeping the registry up to date 💀 some have tables for a few languages and scripts, while others (notably .COM, .NET, and .NAME) have a huge set of tables, including some for languages and scripts that nobody speaks or uses anymore, like Runic and Ogham 🧚 the authors also noticed that a lot of the tables in the IANA registry are clearly out of date, with URLs to policy pages that don't exist anymore and contact info for people who have left the registry 😭

some of the ICANN agreements with each TLD [ICANNAGREE] describe the TLD's IDN practices, but most don't 🙈

4. Domain Practices of gTLDs 🌈

this list covers most of the current gTLDs 🦋 in most cases, the authors also checked the zone files for the gTLD to verify or add to the policy description 🔍

4.1. AERO

the .AERO TLD has no IDNs and no rules or practices for them ✈️

4.2. ASIA

the .ASIA domain takes registrations in lots of Asian languages 🌸 they have IANA tables for Japanese, Korean, and Chinese. the IANA tables point to their CJK IDN policies [ASIACJK], which say that applied-for and preferred IDN variants are "active and included in the zone". no IDN publication mechanism is described in the docs, but since the zone file has no DNAMEs, they must be using parallel NS for variants 🧠✨

4.3. BIZ

ICANN gave the registry (Neustar) non-specific permission to register IDNs in a 2004 letter [TWOMEY04A] 💼 the IDN rules were apparently discussed with ICANN but never actually defined. see Appendix 9 of the registry agreement [ICANNBIZ9] 👀

they have about a dozen IANA tables. no IDN publication mechanism is described, but from inspection, it appears that variants are blocked 🚫

4.4. CAT

the IDN rules are described in Appendix S, Part VII.2 [ICANNCATS] of the ICANN agreement. the quote is "Registry will take a very cautious approach in its IDN offerings. IDNs will be bundled with the equivalent ASCII domains" 🥹 the only language is Catalan. no IDN publication mechanism is described 💜

Appendix S includes "The list of non-ASCII-characters for Catalan language and their ASCII equivalent for the purposes of the defined service", which implicitly describes bundles. the bundles are made of names with accented and unaccented vowels, U+00E7 ("c with cedilla") and a plain c, and the Catalan "ela geminada" written as two l's separated by a U+00B7 ("middle dot") and the three characters "l-l" 🍓

when a registrant registers an IDN, the registry also includes the ASCII version. from looking at the zone file, the ASCII version is provisioned with NS, and the IDN is a DNAME alias of the ASCII version 🫧

4.5. COM

ICANN and Verisign have a LOT of correspondence about IDNs and variants, including letters to ICANN from Ben Turner [TURNER03] and Russell Lewis [LEWIS03] 📝

the IANA registry has tables for several dozen languages, including archaic ones like hieroglyphics and Aramaic 🏛️ Verisign publishes docs describing scripts and languages [VRSNLANG], character variants [VRSNCHAR], registration rules [VRSNRULES], and additional registration logic [VRSNADDL] ✨

in Chinese, variants are blocked (see [VRSNADDL]). in other languages, there's no bundling or blocking 🙌

4.6. COOP

the .COOP TLD has no IDNs and no rules or practices for them 🤍

4.7. INFO

the IANA registry has a table for German. the German table notes that "the Eszet ... character used in the German script will be mapped to a double 's' string (i.e. 'ss')" 🥨 the domain also offers names in Greek, Russian, Arabic, Korean, and other languages. the list and IDN tables are on the registry's web site [INFOTABLES] 🌍

Afilias says (not in a published policy) that it doesn't allow Korean characters with different widths and that there are no variants in .INFO 🙅‍♀️

Appendix 9 of the registry agreement [ICANNINFO9] refers to a 2003 letter from Paul Twomey [TWOMEY03] that refers to blocking variants 🔒

4.8. JOBS

the .JOBS TLD has no IDNs and no rules or practices for them 💼

4.9. MOBI

the zone file has about 22,000 IDNs 🤯 Afilias says (not in a published policy) that .MOBI supports Simplified Chinese only and that the language table for it is the same one .CN uses 🇨🇳

variant characters are blocked from registration. the domain has no tables at IANA. Appendix S of the registry agreement [ICANNMOBIS], says that IDNs are provisioned according to [G1] 📖

4.10. MUSEUM

the zone file has lots of IDNs, but spot checks find that a lot of them are lame or dead 😬 a 2004 letter from Paul Twomey [TWOMEY04] refers to [G1] 🏺

the registry has a detailed policy page [MUSEUMPOLICY] 🖼️ IDNs are accepted in Latin and Hebrew scripts, with plans for Arabic, Chinese, Japanese, Korean, Cyrillic, and Greek. they do no bundling or blocking, but names that might be confusable because they look visually similar are not allowed. these are apparently determined by manual inspection, which is practical because the domain is very small 🫶

4.11. NAME

the .NAME TLD is managed the same as .COM 🪞

4.12. NET

the .NET TLD is managed the same as .COM 🌐

4.13. ORG

a 2003 letter from Paul Twomey [TWOMEY03A] refers to [G1] 📮 the registry has a list of IDN languages [PIRIDN], several written in Latin script, plus Chinese and Korean. a Questions page [PIRFAQ] says that Chinese names have been accepted since January 2010 and Cyrillic names in seven languages since February 2011 🎉 the practices for some, but not all, of the Latin languages are registered with IANA 📋

a Chinese language policy form on the Public Interest Registry (PIR) web site says that the ZH-CN and ZH-TW IDNs use the matching ccTLD tables from IANA. check boxes say that Variant Registration Polices and Variant Management Policies are applicable, but they don't say what those policies are 🤷‍♀️

private correspondence [CHANDIWALA12] describes not-yet-public rules for variants in Chinese and Cyrillic in .ORG that restrict how many variants a registration can have 🤫

the Korean language policy form says it uses the KRNIC table for Korean from IANA and that there are no variants 🇰🇷

4.14. POST

the .POST TLD appears to have no registrations at all yet 📭

4.15. PRO

the .PRO TLD has no IDNs and no rules or practices for them 🧾

4.16. TEL

the zone has lots of IDNs 🫠 it's probably operating under a 2004 letter from Paul Twomey [TWOMEY04A] to Neustar, which didn't mention specific TLDs. its policy page [TELPOLICY] links to IDN practices for 17 languages, all but one of which are registered with IANA 🌟 none of the Latin scripts do bundling or blocking. the Japanese practices say variants are blocked 🚫

the Chinese practices document says:

Therefore, in addition to the blocking mechanism, bundling is also implemented for the Chinese language IDNs. When registering a Chinese language IDN (primary domain name) up to two additional variant domain names will be automatically registered. The first variant will consist entirely of simplified Chinese characters that correspond to those comprising the primary domain name. The second variant will consist exclusively of traditional Chinese characters that correspond to those comprising the primary domain name. The primary domain name together with the requested variants constitutes a bundle on which all operations are atomic. For example, if the registrant adds a name server to the primary domain name, all names in the bundle will be associated with that new name server.

the zone has no DNAME records, so that second paragraph strongly suggests parallel NS 🧐

the .TEL TLD, meant as an online directory, doesn't let registrants put arbitrary Resource Records (RRs) in the zone 📇 nearly all names have NS records pointing to Telnic's own name servers. the A records all point to Telnic's own web server that shows directory info. NAPTR records give telephone numbers for registrants when they're available 📞 users can only directly provision MX records. right now there are 16 domains, none of them IDNs, that point to random other name servers and mostly look parked 🅿️

4.17. TRAVEL

the .TRAVEL TLD has no IDNs and no rules or practices for them ✈️🧳

4.18. XXX

the .XXX TLD has no IDNs and no rules or practices for them 🫣

5. Domain Practices of ccTLDs 🌏

some ccTLDs publish their IDN policies 🗺️ this section is a non-exhaustive sampling of some of those policies. note that few ccTLDs make their zone files available, so the authors couldn't validate the policies by looking in the zone files 🙃

5.1. BG

the .BG TLD (for Bulgaria) publishes a policy page [BGPOLICY] 🇧🇬 it has published an IDN table for the Bulgarian and Russian languages in [IANAIDN]. the policy doesn't mention variants 🤐

5.2. BR

the .BR TLD (for Brazil) publishes a policy page [BRPOLICY] 🇧🇷 it has published an IDN table for the Portuguese language in [IANAIDN]. even though the IDN table doesn't describe variants, the policy page says that bundles are made of names that are the same once you ignore accents on vowels, cedillas on the letter "c", and inserted or deleted hyphens. only the registrant of a name in a bundle can register other names from the same bundle 🫶

5.3. CL

the .CL TLD (for Chile) publishes a policy page [CLPOLICY] 🇨🇱 it has published an IDN table for the Latin script in [IANAIDN]. the policy says that variants are not considered for registration 🚫

5.4. CN

the .CN TLD (for China) publishes its policy as [RFC4713] 🇨🇳 it has published an IDN table for the Chinese language in [IANAIDN]. the policy says that variants are "added into the zone file", presumably as NS records 🧩

5.5. ES

the .ES TLD (for Spain) publishes an IDN Area page [ESIDN] 🇪🇸 it allows ten accented vowels, U+00E7 ("c with cedilla"), U+00F1 ("n with tilde"), and the Catalan "ela geminada" written as two l's separated by a U+00B7 ("middle dot"). there are no published IDN tables, and there appears to be no variant policy 🤷‍♀️

5.6. EU

the .EU TLD (for Europe) publishes a policy page [EUPOLICY] 🇪🇺 it has published IDN tables for three scripts in [IANAIDN]. there appears to be no variant policy 💫

5.7. GR

the .GR TLD (for Greece) publishes a policy page [GRPOLICY] and an FAQ [GRFAQ] 🇬🇷 the policy says that all variants of a name under .GR are assigned to the domain owner, with the zone pointing the NS records of all the variants to the name server of the "main form" of the registered name 🧠 the FAQ says that domain names in Greek characters go into the zone in their non-punctuated form in Punycode, and that the punctuated form is linked to the non-punctuated one with a DNAME record 🪄 it does not publish IDN tables in [IANAIDN] 🥲

5.8. IL 🇮🇱

okay so the .IL TLD (for Israel) publishes a policy page [ILPOLICY] 📄 and it has published an IDN table for the Hebrew language in [IANAIDN] 💖. there is no variant policy, so nothing to juggle here 🫶

5.9. IR 🌸

the .IR TLD (for Iran) publishes a policy page [IRPOLICY] 📜. it has published an IDN table for the Persian language in [IANAIDN] ✨. the IDN table says that it will block registration of variants 🚫, but ngl the policy document says that no IDNs can be registered in .IR 💀, so the two don't fully match up, bestie 🙈

5.10. JP 🍓

the .JP TLD (for Japan) publishes a policy page [JPPOLICY] 🗾 and it has published an IDN table for the Japanese language in [IANAIDN] 🎀. every code point in that table defines no variants, which means there are no variants in registration or resolution 🦋. very clean, very iconic 💅

5.11. KR 🌈

the .KR TLD (for South Korea) appears to only publish its policy as an IDN table for the Korean language in [IANAIDN] 🧚. the policy in that table does not discuss variants 🤷‍♀️

5.12. MY 🎀

the .MY TLD (for Malaysia) appears to only publish its policy as an IDN table for the Jawi language in [IANAIDN] 📖. however, IANA lists that as a table for "Malay (macrolanguage)" 🤔, which is a whole plot twist 😭. the policy in that table does not discuss variants 💜

5.13. NZ 🥝

the .NZ TLD (for New Zealand) publishes a policy page [NZPOLICY] 🌿. it has published IDN tables for the Latin script in [IANAIDN] 💫. the policy does not discuss variants ✨

5.14. PL 🦢

the .PL TLD (for Poland) publishes a policy page [PLPOLICY] 🏰. it has published IDN tables for numerous European languages in [IANAIDN] 🌍. the policy says that it will block registration of "look-alike" variants 👀, so lookalikes get the boot 👢

5.15. RS 🌻

the .RS TLD (for Serbia) publishes a policy page [RSPOLICY] 🌟. it has published IDN tables for the Serbian language, and the Latin script, in [IANAIDN] 💌. the policy does not discuss variants 🙃

5.16. RU 🪆

the .RU TLD (for Russia) appears to only publish its policy as an IDN table for the Russian language in [IANAIDN] 📚. the policy in that table does not discuss variants 🫠

5.17. SA 🐪

the .SA TLD (for Saudi Arabia) publishes a policy page [SAPOLICY] 🕌. it has published an IDN table for the Arabic language in [IANAIDN] 🌙. the policy permits the registration of variants ✅, but it is not clear whether others can register names with variants if the owner of a name has not registered them 🥺. the vibe is "maybe, but who knows" 😅

5.18. SE 🇸🇪

the .SE TLD (for Sweden) publishes a policy page [SEPOLICY] ❄️. it has published IDN tables for the Swedish and Yiddish languages, and the Latin script, in [IANAIDN] 🪄. the policy does not discuss variants 🧁

5.19. TW 🧋

the .TW TLD (for Taiwan) appears to only publish its policy as an IDN table for the Chinese language in [IANAIDN] 🍵. the policy in that table does not discuss variants 🌷

5.20. UA 🌻

the .UA TLD (for Ukraine) publishes a policy page [UAPOLICY] 💛. it has published an IDN table for the Cyrillic script in [IANAIDN] 💙. the policy does not discuss variants 🌾

5.21. VE 🦜

the .VE TLD (for Venezuela) appears to only publish its policy as an IDN table for the Spanish language in [IANAIDN] 🌺. the policy in that table does not discuss variants 💃

5.22. XN--90A3AC 🔮

the .XN--90A3AC TLD (for Serbia) (U+0441 U+0440 U+0431) publishes a policy page [RSIDNPOLICY] 🪩. it has published IDN tables for the Cyrillic script in [IANAIDN] 🩵. the policy does not discuss variants 🫧

5.23. XN--MGBERP4A5D4AR 🕋

the .XN--MGBERP4A5D4AR TLD (for Saudi Arabia) (U+0627 U+0644 U+0633 U+0639 U+0648 U+062F U+064A U+0629) appears to only publish its policy as an IDN table for the Arabic script in [IANAIDN] 📜. the policy permits the registration of variants ✅, but it is not clear whether others can register names with variants if the owner of a name has not registered them 🥹. same energy as .SA, no cap 💅

6. Acknowledgements 🫶

many people contributed to this document, especially Nacho Amadoz, Marc Blanchet, Michelle Coon, Jordi Iparraguirre, Frederico A. C. Neves, Vaggelis Segredakis, Doron Shikmoni, Andrew Sullivan, Dennis Tan, and Joseph Yee 👑💖 absolute legends, all of them 🙌

7. Security Considerations 🔐

⚠️ bestie, read this part carefully 🥹

there are many potential security considerations for various methods of dealing with IDN variants 🚨. however, this document is only a catalog of current variant policies 📋, and it does not address whether they are good or bad ideas from a security standpoint 🙅‍♀️. the documents cited in the Terminology section have a little discussion of security considerations for IDN variants 🔍, so go check those out 🧠

8. Informative References ✨

okay so this is the receipts section 📚 every doc, policy, and letter the spec leaned on, all listed here so nobody can say we didn't cite our sources 💅

Authors' Addresses 🦋

John Levine Taughannock Networks

EMail: standards@taugh.com

Paul Hoffman VPN Consortium

EMail: paul.hoffman@vpnc.org

📦 where this page comes from