First? TRUE Root Name Server On Line

Jim Fleming JimFleming at unety.net
Sun Nov 24 01:20:24 UTC 1996


On Saturday, November 23, 1996 1:58 PM, Jamie[SMTP:jamie at dilbert.multiverse.com] wrote:
@ Jim "Beam me up" Fleming wrote:
@ > 
@ > What do you suggest as a constructive solution ?
@ > 
@ > 	1. Would TCP wrappers satisfy you ?
@ 
@ It's your network security you have to worry about. Not me.
@ TCP wrappers in coordination with the appropriate filters, restrictions,
@ etc., are desirable.
@ 
@ > 	2. or, do you think those services should not
@ > 		even be in the inetd repetoire ?
@ 
@ Correct.
@ 
@ > Also, have you checked all of the 9 "popular" root
@ > name servers ? Do they conform to your requirements ?
@ 
@ Yes.
@ 
@ Here's a little chart from a three minute discovery.
@ 
@ Server		chargen	echo	daytime	discard	smtp	telnet
@ a		no	no	no	no	no	no
@ b		no	no	no	no	no	no
@ c		yes	yes	yes	yes	no	[2]	:(
@ d		no	no	no	no	no	[3]
@ e		no	no	no	no	yes	[2]
@ f		[1]	[1]	[1]	[1]	[1]	[1]
@ g		no	no	no	no	no	no
@ h		no	no	no	no	no	yes
@ i		yes	yes	yes	yes	no	yes	:(
@ 
@ [1] This service is filtered at the upstream router (Yay)
@ [2] Service is running, but wrappered
@ [3] Service is running, but with "go away" warnings.
@ 
@ 
@ > Can you provide a summary of ALL of the requirements
@ > that you would like to see for a root name server ?
@ 
@ Not really, but off of the top of my head I can think of a few things..
@ 
@ - The server should be running a release of its operating system that
@   has been tested and is known to be stable.  The server should not
@   be running an operating system known to have a history of security
@   holes, or "new" operating systems.
@ 
@ - The server should optimally have no less than two points out to the Internet,
@   and should be on a network no more than two hops from a major backbone.
@ 
@ - The server should not be running "small tcp" or "small udp" services,
@   such as daytime, echo, chargen, comsat,  etc.
@ 
@ - The server should not be running any larger tcp services, such as
@   ftp, exec, r*, uucp, tftp, etc. .  If this is a requirement for
@   distribution of the data files, hosts allowed in should be filtered
@   at the upstream router as well as via TCP wrappers.
@ 
@ - At the upstream, the router should not be running small services, should
@   have source routing disabled and access lists to prohibit anyone other
@   than people coming from a select list of authorized hosts at the root
@   nameserver.  The root nameserver also would optimally be on its own
@   small subnet to only include the server itself and the default
@   route up (255.255.255.252).
@ 
@ - The machine should not be an open machine : All non-essential accounts
@   on the system should be removed, and no users other than root domain name
@   administrators should be allowed access.
@ 
@ - The machine should have at least one redundant power supply in case of
@   emergency, should have an immediate uninterruptible power supply and
@   conditioner, and should optimally have some sort of "long term"
@   power backup , such as a diesel generator.
@ 
<trim addresses>


Jamie,

This is truly a fine piece of work. I hope that you continue
to refine your analysis of not only the 9 "popular" Root Name
Servers but all of the Root Name Servers.

The discussion on the "newdom" list, at one time was focused
on the simple objective of configuring more Root Name Servers
around the world. Maybe this can be a kick-start to help get
everyone refocused on that objective.

Thanks for the fine work. I am working on a web site to help
people learn more about name servers. It is temporarily at
the following address, <http://www.unety.net/Platform>.
If you do not mind, I will be happy to incorporate some of
your points.

If you ever develop a web site, showcasing your analysis
talents, let me know. I can add a link and I think that everyone
would benefit from the work that you have done.

Thanks again, for the nice reply.

--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL

e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)






More information about the NANOG mailing list