New Zealand Registry Services

New Zealand Registry Services -- DNAME Public test

Introduction

Beginning in Māori Language week 2010 (26 July - 01 August), the registration of Internationalised Domain Names (IDN) under the .nz domain name will be possible.

We are adding five new characters to the list of allowed characters, being the new addition of the macronised vowels: ā, ē, ī, ō and ū.

This change enables the registration of domain names using the māori script, so names like whakatū.org.nz can be registered.

Māori (with the ā macron) will be added to the list of allowed second level domain names (2LDs). Both .māori.nz and .maori.nz will be valid 2LDs. All existing and future names registered under .maori.nz will be duplicated in the DNS to be available under .māori.nz as well.  We will use a DNS record called a DNAME to implement this functionality.

You are using te-reo.māori.dns.net.nz but I'm seeing te-reo.xn--mori-qsa.dns.net.nz, is that correct?


By protocol specification domain names can only contain digits, the dash and letters from the 'a' to the 'z'. But efforts at the IETF to overcome that restriction and provide names in the language script of the user produced the IDNA specification. RFC 3490 created the "ASCII Compatible Encoding" or ACE, that allows a label in UTF-8 to be encoded using alphanumeric characters. So, te-reo.xn--mori-qsa.dns.net.nz is the ACE encoding for te-reo.māori.dns.net.nz.

What is a DNAME record?


DNAME is defined on RFC 2672, and it was created to allow some level of equivalence between different parts of the name hierarchy.
The structure of a DNAME record is

xn--mori-qsa.dns.net.nz. IN DNAME maori.dns.net.nz.

This creates the automatic translation of any name under xn--mori-qsa.dns.net.nz to an equivalent name under maori.dns.net.nz.
If you ask for te-reo.māori.dns.net.nz and a DNAME record is in place, that name is translated to te-reo.maori.dns.net.nz at the DNS level.

In order to provide backward compatibility, an authoritative nameserver using a DNAME record will return a DNAME and a synthesized CNAME record with TTL=0 for the name being queried. If a cache resolver doesn't understand the DNAME record, will simply ignore it and will use the CNAME. If it understands DNAME, that record will be used and cached.

Why are you testing the DNAME?


The purpose of this page is to test if your local cache resolver can handle DNAME records. While loading this page, we ran a test to see if your client accessed the contents of this page using the DNAME or using the synthesized CNAME. We need to do this to ensure the domain names under māori.nz will work as well as the names under maori.nz.

How the experiment works?


The page you are viewing includes the following code:

<!--Code inspired by
http://www.potaroo.net/ispcol/2010-04/ipv6-measure.html -->
<div id="dname-detection"></div>
<script type="text/javascript">

function detect_dname() {
var div = document.getElementById('dname-detector');
var iframe = document.createElement('iframe');
iframe.setAttribute('src','http://te-reo.xn--mori-qsa.dns.net.nz/visitor.php');
iframe.setAttribute('width', '1');
iframe.setAttribute('height', '1');
iframe.setAttribute('frameborder', '0');
div.appendChild(iframe);

var compl_msg = document.createElement('span');
compl_msg.setAttribute('style', 'color: #0044AD; font-size: 120%; font-weight: bold');
compl_msg.innerHTML = 'Testing completed!';
div.appendChild(compl_msg);

if (window.removeEventListener) {
window.removeEventListener(name, detect_dname, false);
}
else if (window.detachEvent) {
 try {
  window.detachEvent('on' + name, detect_dname);
 } catch (e) {}
}


try {
if (window.addEventListener) {
window.addEventListener('load', detect_dname, false);
}
else if (window.attachEvent) {
window.attachEvent('onload', detect_dname);
}
} catch (e) {}
</script>


And the visitor.php file contains the following:

<?
$remote_addr=$_SERVER['REMOTE_ADDR'];
$referer=$_SERVER['HTTP_REFERER'];
$subdomain="a".str_pad(mt_rand(1,100000),6,"0",STR_PAD_LEFT);
$visit_time=time();
$host=$_SERVER['HTTP_HOST'];

$data_a = array( "addr=$remote_addr", "ref=$referer", "dom=$subdomain", "t=$visit_time", "host=$host");
$raw_data = join(';', $data_a);
$enc_data = base64_encode($raw_data);

echo "<img src=\"http://$subdomain.xn--mori-qsa.dns.net.nz/1x1.png?data=$enc_data\" height=\"1\" width=\"1\" alt=\"counter\"/>"
?>

We create an iframe referencing a 1-pixel image located in a URL with a name in the form of aDDDDDD.xn--mori-qsa.dns.net.nz.
If your cache resolver supports DNAME, we will see a query for <A, aDDDDDD.maori.dns.net.nz>.
If your cache resolver doesn't handle DNAME, then will use the CNAME record, so we will see a query for <A, aDDDDDD.xn--mori-qsa.dns.net.nz>.
We use a unique ID for each visit to correlate the access on the webservers logs and the queries on the nameservers.

IDN support in browsers

Depending on the browser and the language settings, URLs containing IDN hostnames will be shown in their Unicode or Punycode form.

For more information, you can visit the information page for your preferred browser:

Google Chrome:
http://www.chromium.org/developers/design-documents/idn-in-google-chrome

Firefox:
http://www.mozilla.org/projects/security/tld-idn-policy-list.html

Microsoft IE:
http://msdn.microsoft.com/en-us/library/bb250505%28VS.85%29.aspx

Opera:
http://www.opera.com/support/kb/view/788/

Safari:
http://support.apple.com/kb/TA22996

Thank you for your help. If you have any further question or comments, please contact Sebastian Castro.