Technical Committee Report to Council 13/04/02

Report Adopted by the Council Meeting of 13 March 2002

D. Zanetti, Chair
27 March 2002

UPDATES TO "NEW ZEALAND DOMAIN NAME STRUCTURE" POLICY

1. Introduction

This document is intended to address some of the changes in standing policy for the New Zealand namespace (".nz") to reflect the Society's decision to move away from a "thick" registry-registrar entity towards a thinner Shared Registry System.

It is, in part, in response to questions from the SRS Implementation Team, and is intended to clarify their interpretation of policy, as well as establish new policy where the SRS needs it.

2. Issues not covered in this document

This document does not attempt to address updates to the policy to clarify Domainz's role in the administration and operation of the namespace. An update should be made to the policy to reflect the new structure at an appropriate time.

3. Interpretation of RFC1034, 2181

"Zone" is a term used in both RFC1034 and RFC2181, and is defined by 4.2 of RFC1034. The definition provided is lengthy (and is not immediately obvious as to its meaning), so for the purpose of InternetNZ policy, consider a zone is a collection of RRs (Resource Records, herein called "records") for which there is a common portion (or, root, so to speak), and which has been delegated to a number of nameservers. For example, "nz." is a zone, as is "internetnz.net.nz".

This clarification does not override the definition provided in RFC1034, it is merely the interpretation used when considering policy.

4. Non-Delegated Registrations

Prior to June 1996, the namespace allowed for domains to be registered but without needing to be fully delegated to a set of nameservers. This was mostly used to add domains which were "MX-only", in that the only requirement they had was for mail to the domain be sent to a particular set of machines.

The namespace also allowed "TXT-only" entries, in which case nothing more than a comment was available for the domain. This amounted to a simple reservation.

In June 1996, the policy was amended to lower the administration overheads of maintaining different types of registration. The result was that domains may still end up with only MX or TXT records, but those answers are never sourced from the New Zealand root servers.

There is, however, an argument that the SRS does not preclude a domain being entered into the database without actually ending up in the zone build. The argument advances that the cost of maintaining these entries is no higher than the cost of other entries, and that since the Registry will bill based effectively on "lines in the database", and not the zone file, such registration still recovers costs.

The counter argument is that the Registry exists solely to enter names into the zone file on the root nameservers. It argues that the barrier to set up a nameserver with placeholders is not steep, and that it complicates the Registry to have to filter what ends up in the zone file.

The committee considers that as the cost of maintaining such entries are still recovered, and that the actual cost of filtering the list of names for the zone file is not that much higher with non-delegated names, that the Registry should allow Registrars to enter names into the Registry with no delegation.

The committee also noted that it promotes a more healthy DNS by removing some of the potential problems when a given name is moved from "parked" (ie, non-delegated) to active use, in that there is no need to propagate new DNS entries, wait for caching to expire, etc. The alternative is for new nameservers to be propagated, and only once safely propagated can the old nameservers be deactivated. During the propagation time, end-users may get different results.

Note that this does NOT allow any situation other than having no nameservers configured at all. This is NOT rescinding the part of the policy change in 1996 removing MX-only registration. This change simply allows zero as a valid number of nameservers for a name. This does not remove the requirement that a zone must have at least two nameservers configured - the zone is never delegated at all, and never occurs in the root zone file.

5. Lame Delegations

A "lame delegation" occurs when the delegated nameservers according to the root servers do not respond with authoritative answers. A lame delegation effectively creates inconsistencies between different users of the Internet of the contents of a zone.

The current policy states that such lame delegations will be automatically deactivated, but this does not appear to have ever been implemented, nor does there appear to exist a policy on how often the Registry should be checking for lame delegations, other than at time of submission.

As was often noted by discussions on this issue, lame delegations are rarely true at the time of submission, which makes the usefulness of this fairly minimal. To be useful, this policy would have to be performed on a more regular basis.

One argument advanced is that removing lame delegations helps keep the Internet's DNS clean, and improves response times to users. The opposing argument is that keeping your DNS servers authoritative is "basic administration", and that it only hurts the holders of domains which have lame delegations.

In either case, the committee considered that it is not a role for the registry to perform. In order for the service to be useful, it would have to either notify registrants their name has a lame delegation, or notify the registrar of the lame delegation.

Notifying the registrant breaks a rule that the registry should never contact the registrant directly. Notifying registrars would add extra overhead to the protocol between the registry and registrars.

Therefore, the committee considered the checking of lame delegations to be an option registrars are welcome to take, but are not required to do so. The registry will never check for lame delegations, either at submission time, nor at any point after submission. Registrars may wish to offer this as a service to registrants, and should be encouraged to do so. However, registrars should be very careful to declare any intention to deactivate names based on these checks.

© 2002 The Internet Society of New Zealand
Last updated 12 April 2002