Network Working Group G. Zhang Internet-Draft X. Lee Intended status: Standards Track CNNIC Expires: July 19, 2009 January 15, 2009 The keyword to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(Keyword) draft-zhang-keyword-ddds-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on July 19, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo discusses the use of the Domain Name System(DNS) for Zhang & Lee Expires July 19, 2009 [Page 1] Internet-Draft Keyword DDDS Application January 2009 storage of Keyword to URI mapping. More specifically, how DNS can be used for identifying URIs associated with one Keyword. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. The Keyword Application Specification . . . . . . . . . . . . 4 3.1. Application Unique String . . . . . . . . . . . . . . . . 4 3.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5 3.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5 3.4. Valid Database . . . . . . . . . . . . . . . . . . . . . . 5 3.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.2. Service parameters . . . . . . . . . . . . . . . . . . 6 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Zhang & Lee Expires July 19, 2009 [Page 2] Internet-Draft Keyword DDDS Application January 2009 1. Introduction eople often refer to things in the real world by a common name or keyword, e.g, a trade name, company name, or a book title. These names are typically easier for people to remember and type than URIs. For this reason, services are arising in different countries or regions that offer a mapping from keywords to Internet resources(e.g, as identified by a URI), for example, Netpia in South Korea, Real Names and Netword in USA, 3721 and CNNIC in China. However, the lack of regulation on the Keyword Addressing System and chaotic marketplace today makes this useful addressing technique hard to be widely deployed and accepted. Currently, the resolution result for a given keyword completely depends on the Keyword provider that provides registration service to the public and typically distributes its own plug-in to aid the resolution procedure. This effort is about the standardization of an internationalized Keyword Addressing System that can accommodate different languages. In this system, the registered keyword will be unique across the globe so its registrant's right will be better protected. Users can also benefit from the standardization effort for its simplified user experience, e.g, deterministic resolution result and no requirement for plug-ins. This document defines the Keyword Addressing System as an Application of the Dynamic Delegation Discovery System(DDDS). It makes use of the DNS database for the storage of Keyword and URI mapping information. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401 [13]. Each cctld top-level domain is required to contain a NAPTR record that, when applied, specifies the sub-domain used in each country or region for storage of Keywords. These subdomains can be further divided according to the top-level keyword. Anyone who wants to register a keyword should contact the appropriate zone administrator according to the policy which is attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations[1][2]. 2. Conventions used in this document 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 BCP 14, RFC 2119 [3]. Zhang & Lee Expires July 19, 2009 [Page 3] Internet-Draft Keyword DDDS Application January 2009 All other capitalized termed are taken from the vocabulary found in the DDDS algorithm specification[4]. 3. The Keyword Application Specification This template defines the Keyword DDDS application according to the rules and requirements found in DDDS. The DDDS database used by this application is found in DDDS Database defined in RFC 3403 [4]. which is the document that defines the NAPTR DNS Resource Record type. 3.1. Application Unique String The Application Unique String is a fully qualified keyword. The ABNF(RFC 4234) [5] definition for a valid keyword is as follows: keyword = country-code delim classifier top-level-keyword [delim secondary-keyword] top-level-keyword = keyword-label secondary-keyword = keyword-label delim = ":" keyword-label = internationalized-label The follows the definition of RFC 3490 [6] which defines the internationalized label of an IDN. A valid internationalized label can be any combination of the Unicode characters with the only requirement that it MUST pass the ToASCII operation without failure. The is any valid country code specified in ISO 3166 [7]. Applications that need to use Keyword Addressing System are responsible for providing the country code. Operating systems typically have a default location setting that can be used for this purpose. Classifier is a specific letter used to signal the different categories this keyword belongs to. Currently, three classifiers are defined:"@" is used to specify the keywords that are used by companies and organizations, "=" is used to specify keywords that relate to personal use, and "+" is used to specify keywords for public use. The classifier set can be extended according to future requirement. Zhang & Lee Expires July 19, 2009 [Page 4] Internet-Draft Keyword DDDS Application January 2009 3.2. First Well Known Rule The first well known rule for this application is to extract the < country-code > part of the AUS, i.e, the output of the First Well Known Rule is the of the AUS. 3.3. Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the "absoluteURI" production in the Collected ABNF found in RFC 2396 [8]. 3.4. Valid Database At present only one DDDS Database is specified for this application. "Dynamic Delegation Discovery System(DDDS) Part Three: The DNS Database"RFC 3403 [4] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The keys for this database are encoded as domain-names. Note that the keys are valid IDNs as specified in RFC 3490 [6]. How the IDNs are encoded and stored in the database is out of the scope of this memo. Currently, the IDNA specifies that each IDN label is encoded as an ACE(ASCII Compatible Encoding) label. A simple and efficient transfer encoding syntax designed for use with IDNA is the Puyncode specified in RFC 3492 [9]. The output of the First Well Known Rule for the Keyword Application is the part of AUS. Since each country code is reserved for the cctld domain usage (except for the Great Britain, whose reserved country code is GB, but UK is used as the cctld instead), the country code itself can be used as the first valid key to search the DNS database, requesting NAPTR records from the DNS. Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore useful for a client to check for this additional information. It is also easy to contemplate a Keyword enhanced nameserver that understands the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Clients are encouraged to check for additional information but are not required to do so. See the Additional information processing section of RFC 3403 [4], Section 4.2 for more information on NAPTR records and the Additional Information section Zhang & Lee Expires July 19, 2009 [Page 5] Internet-Draft Keyword DDDS Application January 2009 of a DNS response packet. The character set used to encode the substitution expression is UTF-8. The allowed input characters are all those characters that are allowed anywhere in a valid keyword. The characters allowed to be in a Key of the database are those that are currently defined for DNS domain-names. Currently, there is a practical limit of 512 bytes for DNS replies. Until all resolvers can handle larger responses, it is strongly advised to maintain as few rules as possible and make rules as short as possible, to keep the NAPTR replies below 512 bytes. 3.4.1. Flags This database contains a field to encode flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined, conforming to RFC 3404 [10]. This flag means that this Rule is the last one and that the output of the rule is a URI. If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields. If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then clients MUST use the Key produced by this Rewrite Rule as the new key in the DDDS loop(i.e, causing the client to query for new NAPTR records at the domain-name that is the result of this Rule). 3.4.2. Service parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record. Service-field = "K2U" [protocol] protocol = "+" ALPHA *3ALPHANUM In other words, the service parameter is a non-optional "K2U"(used to denote Keyword only Rewrite Rules in order to mitigate record collision) followed by an optional protocol which indicates the protocol of the final URI. The protocol can be used by the client to determine whether the rule meets the client!_s requirements, as described in step 4 of the comprehensive DDDS algorithm defined in RFC 3402 [11]. For non-terminal rules, the protocol is of no use and SHOULD be omitted. For terminal rules, the protocol is strongly RECOMMENDED. Zhang & Lee Expires July 19, 2009 [Page 6] Internet-Draft Keyword DDDS Application January 2009 In case the protocol is absent, the client application SHOULD use the default protocol "http". 4. Examples The examples below show how the rewrite rules look like and how the resolutions take place, illustrating the usage in typical scenarios. These examples are only for pedagogical purposes only. Assume "@example" and "@example1:example2" are two keywords registered in China, whose country code is CN, and suppose "kw.cn" is reserved for storage of Keywords registered in China. The rewrite rules for "cn" will contain a single NAPTR record that points to the exact subdomain used for Keyword storage. $ORIGIN cn @ IN NAPTR 100 10 "" "K2U" "" "kw.cn" The rewrite rules for "kw.cn" look like: $ORIGIN kw.cn @ IN NAPTR 100 10 "" "K2U" "!^.*:@.*$!org.kw.cn!i" . IN NAPTR 100 10 "" "K2U" "!^.*:=.*$!ps.kw.cn!i" . IN NAPTR 100 10 "" "K2U" "!^.*:+.*$!pub.kw.cn!" . The rewrite rules for "org.kw.cn" look like: $ORIGIN org.kw.cn @ IN NAPTR 100 10 "" "K2U" "!^.*@(.*):(.*)$!\2.\1.org.kw.cn!i" . IN NAPTR 100 20 "" "K2U" "!^.*@(.*)$!\1.org.kw.cn!i" . Also, there are rules for the corresponding nodes of the two keywords. example IN NAPTR 100 10 "U" "K2U+ftp" "!^.*$!ftp.example.com!i" . IN NAPTR 100 20 "U" "K2U+http" "!^.*$!www.example.com!i" . example2.example1 IN NAPTR 100 10 "U" "K2U" "!^.*$!www.example1-example2.com!i" . If the administrator of "org.kw.cn" delegates the subdomain "example1" to another zone, the zone file for "example1.org.kw.cn" will looks like: $ORIGIN example1.org.kw.cn example2 Zhang & Lee Expires July 19, 2009 [Page 7] Internet-Draft Keyword DDDS Application January 2009 IN NAPTR 100 10 "U" "K2U" "!^.*$!www.example1-example2.com!i" . The AUS for the two examples are "cn:@example" and "cn:@ example1:example2" respectively. For both the two keywords, the first key for searching the database is "cn". Since the sole rewrite rule is not a terminal rule, its result "kw.cn" will be used as the input of the next DDDS loop to search the database. Both the two keywords match the first rule, producing "org.kw.cn" as another key to search the database. Of the two rules returned by requesting NAPTR records for "org.kw.cn", which one matches the AUS depends on the format of the AUS itself. In this example, "cn:@example" matches the second rule and "cn:@example1:example2" matches the first rule. The result arising from this rule will be used for the next DDDS loop, "example.org.kw.cn" or "example2.example1.org.kw.cn". Querying the key "example.org.kw.cn" will return two NAPTR records, one for ftp client and one for http client. The client application can choose which one to use according to its requirement. Querying the key "example2.example1.org.kw.cn" will return one NAPTR terminal rule, which produces "www.example1-example2.com" as the final URI(implicitly adopting the default protocol "http"). 5. Security Considerations Since Keyword uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As Keyword is to be deployed on the global Internet, it is expected to be a popular target for various kinds of attacks, and attacking the underlying DNS infrastructure is one way of attacking the Keyword service itself. There are multiple types of attacks that can happen against DNS that Keyword implementations should be aware of. RFC 3833 [14] gives a deep analysis of the known threats and attacks of DNS. Because of these threats, a deployed Keyword Addressing System SHOULD include mechanisms which ameliorate these threats. Most of these threats can be solved by verifying the authenticity of the data via mechanisms such as DNSSEC[12] once it is deployed. Others, such as Denial of Service attacks, cannot be solved by data authentication. Applications using the Keyword Addressing System are encouraged to utilize any firewalls or other security facilities to detect and prevent any potential insecure resources identified by the final URI. Zhang & Lee Expires July 19, 2009 [Page 8] Internet-Draft Keyword DDDS Application January 2009 6. IANA Considerations There is no special requirement for the IANA to make this application deployable. 7. Acknowledgments This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. 8. References 8.1. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [7] International Organization for Standardization, "ISO 3166- 1:1997. Codes for the representation of names of contries and their subdivisions -- Part 1: Country codes", 1997. [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [9] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. Zhang & Lee Expires July 19, 2009 [Page 9] Internet-Draft Keyword DDDS Application January 2009 [10] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [11] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [12] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. 8.2. Informative References [13] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [14] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. Authors' Addresses Guoqiang Zhang CNNIC No.4 South 4th Street, Zhongguancun Beijing, CN Phone: +86 10 58813038 Email: zhangguoqiang@cnnic.cn Xiaodong Lee CNNIC No.4 South 4th Street, Zhongguancun Beijing, CN Phone: +86 10 58813020 Email: lee@cnnic.cn Zhang & Lee Expires July 19, 2009 [Page 10]