internationalized domain name evolution

Internationalized Domain Name Evolution

Kenny HuangTWNIC

2001.10.17

DemandsWhere and How

Human factors

• People would like to name themselves and their objects in their own language

• ISO 10646+UNICODE is a necessary answer, but not sufficient

• DNS has some shortcomings as well

Deployment Issues

• Objectives of Internationalizing Protocols

• Deploying parallel name spaces• Deploying parallel communication

spaces

Objectives of Internationalizing Protocols

• Many protocols internationalized:– SMTP, HTML, etc

• Domain Name Service foundational– and therefore has earthquake effects if

changed without thinking clearly

Deploying parallel name spaces

• Simple to do - – Deploy many DNS roots with different name

spaces

• Effect: – People using one cannot find people in

another– Commerce diminished– Mail exchange impeded, etc

Correctness issues

• Many servers running Bind– Often as old as version 4

• Incompatible upgrades cause other systems to fail– Software reliability is one of the big issues,

and this is a key component

ASCII (ACE) or non ASCII IDN

• The IDN solutions can be very extreme, there is no intermediate solution

• ACE has short-term benefit but has long-term penalty

• 8bit clean technique introduces system vulnerability ?

Policy PerspectiveWHO’S WHO

Who Own and Control the Internet?

• Domain Names(gTLD, ccTLD)• IP Address• Protocol Parameter• Root Server• BIND

ICANN

ICANN(Formally IANA)

TLDs:gTLD/ccTLD

ARIN,RIPEAPNIC

IETF/IAB

Govt. AdvisoryCommittee

DNS Root Server

What ICANN does

• To Coordinate the unique assignment of

• Three values that are essential to the • Proper functioning of the Internet

– Domain Names– IP addresses – Protocol port and parameter numbers

What ICANN does not do

• Content Control• Network Security• Data Privacy Protection• Setting multilingual name standards• Multilingual Internet interoperability

ICANN’s Responses

• 2000. 3 Cairo • 2000. 6 Yokohama

– ASCII, Internet Language• 2000. 11Marina del Rey

– To host Internationalized Domain Names Workshop• 2001. 3 Melbourne

– To discuss Internationalized DN in the public forum

MINC

• Coordination of R&D on multilingual names• Coordination on deployment of multilingual

names • Coordination with the relevant

organizations i.e. IETF, W3C, ICANN, ISOC, Unicode, IEEE, ISO and ITU

• Coordination for standards development

Issues of Interoperability

• Tower of Babel – Babelisation of Internet has taken place.

• “Islands” of the Internet should be prevented i.e. which should not fragment the network with multiple non-interoperable standards

• Asia Pacific Taskforce on internationalising Domain Names set up

• Internet Engineering Task Force urgently set up IDN Working Group

Several Multilingual Domain Names Testbeds emergent

• Industry driving this• NSI (Verisign) and partner companies setting up m

ultilingual.com services testbed• JPNIC, KRNIC launching production level testbeds

for japanese.jp and korean.kr• CNNIC, TWNIC, HKNIC, MONIC forms CDNC

- in progress

MINC’s Role

• MINC will coordinate the Interoperability Testing as a whole.

• MINC will commission the Interoperability Testing Working Group to manage the Testing.

• MINC will operate the testing using a self-financing cost-recovering model.

What is JET?

• Joint Engineer Team for developing Open Multilingual Domain Name System for ICANN TLDs.

• Core members are CNNIC, JPNIC, KRNIC and TWNIC.

• ISC, IETF co-chair and VeriSign GRS are invited.

• Business status & plan are exchanged for the better service introduction.

JET meetings & Discussions

• 1st : July 15 2000 (Yokohama) Local charset or ACE

• 2nd : Aug 28-30 2000 (Beijing) Common mDNS

• 3rd : Nov. 29-30 2000 (Taipei) Global/Localized components

• 4th : Feb. 28 – Mar 1 2001 (Kuala Lumpur) IETF Standardization & Localization

• 5th : June 25-26 2001 (Shanghai)• 6th : Oct 18 2001 (Beijing)

– Last f2f meeting before IETF standardization

Open Source Code

• TWNIC/CNNIC– mDNS with 8-bit clean BIND– 8-bit clean Squid proxy/Apache web server

• JPNIC– mDNkit

• To be fully compatible with IETF standards• Core library for processing mDN

– Code conversion between local charset and ACEs

– Normalization• Tools for code conversion

– mdnconv, dnsproxy, runmdn, mDN Wrapper• BIND 8 & 9 Patches

JET Outcome

• Information exchange on the business– Service menu & schedule (JPRS)– System development– Reserved words– DRP

• Engineering Discussion• IETF Contribution

– UNAME– TSCONV– JPCHAR– HANGUELCHAR

• Software Release: JPNIC’s mDNkit Plan• Localization

CDNC

• Members : CNNIC, TWNIC, MONIC, HKNIC

• Development– multilingual domain name

system– system interoperability

• Information Sharing• Multilingual domain name service

activation and operation

CDNC Experience

• Strong momentum from official registries• First organization introduce multiple root

systems model (chain table) and multilingual ccTLDs, gTLDs (全漢字 )

• Normalization– Simplified Chinese Characters vs. traditional Chi

nese Characters

Technology PerspectiveIETF IDN Movement & Status

Update

IDNA Concept

CommunicationCommunicationLayerLayer

Input/OutputInput/Output

DNS ProtocolDNS Protocol Application Application ProtocolProtocol

IDNAIDNATransformationTransformation

IDNA Overview

• Changes of presentation layer of applications

• No changes to application protocols• No changes to DNS protocol• No changes to any current DNS servers

IDNA Interface Components

Changes to applications for IDNA

• Input of host names– Prepares name using stringprep– Applies an ACE– Sends encoded name to resolver (as well as application laye

r protocol)• Display of host names

– Scans displayable text or protocol elements for ACEs– Displays them in local display format

STRINGPREP

• Output of a single, unambiguous string• Let user enter anything that might look

correct to them• Typical users should be able to follow

logic of preparation

Overview of STRINGPREP

• Mapping – Mapping characters to other characters

• Normalization– Normalizing the characters

• Prohibit– Excluding characters that are prohibited

from in internationalized host names

Ripple Effects

• Un-updated applications will display obscure ACE format

• Non-IDN names that use the ACE prefix or suffix will either be considered illegal or will appear as nonsense characters

• Doesn’t internationalize text records in the DNS zone files

Administrative Issues

• Administrative interface for DNS servers must all check IDN names

• Probably done with automated scripts converting from and to preferred native format

• Will probably be important to check all names with stringprep, even after they are in the zone files

IETF IDN Update

• AMC-ACE-Z as chosen ACE• nameprep/tsconv/hanguelchar/jpchar/

stringprep should be consolidated into one architecture

• the requirements draft will be moving forward for IETF Last Call

• Go forward with IDNA.

IDNA Possible Structure

Client

Local Process

StringPrep

Reordering

AMC-ACE-Z

Localization

IDNA Internationalization

Search Model Example One

ApplicationApplication

StringPrepStringPrepTC/SC EngineTC/SC Engine DNS

Yellowpage

Search Model Example Two

ApplicationApplication

StringPrepStringPrepDNS

Yellowpage

THANK YOU