draft-manning-dnssvr-criteria-01.txt

[Randy Bush <[e-mail]>]

Please excuse the level of outrage and sarcasm.  But a little birdie told me
that this was going to iRFC and I don't have the time to polish this into my
normal good manners <grin>.

I can not support the publication of draft-manning-dnssvr-criteria-01.txt as
either a BCP or as an informational RFC.  In a nutshell, it would impose
strange and unnecessary constraints on those running TLDs, especially those
in startup networks in developing countries, precisely the kind of folk we
want to get online and up in a reasonable fashion.

> 1. Modern BIND or equivalents (if any exist).

What's BIND?  Some kind of Californain bondage and discipline stuff?

Thanks, but the protocol specs tell us what is necessary from an on the wire
perspective.  That's why we write protocol specs and not publish C code as
RFCs.  It is no one's business how a server achieves that, and this spec
attepts to peek past that magic curtain.  

If Blortania does it with a 1401, Autocoder, and a bi-synch to frame relay
converter, they should take a picture and post it on their web site.

> 	The upgrade process will be coordinated with the zone-master staff
> 	and will occur within 96 hours of initial notification. Zone-master
> 	senior staff will specify the software and version(s) that will
> 	be run in a particular zone.

This seems to mandate coordination and approval by a newly created
net.goddom, 'zone-master' and 'zone-master staff' which are undefined, and
not motivated as needed.  I smell a new technocracy who can solve the
problems of the world through the wonders of technology.

> 3. Dedicated host. 
> 	No user accounts, just the operations & admin or root account.

No problem if the authors will be funding the extra host(s) for the folk who
can not afford one.  Otherwise, get out of their face.

> 4. Singly homed (only one interface).
> 	Name service should always answer out the same interface as requests
> 	come in on. Also, delegations will usually list a single A RR, so there
> 	should only be a single canonical name.

One presumes that the nameserver software will handle this properly, and I
should not be restricted by how many interfaces my host has.

> 5. Protected.
> 	In general, each server must be adequately protected against security 
>    	threats.  The system administrator must stay up-to-date on the latest
>    	security methods and threats and must implement reasonable security
>    	countermeasures. Audits by the zone administrator or authorized agents
>    	will be permitted and corrective measures will be taken. A good way to
>    	keep current is to follow the CERT recommendations.  A reasonable 
> 	approach is to only run DNS sw, NTP and ICMP support with extensive 
> 	logging. Recommended packages to assist are tcp_wrappers and ipfilter. 
> 	Any other package which has an acceptable technology is fine.

Do the 'zone masters' give them a competence test every two months?  How
about a lie-detector test to ensure that they are not cheating?  Maybe we
should license DNS admins and be done with it.

> 6. Servers time is synchronized via NTP.
>    	This is useful for supporting functions; e.g. logging. It is expected 
> 	that future enhancements such as dynamic update and security support 
> 	will take advantage of accurate clocks. This presumes that the NTP 
> 	server has been secured using strong authentication.

NTP is nice.  We use it here.  But we can not mandate that the national TLD
for Blortania be secure, synchronized, ...  And, if we wanted to do so, we
would not do it in an informational RFC on a side subject.

> 7. Sufficient resources. 
> 	Each system must be able to support a transaction rate of 1200/sec and
>    	mean time to respond of 5 milliseconds per transaction as a baseline.

That's nice.  Blortania looks forward to having such a load in five years,
and they'll be able to afford the hardware to supply it in five years.
Right now they have a 28.8 to Brunhildeville, and hope to upgrade to 64kb
DDS in the second half of '96.  Get out of their face.

> 8. Representatives on TLD/Root administrator list are responsive:
>         8a. e-mail about required changes will be answered within 24 hours;
>         8b. vacations will cause responsibilities to be delegated, not
>             ignored;
>         8c. contact numbers, including after hours and emergency, on file 
> 	      with zone-master senior staff members;
> 	  8d. an escalation/delegation list that has at least three levels of
> 	      hierarchy.

All nice desirable things.  But the assumptions of staffing levels, etc. are
so wonderfuly <bleep> first-world arrogant that this is worth posting on one
of the lists for networking in developing countries.

> 9. Named.boot file will specify:

What's a named.boot file?  Something peculiar to VMS?

I give up.  It is not worth going further.  This has nothing to do with
running 50% of the TLD servers in the world today.  And it's tone of mandate
and arrogance precludes it being helpful technical advice to a TLD admin.

And, even were it to limit itself to non-national TLDs, I think it is
attempting to mandate operational practice without the scrutiny of the BCP
process which might ameliorate it's narrow view of the DNS as having only
one implementation and the strange limitations and peculiarities of that one
implementation.

randy