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:
_nicname._tcp.example.ltd.uk.
_nicname._tcp.ltd.uk.
_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:
_nicname._tcp.ltd.uk.
_nicname._tcp.uk.
As they say: Job done!