.nz domain name model

NZ Registry Services run the .nz domain name registry, following policy set by the .nz Domain Name Commission. Both are subsidiaries of InternetNZ, which gained control of the .nz domain name space in the mid-1990s (in part because the previous .nz domain name registry was a volunteer effort by staff at the University of Waikato, for historical reasons, who no longer wished to continue as the Internet became more widely adopted).

About 15 years ago, the current .nz domain name registry model was created, to replace a fairly controversial vertically integrated registrar/registry implementation run by Domainz. Those with a good memory for history might also remember that this was around the time that control of the global TLD (top level domain) names were being split off from their historical vertically integrated manager, Network Solutions. Both redesign/reimplementations happened approximately in parallel, which is part of the reason that the .nz domain name registry works somewhat differently from the global ones (ie, there was no obvious Best Practice model to just adopt). I was involved with some of the early design and implementation (up through a working prototype) of the .nz registry implementation (which, after 15 years evolution, is what NZRS now operate).

Back when the .nz domain name registry model was being designed there was considerable concern about rogue registrars -- the intermediary between the registrant that registered the name and the registry that published the DNS records that made the domain work. That is concern about a registrar that failed to function exactly according to the contracts to which it had agreed. This had a substantial influence on the eventually deployed design, including NZRS holding .nz domain name registration fees in escrow when they were paid in advance, rather than the adoption of a month-by-month wholesale/retail model. (Some other downstream decisions from that one led to a means by which registrants that registered a name "by mistake" could get their money back within a few days, which created a market for "taster" registrations of domain names -- at no cost! -- leading to technical (load spikes!) challenges as domains became available for re-registration. Almost that entire technical challenge could be avoided by simply charging the "taster" registrants for a month of service, at which point domain speculation would be much less profitable.)

UDAI motivation

One of the concerns about a rogue registrar was that they might hold a domain name hostage when a registrant wanted to do something else with the domain name (for instance as a result of a related or unrelated business dispute). Remember this was around the time that many people were trying to get their older gTLD domain name registrations out of Network Solutions, and finding that Network Solutions refused to approve the transfer away from them unless everything was Perfectly In Order (tm) before the transfer, and the transfer request was done Just Right (tm) -- and that the incumbent combined registry/registrar for .nz domain names (Domainz) also did not always act in the registrants best interests. (As an example, at one point Domainz updated details of some of my domain name registrations so as to muddle their ownership, and then was trying to insist on being paid a "change fee" before they would change the records back to the correct details that were there before. It took a fairly assertive phone call to the head of Domainz to get them to concede that "just this once" they would undo their change at no charge.)

There were two separate, parallel, solutions requested to this problem of rogue registrars. Firstly there was a contractual solution, whereby it was a breach of the registrar contract (with the Domain Name Commissioner) to hold domains hostage -- and the DNC had some leverage by being able to deauthorise .nz domain name registrars. Secondly, and more relevantly to this story, there was a technical solution -- a registrant "self help" solution to this problem. The technical solution was desired because the registrant could use it in a matter of hours, where as a policy/contractual solution, potentially involving calling in the DNC for dispute resolution, could take much longer.

The use case for the technical solution was something like this:

Jill is a .nz domain name registrant of the domain example.co.nz. She uses Alan's company to register the domain name, and also design the website for her new business. Later Jill and Alan have a falling out, and Jill changes to a new web design company run by Brenda. Alan is unhappy about this and refuses to update the DNS to send web requests to the server run by Brenda's company.

Jill's business is effectively shut down by this dispute with Alan, and she wants to get her web site operational with the new content as soon as possible.

UDAI design

The resulting technical solution was the UDAI (the Unique Domain Authentication ID), which was a single purpose credential generated by the .nz registry that allowed a person in possession of the of the UDAI matching a domain name to immediately transfer that domain name to another .nz registrar -- by requesting the new registrar transfer in the domain name, and providing the UDAI to the new registrar. Because it provided a direct registrant to registry authentication method, the registry could immediately action the change and Jill could have her domain name pointing at her new website within an hour (ie, at the next DNS push, now hourly).

The UDAI had a very simple design:

  • It was randomly generated by the registry for each newly registered domain name, and provided -- via the registrar -- to the registrant.

  • Registrants were advised to expect the UDAI when they registered a domain name, and store it securely, away from anyone not to have full control of the domain name, for later use -- potentially years later.

  • The registry stored the result of a one way hash function of the generated UDAI, ensuring that it could immediately validate if the correct UDAI was provided, but that there was no record of "all valid UDAIs" to be a target for theft or accidental disclosure.

  • When a registrant wanted to change registrars they went to the new registrar and provided the domain name and the UDAI for that domain name, which the registrar passed to the registry to authenticate the transfer request. On receipt of this request the registry hashed the supplied UDAI again, and verified that the one way hash result matched -- proving the original UDAI was known to the person initiating the transfer request.

