At NZRS we run Critical Internet Infrastructure and we are a source of Authoritative Internet Data. Because we run the DNS for the .nz country code Top Level Domain (ccTLD), we get access to a great amount and variety of data, but we also seek interesting ways to collect more data to better understand how .nz is used.

One of our initiatives is the .nz zone scan, a collection started in August 2013, run monthly where all active .nz domain names are checked for DNS correctness such as broken/lame delegations or nameservers open for recursion, and checked for the presence of new uses of DNS such as if domains are DNSSEC signed or if they announce IPv6 addresses for various services.
To run the zone scan, we use our own fork of IIS dnscheck.

Summarized data of the zone scan is available in our Internet Data Portal for download and exploration. To provide you with a glimpse of the things we found, we'll show you some highlights.

Because we are geeks, we will be using the newly available JavaScript library for plotting, and querying the data directly from the portal. Everytime you check this post, the data will be fresh and new, directly consumed from the available dataset.

Domain Errors

IDP Dataset: Domain Errors

There are a variety of checks run at the domain level, the most relevant are shown below.

There are three high level categories:

  • Broken Delegation, where a domain is utterly broken and no other tests can be run. This usually caused when an active domain has nameservers that don't respond for the name. We consider these domains as inactive, they can't be used.
  • Lame Delegations, where a domain has one or more listed nameservers that don't respond for the domain. Lame delegations can lead to non-deterministic failures of the domain, so it's a good thing to see a slow decrease of those cases.
  • No MX Record, domains that don't have an MX record, so it's not practically possible to use them for email. We use this as an indication of activity for the domain

Nameservers info and errors

IDP Dataset: Nameserver Errors

As part of the correctness test, we query each nameserver for a set of queries, to discover if they provide recursion (bad thing!), if they leave open access to the zone (undesirable), hints of new software versions (NSID), and others.

Nameservers with open recursion are a menace for all Internet users, they can be used for DNS amplification attacks and should be completely eradicated. It's good to see the downward trend. Nameservers with open transfer make the zone contents available via zone transfer. In the InfoSec environment, such situation is seen as an open door for reconnaissance and target identification.

NSID is a relatively new feature in the DNS defined in RFC 5001 to identify the precise server behind a nameserver. With the expansion of anycast, where several hosts distributed in different places can represent a single nameserver, NSID is a useful tool to track an specific instance. If you feel brave, you can test it against our nameservers ;)

dig soa nz +nsid

The response will include something like this

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 6e 73 32 61 2e 69 6e 74 2e 64 6e 73 2e 6e 65 74 2e 6e 7a (n) (s) (2) (a) (.) (i) (n) (t) (.) (d) (n) (s) (.) (n) (e) (t) (.) (n) (z) ;; QUESTION SECTION: ;nz. IN SOA

In this case, the server answered for the query. Depending on your location, you can get ns2a or ns2b.



DNSSEC is an extension to the original DNS protocol, to provide integrity, authentication and non-repudiation using cryptographic signatures. The .nz zone has been signed for some years, and we are interested on seeing how deployment has progressed. Adoption is currently quite low, but from time to time there is a disruption that speed things up.

There are a couple of situations to observe from this plot. The number of signed domains grows faster that the number of secure delegations (DS records in the registry). We think this is mainly due to registrants testing signing without committing to complete the chain of trust (that may cause operational problems), and also due to few registrars able to handle DS records for their registrants.

The disruption came from Cloudflare, who announced their Universal DNSSEC service to facilitate DNSSEC signing. The uptake was phenomenal, and CloudFlare decided to use the rather a new ECDSA algorithm, which encouraged us to swiftly enable it the registry.


IDP Dataset: IPv6

As part of the data gathering effort, we check if domain names have IPv6 addresses for their nameservers, mail servers and web servers. We use this as an indication of IPv6 adoption.

As we described the IPv6 situation for a policy person recently, it's flat like a pancake. There is little growth along the years, with the unique disruption of a 11% increase in December 2015, due to a registrar adding IPv6 addresses to their nameservers. That change was not driven by registrants, but by operational rules of that registrar in particular. Using other data sources, IPv6 adoption in NZ is basically stalled (will leave that for a different post).


The results presented above are just a little sample of the many metrics we collect monthly for the .nz namespace. We are interested in seeing other people exploring those metrics using the open access the Internet Data Portal provides. We are also planning to make other datasets available, like aggregated counts from our DNS traffic.