Providing your own NICNAME service.

There has been a modicum of fuss made throughout the past decade or so over the security and reliability of the NICNAME service that domain-name registries provide. People are worried that registries will "close off port 43", or that they won't keep data up to date for their customers that happen not to speak the same languages as they do, or that by bowing to customer pressure to publish customer-supplied data they'll end up publishing false data.

A lot of the solutions to these issues involve suggestions that people provide their own NICNAME services. Registrants who want extra or different, customer-specified, data will stop pressuring the registries to be more permissive, because they can supply their own data from their own servers. Registries won't be so pressured into "closing off port 43" because of excessive server loads, since more NICNAME traffic will be directed to registrant-owned (and registrant-paid-for) servers rather than to the registries' servers. Registrants who don't speak the right language won't have to talk to a registry in a language they don't deal with simply in order to make minor non-administative/billing-contact-related changes.

There are all sorts of roll-your-own schemes suggested for doing this, from files with well-known names on content HTTP servers to (yet more!) things to stuff into TXT resource records in the Domain Name System (as if there weren't enough people already trying to hi-jack those records for their own purposes!).

This is the Frequently Given Answer to such reinventions of the wheel.

You can do all this with the ordinary NICNAME protocol, and ordinary NICNAME clients. The facilities already exist, and have existed for some years, for providing one's own NICNAME service if one wants to.

The simple fact is that modern NICNAME clients use SRV lookups to locate servers, and these lookups proceed, of necessity, in bottom-up fashion, from subdomains to superdomains. A NICNAME client trying to find, for example, the NICNAME server for example.ltd.uk. will perform SRV DNS lookups for the following domain names, stopping at the first one that succeeds:

  1. _nicname._tcp.example.ltd.uk.
  2. _nicname._tcp.ltd.uk.
  3. _nicname._tcp.uk.

They have to proceed bottom-up like this because NICNAME servers already exist in subdomains. FreeDNS's own NICNAME server, for example, is found by looking up the SRV resource records for _nicname._tcp.eu.org., which of course has to be looked up ahead of looking up _nicname._tcp.org..

Nominet provides SRV records for _nicname._tcp.ltd.uk. and _nicname._tcp.uk., pointing to its own NICNAME servers. But Example Ltd itself has full control of what NICNAME server _nicname._tcp.example.ltd.uk. maps to. It can point it at its own NICNAME server, and modern NICNAME clients will use that server for any domain names in example.ltd.uk. and below.

It's not hard to set up a NICNAME server. People who run registries think that it is. But Example Ltd isn't a registry and doesn't aim to be. All of the complex bells and whistles that real registries employ aren't needed when one is only telling the world about onesself rather than about arbitrary customers with further subdomains. If people come to Example Ltd's NICNAME servers and ask about other peoples' domains, then more fool them, as far as Example Ltd is concerned. (And as can be seen above, this isn't how the lookup mechanism actually operates.) All that Example Ltd needs to do, in the minimum case, is set up a server that listens on the NICNAME/TCP port, and that spits out a constant text file to all comers. That's a trivial exercise in the use of the cat command and ucspi-tcp on some operating systems.

The Internet Utilities for OS/2 has a very simple NICNAME client for OS/2, that is only slightly smarter. It reads the domain requested by the client, looks for a text file named the same, and spits it back out to the client. So Example Ltd can provide differentiated NICNAME service for example.co.uk., example.ltd.uk., and even example.plc.uk. with a single NICNAME server.

This level of smartness is all that a registrant that does not want to be a domain name registry actually needs. And it really is not at all hard to achieve.

The only remaining consideration is NICNAME clients who don't want to be fooled by fraudsters, who publish untruths on their own NICNAME servers. This, too, is not a difficult problem to solve. Simply provide NICNAME clients with the ability to skip SRV lookups for the lowest subdomain.

Again, the Internet Utilities for OS/2 exemplifies the simplicity of achieving this. WHOIS.EXE, its NICNAME client, has a /SRV_SELF option, that can be turned off. If turned off, then the search for example.ltd.uk.'s NICNAME servers proceeds with one less step, omitting the lookup for the "self" domain name:

  1. _nicname._tcp.ltd.uk.
  2. _nicname._tcp.uk.

As they say: Job done!


© Copyright 2009 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.