There are of course some special cases:

  • Anyone with the UDAI could take full control of the domain name, so access to the UDAI had to be kept away from anyone that should not have full control over the domain name. This was the reason for creating a new single-purpose authentication token, direct from the registrant to the registry.

  • If the registrant changed registrars, then one possible reason for doing so is that they no longer trusted their previous registrar to act in their best interest. The previous registrar had been in a position to observe the UDAI, so on change of registrar the old UDAI was invalidated and a new UDAI generated to ensure the domain name was safe from the previous registrar.

  • If the domain name legitimately changed ownership, then the old registrant should have no further ability to take control of the domain name, so a new UDAI needs to be issued to the new registrant. (And this needs to be done any time it looks like the registrant might have changed -- for instance any change in the ownership details -- just in case that does actually represent a change in ownership.)

But apart from those special cases, the UDAI was valid from the time of issue (registrant of a new domain name, change of registrar, change of registrant) until the registrant requested a new UDAI be generated, which would invalidate the old UDAI. (A registrant might want a new UDAI generated because of change of staff members -- a rogue employee for instance. Or possibly because they had lost the original UDAI documentation, which is always a risk with long held seldom used credentials.)

Scope creep

Relatively soon after the .nz domain name registry model was deployed some registrars started pushing to use the single-purpose UDAI for other purposes.

For instance, some registrars found that user validation was "difficult" and noticed that the .nz registry already had an authentication token, so wanted to repurpose that authentication token for their own purposes. They managed to convince the DNC and NZRS to provide a registry API method that would allow them to validate a string they sent matched the UDAI (see clause 17.4 of the policy) -- thus allowing them to skip implementing their own authentication method, and simply insist that all users provide the UDAI for their domain to make any change.

This increased use of the UDAI immediately weakens its original security benefit -- not only is the UDAI being passed around much more often, and thus much more likely to be revealed to, eg, someone observing the network, it is also almost inevitably given to staff, contractors, or consultants who need to make some DNS change (perhaps a minor DNS server update, or even in some cases a DNS entry update) but whom should not be able to seize control of the entire domain name away from the original registrant.

In this scenario if Alan were only the web designer, not the registrar, but Jill had to give Alan the UDAI in order to get a simple DNS entry updated for her website to work, then Alan already has the power to take over Jill's domain. Jill might not even realise that she was trusting Alan that much until it was too late.

The original UDAI design avoided this rogue web designer problem by separating the authentication for the ultimate control of the domain name (the UDAI) from the authentication to make day to day operational changes (eg, updating a DNS entry), which were to be simply authenticated separately by the registrar or DNS provider. By providing this UDAI-validation method, and allowing registrars to repurpose the UDAI, the DNC/NZRS increased the risk of Jill losing control of her domain name -- at least for a period of time -- to a rogue web designer or staff member.

Death of the UDAI

In August 2014, the DNC changed the .nz policy for the UDAI (by DNC board decision, after a short period of consultation) so that UDAIs would expire after 30 days. I found out about this change only earlier this week, after an older UDAI failed to work, and my registrar suggested the UDAI might be out of date -- and pointed out that they now expire after 30 days.

The original consultation says:

There is an additional change in the function of a UDAI that introduces a time limit on the life cycle of a UDAI. At the moment UDAIs do not expire and with the plan to use UDAIs to verify domain names as part of the second level registration process, it would be good to ensure that all registrants had valid UDAIs. It is therefore proposed that UDAIs will expire after 30 days which is a new functionality. This is a functional change only as current policies do not explicitly state how long a UDAI is valid for.

The logic of "it would be good to ensure that all registrants had valid UDAIs" therefore "UDAIs will expire after 30 days" escapes me -- expiring the UDAIs after 30 days increase the chances that registrants will not have valid UDAIs, because they have been expired. It also seems an unnecessary step for the stated purpose (ie, registrants needing the UDAIs to "verify domains as part of the second level registration process"), because the existing UDAI infrastructure already provided registrants with a method to request a new UDAI be generated if they had lost the old one or it otherwise did not work. Besides, the new "30 day expiry" UDAI practically requires that the registrants have to use this mechanism to request a new UDAI -- exactly the same thing that the registrants who did not have "valid UDAIs" would need to have done anyway. It is, in my opinion, a non-solution to a non-problem.

