draft-ietf-idn-dnsii-mdnr-00.txt   draft-ietf-idn-dnsii-mdnr-01.txt 
IDN Working Group Edmon Chung & David Leung IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc. Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnr-00.txt> August 2000 <draft-ietf-idn-dnsii-mdnr-01.txt> February 2001
DNSII Multilingual Domain Name Resolution DNSII Multilingual Domain Name Resolution
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 31 skipping to change at line 30
The reader is cautioned not to depend on the values that appear in The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited. educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A copy of this particular draft is also archived at
http://www.dnsii.org.
Abstract Abstract
This document outlines a resolution process that forms a framework
for the resolution of multilingual domain names. Additionally, a
tunneling mechanism utilizing additional RRs is introduced for the
transition to a fully multilingual capable name space.
The Internet-Draft for DNSII-MDNP was focused purely on discussing The Internet-Draft for DNSII-MDNP was focused purely on discussing
the ultimate packet protocol that is being sent around the Internet the ultimate packet protocol that is being sent around the Internet
for multilingual domain names. This paper complements the previous for multilingual domain names. This paper complements the previous
paper by outlining the contemplated resolution process with the DNSII paper by outlining the contemplated resolution process with the DNSII
protocol throughout the DNS name resolution process. protocol throughout the DNS name resolution process.
The DNSII-MDNR outlines a resolution process that forms a framework Whether the DNSII protocol is implemented exactly as specified in
for the resolution of multilingual domain names. Whether the DNSII DNSII-MDNP is less relevant, rather it is the idea of having a
protocol is implemented exactly as specified in DNSII-MDNP is less multilingual packet identifier and the fall back process that
relevant, rather it is the idea of having a multilingual packet matters. The DNSII-MDNR successfully addresses the transitional
identifier and the fall back process that matters. The DNSII-MDNR issues at each node of the DNS resolution process providing a clear
successfully addresses the transitional issues at each node of the migration path and strategy for the deployment of a multilingual
DNS resolution process providing a clear migration path and strategy enabled DNS system. It also outlines the conformance levels required
for the deployment of a multilingual enabled DNS system. It also for basic or complete implementations for applications, resolvers and
outlines the conformance levels required for basic or complete name servers.
implementations for applications, resolvers and name servers.
This document also introduces a tunneling mechanism for the short-run
to transition the system through to a truly multilingual capable name
space.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
1.1 Terminology....................................................2 1.1 Terminology....................................................2
1.2 Multilingual Domain Name Resolution............................3 1.2 Multilingual Domain Name Resolution............................3
1.2 DNSII-MDNR.....................................................3 1.2 DNSII-MDNR.....................................................3
2. DNSII Proposal with respect to the DNS Layers...................3 2. DNSII Proposal with respect to the DNS Layers...................3
3. The Resolution Process..........................................5 3. The Resolution Process..........................................5
3.1 Steady State Resolution........................................5 3.1 Steady State Resolution........................................5
skipping to change at page 6, line 38 skipping to change at line 277
| | (1) user queries | | (2) if Resolver is | | (1) user queries | | (2) if Resolver is
| | (DNSII identifier | | DNSII compliant, | | (DNSII identifier | | DNSII compliant,
| | ILET=UCS without | | Packet is resolved | | ILET=UCS without | | Packet is resolved
| User | Transformation) | | accordingly. If | User | Transformation) | | accordingly. If
| Program |----------------------->| Resolver | not fallback to (3) | Program |----------------------->| Resolver | not fallback to (3)
| | | | | | | |
| |<-----------------------| | | |<-----------------------| |
| | (3) Upon the detection | | | | (3) Upon the detection | |
| | of the DNSII Flag | | | | of the DNSII Flag | |
| | resolver will reply | | | | resolver will reply | |
| | with "Format Error" | | | | with _Format Error_ | |
| | | | | | | |
| |----------------------->| | (5) Current resolu- | |----------------------->| | (5) Current resolu-
| | (4) Send QNAME using | | tion process begins | | (4) Send QNAME using | | tion process begins
| | local encoding or | | with the DNSII RR | | local encoding or | | with the DNSII RR
| | UTF-8 with or without | | passed along as an | | UTF-8 with or without | | passed along as an
| | Additional DNSII RR | | Additional RR | | Additional DNSII RR | | Additional RR
+---------+ +----------+ +---------+ +----------+
3.2.1 Tunneling MDNP through DNSII RR 3.2.1 Tunneling MDNP through DNSII RR
skipping to change at page 7, line 21 skipping to change at line 309
at any level in the DNS. More detailed description in Section 3.4. at any level in the DNS. More detailed description in Section 3.4.
For older DNS servers, requests with a non-empty additional For older DNS servers, requests with a non-empty additional
information section MAY produce error returns, however since the information section MAY produce error returns, however since the
deployment of DNSSEC, especially for TSIG considerations, this no- deployment of DNSSEC, especially for TSIG considerations, this no-
longer constitutes a problem. Basic security prepared servers such longer constitutes a problem. Basic security prepared servers such
as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR. as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR.
It is possible to use ACE/RACE type translations at this level, It is possible to use ACE/RACE type translations at this level,
however it is more advisable to use a truly arbitrary label such as however it is more advisable to use a truly arbitrary label such as
"-for-tunneling-only-". So doing requires only reserving one _-for-tunneling-only-_. So doing requires only reserving one
arbitrary name while ACE/RACE creates one more arbitrary name for arbitrary name while ACE/RACE creates one more arbitrary name for
each new multilingual name registered, which will eventually each new multilingual name registered, which will eventually
contribute to the fracturing of the DNS. contribute to the fracturing of the DNS.
As an example, a tunneling packet for the domain name: host. Wt As an example, a tunneling packet for the domain name: host. Wt
.tld. (4host4Wt3 tld0) will be represented as: .tld. (4host4Wt3 tld0) will be represented as:
(in the QNAME field) (in the QNAME field)
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
skipping to change at page 9, line 39 skipping to change at line 413
"-for-tunneling-only-" should result in an NXDomain response. "-for-tunneling-only-" should result in an NXDomain response.
For security aware servers, an NXT RR of the last name wrapped by its For security aware servers, an NXT RR of the last name wrapped by its
first name in the zone records will be returned because of the first name in the zone records will be returned because of the
leading "-" for the tunneling label. leading "-" for the tunneling label.
If the application end is not DNSII compliant, the fallback If the application end is not DNSII compliant, the fallback
resolution strategy for resolvers would simply be to pass along the resolution strategy for resolvers would simply be to pass along the
labels in their 8-bit format and determine the existence of the labels in their 8-bit format and determine the existence of the
requested name as usual. If a tunneled DNSII RR is detected, by way requested name as usual. If a tunneled DNSII RR is detected, by way
of a label constituting entirely of "-for-tunneling-only-" and the of a label constituting entirely of _-for-tunneling-only-_ and the
existence of a valid DNSII RR, the resolver should attempt to resolve existence of a valid DNSII RR, the resolver should attempt to resolve
the name according to the DNSII specification and tunnel the answer the name according to the DNSII specification and tunnel the answer
back to the inquirer. back to the inquirer.
3.3.1 Tunneling MDNP Responses through DNSII ANS RR 3.3.1 Tunneling MDNP Responses through DNSII ANS RR
To tunnel a DNSII compliant answer through a non-compliant resolver, To tunnel a DNSII compliant answer through a non-compliant resolver,
another DNSII ANS RR is tunneled. Also using the TXT RR format as a another DNSII ANS RR is tunneled. Also using the TXT RR format as a
mask. TXT RRs are best used because it is a valid RR and its RDATA mask. TXT RRs are best used because it is a valid RR and its RDATA
is an unrestricted byte stream determined only by the RDLENGTH. The is an unrestricted byte stream determined only by the RDLENGTH. The
skipping to change at page 13, line 11 skipping to change at line 587
compliant format. Two tunneling mechanisms using the TXT RR was compliant format. Two tunneling mechanisms using the TXT RR was
introduced for the preservation of information during transitional introduced for the preservation of information during transitional
resolution. resolution.
6.1 Client/Application Resolution Strategy 6.1 Client/Application Resolution Strategy
Send Query in DNSII format Send Query in DNSII format
IF RCODE = Format Error IF RCODE = Format Error
THEN send query in UTF-8/Local Encoding AND append DNSII RR THEN send query in UTF-8/Local Encoding AND append DNSII RR
IF RCODE = Format Error IF RCODE = Format Error
THEN send Query in ASCII with "-for-tunneling-only-" label THEN send Query in ASCII with _-for-tunneling-only-_ label
AND append DNSII RR AND append DNSII RR
AND check for DNSII ANS RR in response AND check for DNSII ANS RR in response
ELSE proceed and check for DNSII ANS RR in response ELSE proceed and check for DNSII ANS RR in response
ELSE proceed as usual ELSE proceed as usual
6.2 Resolver Resolution Strategy 6.2 Resolver Resolution Strategy
(*)IF incoming request is in pure DNSII format (*)IF incoming request is in pure DNSII format
THEN resolve according to ILET in cache and by recursive lookup THEN resolve according to ILET in cache and by recursive lookup
IF encounter RCODE = Format Error IF encounter RCODE = Format Error
THEN send query in UTF-8 AND append DNSII RR THEN send query in UTF-8 AND append DNSII RR
IF RCODE = Format Error IF RCODE = Format Error
THEN send query in ASCII with "-for-tunneling-only-" THEN send query in ASCII with _-for-tunneling-only-_
label label
AND append DNSII RR AND append DNSII RR
AND check for DNSII ANS RR in response AND check for DNSII ANS RR in response
ELSE proceed and check for DNSII ANS RR in response ELSE proceed and check for DNSII ANS RR in response
ELSE proceed as usual with pure DNSII Format (*) ELSE proceed as usual with pure DNSII Format (*)
AND respond in pure DNSII format AND respond in pure DNSII format
ELSE IF incoming request has tunneled MDNP information ELSE IF incoming request has tunneled MDNP information
THEN resolve using the information in the appended DNSII RR THEN resolve using the information in the appended DNSII RR
Reset Query using DNSII Format and go through (*) Reset Query using DNSII Format and go through (*)
AND convert back to tunneling format before responding to query AND convert back to tunneling format before responding to query
skipping to change at page 15, line 4 skipping to change at line 677
Character Set (UCS) Character Set (UCS)
[RFC1034] Mockapetris, P., "Domain Names - Concepts and [RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities," STD 13, RFC 1034, USC/ISI, November 1987 Facilities," STD 13, RFC 1034, USC/ISI, November 1987
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification," STD 13, RFC 1035, USC/ISI, November Specification," STD 13, RFC 1035, USC/ISI, November
1987 1987
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Authors: Authors:
Edmon Chung Edmon Chung
Neteka Inc. Neteka Inc.
2462 Yonge St. Toronto, 2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5 Ontario, Canada M4P 2H5
edmon@neteka.com edmon@neteka.com
David Leung David Leung
Neteka Inc. Neteka Inc.
 End of changes. 10 change blocks. 
23 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/