]> JPRS

Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku Tokyo 101-0065 Japan +81 3 5215 8451 yoshiro.yoneya@jprs.co.jp

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.

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:

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 . 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;