I've read draft-kurtis-tld-ops-00.txt and I find it disappointing.

My main problem is that it says:

> This document tries to analyze and define the operational
> requirements for the second tier in the DNS lookup hierarchy.

But it just describes *solutions* (redundant power supply, backups),
not actual *requirments* (availability, correction, response time,
etc).

I would love to see a document which first describes the requirments,
*then* gives possible solutions to meet these requirments. Otherwise,
the tree hides the forest. A good example is the "Redundant power
feeding": the real requirment is to have at least one name server
available. It is better to have five nameservers without redundant
power supply, but in various places, than only one name server with a
super power supply.

Otherwise:

> Backups: The slave-server systems should be backed up
> regularly. This includes zone data,

Well, this is a strange advice, the zone data alone is almost
useless. You should backup the original database, not the zone
data. May be it is intended to be in "5.3 Registry operations"?

No mention is done of the *correction* of the name server
configuration, something that SHOULD be automated with tools like
Zonecheck (http://www.zonecheck.fr/) or even the simple check_soa. A
broken nameserver is much more dangerous than a dead one!

I also share the concerns of the people who said that the distinction
between TLD and SLD is artificial: google.com is probably more
strategic than a TLD like BD or JM.

In short, this document is really a draft of draft and it is too soon
to comment it in depth. "Security considerations" is completely
missing, while it is an fundamental topic and so is
"Registry/Registrar interface" (I hope that EPP will not be regarded
as "best practice").

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Reply via email to