If this change were merely pointless, I would have shrugged and moved on. But the same change renders the UDAI practically useless for its original design purpose, as described in the use case above. Because now by the time that Jill needs the UDAI as a self-help measure to get away from Alan's web design company, it will (most likely) have expired. The stated proposed remedy in that situation is that Jill should go to her registrar (Alan) and request a new UDAI -- which if Alan has gone rogue, he will most likely refuse to provide, leaving Jill with no immediate technical solution to escape from the problem. (Jill does still have other contractual and policy remedies available, just as she had before, including involving the DNC in the dispute. But none of those comes with a guarantee of getting her website functional with Brenda's design company in under an hour.)

From discussion with the Domain Name Commissions contact address (to whom my query to the NZRS about this technical change was forwarded), and from the minutes of the DNC board meeting it appears the DNC have decided that because this technical self-help measure was infrequently used (eg, "in all recent transfer cases, new UDAIs are already requested just prior to the transfer") expiring the UDAIs after 30 days would not inconvenience registrants. Instead the DNC appears to place reliance on the DNC getting involved at a policy/contractual level instead -- which was an alternative option always open to Jill if she chose to exercise it instead of the technical solution.

This replaces an "in case of emergency break glass" self-help technical measure, like an emergency door release, with a sticker saying "in case of emergency please phone this number and someone will come to help you". In normal situations that might be nearly as good. But if the reason you really want to open the doors right now is that there is a fire behind you, non-trivial damage may occur before anyone can assist you.

Like the "in case of emergency break glass" door releases, the UDAI technical measure existed for a specific self-help reason. But now, without ever explicitly stating it was their intention, the DNC/NZRS have repurposed the UDAI for a set of different purposes, and removed the "emergency self-help" ability that led to its creation in the first place.

Footnote: Potentially worse still, it appears the UDAI will no longer be regenerated on change of registrar (current policy), which would appear to mean that if Jill did persuade Alan to generate a new UDAI (eg through an automated tool on Alan's registrar site), and then transfer the domain name away to another registrar, a rogue website designer/registrar like Alan could then transfer it back within 30 days, and then request a new UDAI to lock Jill out from reclaiming her domain. Naturally such actions would be a breach of multiple policies and contracts, but Jill's business website may be non-functional while everyone argues about that, giving any web designer/registrar willing to "play hard ball" considerable leverage that they did not have before.

At quick glance it also looks like the UDAI is no longer changed on change of registrant either, enabling the seller to reclaim a sold domain (perhaps because the payment did not clear -- instead of a payment dispute, they can have their domain back and get more leverage). So it seems all of the fundamental security properties of the UDAI design are now rendered ineffective.

It appears registrants are expected to manually initiate a UDAI change in these scenarios to protect themselves, but there does not appear to be any advice to registrants of the newly-created (by this policy change) importance of doing something that the registry used to do automatically. For instance it does not appear in the DNC FAQ for Registrants.

(To validate this, compare clause 12.3 with what has become clause 17.3, to see that the proposed change took effect. Don Stokes pointed out many of these issues in advance, but the DNC Board seem to have disregarded this voice of concern.)

ETA, 2014-10-19: My registrar let me know that while new UDAIs are not generated on transfer between registrars, it appears they are at least invalidated, so hopefully that avoids the risk of a rogue registrar (Alan) transfering a domain back to them using the UDAI that was used to transfer it away from them. (I also emailed the DNC about that particular issue suggesting they mention it in their Registrant FAQ.)

ETA, 2014-10-20: By email the DNC confirms that the UDAI is now a "single-use code" for domain transfer, and expired on transfer between registrars (even though a new one is not generated). However they also say it is not currently expired on change of registrant which leaves the second of the risks in the footnote as a possibilty. Ie registrants should manually generate a new UDAI on gaining control over a new domain to force-expire the old UDAI.

It also occurs to me that with many registrars providing the UDAI "in band" (eg, via the web interface), which is practically required by them expiring all the time and registrants being encouraged to generate one immediately before transfer, anyone gaining access to the registrar interface now has the ability to:

  1. Generate a new UDAI

  2. Receive that UDAI through the registrar interface

  3. Transfer the domain name away from that registrar to somewhere else, and generally seize control of the domain name

When the UDAI was a long lived, seldom used, credential it was much more practical to send it out of band (even by printed letter, if one could justify the postage). But as a "transfer now" token, that is much less likely to be implemented. So the in-band delivery provides another opportunity for a rogue webdesigner that "needs a registrar login to update the DNS" to gain more control than they were intended to have.

Registrars could defend against that risk by:

  • requiring a special login in order to generate a new UDAI, separate from the "tech/web designer" login for day to day operations; or

  • sending the UDAI out of band (eg, text message, or even plain text email would provide some separation from the registrar web interface secured by a single password)

but it is not clear to me that (m)any of them do this, and AFAICT the DNC policy neither encourages nor requires them to do so.

Cached copies: