| Network Working Group | Y. Yoneya |
| Internet-Draft | JPRS |
| Intended status: Standards Track | February 18, 2013 |
| Expires: August 22, 2013 |
Variant Label Resource Record
draft-yoneya-dns-variant-label-rr-00
Definition and operation of variant domain names are differ from zone administrators, and there is no generic rules, therefore, in general, it is hard to guess variant labels for end users and / or applications. Meanwhile, zone administrators are understanding all variant labels list because they generate variant labels and activate them according to rules they defined. Thus, if there is a mechanism that end users and / or applications can obtain variant labels list from zone administrators, then it would be useful. The Variant Labels Resource Record (VL RR) provides such variant labels list for that purpose.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 22, 2013.
Copyright (c) 2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Some of the zone administrators such as TLD registries that accepting IDNs are bundling variants as a package. Also, in conjunction with the deployment of IDN TLDs, consideration of Variant IDN TLD is in progress. It is hard to guess variant labels list from short string that does not have context like domain name, because definition of variants are differ from languages even though using the same script. The zone administrators such as registries have complete list of variant labels for a label, so if they have mechanism to provide the list, end users and / or applications can obtain variant labels list without guessing. The Variant Labels Resource Record (VL RR) is a new DNS RR that provides variant labels for a label.
VL RR format is as follows:
variant1 TTL IN VL priority1 variant1.
priority2 variant2.
priority3 variant3.
Here, the variant1 is a variant label in a query name, the variant1, variant2 and the variant3 are the list of variant labels for the variant1. The values of right hand side can be listed multiple times as RRset like other RRs. Period at the end can't be omitted. If the variant label is IDN, then it must be written in A-label [RFC5890]. The priority1, priority2 and priority3 are the integer numbers which indicate priorities for the variant1, variant2 and variant3 respectively. The smallest number means that the variant label is the canonical label.
All variant labels must be defined inside of one zone, and they can't refer labels outside of the zone.
The VL RR can't set to the zone apex.
The full resolvers send VL RR query to the authoritative DNS server(s) for the FQDN which is generated from the query name omitting most left label (parent zone authoritative DNS server(s)) and get response. The full resolvers may cache the response during the TTL time.
The authoritative DNS servers must ignore VL RR which is set to the zone apex. The authoritative DNS servers respond NXDOMAIN for queries to non-existent label. The authoritative DNS servers respond VL RRset for queries to existing label if it has VL RRs, or respond NOERROR for queries to existing label if it does not have VL RRs.
The full resolvers which is not VL RR capable can't send queries to the parent zone's authoritative DNS server(s), therefore, it can't obtain VL RR for the zone apex actively. Thus, parent zone's authoritative DNS server(s) should respond VL RRset in additional section when it respond NS RRset.
The applications treat a label with most small number priority as a canonical label from list of variant labels obtained by the query. Other labels may be displayed to the users as list of variant labels.
The VL RR increases volume of large zone such as TLD registries have. This will impact zone generation and / or zone transfer.
Deployment of VL RR aware applications will increases queries to Root zone or TLD zones. This will impact Root / TLD authoritative servers in performance and / or bandwidth.
The zone administrators who will introduce VL RR are recommended to have enough assessment previously with recognition above.
IANA is required to assign VL RR type and number.
Because the VL RR can set many variant labels, it can be a source of DNS amplifier attack. The zone administrators can avoid this issue by suppressing number of activating variant labels appropriately.
| [RFC5890] | Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010. |