Colin Humphreys was once rumoured to have said:
> Crossfire wrote:
> > djbdns is not really suitable for use on public DNS servers.
> 
> Could you please explain why? I have been using djbdns on various public
> dns servers for well over a year. I have never had any problems.

What, apart from the licensing, the fact the author is an idiot who
thinks he knows whats best?

What about the fact you need to set up and maintain lots of little
processes which make life harder to trace failures through?  What
about using the ZONE format (the same format used globally elsewhere)? 
What about the fact that tinydns only implements a subset of the DNS
protocol that djb arbitarily decided was all that you need?

[What? tinydns's format is easier to read?  I'm sorry, it bears no
 resemblence to any piece of DNS data I've ever seen]

djb slanders BIND practice using examples of human stupidity and
blaming BIND and its process for it.  (Read the FAQ and read about
assigning different names to your zone's nameservers than listed in
the parent zone).

He slanders .de for enforcing that you host your DNS servers on
seperate subnets without mentioning why they would do such a thing.
[Why? its best practice with public DNS - otherwise you might as well
have only one nameserver since when your network connection fails or
looses route, nobody will be able to contact your nameservers anyway].

Sorry, djb, would you kindly stop tripping on your own ego so much?
What you're promoting is far from good practice.

>> That, and it doesn't cache [it relies upon dnscache to do that],
>> which makes it moderately useless.
> 
> Why? Whats wrong with relying on dnscache? You can run dnscache on the
> loopback, and make djbdns available on the external interface. If you
> want a external cache, use ip aliasing. Its just different.

Whoa? IP *aliasing*!  thats a luxury, not a given.  You won't always
have IP space to do such things in.  And the fact you need to use an
IP alias is just plain *wrong*.

>> It also doesn't support AFXR, which means you'll be manually
>> updating your secondaries.  It is on my "not recommended list".  >
>
> um, yes it does. Thats some of the secondaries I administer get
> updated.

Ok, after deeper diging, I'll concede this - but it means *another*
daemon you have to run, which only understands AFXR.  Still, PITA to
administer I'm sure.

Of course, he flags AFXR as obsolete - never mind that its standard
operating practice, and will continue to be so until something better
is universally supported.


Like I said, if he didn't public crap, I wouldn't be offended.

If he wants his stuff to be accepted, then he should sit through what
the rest of us have to and post RFCs detailing new protocols, and then
convince people that they should be implemented, rather than just
blindly going off and pushing out semi-compatible implementations as
being superior secure implementations.

What? this practice sounds famaliar to you?  

What? From a company in redmond?...

C.
-- 
--==============================================--
  Crossfire      | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==============================================--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Reply via email to