From 540c1bf12c9e0e9960a67fcb5d15c20357ca84dd Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Fri, 3 Mar 2000 21:05:56 +0000 Subject: [PATCH] added new drafts and removed obsolete ones --- ...8n-01.txt => draft-duerst-dns-i18n-02.txt} | 1804 +++++++++-------- .../draft-ietf-dnsind-indirect-key-00.txt | 470 ----- .../draft-ietf-dnsind-indirect-key-01.txt | 19 + .../draft-ietf-dnsind-local-names-07.txt | 662 ------ .../draft-ietf-dnsind-local-names-08.txt | 19 + doc/draft/draft-ietf-dnsind-verify-00.txt | 158 -- doc/draft/draft-ietf-dnsind-verify-01.txt | 19 + doc/draft/draft-ietf-dnssec-as-map-05.txt | 522 ----- doc/draft/draft-ietf-dnssec-as-map-06.txt | 19 + ...sig-04.txt => draft-skwan-gss-tsig-05.txt} | 193 +- ...dns-02.txt => draft-skwan-utf8-dns-03.txt} | 78 +- 11 files changed, 1210 insertions(+), 2753 deletions(-) rename doc/draft/{draft-duerst-dns-i18n-01.txt => draft-duerst-dns-i18n-02.txt} (95%) delete mode 100644 doc/draft/draft-ietf-dnsind-indirect-key-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-indirect-key-01.txt delete mode 100644 doc/draft/draft-ietf-dnsind-local-names-07.txt create mode 100644 doc/draft/draft-ietf-dnsind-local-names-08.txt delete mode 100644 doc/draft/draft-ietf-dnsind-verify-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-verify-01.txt delete mode 100644 doc/draft/draft-ietf-dnssec-as-map-05.txt create mode 100644 doc/draft/draft-ietf-dnssec-as-map-06.txt rename doc/draft/{draft-skwan-gss-tsig-04.txt => draft-skwan-gss-tsig-05.txt} (91%) rename doc/draft/{draft-skwan-utf8-dns-02.txt => draft-skwan-utf8-dns-03.txt} (89%) diff --git a/doc/draft/draft-duerst-dns-i18n-01.txt b/doc/draft/draft-duerst-dns-i18n-02.txt similarity index 95% rename from doc/draft/draft-duerst-dns-i18n-01.txt rename to doc/draft/draft-duerst-dns-i18n-02.txt index fb71e11962..a42981634b 100644 --- a/doc/draft/draft-duerst-dns-i18n-01.txt +++ b/doc/draft/draft-duerst-dns-i18n-02.txt @@ -1,899 +1,905 @@ - - - - - - -Internet Draft M. Duerst - University of Zurich -Expires in six months July 1997 - - - Internationalization of Domain Names - - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working doc- - uments of the Internet Engineering Task Force (IETF), its areas, and - its working groups. Note that other groups may also distribute work- - ing documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a "working - draft" or "work in progress". - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net (US East Coast), nic.nordu.net - (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific - Rim). - - Distribution of this document is unlimited. Please send comments to - the author at . - - -Abstract - - Internet domain names are currently limited to a very restricted - character set. This document proposes the introduction of a new - "zero-level" domain (ZLD) to allow the use of arbitrary characters - from the Universal Character Set (ISO 10646/Unicode) in domain names. - The proposal is fully backwards compatible and does not need any - changes to DNS. - - -Table of contents - - 0. Change History ................................................. 2 - 0.8 Changes (to be) Made from Version 01 to Version 02 (or later) 2 - 0.9 Changes Made from Version 00 to Version 01 .................. 2 - 1. Introduction ................................................... 3 - 1.1 Motivation .................................................. 3 - - - - Expires End of January 1998 [Page 1] - -Internet Draft Internationalization of Domain Names July 1997 - - - 1.2 Notational Conventions ...................................... 4 - 2. The Hidden Zero Level Domain ................................... 4 - 3. Encoding International Characters .............................. 5 - 3.1 Encoding Requirements ....................................... 5 - 3.2 Encoding Definition ......................................... 5 - 3.3 Encoding Example ............................................ 7 - 3.4 Length Considerations ....................................... 8 - 4. Usage Considerations ........................................... 8 - 4.1 General Usage ............................................... 8 - 4.2 Usage Restrictions .......................................... 9 - 4.3 Domain Name Creation ....................................... 10 - 4.4 Usage in URLs .............................................. 12 - 5. Alternate Proposals ........................................... 13 - 5.1 The Dillon Proposal ........................................ 13 - 5.2 Using a Separate Lookup Service ............................ 13 - 6. Generic Considerations ........................................ 14 - 5.1 Security Considerations .................................... 14 - 5.2 Internationalization Considerations ........................ 14 - Acknowledgements ................................................. 14 - Bibliography ..................................................... 15 - Author's Address ................................................. 16 - - - - -0. Change History - - - -0.8 Changes (to be) Made from Version 01 to Version 02 (or later) - - - - Decide on ZLD name (.i or .i18n.int or something else) - - - Decide on casing solution - - - Decide on exact syntax - - - Proposals for experimental setup - - - - -0.9 Changes Made from Version 00 to Version 01 - - - - - - - - Expires End of January 1998 [Page 2] - -Internet Draft Internationalization of Domain Names July 1997 - - - - Minor rewrites and clarifications - - - Added the following references: [RFC1730], [Kle96], [ISO3166], - [iNORM] - - - Slightly expanded discussion about casing - - - Added some variant proposals for syntax - - - Added some explanations about different kinds of name parallelism - - - Added some explanation about independent addition of internation- - alized names in subdomains without bothering higher-level domains - - - Added some explanations about tools needed for support, and the - MX/CNAME problem - - - Change to RFC1123 (numbers allowed at beginning of labels) - - - - -1. Introduction - - -1.1 Motivation - - - The lower layers of the Internet do not discriminate any language or - script. On the application level, however, the historical dominance - of the US and the ASCII character set [ASCII] as a lowest common - denominator have led to limitations. The process of removing these - limitations is called internationalization (abbreviated i18n). One - example of the abovementioned limitations are domain names [RFC1034, - RFC1035], where only the letters of the basic Latin alphabet (case- - insensitive), the decimal digits, and the hyphen are allowed. - - While such restrictions are convenient if a domain name is intended - to be used by arbitrary people around the globe, there may be very - good reasons for using aliases that are more easy to remember or type - in a local context. This is similar to traditional mail addresses, - where both local scripts and conventions and the Latin script can be - used. - - There are many good reasons for domain name i18n, and some arguments - that are brought forward against such an extension. This document, - however, does not discuss the pros and cons of domain name i18n. It - proposes and discusses a solution and therefore eliminates one of the - - - - Expires End of January 1998 [Page 3] - -Internet Draft Internationalization of Domain Names July 1997 - - - most often heard arguments agains, namely "it cannot be done". - - The solution proposed in this document consists of the introduction - of a new "zero-level" domain building the root of a new domain - branch, and an encoding of the Universal Character Set (UCS) - [ISO10646] into the limited character set of domain names. - - - -1.2 Notational Conventions - - In the domain name examples in this document, characters of the basic - Latin alphabet (expressible in ASCII) are denoted with lower case - letters. Upper case letters are used to represent characters outside - ASCII, such as accented characters of the Latin alphabet, characters - of other alphabets and syllabaries, ideographic characters, and vari- - ous signs. - - -2. The Hidden Zero Level Domain - - The domain name system uses the domain "in-addr.arpa" to convert - internet addresses back to domain names. One way to view this is to - say that in-addr.arpa forms the root of a separate hierarchy. This - hierarchy has been made part of the main domain name hierarchy just - for implementation convenience. While syntactically, in-addr.arpa is - a second level domain (SLD), functionally it is a zero level domain - (ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is - the domain tpc.int, which provides a hierarchy of the global phone - numbering system [RFC1530] for services such as paging and printing - to fax machines. - - For domain name i18n to work inside the tight restrictions of domain - name syntax, one has to define an encoding that maps strings of UCS - characters to strings of characters allowable in domain names, and a - means to distinguish domain names that are the result of such an - encoding from ordinary domain names. - - This document proposes to create a new ZLD to distinguish encoded - i18n domain names from traditional domain names. This domain would - be hidden from the user in the same way as a user does not see in- - addr.arpa. This domain could be called "i18n.arpa" (although the use - of arpa in this context is definitely not appropriate), simply - "i18n", or even just "i". Below, we are using "i" for shortness, - while we leave the decision on the actual name to further discussion. - - - - - - - Expires End of January 1998 [Page 4] - -Internet Draft Internationalization of Domain Names July 1997 - - -3. Encoding International Characters - - - - -3.1 Encoding Requirements - - - Until quite recently, the thought of going beyond ASCII for something - such as domain names failed because of the lack of a single encom- - passing character set for the scripts and languages of the world. - Tagging techniques such as those used in MIME headers [RFC1522] would - be much too clumsy for domain names. - - The definition of ISO 10646 [ISO10646], codepoint by codepoint iden- - tical with Unicode [Unicode], provides a single Universal Character - Set (UCS). A recent report [RFCIAB] clearly recommends to base the - i18n of the Internet on these standards. - - An encoding for i18n domain names therefore has to take the charac- - ters of ISO 10646/Unicode as a starting point. The full four-byte - (31 bit) form of UCS, called UCS4, should be used. A limitation to - the two-byte form (UCS2), which allows only for the encoding of the - Base Multilingual Plane, is too restricting. - - For the mapping between UCS4 and the strongly limited character set - of domain names, the following constraints have to be considered: - - - The structure of domain names, and therefore the "dot", have to be - conserved. Encoding is done for individual labels. - - - Individual labels in domain names allow the basic Latin alphabet - (monocase, 26 letters), decimal digits, and the "-" inside the - label. The capacity per octet is therefore limited to somewhat - above 5 bits. - - - There is no need nor possibility to preserve any characters. - - - Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order) - should be encoded relatively compactly. A variable-length encoding - (similar to UTF-8) seems desirable. - - - -3.2 Encoding Definition - - - Several encodings for UCS, so called UCS Transform Formats, exist - - - - Expires End of January 1998 [Page 5] - -Internet Draft Internationalization of Domain Names July 1997 - - - already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni- - code]. Unfortunately, none of them is suitable for our purposes. We - therefore use the following encoding: - - - To accommodate the slanted probability distribution of characters - in UCS4, a variable-length encoding is used. - - - Each target letter encodes 5 bits of information. Four bits of - information encode character data, the fifth bit is used to indi- - cate continuation of the variable-length encoding. - - - Continuation is indicated by distinguishing the initial letter - from the subsequent letter. - - - Leading four-bit groups of binary value 0000 of UCS4 characters - are discarded, except for the last TWO groups (i.e. the last - octet). This means that ASCII and Latin-1 characters need two - target letters, the main alphabets up to and including Tibetan - need three target letters, the rest of the characters in the BMP - need four target letters, all except the last (private) plane in - the UTF-16/Surrogates area [Unicode] need five target letters, and - so on. - - - The letters representing the various bit groups in the various - positions are chosen according to the following table: - - - Nibble Value Initial Subsequent - Hex Binary - 0 0000 G 0 - 1 0001 H 1 - 2 0010 I 2 - 3 0011 J 3 - 4 0100 K 4 - 5 0101 L 5 - 6 0110 M 6 - 7 0111 N 7 - 8 1000 O 8 - 9 1001 P 9 - A 1010 Q A - B 1011 R B - C 1100 S C - D 1101 T D - E 1110 U E - F 1111 V F - - - [Should we try to eliminate "I" and "O" from initial? "I" might be - - - - Expires End of January 1998 [Page 6] - -Internet Draft Internationalization of Domain Names July 1997 - - - eliminated because then an algorithm can more easily detect ".i". "O" - could lead to some confusion with "0". What other protocols are - there that might be able to use a similar solution, but that might - have other restrictions for the initial letters? Proposal to run ini- - tial range from H to X. Extracting the initial bits then becomes ^ - 'H'. Proposal to have a special convention for all-ASCII labels - (start label with one of the letters not used above).] - - Please note that this solution has the following interesting proper- - ties: - - - For subsequent positions, there is an equivalence between the hex- - adecimal value of the character code and the target letter used. - This assures easy conversion and checking. - - - The absence of digits from the "initial" column, and the fact that - the hyphen is not used, assures that the resulting string conforms - to domain name syntax. - - - Raw sorting of encoded and unencoded domain names is equivalent. - - - The boundaries of characters can always be detected easily. - (While this is important for representations that are used inter- - nally for text editing, it is actually not very important here, - because tools for editing can be assumed to use a more straight- - forward representation internally.) - - - Unless control characters are allowed, the target string will - never actually contain a G. - - - -3.3 Encoding Example - - - As an example, the current domain - - is.s.u-tokyo.ac.jp - - with the components standing for information science, science, the - University of Tokyo, academic, and Japan, might in future be repre- - sented by - - JOUHOU.RI.TOUDAI.GAKU.NIHON - - (a transliteration of the kanji that might probably be chosen to rep- - resent the same domain). Writing each character in U+HHHH notation as - in [Unicode], this results in the following (given for reference - - - - Expires End of January 1998 [Page 7] - -Internet Draft Internationalization of Domain Names July 1997 - - - only, not the actual encoding or something being typed in by the - user): - - U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c - - The software handling internationalized domain names will translate - this, according to the above specifications, before submitting it to - the DNS resolver, to: - - M0C5L831.N406.M771L927.LB66.M5E5M72C.i - - - -3.4 Length Considerations - - - DNS allows for a maximum of 63 positions in each part, and for 255 - positions for the overall domain name including dots. This allows up - to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic - alphabet, in a label. While this does not allow for the same margin - as in the case of ASCII domain names, it should still be quite suffi- - cient. [Problems could only surface for languages that use very long - words or terms and don't know any kind of abbreviations or similar - shortening devices. Do these exist? Islandic expert asserted - Islandic is not a problem.] DNS contains a compression scheme that - avoids sending the same trailing portion of a domain name twice in - the same transmission. Long domain names are therefore not that much - of a concern. - - -4. Usage Considerations - - - -4.1 General Usage - - - To implement this proposal, neither DNS servers nor resolvers need - changes. These programs will only deal with the encoded form of the - domain name with the .i suffix. Software that wants to offer an - internationalized user interface (for example a web browser) is - responsible for the necessary conversions. It will analyze the domain - name, call the resolver directly if the domain name conforms to the - domain name syntax restrictions, and otherwise encode the name - according to the specifications of Section 3.2 and append the .i suf- - fix before calling the resolver. New implementations of resolvers - will of course offer a companion function to gethostbyname accepting - a ISO10646/Unicode string as input. - - - - Expires End of January 1998 [Page 8] - -Internet Draft Internationalization of Domain Names July 1997 - - - For domain name administrators, them main tool that will be needed is - a program to compile files configuring zones from an UTF-8 notation - (or any other suitable encoding) to the encoding described in Section - 3.3. Utility tools will include a corresponding decompiler, checkers - for various kinds of internationalization-related errors, and tools - for managing syntactic parallelism (see Section 4.3). - - -4.2 Usage Restrictions - - - While this proposal in theory allows to have control characters such - as BEL or NUL or symbols such as arrows and smilies in domain names, - such characters should clearly be excluded from domain names. Whether - this has to be explicitly specified or whether the difficulty to type - these characters on any keyboard of the world will limit their use - has to be discussed. One approach is to start with a very restricted - subset and gradually relax it; the other is to allow almost anything - and to rely on common sense. Anyway, such specifications should go - into a separate document to allow easy updates. - - A related point is the question of equivalence. For historical rea- - sons, ISO 10646/Unicode contain considerable number of compatibility - characters and allow more than one representation for characters with - diacritics. To guarantee smooth interoperability in these and related - cases, additional restrictions or the definition of some form of nor- - malization seem necessary. However, this is a general problem - affecting all areas where ISO 10646/Unicode is used in identifiers, - and should therefore be addressed in a generic way. See [iNORM] for - an initial proposal. - - Equally related is the problem of case equivalence. Users can very - well distinguish between upper case and lower case. Also, casing in - an i18n context is not as straightforward as for ASCII, so that case - equivalence is best avoided. Problems therefore result not from the - fact that case is distinguished for i18n domain names, but from the - fact that existing domain names do not distinguish case. Where it is - impossible to distinguish between next.com and NeXT.com, the same two - subdomains would easily be distinguishable if subordinate to a i18n - domain. There are several possible solutions. One is to try to grad- - ually migrate from a case-insensitive solution to a case-sensitive - solution even for ASCII. Another is to allow case-sensitivity only - beyond ASCII. Another is to restrict anything beyond ASCII to lower- - case only (lowercase distinguishes better than uppercase, and is also - generally used for ASCII domain names). - - A problem that also has to be discussed and solved is bidirectional- - ity. Arabic and Hebrew characters are written right-to-left, and the - - - - Expires End of January 1998 [Page 9] - -Internet Draft Internationalization of Domain Names July 1997 - - - mixture with other characters results in a divergence between logical - and graphical sequence. See [HTML-I18N] for more explanations. The - proposal of [Yer96] for dealing with bidirectionality in URLs could - probably be applied to domain names. Anyway, there should be a gen- - eral solution for identifiers, not a DNS-specific solution. - - -4.3 Domain Name Creation - - - The ".i" ZLD should be created as such to allow the internationaliza- - tion of domain names. Rules for creating subdomains inside ".i" - should follow the established rules for the creation of functionally - equivalent domains in the existing domain hierarchy, and should - evolve in parallel. - - For the actual domain hierarchy, the amount of parallelism between - the current ASCII-oriented hierarchy and some internationalized hier- - archy depends on various factors. In some cases, two fully parallel - hierarchies may emerge. In other cases, if more than one script or - language is used locally, more than two parallel hierarchies may - emerge. Some nodes, e.g. in intranets, may only appear in an i18n - hierarchy, whereas others may only appear in the current hierarchy. - In some cases, the pecularities of scripts, languages, cultures, and - the local marketplace may lead to completely different hierarchies. - - Also, one has to be aware that there may be several kinds of paral- - lelisms. The first one is called syntactic parallelism. If there is - a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz - will have to exist both in the traditional DNS hierarchy as well as - within the hierarchy starting at the .i ZLD, with appropriate encod- - ing. - - The second type of parallelism is called transcription parallelism. - It results by transcribing or transliterating relations between ASCII - domain names and domain names in other scripts. - - The third type of parallelism is called semantic parallelism. It - results from translating elements of a domain name from one language - to another, possibly also changing the script or set of used charac- - ters. - - On the host level, parallelism means that there are two names for the - same host. Conventions should exist to decide whether the parallel - names should have separate IP addresses or not (A record or CNAME - record). With separate IP addresses, address to name lookup is easy, - otherwise it needs special precautions to be able to find all names - corresponding to a given host address. Another detail entering this - - - - Expires End of January 1998 [Page 10] - -Internet Draft Internationalization of Domain Names July 1997 - - - consideration is that MX records only work for hostnames/domains, - not for CNAME aliases. This at least has the consequence that alias - resolution for internationalized mail addresses has to occur before - MX record lookup. - - When discussing and applying the rules for creating domain names, - some peculiarities of i18n domain names should be carefully consid- - ered: - - - Depending on the script, reasonable lengths for domain name parts - may differ greatly. For ideographic scripts, a part may often be - only a one-letter code. Established rules for lengths may need - adaptation. For example, a rule for country TLDs could read: one - ideographic character or two other characters. - - - If the number of generic TLDs (.com, .edu, .org, .net) is kept - low, then it may be feasible to restrict i18n TLDs to country - TLDs. - - - There are no ISO 3166 [ISO3166] two-letter codes in scripts other - than Latin. I18n domain names for countries will have to be - designed from scratch. - - - The names of some countries or regions may pose greater political - problems when expressed in the native script than when expressed - in 2-letter ISO 3166 codes. - - - I18n country domain names should in principle only be created in - those scripts that are used locally. There is probably little use - in creating an Arabic domain name for China, for example. - - - In those cases where domain names are open to a wide range of - applicants, a special procedure for accepting applications should - be used so that a reasonable-quality fit between ASCII domain - names and i18n domain names results where desired. This would - probably be done by establishing a period of about a month for - applications inside a i18n domain newly created as a parallel for - an existing domain, and resolving the detected conflicts. For - syntactically parallel domain names, the owners should always be - the same. Administration may be split in some cases to account for - the necessary linguistic knowledge. For domain names with tran- - scription parallelism and semantic parallelism, the question of - owner identity should depend on the real-life situation (trade- - marks,...). - - - It will be desirable to have internationalized subdomains in non- - internationalized TLDs. As an example, many companies in France - may want to register an accented version of their company name, - - - - Expires End of January 1998 [Page 11] - -Internet Draft Internationalization of Domain Names July 1997 - - - while remaining under the .fr TLD. For this, .fr would have to be - reregistered as .M6N2.i. Accented and other internationalized sub- - domains would go below .M6N2.i, whereas unaccented ones would go - below .fr in its plain form. - - - To generalize the above case, one may need to create a requirement - that any domain name registry would have to register and manage - syntactically parallel domain names below the .i ZLD upon request - to allow registration of i18n domain names in arbitrary subdo- - mains. An alternative to this is to organize domain name search - so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in - .i, the name server for .fr is queried for XXXXXX.M6N2.i (with - XXXXXX appropriately encoded). This convention would allow lower- - level domains to introduce internationalized subdomains without - depending on higher-level domains. - - - -4.4 Usage in URLs - - According to current definitions, URLs encode sequences of octets - into a sequence of characters from a character set that is almost as - limited as the character set of domain names [RFC1738]. This is - clearly not satisfying for i18n. - - Internationalizing URLs, i.e. assigning character semantics to the - encoded octets, can either be done separately for each part and/or - scheme, or in an uniform way. Doing it separately has the serious - disadvantage that software providing user interfaces for URLs in gen- - eral would have to know about all the different i18n solutions of the - different parts and schemes. Many of these solutions may not even be - known yet. - - It is therefore definitely more advantageous to decide on a single - and consistent solution for URL internationalization. The most valu- - able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an - ASCII-compatible encoding of UCS4. - - Therefore, an URL containing the domain name of the example of Sec- - tion 3.3 should not be written as: - - ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i - - (although this will also work) but rather - - ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7. - %e5%ad%a6.%e6%97%a5%e6%9c%ac - - - - - Expires End of January 1998 [Page 12] - -Internet Draft Internationalization of Domain Names July 1997 - - - In this canonical form, the trailing .i is absent, and the octets can - be reconstructed from the %HH-encoding and interpreted as UTF-8 by - generic URL software. The software part dealing with domain names - will carry out the conversion to the .i form. - - -5. Alternate Proposals - - - -5.1 The Dillon Proposal - - The proposal of Michael Dillon [Dillon96] is also based on encoding - Unicode into the limited character set of domain names. Distinction - is done for each part, using the hyphen in initial position. Because - this does not fully conform to the syntax of existing domain names, - it is questionable whether it is backwards-compatible. On the other - hand, this has the advantage that local i18n domain names can be - installed easily without cooperation by the manager of the superdo- - main. - - A variable-length scheme with base 36 is used that can encode up to - 1610 characters, absolutely insufficient for Chinese or Japanese. - Characters assumed not to be used in i18n domain names are excluded, - i.e. only one case is allowed for basic Latin characters. This means - that large tables have to be worked out carefully to convert between - ISO 10646/Unicode and the actual number that is encoded with base 36. - - -5.2 Using a Separate Lookup Service - - Instead of using a special encoding and burdening DNS with i18n, one - could build and use a separate lookup service for i18n domain names. - Instead of converting to UCS4 and encoding according to Section 3.2, - and then calling the DNS resolver, a program would contact this new - service when seeing a domain name with characters outside the allowed - range. - - Such solutions have various problems. There are many directory ser- - vices and proposals for how to use them in a way similar to DNS. For - an overview and a specific proposal, see [Kle96]. However, while - there are many proposals, a real service containing the necessary - data and providing the wide installed base and distributed updating - is in DNS does not exist. - - Most directory service proposals also do not offer uniqueness. - Defining unique names again for a separate service will duplicate - much of the work done for DNS. If uniqueness is not guaranteed, the - - - - Expires End of January 1998 [Page 13] - -Internet Draft Internationalization of Domain Names July 1997 - - - user is bundened with additional selection steps. - - Using a separate lookup service for the internationalization of - domain names also results in more complex implementations than the - proposal made in this draft. Contrary to what some people might - expect, the use of a separate lookup service also does not solve a - capacity problem with DNS, because there is no such problem, nor will - one be created with the introduction of i18n domain names. - - -6. Generic Considerations - - - -6.1 Security Considerations - - This proposal is believed not to raise any other security considera- - tions than the current use of the domain name system. - - -6.2 Internationalization Considerations - - This proposal addresses internationalization as such. The main addi- - tional consideration with respect to internationalization may be the - indication of language. However, for concise identifiers such as - domain names, language tagging would be too much of a burden and - would create complex dependencies with semantics. - - - NOTE -- This section is introduced based on a recommenda- - tion in [RFCIAB]. A similar section addressing internation- - alization should be included in all application level - internet drafts and RFCs. - - - - - -Acknowledgements - - I am grateful in particular to the following persons for their advice - or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E. - Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith - Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl, - Paul A. Vixie, Francois Yergeau, - - - - - - - Expires End of January 1998 [Page 14] - -Internet Draft Internationalization of Domain Names July 1997 - - -Bibliography - - [ASCII] Coded Character Set -- 7-Bit American Standard Code - for Information Interchange, ANSI X3.4-1986. - - [Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software - Inc., November 1996 (circulated Dec. 6, 1996 on iahc- - discuss@iahc.org). - - [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter- - nationalization of the Hypertext Markup Language", - Work in progress (draft-ietf-html-i18n-05.txt), August - 1996. - - [iNORM] M. Duerst, "Normalization of Internationalized Identi- - fiers", draft-duerst-i18n-norm-00.txt, July 1997. - - [ISO3166] ISO 3166, "Code for the representation of names of - countries", ISO 3166:1993. - - [ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor- - mation technology -- Universal multiple-octet coded - character Set (UCS) -- Part 1: Architecture and basic - multilingual plane. - - [Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company - Name Retrieval", Work in progress (draft-klensin-tld- - whois-01.txt), November 1996. - - [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili- - ties", ISI, Nov. 1987. - - [RFC1035] P. Mockapetris, "Domain Names - Implementation and - Specification", ISI, Nov. 1987. - - [RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten- - sions) Part Two: Message Header Extensions for Non- - ASCII Text", University of Tennessee, September 1993. - - [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor- - mation Format of Unicode", Taligent Inc., July 1994. - - [RFC1730] C. Malamud and M. Rose, "Principles of Operation for - the TPC.INT Subdomain: General Principles and Policy", - Internet Multicasting Service, October 1993. - - [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, - "Uniform Resource Locators (URL)", CERN, Dec. 1994. - - - - Expires End of January 1998 [Page 15] - -Internet Draft Internationalization of Domain Names July 1997 - - - [RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode - and ISO 10646", Alis Technologies, October 1996. - - [RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. - Atkinson, M. Crispin, P. Svanberg, "Report from the - IAB Character Set Workshop", October 1996 (currently - available as draft-weider-iab-char-wrkshop-00.txt). - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 2.0", Addison-Wesley, Reading, MA, 1996. - - [Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech- - nologies, - . - - - -Author's Address - - Martin J. Duerst - Multimedia-Laboratory - Department of Computer Science - University of Zurich - Winterthurerstrasse 190 - CH-8057 Zurich - Switzerland - - Tel: +41 1 257 43 16 - Fax: +41 1 363 00 35 - E-mail: mduerst@ifi.unizh.ch - - - NOTE -- Please write the author's name with u-Umlaut wherever - possible, e.g. in HTML as Dürst. - - - - - - - - - - - - - - - - - - Expires End of January 1998 [Page 16] - \ No newline at end of file + + + + + + +Internet Draft M. Duerst + Keio University +Expires in six months July 1998 + + + Internationalization of Domain Names + + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working doc- + uments of the Internet Engineering Task Force (IETF), its areas, and + its working groups. Note that other groups may also distribute work- + ing documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a "working + draft" or "work in progress". + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ftp.ietf.org (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + Distribution of this document is unlimited. Please send comments to + the author at . + + +Abstract + + Internet domain names are currently limited to a very restricted + character set. This document proposes the introduction of a new + "zero-level" domain (ZLD) to allow the use of arbitrary characters + from the Universal Character Set (ISO 10646/Unicode) in domain names. + The proposal is fully backwards compatible and does not need any + changes to DNS. Version 02 is reissued without changes just to + keep this draft available. + +Table of contents + + 0. Change History ................................................. 2 + 0.8 Changes Made from Version 01 to Version 02 .................. 2 + 0.9 Changes Made from Version 00 to Version 01 .................. 2 + 1. Introduction ................................................... 3 + 1.1 Motivation .................................................. 3 + + + + Expires End of January 1998 [Page 1] + +Internet Draft Internationalization of Domain Names July 1997 + + + 1.2 Notational Conventions ...................................... 4 + 2. The Hidden Zero Level Domain ................................... 4 + 3. Encoding International Characters .............................. 5 + 3.1 Encoding Requirements ....................................... 5 + 3.2 Encoding Definition ......................................... 5 + 3.3 Encoding Example ............................................ 7 + 3.4 Length Considerations ....................................... 8 + 4. Usage Considerations ........................................... 8 + 4.1 General Usage ............................................... 8 + 4.2 Usage Restrictions .......................................... 9 + 4.3 Domain Name Creation ....................................... 10 + 4.4 Usage in URLs .............................................. 12 + 5. Alternate Proposals ........................................... 13 + 5.1 The Dillon Proposal ........................................ 13 + 5.2 Using a Separate Lookup Service ............................ 13 + 6. Generic Considerations ........................................ 14 + 5.1 Security Considerations .................................... 14 + 5.2 Internationalization Considerations ........................ 14 + Acknowledgements ................................................. 14 + Bibliography ..................................................... 15 + Author's Address .................................................= + 16 + + + + +0. Change History + + + +0.8 Changes Made from Version 01 to Version 02 + + No significant changes; reissued to make it available officially. + Changed author's address. + + Changes deferred to future versions (if ever): + - Decide on ZLD name (.i or .i18n.int or something else) + - Decide on casing solution + - Decide on exact syntax + - Proposals for experimental setup + + + + +0.9 Changes Made from Version 00 to Version 01 + + + + + + + + Expires End of January 1998 [Page 2] + +Internet Draft Internationalization of Domain Names July 1997 + + + - Minor rewrites and clarifications + + - Added the following references: [RFC1730], [Kle96], [ISO3166], + [iNORM] + + - Slightly expanded discussion about casing + + - Added some variant proposals for syntax + + - Added some explanations about different kinds of name parallelism + + - Added some explanation about independent addition of internation- + alized names in subdomains without bothering higher-level domains + + - Added some explanations about tools needed for support, and the + MX/CNAME problem + + - Change to RFC1123 (numbers allowed at beginning of labels) + + + + +1. Introduction + + +1.1 Motivation + + + The lower layers of the Internet do not discriminate any language or + script. On the application level, however, the historical dominance + of the US and the ASCII character set [ASCII] as a lowest common + denominator have led to limitations. The process of removing these + limitations is called internationalization (abbreviated i18n). One + example of the abovementioned limitations are domain names [RFC1034, + RFC1035], where only the letters of the basic Latin alphabet (case- + insensitive), the decimal digits, and the hyphen are allowed. + + While such restrictions are convenient if a domain name is intended + to be used by arbitrary people around the globe, there may be very + good reasons for using aliases that are more easy to remember or type + in a local context. This is similar to traditional mail addresses, + where both local scripts and conventions and the Latin script can be + used. + + There are many good reasons for domain name i18n, and some arguments + that are brought forward against such an extension. This document, + however, does not discuss the pros and cons of domain name i18n. It + proposes and discusses a solution and therefore eliminates one of the + + + + Expires End of January 1998 [Page 3] + +Internet Draft Internationalization of Domain Names July 1997 + + + most often heard arguments agains, namely "it cannot be done". + + The solution proposed in this document consists of the introduction + of a new "zero-level" domain building the root of a new domain + branch, and an encoding of the Universal Character Set (UCS) + [ISO10646] into the limited character set of domain names. + + + +1.2 Notational Conventions + + In the domain name examples in this document, characters of the basic + Latin alphabet (expressible in ASCII) are denoted with lower case + letters. Upper case letters are used to represent characters outside + ASCII, such as accented characters of the Latin alphabet, characters + of other alphabets and syllabaries, ideographic characters, and vari- + ous signs. + + +2. The Hidden Zero Level Domain + + The domain name system uses the domain "in-addr.arpa" to convert + internet addresses back to domain names. One way to view this is to + say that in-addr.arpa forms the root of a separate hierarchy. This + hierarchy has been made part of the main domain name hierarchy just + for implementation convenience. While syntactically, in-addr.arpa is + a second level domain (SLD), functionally it is a zero level domain + (ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is + the domain tpc.int, which provides a hierarchy of the global phone + numbering system [RFC1530] for services such as paging and printing + to fax machines. + + For domain name i18n to work inside the tight restrictions of domain + name syntax, one has to define an encoding that maps strings of UCS + characters to strings of characters allowable in domain names, and a + means to distinguish domain names that are the result of such an + encoding from ordinary domain names. + + This document proposes to create a new ZLD to distinguish encoded + i18n domain names from traditional domain names. This domain would + be hidden from the user in the same way as a user does not see in- + addr.arpa. This domain could be called "i18n.arpa" (although the use + of arpa in this context is definitely not appropriate), simply + "i18n", or even just "i". Below, we are using "i" for shortness, + while we leave the decision on the actual name to further= + discussion. + + + + + + + Expires End of January 1998 [Page 4] + +Internet Draft Internationalization of Domain Names July= + 1997 + + +3. Encoding International Characters + + + + +3.1 Encoding Requirements + + + Until quite recently, the thought of going beyond ASCII for something + such as domain names failed because of the lack of a single encom- + passing character set for the scripts and languages of the world. + Tagging techniques such as those used in MIME headers [RFC1522] would + be much too clumsy for domain names. + + The definition of ISO 10646 [ISO10646], codepoint by codepoint iden- + tical with Unicode [Unicode], provides a single Universal Character + Set (UCS). A recent report [RFCIAB] clearly recommends to base the + i18n of the Internet on these standards. + + An encoding for i18n domain names therefore has to take the charac- + ters of ISO 10646/Unicode as a starting point. The full four-byte + (31 bit) form of UCS, called UCS4, should be used. A limitation to + the two-byte form (UCS2), which allows only for the encoding of the + Base Multilingual Plane, is too restricting. + + For the mapping between UCS4 and the strongly limited character set + of domain names, the following constraints have to be considered: + + - The structure of domain names, and therefore the "dot", have to be + conserved. Encoding is done for individual labels. + + - Individual labels in domain names allow the basic Latin alphabet + (monocase, 26 letters), decimal digits, and the "-" inside the + label. The capacity per octet is therefore limited to somewhat + above 5 bits. + + - There is no need nor possibility to preserve any characters. + + - Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order) + should be encoded relatively compactly. A variable-length encoding + (similar to UTF-8) seems desirable. + + + +3.2 Encoding Definition + + + Several encodings for UCS, so called UCS Transform Formats, exist + + + + Expires End of January 1998 [Page 5] + +Internet Draft Internationalization of Domain Names July 1997 + + + already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni- + code]. Unfortunately, none of them is suitable for our purposes. We + therefore use the following encoding: + + - To accommodate the slanted probability distribution of characters + in UCS4, a variable-length encoding is used. + + - Each target letter encodes 5 bits of information. Four bits of + information encode character data, the fifth bit is used to indi- + cate continuation of the variable-length encoding. + + - Continuation is indicated by distinguishing the initial letter + from the subsequent letter. + + - Leading four-bit groups of binary value 0000 of UCS4 characters + are discarded, except for the last TWO groups (i.e. the last + octet). This means that ASCII and Latin-1 characters need two + target letters, the main alphabets up to and including Tibetan + need three target letters, the rest of the characters in the BMP + need four target letters, all except the last (private) plane in + the UTF-16/Surrogates area [Unicode] need five target letters, and + so on. + + - The letters representing the various bit groups in the various + positions are chosen according to the following table: + + + Nibble Value Initial Subsequent + Hex Binary + 0 0000 G 0 + 1 0001 H 1 + 2 0010 I 2 + 3 0011 J 3 + 4 0100 K 4 + 5 0101 L 5 + 6 0110 M 6 + 7 0111 N 7 + 8 1000 O 8 + 9 1001 P 9 + A 1010 Q A + B 1011 R B + C 1100 S C + D 1101 T D + E 1110 U E + F 1111 V F + + + [Should we try to eliminate "I" and "O" from initial? "I" might be + + + + Expires End of January 1998 [Page 6] + +Internet Draft Internationalization of Domain Names July 1997 + + + eliminated because then an algorithm can more easily detect ".i". "O" + could lead to some confusion with "0". What other protocols are + there that might be able to use a similar solution, but that might + have other restrictions for the initial letters? Proposal to run ini- + tial range from H to X. Extracting the initial bits then becomes ^ + 'H'. Proposal to have a special convention for all-ASCII labels + (start label with one of the letters not used above).] + + Please note that this solution has the following interesting proper- + ties: + + - For subsequent positions, there is an equivalence between the hex- + adecimal value of the character code and the target letter used. + This assures easy conversion and checking. + + - The absence of digits from the "initial" column, and the fact that + the hyphen is not used, assures that the resulting string conforms + to domain name syntax. + + - Raw sorting of encoded and unencoded domain names is equivalent. + + - The boundaries of characters can always be detected easily. + (While this is important for representations that are used inter- + nally for text editing, it is actually not very important here, + because tools for editing can be assumed to use a more straight- + forward representation internally.) + + - Unless control characters are allowed, the target string will + never actually contain a G. + + + +3.3 Encoding Example + + + As an example, the current domain + + is.s.u-tokyo.ac.jp + + with the components standing for information science, science, the + University of Tokyo, academic, and Japan, might in future be repre- + sented by + + JOUHOU.RI.TOUDAI.GAKU.NIHON + + (a transliteration of the kanji that might probably be chosen to rep- + resent the same domain). Writing each character in U+HHHH notation as + in [Unicode], this results in the following (given for reference + + + + Expires End of January 1998 [Page 7] + +Internet Draft Internationalization of Domain Names July 1997 + + + only, not the actual encoding or something being typed in by the + user): + + U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c + + The software handling internationalized domain names will translate + this, according to the above specifications, before submitting it to + the DNS resolver, to: + + M0C5L831.N406.M771L927.LB66.M5E5M72C.i + + + +3.4 Length Considerations + + + DNS allows for a maximum of 63 positions in each part, and for 255 + positions for the overall domain name including dots. This allows up + to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic + alphabet, in a label. While this does not allow for the same margin + as in the case of ASCII domain names, it should still be quite suffi- + cient. [Problems could only surface for languages that use very long + words or terms and don't know any kind of abbreviations or similar + shortening devices. Do these exist? Islandic expert asserted + Islandic is not a problem.] DNS contains a compression scheme that + avoids sending the same trailing portion of a domain name twice in + the same transmission. Long domain names are therefore not that much + of a concern. + + +4. Usage Considerations + + + +4.1 General Usage + + + To implement this proposal, neither DNS servers nor resolvers need + changes. These programs will only deal with the encoded form of the + domain name with the .i suffix. Software that wants to offer an + internationalized user interface (for example a web browser) is + responsible for the necessary conversions. It will analyze the domain + name, call the resolver directly if the domain name conforms to the + domain name syntax restrictions, and otherwise encode the name + according to the specifications of Section 3.2 and append the .i suf- + fix before calling the resolver. New implementations of resolvers + will of course offer a companion function to gethostbyname accepting + a ISO10646/Unicode string as input. + + + + Expires End of January 1998 [Page 8] + +Internet Draft Internationalization of Domain Names July 1997 + + + For domain name administrators, them main tool that will be needed is + a program to compile files configuring zones from an UTF-8 notation + (or any other suitable encoding) to the encoding described in Section + 3.3. Utility tools will include a corresponding decompiler, checkers + for various kinds of internationalization-related errors, and tools + for managing syntactic parallelism (see Section 4.3). + + +4.2 Usage Restrictions + + + While this proposal in theory allows to have control characters such + as BEL or NUL or symbols such as arrows and smilies in domain names, + such characters should clearly be excluded from domain names. Whether + this has to be explicitly specified or whether the difficulty to type + these characters on any keyboard of the world will limit their use + has to be discussed. One approach is to start with a very restricted + subset and gradually relax it; the other is to allow almost anything + and to rely on common sense. Anyway, such specifications should go + into a separate document to allow easy updates. + + A related point is the question of equivalence. For historical rea- + sons, ISO 10646/Unicode contain considerable number of compatibility + characters and allow more than one representation for characters with + diacritics. To guarantee smooth interoperability in these and related + cases, additional restrictions or the definition of some form of nor- + malization seem necessary. However, this is a general problem + affecting all areas where ISO 10646/Unicode is used in identifiers, + and should therefore be addressed in a generic way. See [iNORM] for + an initial proposal. + + Equally related is the problem of case equivalence. Users can very + well distinguish between upper case and lower case. Also, casing in + an i18n context is not as straightforward as for ASCII, so that case + equivalence is best avoided. Problems therefore result not from the + fact that case is distinguished for i18n domain names, but from the + fact that existing domain names do not distinguish case. Where it is + impossible to distinguish between next.com and NeXT.com, the same two + subdomains would easily be distinguishable if subordinate to a i18n + domain. There are several possible solutions. One is to try to grad- + ually migrate from a case-insensitive solution to a case-sensitive + solution even for ASCII. Another is to allow case-sensitivity only + beyond ASCII. Another is to restrict anything beyond ASCII to lower- + case only (lowercase distinguishes better than uppercase, and is also + generally used for ASCII domain names). + + A problem that also has to be discussed and solved is bidirectional- + ity. Arabic and Hebrew characters are written right-to-left, and the + + + + Expires End of January 1998 [Page 9] + +Internet Draft Internationalization of Domain Names July 1997 + + + mixture with other characters results in a divergence between logical + and graphical sequence. See [HTML-I18N] for more explanations. The + proposal of [Yer96] for dealing with bidirectionality in URLs could + probably be applied to domain names. Anyway, there should be a gen- + eral solution for identifiers, not a DNS-specific solution. + + +4.3 Domain Name Creation + + + The ".i" ZLD should be created as such to allow the internationaliza- + tion of domain names. Rules for creating subdomains inside ".i" + should follow the established rules for the creation of functionally + equivalent domains in the existing domain hierarchy, and should + evolve in parallel. + + For the actual domain hierarchy, the amount of parallelism between + the current ASCII-oriented hierarchy and some internationalized hier- + archy depends on various factors. In some cases, two fully parallel + hierarchies may emerge. In other cases, if more than one script or + language is used locally, more than two parallel hierarchies may + emerge. Some nodes, e.g. in intranets, may only appear in an i18n + hierarchy, whereas others may only appear in the current hierarchy. + In some cases, the pecularities of scripts, languages, cultures, and + the local marketplace may lead to completely different hierarchies. + + Also, one has to be aware that there may be several kinds of paral- + lelisms. The first one is called syntactic parallelism. If there is + a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz + will have to exist both in the traditional DNS hierarchy as well as + within the hierarchy starting at the .i ZLD, with appropriate encod- + ing. + + The second type of parallelism is called transcription parallelism. + It results by transcribing or transliterating relations between ASCII + domain names and domain names in other scripts. + + The third type of parallelism is called semantic parallelism. It + results from translating elements of a domain name from one language + to another, possibly also changing the script or set of used charac- + ters. + + On the host level, parallelism means that there are two names for the + same host. Conventions should exist to decide whether the parallel + names should have separate IP addresses or not (A record or CNAME + record). With separate IP addresses, address to name lookup is easy, + otherwise it needs special precautions to be able to find all names + corresponding to a given host address. Another detail entering this + + + + Expires End of January 1998 [Page 10] + +Internet Draft Internationalization of Domain Names July 1997 + + + consideration is that MX records only work for hostnames/domains, + not for CNAME aliases. This at least has the consequence that alias + resolution for internationalized mail addresses has to occur before + MX record lookup. + + When discussing and applying the rules for creating domain names, + some peculiarities of i18n domain names should be carefully consid- + ered: + + - Depending on the script, reasonable lengths for domain name parts + may differ greatly. For ideographic scripts, a part may often be + only a one-letter code. Established rules for lengths may need + adaptation. For example, a rule for country TLDs could read: one + ideographic character or two other characters. + + - If the number of generic TLDs (.com, .edu, .org, .net) is kept + low, then it may be feasible to restrict i18n TLDs to country + TLDs. + + - There are no ISO 3166 [ISO3166] two-letter codes in scripts other + than Latin. I18n domain names for countries will have to be + designed from scratch. + + - The names of some countries or regions may pose greater political + problems when expressed in the native script than when expressed + in 2-letter ISO 3166 codes. + + - I18n country domain names should in principle only be created in + those scripts that are used locally. There is probably little use + in creating an Arabic domain name for China, for example. + + - In those cases where domain names are open to a wide range of + applicants, a special procedure for accepting applications should + be used so that a reasonable-quality fit between ASCII domain + names and i18n domain names results where desired. This would + probably be done by establishing a period of about a month for + applications inside a i18n domain newly created as a parallel for + an existing domain, and resolving the detected conflicts. For + syntactically parallel domain names, the owners should always be + the same. Administration may be split in some cases to account for + the necessary linguistic knowledge. For domain names with tran- + scription parallelism and semantic parallelism, the question of + owner identity should depend on the real-life situation (trade- + marks,...). + + - It will be desirable to have internationalized subdomains in non- + internationalized TLDs. As an example, many companies in France + may want to register an accented version of their company name, + + + + Expires End of January 1998 [Page 11] + +Internet Draft Internationalization of Domain Names July 1997 + + + while remaining under the .fr TLD. For this, .fr would have to be + reregistered as .M6N2.i. Accented and other internationalized sub- + domains would go below .M6N2.i, whereas unaccented ones would go + below .fr in its plain form. + + - To generalize the above case, one may need to create a requirement + that any domain name registry would have to register and manage + syntactically parallel domain names below the .i ZLD upon request + to allow registration of i18n domain names in arbitrary subdo- + mains. An alternative to this is to organize domain name search + so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in + .i, the name server for .fr is queried for XXXXXX.M6N2.i (with + XXXXXX appropriately encoded). This convention would allow lower- + level domains to introduce internationalized subdomains without + depending on higher-level domains. + + + +4.4 Usage in URLs + + According to current definitions, URLs encode sequences of octets + into a sequence of characters from a character set that is almost as + limited as the character set of domain names [RFC1738]. This is + clearly not satisfying for i18n. + + Internationalizing URLs, i.e. assigning character semantics to the + encoded octets, can either be done separately for each part and/or + scheme, or in an uniform way. Doing it separately has the serious + disadvantage that software providing user interfaces for URLs in gen- + eral would have to know about all the different i18n solutions of the + different parts and schemes. Many of these solutions may not even be + known yet. + + It is therefore definitely more advantageous to decide on a single + and consistent solution for URL internationalization. The most valu- + able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an + ASCII-compatible encoding of UCS4. + + Therefore, an URL containing the domain name of the example of Sec- + tion 3.3 should not be written as: + + ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i + + (although this will also work) but rather + + ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7. + %e5%ad%a6.%e6%97%a5%e6%9c%ac + + + + + Expires End of January 1998 [Page 12] + +Internet Draft Internationalization of Domain Names July 1997 + + + In this canonical form, the trailing .i is absent, and the octets can + be reconstructed from the %HH-encoding and interpreted as UTF-8 by + generic URL software. The software part dealing with domain names + will carry out the conversion to the .i form. + + +5. Alternate Proposals + + + +5.1 The Dillon Proposal + + The proposal of Michael Dillon [Dillon96] is also based on encoding + Unicode into the limited character set of domain names. Distinction + is done for each part, using the hyphen in initial position. Because + this does not fully conform to the syntax of existing domain names, + it is questionable whether it is backwards-compatible. On the other + hand, this has the advantage that local i18n domain names can be + installed easily without cooperation by the manager of the superdo- + main. + + A variable-length scheme with base 36 is used that can encode up to + 1610 characters, absolutely insufficient for Chinese or Japanese. + Characters assumed not to be used in i18n domain names are excluded, + i.e. only one case is allowed for basic Latin characters. This means + that large tables have to be worked out carefully to convert between + ISO 10646/Unicode and the actual number that is encoded with base= + 36. + + +5.2 Using a Separate Lookup Service + + Instead of using a special encoding and burdening DNS with i18n, one + could build and use a separate lookup service for i18n domain names. + Instead of converting to UCS4 and encoding according to Section 3.2, + and then calling the DNS resolver, a program would contact this new + service when seeing a domain name with characters outside the allowed + range. + + Such solutions have various problems. There are many directory ser- + vices and proposals for how to use them in a way similar to DNS. For + an overview and a specific proposal, see [Kle96]. However, while + there are many proposals, a real service containing the necessary + data and providing the wide installed base and distributed updating + is in DNS does not exist. + + Most directory service proposals also do not offer uniqueness. + Defining unique names again for a separate service will duplicate + much of the work done for DNS. If uniqueness is not guaranteed, the + + + + Expires End of January 1998 [Page 13] + +Internet Draft Internationalization of Domain Names July 1997 + + + user is bundened with additional selection steps. + + Using a separate lookup service for the internationalization of + domain names also results in more complex implementations than the + proposal made in this draft. Contrary to what some people might + expect, the use of a separate lookup service also does not solve a + capacity problem with DNS, because there is no such problem, nor will + one be created with the introduction of i18n domain names. + + +6. Generic Considerations + + + +6.1 Security Considerations + + This proposal is believed not to raise any other security considera- + tions than the current use of the domain name system. + + +6.2 Internationalization Considerations + + This proposal addresses internationalization as such. The main addi- + tional consideration with respect to internationalization may be the + indication of language. However, for concise identifiers such as + domain names, language tagging would be too much of a burden and + would create complex dependencies with semantics. + + + NOTE -- This section is introduced based on a recommenda- + tion in [RFCIAB]. A similar section addressing internation- + alization should be included in all application level + internet drafts and RFCs. + + + + + +Acknowledgements + + I am grateful in particular to the following persons for their advice + or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E. + Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith + Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl, + Paul A. Vixie, Francois Yergeau, and others. + + + + + + + Expires End of January 1998 [Page 14] + +Internet Draft Internationalization of Domain Names July= + 1997 + + +Bibliography + + [ASCII] Coded Character Set -- 7-Bit American Standard Code + for Information Interchange, ANSI X3.4-1986. + + [Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software + Inc., November 1996 (circulated Dec. 6, 1996 on iahc- + discuss@iahc.org). + + [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter- + nationalization of the Hypertext Markup Language", + Work in progress (draft-ietf-html-i18n-05.txt), August + 1996. + + [iNORM] M. Duerst, "Normalization of Internationalized Identi- + fiers", draft-duerst-i18n-norm-00.txt, July 1997. + + [ISO3166] ISO 3166, "Code for the representation of names of + countries", ISO 3166:1993. + + [ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor- + mation technology -- Universal multiple-octet coded + character Set (UCS) -- Part 1: Architecture and basic + multilingual plane. + + [Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company + Name Retrieval", Work in progress (draft-klensin-tld- + whois-01.txt), November 1996. + + [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili- + ties", ISI, Nov. 1987. + + [RFC1035] P. Mockapetris, "Domain Names - Implementation and + Specification", ISI, Nov. 1987. + + [RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten- + sions) Part Two: Message Header Extensions for Non- + ASCII Text", University of Tennessee, September 1993. + + [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor- + mation Format of Unicode", Taligent Inc., July 1994. + + [RFC1730] C. Malamud and M. Rose, "Principles of Operation for + the TPC.INT Subdomain: General Principles and Policy", + Internet Multicasting Service, October 1993. + + [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, + "Uniform Resource Locators (URL)", CERN, Dec. 1994. + + + + Expires End of January 1998 [Page 15] + +Internet Draft Internationalization of Domain Names July 1997 + + + [RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode + and ISO 10646", Alis Technologies, October 1996. + + [RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. + Atkinson, M. Crispin, P. Svanberg, "Report from the + IAB Character Set Workshop", October 1996 (currently + available as draft-weider-iab-char-wrkshop-00.txt). + + [Unicode] The Unicode Consortium, "The Unicode Standard, Version + 2.0", Addison-Wesley, Reading, MA, 1996. + + [Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech- + nologies, + = + . + + + +Author's Address + + Martin J. Duerst + World Wide Web Consortium + Keio Research Institute at SFC + Keio University + 5322 Endo + Fujisawa + 252-8520 Japan + + Tel: +81 466 49 11 70 + E-mail: mduerst@w3.org + + + NOTE -- Please write the author's name with u-Umlaut wherever + possible, e.g. in HTML as Dürst. + + + + + + + + + + + + + + + + + + + Expires End of January 1998 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsind-indirect-key-00.txt b/doc/draft/draft-ietf-dnsind-indirect-key-00.txt deleted file mode 100644 index 7857081ee9..0000000000 --- a/doc/draft/draft-ietf-dnsind-indirect-key-00.txt +++ /dev/null @@ -1,470 +0,0 @@ -DNSIND Working Group D. Eastlake -INTERNET-DRAFT IBM -Expires October 1999 - April 1999 -draft-ietf-dnsind-indirect-key-00.txt - - - Indirect KEY RRs in the Domain Name System (DNS) - -------- --- --- -- --- ------ ---- ------ ----- - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is - intended to be become a Proposed Standard RFC. Distribution of this - document is unlimited. Comments should be sent to the DNSSEC mailing - list or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - -Abstract - - [RFC 2535] defines a means for storing cryptographic public keys in - the Domain Name System. An additional code point is defined for the - algorithm field of the KEY resource record (RR) to indicate that the - key is not stored in the KEY RR but is pointed to by the KEY RR. - Encodings to indicate different types of key and pointer formats are - specified. - - [This draft is moved from the DNSSEC WG as part of that WG's merger - into me DNSIND WG. It would have been draft-ietf-dnssec-indirect- - key-02.txt in the DNSSEC WG.] - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Indirect KEY RRs - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. The Indirect KEY RR Algorithm...........................3 - 2.1 The Target Type Field..................................4 - 2.2 The Target Algorithm Field.............................5 - 2.3 The Hash Fields........................................5 - 3. Performance Considerations..............................6 - 4. IANA Considerations.....................................6 - 5. Security Considerations.................................6 - References.................................................7 - Author's Address...........................................7 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Indirect KEY RRs - - -1. Introduction - - The Domain Name System (DNS) security extensions [RFC 2535] provide - for the general storage of public keys in the domain name system via - the KEY resource record (RR). These KEY RRs are used in support of - DNS security and may be used to support other security protocols. - KEY RRs can be associated with users, zones, and hosts or other end - entities named in the DNS. - - For reasons given below, it will sometimes be desireable to store a - key or keys elsewhere and merely point to it from the KEY RR. - Indirect key storage makes it possible to point to a key service via - a URL, to have a compact pointer to a larger key or set of keys, to - point to a certificate either inside DNS [RFC 2538] or outside the - DNS, and where appropriate, to store a key or key set applicable to - many DNS entries in some place and point to it from those entries. - - However, to simplify DNSSEC implementation, this technique MUST NOT - be used for KEY RRs used in for verification in DNSSEC, i.e., the - value of the "protocol" field of an indirect KEY RR MUST NOT be 3. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", - "RECOMMENDED", and "MAY" in this document are to be interpreted as - described in [RFC 2119]. - - - -2. The Indirect KEY RR Algorithm - - Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535] - algorithm number 252 is defined as the indirect key algorithm. This - algorithm MAY NOT be used for zone keys in support of DNS security. - All KEYs used in DNSSEC validation MUST be stored directly in the - DNS. - - When the algorithm byte of a KEY RR has the value 252, the "public - key" portion of the RR is formated as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | target type | target alg. | hash type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | hash size | hash (variable size) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ - | / - / pointer (variable size) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Indirect KEY RRs - - -2.1 The Target Type Field - - Target type specifies the type of the key containing data being - pointed at. - - Target type - ----------- - - 0 - reserved, see section 4 - - 1 - indicates that the pointer is a domain name from which KEY RRs - [RFC 2535] should be retrieved. Name compression in the pointer - field is prohibited. - - 2 - indicates that the pointer is a null terminated character string - which is a URL [RFC 1738]. For exisiting data transfer URL - schemes, such as ftp, http, shttp, etc., the data is the same as - the public key portion of a KEY RR. (New URL schemes may be - defined which return multiple keys.) - - 3 - indicates that the pointer is a domain name from which CERT RRs - [RFC 2538] should be retrieved. Name compression in the pointer - field is prohibited. - - 4 - indicates that the pointer is a null terminated character string - which is a URL [RFC 1738]. For exisiting data transfer URL - schemes, such as ftp, http, shttp, etc., the data is the same as - the entire RDATA portion of a CERT RR [RFC 2538]. (New URL - schemes may be defined which return multiple such data blocks.) - - 5 - indicates that the pointer is a null terminated character string - which is a URL [RFC 1738]. For exisiting data transfer URL - schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC - 2437] format key. (New URL schemes may be defined which return - multiple keys.) - - 6 through 255 - available for assignment, see section 4. - - 256 through 511 (i.e., 256 + n) - indicate that the pointer is a null - terminated character string which is a URL [RFC 1738]. For - exisiting data transfer URL schemes, such as ftp, http, shttp, - etc., the data is a certificate of the type indicated by a CERT RR - [RFC 2538] certificate type of n. That is, target types 257, 258, - and 259 are PKIX, SPKI, and PGP certificates and target types 509 - and 510 are URL and OID private certificate types. (New URL - schemes may be defined which return multiple such certificates.) - - 512 through 65534 - available for assignment, see section 4. - - 65535 reserved, see section 4. - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Indirect KEY RRs - - -2.2 The Target Algorithm Field - - The algorithm field is as defined in [RFC 2535]. If non-zero, it - specifies the algorithm type of the target key or keys pointed. If - zero, it does not specify what algorithm the target key or keys apply - to. - - - -2.3 The Hash Fields - - If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an - appropriately secure DNS zone with a resolver implementing DNS - security, then there would be a high level of confidence in the - entire value of the KEY RRset including any direct keys. This may or - may not be true of any indirect key pointed to. If an indirect key - is embodied in a certificate or retrieved via a secure protocol such - as SHTTP, it may also be secure. But an indirecting KEY RR could, - for example, simply have an FTP URL pointing to a binary key stored - elsewhere, the retrieval of which would not be secure. - - The hash option in algorithm 252 KEY RRs provides a means of - extending the security of the indirecting KEY RR to the actual key - material pointed at. By including a hash in a secure indirecting RR, - this secure hash can be checked against the hash of the actual keying - material - - Type Hash Algorithm - ---- -------------- - 0 indicates no hash present - 1 MD5 [RFC 1321] - 2 SHA-1 - 3 RIPEMD - 4-252 available, see section 4 - 253 private, domain name (see below) - 254 private, OID (see below) - 255 reserved - - Codes 253 and 254 indicate that a private, proprietary, local, or - experimental hash algorithm is used. For code 253, the hash field - begins with a wire encoded domain name (with compression prohibited) - that indicates the algorithm to use. For code 254, the hash field - begins with a one byte unsigned OID length followed by a BER encoded - OID which indicates the algorithm to use. - - The hash size field is an unsigned octet count of the hash field size - less the length of any code 253 or 254 prefix. For some hash - algorithms it may be fixed by the algorithm choice but this will not - always be the case. For example, hash size is used to distinguish - between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Indirect KEY RRs - - - hash algorithm field is 0, the hash size MUST be zero and no hash - octets are present. - - The hash field itself is variable size with its length specified by - the hash size field and any code 253 or 254 prefix. - - - -3. Performance Considerations - - With current public key technology, an indirect key will sometimes be - shorter than the keying material it points at. In addition, there - can be cases where a single indirect KEY RR points to multiple keys - elsewhere. This may improve DNS performance in the retrieval of the - initial KEY RR. However, an additional retrieval step then needs to - be done to get the actually keying material which must be added to - the overall time to get the public key. - - - -4. IANA Considerations - - IETF consensus, standards action, and similar terms in this section - are as define in [RFC 2434]. - - KEY RR algorithm number 252 was already reserved for indirect keys in - RFC 2535. - - An IETF standards action is required to allocate target type codes - hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF. - Codes in the range x1000 through x7FFF can be allocated by an IETF - consensus. Codes x8000 through xFEFF are available on a first come - first serve basis. Codes xFF00 through xFFFE are available for - experimentation or private local use without allocation. Use of - codes in this block may result in conflicts outside such experiment - or locality. - - An IETF consensus is required to allocate an indirect KEY RR hash - algorithm code in the range 4-252 and a standards action is required - to allocate hash algorithm code 255. Codes 253 and 254 should cover - requirements for local, private, or proprietary algorithms. - - - -5. Security Considerations - - The indirecting step of using an indirect KEY RR adds complexity and - additional steps where security could go wrong. If the indirect key - RR was retrieved from a zone that was insecure for the resolver, you - have no security. If the indirect key RR, although secure itself, - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Indirect KEY RRs - - - point to a key which can not be securely retrieved and is not - validateted by a secure hash in the indirect key RR, you have no - security. - - - -References - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. - - RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform - Resource Locators (URL)", December 1994. - - RFC 2119 - "Key words for use in RFCs to Indicate Requirement - Levels", S. Bradner. March 1997. - - RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS - Specification", July 1997. - - RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", October 1998. - - RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", October 1998. - - RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", March 1999. - - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 shindegan Hill Road, RR #1 - Carmel, NY 10512 USA - - Telephone: +1-914-784-7913 (w) - +1-914-276-2668 (h) - FAX: +1-914-784-3833 (w) - EMail: dee3@us.ibm.com - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Indirect KEY RRs - - -Expiration and File Name - - This draft expires October 1999. - - Its file name is draft-ietf-dnsind-indirect-key-00.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - diff --git a/doc/draft/draft-ietf-dnsind-indirect-key-01.txt b/doc/draft/draft-ietf-dnsind-indirect-key-01.txt new file mode 100644 index 0000000000..61a52e49ba --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-indirect-key-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +D. Eastlake 3rd: dee3@torque.pothole.com + + diff --git a/doc/draft/draft-ietf-dnsind-local-names-07.txt b/doc/draft/draft-ietf-dnsind-local-names-07.txt deleted file mode 100644 index 63fcfcfb0e..0000000000 --- a/doc/draft/draft-ietf-dnsind-local-names-07.txt +++ /dev/null @@ -1,662 +0,0 @@ -DNS Working Group Donald E. Eastlake, 3rd -INTERNET-DRAFT IBM -Expires December 1999 June 1999 - -draft-ietf-dnsind-local-names-07.txt - - - Local Domain Name System (DNS) Names - ----- ------ ---- ------ ----- ----- - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-local-names-07.txt. - Distribution of this document is unlimited. Comments should be sent - to the DNS mailing list or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - -Abstract - - It is increasingly common for their to be "local" domain names which - are not intended to be seen from the global Internet. In some cases - this if for policy reasons, in other cases because they map to IP - addresses or other data which is only locally meaningful [RFC 1918, - 2373]. - - A new top level domain (TLD) name (.local) is reserved and a name - structure suggested below this TLD such that local private DNS zones - can safely be created without fear of conflict if these names should - leak out of a private enclave. It addition, a method of providing - DNS service for these names is suggested such that they are - maintained privately, similar to the reserved private IP addresses, - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Local DNS Names - - - yet locally appear to be part of the global DNS name tree and are - reachable by a local resolver with no special knowledge. Additional - second level domain names are assigned under this TLD for IPv6 link - and site local addresses and loopback functions. - - - -Acknowledgments - - The valuable contributions of the following persons are gratefully - acknowledged: - - Dan Harrington - - Michael A. Patton - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Local DNS Names - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Acknowledgments............................................2 - - Table of Contents..........................................3 - - 1. Introduction............................................4 - 2. Local Names Via The .local Top Level Domain.............5 - 2.1 Local DNS Server Specifics.............................7 - 2.2 Local in-addr.arpa Zones...............................8 - 2.3 Name Conflicts.........................................8 - 2.4 Nested Enclaves........................................9 - 3. Other Names in .local...................................9 - 4. Security Considerations.................................9 - 4.1 Strength of Privacy Offered............................9 - 4.2 Interaction with DNSSEC...............................10 - - References................................................11 - Author's Address..........................................11 - Expiration and File Name..................................11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Local DNS Names - - -1. Introduction - - The global Internet Domain Name System (DNS) is documented in [RFC - 1034, 1035, 1591, 2606] and numerous additional Requests for Comment. - It defines a tree of names starting with root, ".", immediately below - which are top level domain names such as .com and .us. Below top - level domain names there are normally additional levels of names. - - Generally the information in the DNS is public and intended to be - globally accessible. Certainly, in the past, the model of the - Internet was one of end-to-end openness [RFC 1958]. However, with - increasing security threats and concerns, firewalls and enclaves have - appeared. In many cases, organizations have hosts or resources that - they specifically want to reference with DNS names but which they - also want to be walled off from global access and even from global - knowledge of the DNS name for the resource. - - In the realm of IP addresses, this has been accomplished by reserving - three blocks of IPv4 addresses as documented in [RFC 1918] and by - allocating parts of the IPv6 address space for link and site local - addresses [RFC 2373]. Familiarity with the contents of these RFCs is - assumed. Addresses in these blocks are not to be globally routed. - - In the DNS area, local private names have generally been achieved in - the past by "splitting" DNS at the enclave boundary, giving different - answers to resolvers depending or whether they are inside or outside - of the enclave, using different servers for inside and outside, etc. - as mentioned in [RFC 1918]. Such relatively complex configuration - diddling is at variance with the simple global tree structure of the - initial DNS concept. - - This document specifies an alternative approach to achieving the - effect of local names that is more in tune with the concept of a - single global DNS tree or at least the appearance of a single tree. - Use of this approach is not required and older techniques will - continue to work. - - [RFC 1918] requires that private IP addresses not be indirectly - exposed to the general Internet via DNS records or otherwise. By - implication, the same would be true of IPv6 local addresses. This - RFC provides the recommended way to accomplish such private IP - address hiding and carves out a limited exception thereto for the - addresses of the servers for some zones which are children of the - .local top level domain name. - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Local DNS Names - - -2. Local Names Via The .local Top Level Domain - - The fundamental idea, as described in more detail below, is to define - second level domains under .local which are served by DNS name - servers that have private IP addresses. These server's addresses - would only be routed within the domain to which the names are local. - Thus the servers, and the names and resource records inside them, - would not be directly accessible outside the enclave, if the - guidelines in this document are followed. - - The following figure shows a highly simplified overview of an example - configuration: - - +----------------------------+ - | domain/enclave A | - | | - | #====================# | - | H private IP addrs A H | - | H H | - +-----------------------O privhost1 H | - | | H H | - +-----+-----------------O privhost2 H | - | | | H H | - | | | #====================# | - | | a | | - | +--------------------O pubhost3 | - .local | | | | | - +----+ | | +----------------------------+ - | | | | - | | | | +----------------------------+ - | | | | | domain/enclave B | - (root) | | | | | | - . ----+ | | | | #====================# | - | | | | | H private IP addrs B H | - | | | | | H H | - | +--|--------------------O privhost2 H | - | | | | H H | - +-------+ +-----------------O privhost3 H | - .com | | H : H | - | | #====:===============# | - | | : | - | b +-------------O pubhost4 | - +------+ | | - | +-------------O pubhost5 | - | | | - | +----------------------------+ - | - | example - +---------------------O pubhost6 - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Local DNS Names - - - Starting at the bottom, pubhost6 is intended to illustrate an - ordinary host connected to the Internet with domain name - pubhost6.example.com. Though not indicated in the above diagram, - every DNS zone is in fact served by at least two hosts (and some but - substantially more). The addresses of the servers for the root (.), - .com, and example.com zones would all be in the public portion of the - IP address space, i.e., in the space of all unicast IP addresses not - reserved for private use. - - Moving to the top of the figure, enclave A represents some - organization that wishes to have some hosts with publicly visible - names and some with hidden names that are visible only locally. - pubhost3.a.com is an example of a publicly visible host which would - probably have a public IP address although access to pubhost3 from - outside the enclave might be filtered or even blocked by a firewall - or the like. privhost1 and privhost2 are examples of hidden names. - If a zone with privhost1 and privhost2 in it is served by DNS servers - with private IP addresses ("private IP addresses A") such that the - servers are accessible within enclave A but not from outside enclave - A, then the information is that zone will only be locally visible. - As show in the above figure, privhost1 and privhost2 have addresses - that are also private IP addresses, making those hosts inaccessible - outside enclave A, but it is the private addresses of the DNS - servers, not of the hosts pointed to from within the private DNS - zone, that provides the protection for the DNS names and other - private DNS information. (From the above simplified diagram, it - might appear that fully qualified domain names of these hosts would - be privhost1.local and privhost2.local but the names are actually - more complex as explained in Section 2.1.) - - Finally, in the middle, another enclave is shown with two hosts with - visible names and public IP addresses, pubhost4.b.com and - pubhost5.b.com. In addition, there are two private host names - privhost2 and privhost3. The duplication of privhost2 between - enclaves A and B would not be a problem as only DNS resolvers in - enclave A can access the DNS servers with the zone having the enclave - A version of privhost2 and only DNS resolvers in enclave B can access - the DNS servers with the zone having the enclave B version of - privhost2. - - Publicly visible host names are required by [RFC 1918] to have public - (i.e., globally unique) IP addresses. Private DNS names would - normally have private IP addresses, and all do in the figure above, - but this is not required. A public IP address could be stored under - a private name. And, of course, it is possible for the same physical - host to have multiple IP addresses, including a mix of public and - private. The dotted line in the figure above is intended to indicate - that privhost3 and pubhost4 are actually the same physical machine. - The could be accomplished equally well by storing a single public - address for that host under both the public and private names or by - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Local DNS Names - - - having the host answer to both a public IP address stored under the - public name and a private IP address stored under the private name. - In the later case you could even also store the public address along - with the private address under the private name. - - - -2.1 Local DNS Server Specifics - - A variety of second level names are provided in the .local zone each - of which is a delegation point to a zone with some number of name - servers in one of the private IP address space blocks. The multiple - second level names permit choice between the different private IP - blocks and different numbers of servers. Thus the actual fully - qualified name for the private host examples in the figure above - would be more like privhost1.a2.local, privhost2.a2.local, etc. (but - see Section 2.3 below). - - Glue records are provided to give private IP addresses for initial - name servers; however, it should be noted that the NS and A records - in the local zones will dominate the information stored in the .local - zone. This means that once a resolver has contacted a local server, - the list of NS RRs in the local zone on that server will control and - could contain more or different servers than were given at the chosen - .local delegation point. Nevertheless, the glue A records in the - global .local zone do place some constraints of the private IP - address of the local DNS servers implementing zones which are - children of .local. - - It is also possible for an enclave to locally configure its own - version of the .local zone. Depending on its enclave boundary - implementation, it might be able to constrain all of its internal - references to .local to use its own variant version. This version - could have whatever private addresses were desired for the name - servers involved. Such a configuration MAY be used, but it is - recommended that the globally accessible .local specified herein be - used for uniformity. That way, even a unconstrained resolver - starting from the normal root servers (i.e., an "out of the box" - resolver) will correctly resolve or fail to resolve names under - .local depending on the resolvers location in the network as - specified herein. - - It is only necessary for the local DNS servers to have private IP - addresses to achieve the effect of local names. However, care MUST - be taken that none of the local DNS servers or any server that might - cache their output is accessible by any network interface that has a - non-private IP address. Otherwise considerable confusion could - result if local names are resolved by a resolver outside a local - enclave to private IP addresses which have a different meaning for - that resolver. - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Local DNS Names - - -2.2 Local in-addr.arpa Zones - - Inverse lookup of local names corresponding to private IP addresses - needs to be provided via the in-addr.arpa and ip6.int zones. Because - of the fixed naming within this zone, different names with different - numbers of servers or different addresses can not be provided. As - with the forward .local entries, the actual NS RRs in the servers - serving the private portions of the inverse in-addr.arpa will - dominate. When one of these is queried by a resolver, it can provide - information on additional servers for that particular subzone in the - private IP address portion of the in-addr.arpa tree. - - - -2.3 Name Conflicts - - The intention is that local names would only be used in the enclave - where the entities they refer to exist, and these names would not be - exported. However, experience indicates that. despite best efforts - to avoid it, some such names will leak out via email cc's, URL's in - HTML, etc. (Such leakage occurs regardless of how the local names - are formed or whether they are accessible via the default root zone.) - These leaked private names can cause confusion if they can conflict - with global names or names local to other enclaves. Use of the - .local top level domain assures no conflict with global names. To - assure no conflict with different local fully qualified names, the - domain name of the enclave SHOULD always be prefixed to .local. - - For example, a company might have - host1.company.example - as a globally accessible host and - host2.company.example.b3.local - as a host for internal use only. The global name could normally be - resolvable anywhere on the Internet while the local name could not be - resolved anywhere except within the company enclave. - - Note that different names were chosen for the initial label in the - two names above, i.e., host1 and host2. The reason for this is that, - in some environments, local hosts are referred to by an unqualified - names, such as host3. For DNS look up purposes, such a name must be - expanded into a fully qualified domain name and a "search list" of - possible suffix qualifications is tried. If, for example, both - host4.school.ac.example and host4.school.ac.example.b3.local existed, - then a local reference to "host4" would be ambiguous and could lead - to either machine depending on the order of qualifications tried. - This order could even be different in different pieces of local - software or on different local hosts, resulting in substantial - confusion. For this reason, it is strongly recommended that disjoint - name sets be used for global and local entity unqualified domain - names and that fully qualified domain names be used wherever - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Local DNS Names - - - practical. - - - -2.4 Nested Enclaves - - It is possible to have enclaves within enclaves. In general the best - way to accomplish this is to use a different portion of the private - IP address space at each nesting level of enclave. (Private IP - address space can be reused in enclaves that are siblings or the - like.) Then similar entries to those proposed here for .local can be - made in the private zone referring to name servers with addresses in - the nested enclave's private IP address space. - - - -3. Other Names in .local - - Three additional second level domain names are assigned in the .local - top level domain for other types of local names. - - In particular, - link.local and - site.local - are reserved for use in qualifying IPv6 link local names and site - local names. - - In addition, loopback.local is assigned and given the loopback - address. - - - -4. Security Considerations - - This section discusses the strength of the privacy offered by using - subzones of .local and interactions with DNS security. - - - -4.1 Strength of Privacy Offered - - Local names, as proposed herein, are not intended to be a strong - security mechanism. - - The privacy of the DNS information protected by storing it in servers - with private IP addresses is weak. It is completely dependent on the - integrity of enclave perimeter routing to make these servers - inaccessible. And it may occasionally leak out in any case due to - inclusion in email address fields, web pages, and the like, although - such leakage should be no worse than current split DNS - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT Local DNS Names - - - implementations of DNS data hiding. - - Software should not depend on local names being accessible only - within a particular enclave as someone could deliberately create the - same names within a different enclave. This is true even if, as - recommended herein, the names incorporate the domain name of the - original enclave in an attempt to avoid such conflicts. - - - -4.2 Interaction with DNSSEC - - Although an enclave may derive some amount of security by virtue of - its isolation, it will normally be desirable to implement DNS - security [RFC 2535] within the enclave. The enclave owner should - generate their own keys and sign their subzone of .local. However, a - signed copy of their public key can not be included in the .local - zone as it is different for every enclave. Thus, to authenticate the - .local subzone contents, it will be necessary to sign the KEY RR at - the apex of the local subzone of .local with the .local zone key or - another key that is trusted by local resolvers or staticly configure - the public key for the .local subzone in local resolvers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT Local DNS Names - - -References - - RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", - November 1987. - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", - 03/03/1994. - - RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. - Lear, "Address Allocation for Private Internets", 02/29/1996. - - RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", - 06/06/1996. - - RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing - Architecture", July 1998 - - RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 USA - - Telephone: +1 914-276-2668 (h) - +1 914-784-7913 (w) - FAX: +1 914-784-3833 (w) - EMail: dee3@us.ibm.com - - - -Expiration and File Name - - This draft expires December 1999. - - Its file name is draft-ietf-dnsind-local-names-07.txt. - - -D. Eastlake 3rd [Page 11] - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 12] - diff --git a/doc/draft/draft-ietf-dnsind-local-names-08.txt b/doc/draft/draft-ietf-dnsind-local-names-08.txt new file mode 100644 index 0000000000..ff3b9ed6b1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-local-names-08.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +D. Eastlake: dee3@us.ibm.com + + diff --git a/doc/draft/draft-ietf-dnsind-verify-00.txt b/doc/draft/draft-ietf-dnsind-verify-00.txt deleted file mode 100644 index 1837fe9e7f..0000000000 --- a/doc/draft/draft-ietf-dnsind-verify-00.txt +++ /dev/null @@ -1,158 +0,0 @@ - - - INTERNET-DRAFT Mark Andrews (ISC) - February 1999 - - - Verifying Resource Records Without Knowing Their Contents - - - Status of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - Abstract - - DNSSEC [RFC2065] provides a mechanism to cryptographically verify a - DNS resource record provided we can get it into canonical form. - - The problem is how do we do this without knowing the contents of all - resource record types? - - This document provides one possible solution to this problem. - - 1 - Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - Expires August 1999 [Page 1] - - INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998 - - - 2 - Method - - In order to be able to canonicalise a resource record a resolver needs - to know where in the data domain names exist so that the resolver can - decompress the domain names and convert the uppercase ASCII in ordinary - labels to lowercase prior to the data being feed into the encryption - routines. - - This document propose that all new resource record types defined MUST - have a header at the start of the data section locating where the domain - names are in the data section. A new resource record for the purpose of - this document is any type NOT referenced in section 3 Old Types. Meta - queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are - not covered by this document as they do not return data of this type. - - This table would be a series of unsigned 16 bit words in network order. - The first word contains the length of the table as 16 bit words not - counting the first word. Subsequent words contain the offset from the - start of the data to the start of relevent domain name in the data - assuming all domain names are uncompressed. Offsets in the table are in - the same order as domain names in the data. - - 3 Old Types - - The following types are deemed old and are NOT covered by this document. - A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR - (9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT - (16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22), - NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC - (29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35), - KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID - (102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250). - - - 4 Security Considerations - - It is believed that this document does not introduce any significant - additional security threats other that those that already exist when - using data from the DNS but rather enhances security by allowing new - resource record types to be checked by security aware resolvers. - - 5 IANA Considerations - - This document places no requirements apon IANA. - - - - - Expires August 1999 [Page 2] - - INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998 - - - References - - - [RFC2065] - Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security - Extensions," RFC 2065, January 1997 - - - [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev­ - els," BCP 14, RFC 2119, March 1997 - - - Author's Address - - Mark Andrews - Internet Software Consortium - 1 Seymour St. - Dundas Valley - NSW 2117 - AUSTRALIA - +61 2 9871 4742 - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires August 1999 [Page 3] - diff --git a/doc/draft/draft-ietf-dnsind-verify-01.txt b/doc/draft/draft-ietf-dnsind-verify-01.txt new file mode 100644 index 0000000000..6fc8f531e0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-verify-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Andrews: Mark_Andrews@isc.org + + diff --git a/doc/draft/draft-ietf-dnssec-as-map-05.txt b/doc/draft/draft-ietf-dnssec-as-map-05.txt deleted file mode 100644 index caaf932ca7..0000000000 --- a/doc/draft/draft-ietf-dnssec-as-map-05.txt +++ /dev/null @@ -1,522 +0,0 @@ - -INTERNET-DRAFT Mapping AS Number into the DNS - July 1997 - Expires January 1998 - - - - - Mapping Autonomous Systems Number into the Domain Name System - ------- ---------- ------- ------ ---- --- ------ ---- ------ - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to - be become a Best Current Practice RFC concerning utilization of the - Domain Name System (DNS) to support routing security. Distribution of - this document is unlimited. Comments should be sent to the DNS - Security Working Group mailing list or to the - author. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), - nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), - munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -Abstract - - One requirement of secure routing is that independent routing - entities, such as those identified by Internet Autonomous System - Numbers, be able to authenticate messages to each other. Additions - have developed to the Domain Name System to enable it to be used for - authenticated public key distribution [RFC 2065]. This draft maps - all Autonomous System numbers into DNS Domain Names so that the DNS - security can be used to distribute their public keys. - - [Changes from previous version are to accommodate AS numbers larger - than 16 bits and to delegate on decimal boundaries rather than binary - boundaries.] - - - -Acknowledgements - - The contributions of the following persons, listed in alphabetic - order, to this draft are gratefully acknowledged: - - Ran Atkinson - - Christian Huitema - - Tony Li - - Michael A. Patton. - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -Table of Contents - - Status of This Document....................................1 - - Abstract...................................................2 - Acknowledgements...........................................2 - - Table of Contents..........................................3 - - 1. Introduction............................................4 - - 2. Autonomous System Number Mapping........................5 - - 3. Meaning of RRs..........................................6 - - 4. Security Considerations.................................8 - References.................................................8 - Author's Address...........................................8 - Expiration and File Name...................................9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -1. Introduction - - There are a number of elements required to secure routing in the - Internet. One of these is a way that independently operated routing - domains be able to authenticate messages to each other. - - Sharing a private symmetric key between each pair of such domains is - impractical. Assuming 2**16 Autonomous System routing entities, - which is what is allowed in current versions of BGP, [RFC 1771], this - would imply approximately 2**31 pairs, an impractical number of keys - to securely generate, install, and periodically replace. - - The solution is to use public key technology whereby each routing - domain has a private key it can use to sign messages. Other domains - that know the corresponding public key can then authenticate these - messages. Such authenticated messages can be used to set up and - maintain efficient symmetric keys on an as needed basis. - - But how do the domains securely obtain the Autonomous System number - to public key mapping? - - Extensions have been developed for the Domain Name System that enable - it to be conveniently used for authenticated public key distribution - [RFC 2065]. A variety of key types can be supported. All that is - required is a mapping of Autonomous System numbers into domain names, - which is provided by this draft. - - It should be noted that the public keys retrieved from DNS will - likely be used primarily to authenticate initial connection set up - messages. Autonomous Systems that need to converse with any - frequency will probably negotiate more efficient symmetric session - keys. - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -2. Autonomous System Number Mapping - - Autonomous System (AS) numbers are usually written as decimal number - and when blocks of AS numbers are delegated to a registry, it is - normally on decimal boundaries. Their current use in BGP is limited - to 16 bits providing a maximum value of 65,535. For example, ANS is - autonomous system 690. However, there is no inherent size limit in - the AS concept. AS numbers are mapped into a domain name as - described below. - - Write the AS number, as usual, as a decimal number without any - "thousands" punctuation. If it is less than 5 digits, add leading - zeros to bring it up to five digits. Then simply reverse the order - of the digits, put a period between them, and append ".length.in- - as.arpa" where "length" is the number of AS digits. This mapping is - analogous to the IPv4 address mapping into the in-addr.arpa DNS - domain. - - Thus the domain name correspond to Autonomous System 690 (decimal) is - - 0.9.6.0.0.5.in-as.arpa. - - the domain corresponding to the largest possible AS number in BGP is - - 5.3.5.5.6.5.in-as.arpa. - - the domain corresponding to AS number 65,000 is - - 0.0.0.5.6.5.in-as.arpa. - - and the domain correspond to a hypothetical future greater than 16 - bit AS number 1,234,567 is - - 7.6.5.4.3.2.1.7.in-as.arpa. - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -3. Meaning of RRs - - The following guidance is given for some resource record (RR) types - that could be stored under the names mapped from AS numbers. The KEY - RR is given first, followed by the SIG RR, the NXT RR, and then some - additional RR types in alphabetic order. - - KEY: This type of RR associates a public key with the owner name - which, in this case, corresponds to an Autonomous System (AS). Under - DNS security as proposed in RFC 2065 the KEY RR can be used to store - a variety of digital keys. A KEY for use in securing routing - communications between ASs will have the end entity flag bit on, the - authentication use prohibited flag bit off, and a protocol byte or - flag bit indicating routing communications use. Such a public key can - be used to authenticate communications with or between ASs. The - existence of such KEY RRs in the primary reason for mapping AS names - into the DNS. - - SIG: The SIG signature resource record authenticates the RRs - that it signs as described in RFC 2065. Assuming the signer who - generated the SIG is trustworthy, such as the in-as.arpa zone owner, - then the signed RRs can be trusted. - - NXT: An NXT RR is used in DNS security to provide authenticated - denial of the existence of types and names as described in RFC 2065. - - A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes. - AS domain names are reserved for Autonomous Systems only and should - NOT be used for a host or any type of end entity other than an - Autonomous System. - - CNAME: This type of RR is an alias pointing to another domain - name. An AS could have a CNAME pointing to a different AS but this - is not likely to be very useful as AS RRs will normally be looked up - when the AS number is actually encountered in use. - - MX: There is no special use for an MX RR for an AS name. It - could point to a host that would accept mail related to that AS. - - NS: The presence of NS records under an AS name means that it - has been carved out as a subzone. This gives the AS complete control - over the zone refresh parameters and control over the creation of - inferior names. No special meaning is currently assigned to such - inferior names so, although this is not advised, they could be used - for hosts or whatever. In this case, the will also be a zone KEY at - the AS name, indicated by having the zone flag bit on. - - PTR: The part of the forward domain tree that administratively - corresponds to the AS SHOULD be indicated by a PTR RR. If some - entity, say example.xx, has several ASs, there would be PTRs to - - -Donald E. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - - example.xx from several names in the in-as.arpa hierarchy. - - RP: A Responsible Person RR SHOULD appear under each AS name - telling you who you should contact in the case of problems with that - AS - - TXT: Text RRs can be used for comments, postal address, or - similar notes under an AS name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -4. Security Considerations - - This document concerns a means to map Internet Autonomous System - numbers into the Domain Name System (DNS) so that DNS can be used to - provide secure distribution of Autonomous System's public keys. The - security of the resulting AS to key mapping is dependent on the - security of the DNS security extensions and of the DNS zone where the - key is stored. - - The most obvious way of using the AS keys retrieved from DNS is to - authenticate communications with a directly connected AS. However, - this does not prove that any routing information exchanged is - actually correct and note that routing information communicated over - this secured path may be indirectly forwarded from or to yet other - ASs. - - - -References - - [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, - November 1987 - - [RFC 1035] - Domain Names - Implementation and Specifications, P. - Mockapetris, November 1987. - - [RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP- - 4)", 03/21/1995. - - [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. - Kaufman, January 1997. - - - -Author's Address - - Donald E. Eastlake 3rd - CyberCash, Inc. - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 508 287 4877 - +1 703 620-4200 (main office, Reston, VA) - FAX: +1 508 371 7148 - EMail: dee@cybercash.com - - - - - - - -Donald E. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -Expiration and File Name - - This draft expires January 1998. - - Its file name is draft-ietf-dnssec-as-map-05.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 9] - diff --git a/doc/draft/draft-ietf-dnssec-as-map-06.txt b/doc/draft/draft-ietf-dnssec-as-map-06.txt new file mode 100644 index 0000000000..ff3b9ed6b1 --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-as-map-06.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +D. Eastlake: dee3@us.ibm.com + + diff --git a/doc/draft/draft-skwan-gss-tsig-04.txt b/doc/draft/draft-skwan-gss-tsig-05.txt similarity index 91% rename from doc/draft/draft-skwan-gss-tsig-04.txt rename to doc/draft/draft-skwan-gss-tsig-05.txt index cd5e599b99..8535e96fb8 100644 --- a/doc/draft/draft-skwan-gss-tsig-04.txt +++ b/doc/draft/draft-skwan-gss-tsig-05.txt @@ -2,11 +2,13 @@ INTERNET-DRAFT Stuart Kwan Praerit Garg James Gilroy Microsoft Corp. - June 1999 - Expires January 2000 + February 2000 + Expires August 2000 + GSS Algorithm for TSIG (GSS-TSIG) + Status of this Memo This document is an Internet-Draft and is in full conformance @@ -29,6 +31,7 @@ http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. + Abstract The TSIG protocol provides transaction level authentication for DNS. @@ -36,9 +39,21 @@ TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) [RFC2078]. -Expires January 2000 [Page 1] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + + + + + +Expires August 2000 [Page 1] + + +INTERNET-DRAFT GSS-TSIG February 2000 + Table of Contents @@ -65,6 +80,7 @@ Table of Contents 7: Acknowledgements.................................................13 8: References.......................................................13 + 1. Introduction The Secret Key Transaction Signature for DNS [TSIG] protocol was @@ -87,9 +103,14 @@ over time. For example, a client and server may use Kerberos for one transaction, whereas that same server may use TLS with a different client. -Expires January 2000 [Page 2] -INTERNET-DRAFT GSS-TSIG June 1999 + + +Expires August 2000 [Page 2] + + +INTERNET-DRAFT GSS-TSIG February 2000 + * The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the @@ -97,6 +118,7 @@ developer does not need to create new key distribution or key management systems. Instead the developer relies on the security service mechanism to manage this on its behalf. + 2. Protocol Overview Readers that are unfamiliar with the GSS-API concepts are encouraged @@ -114,6 +136,7 @@ server. Once a context has been established, it has a finite lifetime for which it can be used to secure messages. Thus there are three states of a context associated with a connection: + +----------+ | | V | @@ -138,9 +161,13 @@ states of a context associated with a connection: Every connection begins in the uninitialized state. -Expires January 2000 [Page 3] -INTERNET-DRAFT GSS-TSIG June 1999 + +Expires August 2000 [Page 3] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 2.1 GSS Details @@ -155,6 +182,7 @@ Not all error return values from GSS-API interfaces are specified in this document. When errors are encountered, the caller should act appropriately. + 3. Client Protocol Details A unique context is required for each server to which the client sends @@ -167,6 +195,7 @@ The value key_name also identifies a context handle, and is used on the wire to indicate to a server which context should be used to process the current request. + 3.1 Negotiating Context In GSS, establishing a security context involves the passing of opaque @@ -183,9 +212,19 @@ tokens between client and server. The TKEY record is a general mechanism for establishing secret keys for use with TSIG. For more information, see [TKEY]. -Expires January 2000 [Page 4] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + + + +Expires August 2000 [Page 4] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 3.1.1 Call GSS_Init_sec_context @@ -227,9 +266,22 @@ The handle output_context_handle is unique to this negotiation and is stored in the client's mapping table as the context_handle that maps to target_server_name. -Expires January 2000 [Page 5] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + + + + + + +Expires August 2000 [Page 5] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 3.1.2 Send TKEY Query to Server @@ -261,6 +313,7 @@ and Verifying Signed Messages, for the signing procedure. The query is transmitted to the server. + 3.1.3 Receive TKEY Query-Response from Server The server will return a standard TKEY query-response (see [TKEY]). @@ -277,9 +330,15 @@ next processing step depends on the value of major_status from the most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or GSS_S_CONTINUE. -Expires January 2000 [Page 6] -INTERNET-DRAFT GSS-TSIG June 1999 + + + +Expires August 2000 [Page 6] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 3.1.3.1 Value of major_status == GSS_S_COMPLETE @@ -299,6 +358,7 @@ signature was not included, the context state is advanced to Context Established. Proceed to section 3.2 for usage of the security context. + 3.1.3.2 Value of major_status == GSS_S_CONTINUE If the last call to GSS_Init_sec_context yielded a major_status value @@ -327,9 +387,15 @@ with section 3.1.2. The client should place a limit on the number of continuations in a context negotiation to prevent endless looping. -Expires January 2000 [Page 7] -INTERNET-DRAFT GSS-TSIG June 1999 + + + +Expires August 2000 [Page 7] + + +INTERNET-DRAFT GSS-TSIG February 2000 + If major_status is GSS_S_COMPLETE and output_token is non-NULL, the client-side component of the negotiation is complete but the @@ -347,6 +413,7 @@ signature was not included, the context state is advanced to Context Established. Proceed to section 3.2 for usage of the security context. + 3.2 Context Established When context negotiation is complete, the handle context_handle is @@ -355,6 +422,7 @@ used for the generation and verification of transaction signatures. The procedures for sending and receiving signed messages are given in section 5, Sending and Verifying Signed Messages. + 4. Server Protocol Details As on the client-side, the result of a successful context negotiation @@ -366,14 +434,25 @@ request. The server maintains a mapping of key names to handles: (key_name, context_handle) + 4.1 Negotiating Context A server recognizes TKEY queries as security context negotiation messages. -Expires January 2000 [Page 8] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + + + +Expires August 2000 [Page 8] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 4.1.1 Receive TKEY Query from Client @@ -384,6 +463,7 @@ the NAME value of the TKEY record. If the name is found in the table, the corresponding context_handle is used in following GSS operations. If the name is not found a new negotiation is started. + 4.1.2 Call GSS_Accept_sec_context The server performs its side of a context negotiation by calling @@ -407,6 +487,7 @@ negotiation, then output_context_handle is stored in the server's key-mapping table as the context_handle that maps to the name of the TKEY record. + 4.1.3 Send TKEY Query-Response to Client If major_status returns a GSS failure code, the negotiation has @@ -416,9 +497,19 @@ BADKEY. Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE. -Expires January 2000 [Page 9] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + + + +Expires August 2000 [Page 9] + + +INTERNET-DRAFT GSS-TSIG February 2000 + If major_status is GSS_S_COMPLETE the server component of the negotiation is finished. The message from the client may be signed @@ -442,6 +533,7 @@ repeats beginning with section 4.1.1. The server must limit the number of times that a given context is allowed to repeat, to prevent endless looping. + 4.2 Context Established When context negotiation is complete, the handle context_handle @@ -453,6 +545,7 @@ a context at any time. The procedures for sending and receiving signed messages are given in section 5, Sending and Verifying Signed Messages. + 4.2.1 Terminating a Context A server can terminate any established context at any time. The @@ -463,9 +556,17 @@ by including a TKEY RR in a response with the mode field set to An active context is deleted by calling GSS_Delete_sec_context providing the associated context_handle. -Expires January 2000 [Page 10] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + +Expires August 2000 [Page 10] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 5. Sending and Verifying Signed Messages @@ -475,7 +576,7 @@ The procedure for sending a signature-protected message is specified in [TSIG]. The data to be passed to the signature routine includes the whole DNS message with specific TSIG variables appended. For the exact format, see [TSIG]. For this protocol, use the following -TSIG variable values: +TSIG variable values: TSIG Record NAME = key_name that identifies this context @@ -505,9 +606,24 @@ If major_status is GSS_S_CONTEXT_EXPIRED or GSS_S_CREDENTIALS_EXPIRED, the caller needs to return to the uninitialized state and negotiate a new security context. -Expires January 2000 [Page 11] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + + + + + + + + +Expires August 2000 [Page 11] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 5.2 Verifying a Signed Message - Call GSS_VerifyMIC @@ -547,15 +663,24 @@ If this error checking fails when a server is processing a client request, the appropriate error response must be sent to the client per [TSIG]. + 6. Security Considerations This document describes a protocol for DNS security using GSS-API. The security provided by this protocol is only as effective as the security provided by the underlying GSS mechanisms. -Expires January 2000 [Page 12] -INTERNET-DRAFT GSS-TSIG June 1999 + + + + + +Expires August 2000 [Page 12] + + +INTERNET-DRAFT GSS-TSIG February 2000 + 7. Acknowledgements @@ -563,6 +688,7 @@ The authors of this document would like to thank the following people for their contribution to this specification: Chuck Chan, Mike Swift, Ram Viswanathan and Donald E. Eastlake 3rd. + 8. References [RFC2078] J. Linn, "Generic Security Service Application Program @@ -582,6 +708,7 @@ Ram Viswanathan and Donald E. Eastlake 3rd. [RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update," RFC 2137, CyberCash, April 1997. + 9. Author's Addresses Stuart Kwan Praerit Garg @@ -597,3 +724,15 @@ One Microsoft Way Redmond, WA 98052 USA + + + + + + + + + +Expires August 2000 [Page 13] + + diff --git a/doc/draft/draft-skwan-utf8-dns-02.txt b/doc/draft/draft-skwan-utf8-dns-03.txt similarity index 89% rename from doc/draft/draft-skwan-utf8-dns-02.txt rename to doc/draft/draft-skwan-utf8-dns-03.txt index b104e7f548..3d7cdbc6b8 100644 --- a/doc/draft/draft-skwan-utf8-dns-02.txt +++ b/doc/draft/draft-skwan-utf8-dns-03.txt @@ -1,11 +1,14 @@ + INTERNET-DRAFT Stuart Kwan James Gilroy Microsoft Corp. - June 1999 - Expires January 2000 + February 2000 + Expires August 2000 + Using the UTF-8 Character Set in the Domain Name System + Status of this Memo This document is an Internet-Draft and is in full conformance @@ -28,16 +31,29 @@ http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. + Abstract -The Domain Name System standard specifies that names are represented -using the ASCII character encoding. This document expands that +The Domain Name System standard specifies that names are represented +using the ASCII character encoding. This document expands that specification to allow the use of the UTF-8 character encoding, a superset of ASCII and a translation of the UCS-2 character encoding. -Expires January 2000 [Page 1] -INTERNET-DRAFT UTF-8 DNS June 1999 + + + + + + + + + + +Expires August 2000 [Page 1] + + +INTERNET-DRAFT UTF-8 DNS February 2000 1. Introduction @@ -62,6 +78,7 @@ allowed in a name. In addition, names that are intended to be globally visible [RFC1958] should contain ASCII-only characters per [RFC1123]. + 2. Protocol Description A UTF-8-aware DNS server is a DNS server that can load and store DNS @@ -86,9 +103,14 @@ and record data before transmitting those names in any message. A UTF-8-aware DNS client/resolver must downcase all names containing UTF-8 characters before transmitting those names in any message. -Expires January 2000 [Page 2] -INTERNET-DRAFT UTF-8 DNS June 1999 + + +Expires August 2000 [Page 2] + + +INTERNET-DRAFT UTF-8 DNS February 2000 + For consistency, UTF-8-aware DNS servers must compare names that contain UTF-8 characters byte-for-byte, as opposed to using Unicode @@ -106,6 +128,7 @@ Names encoded in UTF-8 must not exceed the size limits clarified in [RFC2181]. Character count is insufficient to determine size, since some UTF-8 characters exceed one octet in length. + 3. Interoperability Considerations The UTF-8 character encoding is ideal for use with existing protocol @@ -125,10 +148,12 @@ names to a zone file or reload those names from a zone file. Administrators should exercise caution when transferring a zone containing UTF-8 names to a non-UTF-8-aware DNS server. + 4. Security Considerations The choice of character encoding for names does not impact the -security of the DNS protocol. +security of the DNS protocol. + 5. Acknowledgements @@ -136,16 +161,20 @@ The authors of this document would like to thank the following people for their contribution to this specification: John McConnell, Cliff Van Dyke and Bjorn Rettig. -Expires January 2000 [Page 3] -INTERNET-DRAFT UTF-8 DNS June 1999 + +Expires August 2000 [Page 3] + + +INTERNET-DRAFT UTF-8 DNS February 2000 + 6. References [RFC1035] P.V. Mockapetris, "Domain Names - Implementation and Specification," RFC 1035, ISI, Nov 1987. -[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode +[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646," RFC 2044, Alis Technologies, Oct 1996. [RFC1958] B. Carpenter, "Architectural Principles of the @@ -154,17 +183,18 @@ INTERNET-DRAFT UTF-8 DNS June 1999 [RFC1123] R. Braden, "Requirements for Internet Hosts - Application and Support," STD 3, RFC 1123, January 1989. -[RFC2130] C. Weider et. al., "The Report of the IAB Character +[RFC2130] C. Weider et. al., "The Report of the IAB Character Set Workshop held 29 February - 1 March 1996", RFC 2130, Apr 1997. -[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS +[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS Specification," RFC 2181, University of Melbourne and RGnet Inc, July 1997. [UNICODE 2.0] The Unicode Consortium, "The Unicode Standard, Version 2.0," Addison-Wesley, 1996. ISBN 0-201-48345-9. + 7. Author's Addresses Stuart Kwan James Gilroy @@ -174,4 +204,22 @@ Redmond, WA 98052 Redmond, WA 98052 USA USA -Expires January 2000 [Page 4] + + + + + + + + + + + + + + + + +Expires August 2000 [Page 4] + +