Internet-Draft Svend Vrang draft-vrang-idn-cname-00.txt Acme Idealabs, Inc Target Category: Informational August 2001 Expires: February 2002 Synthetic CNAME generation as an equivalence tool Status of this Memo The file name of this memo is draft-alvestrand-idn-cname-00.txt This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Comments on this draft should be sent to the mailing list idn@ops.ietf.org, or to the author Abstract Synthetic CNAMEs Svend Vrang draft-vrang-idn-cname-00.txt Expires February 2002 This document describes an implementation technique for enforcing equivalence between different names in the Domain Name System by synthesizing CNAME records on the fly. It aims to describe some of the advantages and drawbacks of this approach, and how it fits into the overall pattern of the current efforts to provide access to internationalized domain names using the DNS. 1. Introduction IDN is a problem. In particular, the DNS is an identifier system ? unique labels are what it's good at. In particular, we have the problem where people want to embed words or phrases into DNS labels; people are capable of finding very many ways of writing those words and phrases, many of which it is unreasonable to ask mere machines, which are deployed into the network and stay there for many years, to know about. Even worse, people invent new ones. This memo proposes one technique for dealing with this problem. 2. The Synthetic CNAME technique This document uses the following terms: A BASE NAME is a DNS name that may be registered with the DNS system, possibly using IDN characters. ASCII examples are used here, for ease of reading across an internationalized audience. A PURPORTED NAME is a DNS name that may or may not be registered in the DNS. A MATCHING ALGORITHM takes a PURPORTED NAME and a BASE NAME, and tells whether they match or not. A MAPPING ALGORITHM takes a PURPORTED NAME and maps it to an unique BASE NAME. The outline of the synthetic CNAME process is this: When a query arrives at an authoritative server for a domain: 1. The server executes its server-specific MAPPING ALGORITHM on the PURPORTED NAME, resulting in a QUERIED NAME. draft-vrang-idn-cname-00.txt [Page 2] Synthetic CNAMEs Svend Vrang draft-vrang-idn-cname-00.txt Expires February 2002 2. If the QUERIED NAME is exactly the same as the PURPORTED NAME, or if the first component that was changed is not one for which the server is authoritative, proceed as in a normal DNS query. 3. If the QUERIED NAME is different, and the first difference is in a component for which the server is authoritative, return to the caller a CNAME record with the target being the QUERIED NAME and the owner being the PURPORTED NAME. Example A: Query for BLUEBERRIES.EXAMPLE.ORG arrives at authoritative server for EXAMPLE.ORG MAPPING ALGORITHM maps to BLUEBERRY.EXAMPLE.ORG Server returns BLUEBERRIES.EXAMPLE.ORG CNAME BLUEBERRY.EXAMPLE.ORG Example B: Query for BLUEBERRIES.EXAMPLE.ORG arrives at authoritative server for .ORG MAPPING ALGORITHM maps to BLUEBERRY.EXAMPLE.ORG. Server returns a referral to EXAMPLE.ORG servers (not authoritative) Example C: Query for BLUEBERRY.EXAMPLE.ORG arrives at authoritative server for EXAMPLE.ORG MAPPING ALGORITHM maps to BLUEBERRY.EXAMPLE.ORG Server returns a referral to BLUEBERRY.EXAMPLE.ORG server (no change) Example 4: Query for MANY.BLUEBERRIES.EXAMPLE.ORG arrives at authoritative server for EXAMPLE.ORG MAPPING ALGORITHM maps to ONE.BLUEBERRY.EXAMPLE.ORG Server returns MANY.BLUEBERRIES.EXAMPLE.ORG CNAME ONE.BLUEBERRY.EXAMPLE.ORG This illustrates that all labels subsidiary to an authoritative zone may be modified during the query process. draft-vrang-idn-cname-00.txt [Page 3] Synthetic CNAMEs Svend Vrang draft-vrang-idn-cname-00.txt Expires February 2002 3. Advantages and disadvantages of this approach The original requirement for this approach was found in version 6 of the IDN requirements document, and formulated as follows: [30] Within a single zone, the zone manager MAY be able to define equivalence rules that suit the purpose of the zone, such as, but not limited to, and not necessarily, non-ASCII case folding, Unicode normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or traditional/simplified Chinese equivalence. Such defined equivalences MUST NOT remove equivalences that are assumed by (old or local-rule- ignorant) caches. 3.1 Advantages This algorithm is relatively simple to implement, and is very flexible. As long as the authoritative nameservers are 100% consistent, there will be few problems with applying the rule consistently; this fulfils requirement [7]. The method is invisible to the rest of the world, meaning that the algorithms do not have to be standardized, or even uniform across different zones. 3.2 Disadvantages This section refers to requirement numbers from the IDN requirements draft. Numbers are taken from draft 08. This method imposes one more round trip on queries that hit it, violating requirement [28]. The method renders it impossible to use DNSSEC NXT records, violating requirement [30]. The reason is that for even moderately complex algorithms, the servers will not know ahead of time which CNAMEs it will have to generate; thus, it cannot issue NXT records denying the existence of these CNAMEs. The method makes it very hard to use DNSSEC SIG records on the CNAMEs. To do so would require run-time generation of signatures, which is a very heavy performance penalty, and would require that all master AND slave servers for the zone have access to the private key for the zone, which is a security risk. Records are generated that are not in the zonefile, meaning that AXFR to other "stealth" servers MUST be forbidden. Since the matching algorithm is not standardized, the requirement that all servers have the same matching algorithm means that one cannot buy secondary services on the open market, but must use secondary services draft-vrang-idn-cname-00.txt [Page 4] Synthetic CNAMEs Svend Vrang draft-vrang-idn-cname-00.txt Expires February 2002 from those who implement the same algorithm. Mismatches in matching algorithms will have dire consequences. The PURPORTED NAMES that are mapped cannot be the target of PTR records, violating requirement [4]. The method will generate CNAMEs that have no targets; in example 4 above, the ONE.BLUEBERRY.EXAMPLE.ORG CNAME will have to be generated, even though the server for EXAMPLE.ORG has no idea whether or not the name exists. The method will cause confusion with HTTP/1.1 named virtual hosts and other services where the server wishes to know which name the client is trying to use for him; unless the server executes the mapping algorithm himself, the name that the client hands to the server will not match any name that the server knows for itself. Since the CNAMEs are generated without knowing the TTL of the records they point to, the CNAMEs will have to be generated with rather short TTLs; this impacts caching performance. The method will confuse users who are aware of the source and destination domains, since they will not understand why they ended up on a particular website unless they understand the algorithm. (This is, however, quite common in the current Internet too, due to redirections of various sorts.) When users become used to a particular mapping in one domain, they will be confused when using the same names in other domains where the same mapping does not hold. (BLUEBERRIES.EXAMPLE.COM may be mapped to JUICIFRUIT.EXAMPLE.ORG, while BLUEBERRIES.EXAMPLE.ORG maps to BLUEBERRY.EXAMPLE.ORG, and BLUEBERRIES.EXAMPLE.NO will return "Host not found" even if BLUEBERRY.EXAMPLE.NO exists) The method causes extra load on the servers doing the mapping, since they are in the path for any query to the mapped domain; when querying ONE.BLUEBERRY.EXAMPLE.ORG and TWO.BLUEBERRY.EXAMPLE.ORG, normal DNS mechanisms would send the second query to the BLUEBERRY.EXAMPLE.ORG servers without involving the EXAMPLE.ORG servers; with CNAMEs, querying ONE.BLUEBERRIES.EXAMPLE.ORG and TWO.BLUEBERRIES.EXAMPLE.ORG will both hit the EXAMPLE.ORG servers before being redirected by CNAME to the BLUEBERRY.EXAMPLE.ORG servers. 4. Registration implications If the synthetic CNAME approach is to be used in a registry environment, such as a country domain, a few things must be recognized: . The MAPPING ALGORITHM must be executed on any name that is asked to be registered. If it changes the name, it is the QUERIED name draft-vrang-idn-cname-00.txt [Page 5] Synthetic CNAMEs Svend Vrang draft-vrang-idn-cname-00.txt Expires February 2002 that is in fact registered. The registrant needs to be aware of this fact. . A registered name blocks out the entire space of names that will map to it under the MAPPING ALGORITHM. . If the MAPPING ALGORITHM ever changes, the names that map to each individual name change. If names that previously mapped to one name now map to another, irritation may result. 5. Author's Address Svend Vrang Acme Idealabs, Inc. Lostwoods, MA EMail: Not relevant The author can be contacted via root@alvestrand.no 6. References draft-vrang-idn-cname-00.txt [Page 6]