To get things started

Below I'll make a comparison with what you state in
your message and the situation on ns.EU.net.

	First let me summarize:
		Regarding manpower, not very much is needed in hours, more
		in alertness.
Clear, but part of it can be automated.
		And when looking at hardware, a SparcStation 1 with 500M
		disk and 16M memory will do.
See below.
		The crucial point is the connectivity, this must be good,
		otherwise there is not much use adding one more root server.
Speaks for itself.

	1) manpower
		...the only thing that must be done/checked is to pickup the
		new zone files from nic.ddn.mil (with ftp, zone-transfers
		won't do). This can be made with a script (a mail message is
		sent when the new files are available), even if I prefer to
		do it manually as the transfer fails every now and then (or
		the zone files themself can be corrupt/ truncated).
		....
This can mostly be reliably automated; it's comparable
to how ns.EU.net constructs its named.boot file every
night from -amongst other things- a list of domains it
runs secondary for and that it receives from uunet.

	2) hardware
		NIC.NORDU.NET is a SparcStation 1, and this works nice (we
		tried an ELC, but that didn't really work, don't know if it
		was the e-net interface or what, but it didn't really manage
		the load).
Interesting, but:
		If it is only used for the name server, I would say that 16M
		memory will do, BIND tends to get big, lots of cache.
Maybe it will do for a machine that runs *only* root
server, but not if it has to run primary/secondary for
a bunch of other domains too. By comparison: ns.EU.net
is an ELC; it runs BIND 4.8.3; it runs primary/secondary
for some 1700 domains; the SIZE and RSS are around 10M
on the average but can go well above 15M; queries/day
average between 200,000 and 1,200,000.
Crucial point is swapping, which has to be avoided at
all cost. Which means 16M of memory just isn't enough,
especially when you take into consideration that things
like zone transfers by secondary servers off ns.EU.net
cause the named process to fork off *the complete core
image*. Even the current 24M in ns.EU.net isn't enough
to cope with that, so we're about to upgrade it to 40M
of memory.



	Piet