clueing in TLD registries for delegations to non-BIND servers

At 5:40 PM +0100 2003/02/11, Stefan Paletta wrote:

>  Bait not taken; rest assured, my choice of nameserver software has
>  never hindered any registration (at least not yet) and I will never
>  hesitate a second to cheat around useless requirements if necessary.

	If you choose to "cheat around requirements" that you consider to 
be useless, do not be surprised if you find yourself summarily 
disconnected and treated as a true net.pariah.

>  I believe that diversity of software is actually a strong requirement
>  for the stability of the Internet (but then I'm not geeting paid by a
>  company that makes and sells nameserver software---SCNR!) and I
>  welcome the effort RIPE has made to contribute to that.

	As far as this statement goes, I think everyone on this list will 
agree -- regardless of who their employer may or may not be.  Before 
you casually dismiss us, you should at least check to see if we 
actually support whatever it is that you abhor so much.

	Throwing mud at people you do not know sufficiently well to 
determine whether or not they agree or disagree with your statements 
is not a particularly effective manner of convincing people that 
you're right.

>                                                          A simple,
>  reliable and fast nameserver that groks BIND zonefiles is a good thing
>  to have. What concerns me, though, is a possible limitation of use-
>  fulness of NSD and I would expect RIPE to actually care about that,
>  too (I am aware that this list is not authoritative wrt. this).

	One of the fundamental design criteria for nsd was to eliminate 
all possible operations that were not strictly required for the 
proper functioning of a TLD nameserver.  However, this does limit the 
functionality of nsd with regard to regular authoritative functioning.

>  Anyway, just let me know if that is not the case and I will shut up.
>  (Though I might then -- at another place -- raise the question why
>  RIPE is purposely wasting my money making nameserver software that is
>  not usable for domains in some TLDs.)

	This is a design choice made by the authors.  I don't think 
there's any chance of getting them to change their minds about 
eliminating all functions not strictly necessary for a TLD nameserver.

>  It is entirely reasonable. Altough I firmly believe Darwinism is much
>  better in selecting those who know DNS and those who don't, actively
>  giving people clues about how to do it right is probably more within
>  the spirit of the Internet.

	Regretfully, there are many people who can cause much damage to 
the DNS and the Internet as a whole, without actually being 
eliminated themselves.  This is kind of the same problem as you have 
with drunk drivers -- they usually cause far more damage to others 
than to themselves.

>                                                            i.e. people
>  can screw up in wonderful ways once a zone has been delegated anyway.

	Sure, that's always possible.  Indeed, this sort of problem is 
possible in most human endeavours.

	However, it's also possible for people like Rob Thomas or someone 
else to put into place procedures that will periodically check for a 
variety of DNS configuration problems, and then we can publicly name 
and shame them.  There's little more we can do, but there is at least 
the chance that this might do some good.

>  I was not asking for anyone to dictate policy at all. It is just that
>  registries have a habit of not listening to their customers (esp. not
>  those who apparently cannot get their nameserver to work 'correctly').
>  That is where a RIPE document at least gives people something in their
>  hands to take to a registry and (hopefully) make them listen.

	Things like this are also useful to take to program authors who 
insist on implementing b0rken behaviour in their software, just 
because they think it's right.

>  For example quite a few registries have the requirement for at least
>  two independent nameservers and that those have addresses not within
>  the same /24. This can be replaced by one completely different re-
>  quirement that, in contrast, is revisable, enforcable and actually
>  useful. By all means, if someone wants to hear I will be happy to
>  write this up and have it discussed and, for that matter, proven wrong.

	I would be curious to know what your proposed alternative is.

-- 
Brad Knowles, <brad.knowles at skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)