Referring to http://www.ietf.org/internet-drafts/draft-kurtis-tld-ops-00.txt
At 21:51 +0200 8/8/05, Kurt Erik Lindqvist wrote:
The draft was written by me as a task from the IAB. This had been on the IAB
TODO list long before I got nominated. After writing the first rough outline
which is what got published under the name above I circulated it to some of
the usual DNS suspects.
Given that, I won't hold the document against you. ;)
DNS is not the critical element for a registry. DNS is a critical
element to the network and it is populated by a registry.
Understanding this is a necessary first step in analyzing the
document, or what the document is seemingly intended to be.
Titled "tld ops" leads me to believe this is supposed to be guidance
towards running a registry for, what I would call, a widely-delegated
zone. I include in this 207.in-addr.arpa., .info, .us, .co.jp., and
many others. On the other hand, .arpa doesn't really fit this mold.
It doesn't matter how many labels are in the zone's name, it matters
how the zone is used.
When I think of a full-fledged registry, this is what comes to my
mind. First and foremost, it has a database associating Internet
resources (addresses, domain names, etc.) to legal bodies
(personified as contacts). The life of the database is the primary
concern - if the data is lost or corrupted, you've upset a large
apple cart. "Business continuation" is a major concern, the
technical element of that is replication and escrow of data.
A registry has a number of important interfaces. Input is
registration activity (EPP is cited in the document as part of this).
Output includes directory listing (WhoIs, IRIS) and DNS. One
interface often overlooked in engineering circles, but nonetheless
vital is billing. There is also the less definable interface with
law enforcement authorities seeking identifying information when they
need it. Unifying the data flows amongst all of the interfaces is
non-trivial. Oh, and don't forget customer service.
Besides maintaining the life of the database, maintaining and
unifying the interfaces, there is policy to deal with. Policy can
mean what names are permitted, who is eligible to get a name, and
what happens when there is a dispute over the use or registration of
a name. For the RIRs policy also extends to who can get a resource
and how much of it.
I didn't write much about DNS. That's no accident. I can go so far
to say that there are many registries that do not operate their own
DNS servers. Why? It's because DNS has been so well defined and so
modular that it can be out-sourced. The moral of this point is that
if you want to talk about TLD operations, don't start with DNS as the
main focus.
However, I can see that we don't want to neglect running DNS
altogether. It is probably the one component of a registry that is
easiest for the IETF to document. The DNS has the largest impact on
the Internet of all registry interfaces. I agree that there is
usefulness in preparing requirements for providing DNS services for
different kinds of zones. But I wouldn't equate it with describing
registry operations.
I am trying to find a copy of BCP 40 (but
http://www.ietf.org/rfc/bcp/bcp40.txt says "access denied" and mail
has gone to the web admin for the site), but am failing - I guess
this is the root server operations document. If so...
The requirements for a root server are not all that closely related
to the requirements for a "tld" zone server. Some "tlds" are high
volume, high churn zones. For this reason incremental zone updates
are crucial, in contrast with the zone updating of the root. The
propagation time (latency) from registration of a name to seeing it
in the DNS is much less in some "tlds," as well as name server
re-listings.
There are a lot of technical differences between the root and the
next level down. The set of differences also varies greatly from one
kind of "tld" to the next. So, trying to document them will be
tricky.
I've been through the experience of trying to respond to bids for
registry operations. When it comes to DNS, RFP's have asked the
bidders to describe their DNS and what it conforms to. Preparing
this answer is not easy - the IETF isn't good at publishing
"profiles" and some of the early DNS RFC's are not clear on
conformance. So, the IETF'er in me has thought that "it would be
good to document a DNS profile" but when I think of the process, I
can't see it would be successful. E.g., would a "tld" DNS server be
required to implement CNAME? I'd rather see RFC 1995 integrated with
RFC 1034/1035. How about dynamic update? Before you say "no, don't
allow dynamic update to DNS servers in a 'tld'" consider that it is
one tool for loading database changes into hidden masters. It's not
clear what should be in and what should be out.
Facility requirements are sticky. With the advent of anycast, is it
detrimental to have a server located in a best-effort facility?
Should a "tld" be afraid to place servers where the local
infrastructure hasn't matured? I wouldn't want a document to make
operators intolerant of the (service level agreement) risk of
furthering the spread of the Internet.
One of the questions that came up in the meeting in Paris was "what
was the motivation behind this?" If this is to help organizations
prepare RFP's for registry operations, I'd be leery of trying to do
this in the IETF. There are already examples of RFP's available (and
the resulting bids too). If I were to be issuing an RFP for a new
"tld", I'd run off and copy the RFP sections from someone else who
had a successful procurement. ;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
