1 © 2000, Cisco Systems, Inc. DNSSEC IDN Patrik Fältström [email protected]

1© 2000, Cisco Systems, Inc. DNSSEC

IDNIDN

Patrik FältströmPatrik Fältström

[email protected]@cisco.com

2IDN © 2001, Cisco Systems, Inc.

The Domain Name SystemThe Domain Name System

• It is a distributed database with only limited lookup mechanism

• It is a protocol

• Often the two get mixed up


Protocol is “safe”Protocol is “safe”

• In each label you can have any octets

Including for example ‘.’

• So, what is the problem?

• Well, people try to register words and phrases in DNS, when DNS is designed for registration of identifiers


Protocol - conclusionProtocol - conclusion

• Even though we can handle 8bit octets in the DNS protocol, many applications have problems

• Is it not the applications that have to be fixed (also?)?

• Can a solution be backward compatible with old protocols?


A real solutionA real solution

• The user types in information he knows, i.e. a search query and a context

“Patrik Fältström”, person, lives in Sweden

Gets back alternative(s)

Selects correct alternative

• What the domain name is, which later is used, doesn’t matter. Just like IP address doesn’t matter -- it is hidden for the user

• Keyword Systems work almost like this


DNS is about equalityDNS is about equality

• Sweden:

http://www.torbjörn.com

• Norway:

http://www.torbjørn.com

• Are they the same site?


DNS is about equalityDNS is about equality

• About Swedish lakes:

http://Å.com

• About a physical unit:

http://Å.com

• Are they the same site?


What can we do in DNS?What can we do in DNS?



Let someone (else) decideLet someone (else) decide

• We have one algorithm, and one only

• Given this algorithm, people can register whatever they want


Unicode ConsortiumUnicode Consortium

• The Unicode Consortium have produced a couple of interesting things:

A character set

Also accepted by ISO as 10646

Technical reports

Normalization

Case Folding


Example: NormalizationExample: Normalization

• A description of what characters are to be treated as the same when comparing them

• Example, U+00C4, ÄU+00C4: LATIN CAPITAL LETTER A WITH DIAERESIS

Equivalent with U+0041 followed by U+0308

U+0041: LATIN CAPITAL LETTER A

U+0308: COMBINING DIAERESIS


Decisions in the IETFDecisions in the IETF

• IETF don’t have knowledge of characters

• Discussions in ISO and Unicode consortium have so far existed in 25 years

• Why should IETF be more successful?

• IETF because of this inherits results from other organizations

In this case the Unicode Consortium


Ultimate goalUltimate goal

• DNS is designed for registration of identifiers

• Users (believe they are) registering words

• IETF can solve the problem of not being able to use local characters in identifier

• IETF can NOT solve the problem of using words in DNS


One more step…One more step…

• One more step is taken

• Distinguish between the generic stringprep, which defines in what order the various translations are to be done, and application specific profiles

Example of decisions made in the profiles include

Case sensitivity

Special groups of characters which are mapped out (forbidden)


Profiles?Profiles?

• So far profiles are created for:

Domain Names (IDN)

iSCSI units

Kerberos Realms (and other things)


Standard / Test?Standard / Test?

• There is a big confusion on the state of various test beds and products

i. .nu

ii. Verisign Global Registry System

iii. ICANN policy


.nu.nu

• Only handle WWW, (i.e. URL’s)

• Microsoft Internet Explorer happen to send, when using Windows, non-ascii characters in UTF-8 encoded Unicode

• As the DNS protocol is “8-bit clean”, the query in UTF-8 reaches the server

• Why bad?

Only one application, one vendor

Other applications can not handle UTF-8

No “Normalization” is done


VGRSVGRS

• Follows, after a lot of discussions, the process in the IDN working group

• Nothing is allowed to happen if ICANN is objecting

• Used RACE, but is now changing to ACE-Z

• Most “correct” testbed out there


ICANNICANN

• Points at IETF (so far)


Objections…Objections…

• Objections exists

• Why not UTF-8?

Backward compatibility is important

Even if UTF-8 is used, nameprep is needed

• Simplified/Traditional Chinese (GB/BIG5)

Unicode Consortium objects to trying to do something

Groups which have been working on SC/TC issues object to IETF doing anything

It is “easy” for 90% of the problem


IDNA proposalIDNA proposal(Nameprep in detail)(Nameprep in detail)



A few stepsA few steps

User interface Local Character set

Application1. Conversion to Unicode2. Nameprep Algorithm

3. ACE Encoding

ApplicationProtocol

DNS A-Z, 0-9 etc


Nameprep (order is important)Nameprep (order is important)

1. Mapping of charactersCase Mapping (UTR 21)Additional FoldingMapped out (deleted)

2. Normalizing characters Normalization (KC in UTR15)

3. Prohibition of code points

Currently prohibited CharactersSpace CharactersControl CharactersPrivate Use and ReplacementNon-character codepointsSurrogate codesInappropriate for textInappropriate for domainnamesChange display property marksInappropriate for some input systems


MappingMapping

• Case Mapping (UTR 21)

• Additional FoldingGreek characters

Symbols which include latin characters

b = NormalizeWithKC(Fold(a));c = NormalizeWithKC(Fold(b));if c is not the same as b, add a mapping for "a to c”;

• Mapped out (deleted)Only interesting in line-based text (zero-width space etc)

Variation selectors (Mongolian) and cursive selectors which doesn’t bear any semantics (zero width joiner)


Normalizing charactersNormalizing characters

• Normalization (KC in UTR15)

Sorting also described in ISO/IEC 14651


Prohibition of code pointsProhibition of code points

• Currently prohibited CharactersControl characters, braces and brackets etc in ASCII

• Space CharactersVarious space characters (including em space etc)

• Control CharactersControl characters, line separators etc

• Private Use and ReplacementPrivate character code points and replacement character

• Non-character code points


Prohibition of code pointsProhibition of code points

• Surrogate codes

• Inappropriate for plain textInterlinear annotation anchor etc

• Inappropriate for domain namesIdeographic description characters

• Change display property marksLeft-To-Right Mark, Activate Arabic Form Shaping etc

• Inappropriate for some input systemsIdeographic Full Stop


Classes of charactersClasses of characters

• AO - Code points that may be in the output

• MN - Code points that cannot be in the output because they are mapped to nothing or never appear as output from normalization

• D - Code points that cannot be in the output because they are disallowed in the prohibition step

• U - Unassigned code points


VersioningVersioning

• New versions of nameprep will move code points from class U to one of AO, MN or D

• Only class AO code points will exist in authoritative name servers

• Applications seeing class U code points must treat them as AO

(Lots of more explanation in the document...)


Conclusion...Conclusion...

This is not easy...…and what IDN wg is doing is not a

perfect, but working, solution…

…for the problem of being able to use local script in identifiers, not the

interest of storing words in DNS…


Patrik FältströmPatrik Fältströ[email protected]@cisco.com


Documents

1 © 2000, Cisco Systems, Inc. DNSSEC IDN Patrik Fältström [email protected]