On Wednesday, November 20, 2002, at 05:16 AM, Oden Eriksson wrote: [...]
True enough. I've not benchmarked it either. I didn't bother... how can you benchmark security? That was my main reason for switching. Performance benefits are an added bonus.Well..., I meant that to _know_ what you talking about you have to presentAs I'm not in the position to tell if bind does the job worse than
whatever else name server software I can't really say. I do have to trust
that the de facto standard name server software works. If it didn't work
you would surely be notified from a bunch of angry customers. Switching
to djbdns is not an option for me in the near future I'm afraid.
facts and tests in some form. I cannot present this because I don't know the
rfc:s by heart, I am no programmer, I do not have the skills to do the tests
neither do I have the suitable lab environment.
Again, I do trust the words of a guy that have been working many years at theOk, but then he needs to define for you what "job" he is referring to. Everyone has different needs. If the "job" is a caching DNS server for a LAN, I can unequivocally say that djbdns does the job better than bind. It is more secure, and it is faster. If the "job" is serving up DNS entries for a single host, or even multiple hosts, then I can also say that it does the job perfectly. I've been using djbdns for over a year to act as primary for over two dozen domains. It has also acted as a secondary for other bind-based nameservers; so throw another dozen domains in there. The fact that it has worked, flawlessly, without requiring an update, for over a year serving two dozen primary and a dozen secondary (and on my secondary NS, serving two dozen secondary and a dozen "third place" (don't know the expression off the top of my head) domains, tells it me it does this "job" just fine.
SE top domain that "tinydns" (part of djbdns by DJB) does not do the job
properly.
So finding out from this "expert" what "job" it is that djbdns cannot do would be very enlightening. From where I sit, the only thing djbdns doesn't do is DNSSEC and DDNS, neither of which are useful to me. DNSSEC can be avoided by using tcprules to protect access to zone transfers. Actually, IIRC, there is a different daemon that does zone transfers, so if you don't need them at all, you just don't link that daemon under supervise's control. If you do need it, use qmail-style tcprules to protect access to it.
Let me quickly describe how djbdns works, for me. On my two webservers that also act as nameservers, I run tinydns to serve up DNS information for my domains. They listen on eth0 for connections. This is *all* they do. Since I also want each server to have it's own local DNS cache (without making the local cache available externally), I run dnscache bound to the lo interface, so in resolve.conf, everything is pointing to 127.0.0.1. The outside world cannot touch my cache, which prevents poisoning my cache, a common attack. This separation of services is something that I've come to enjoy. On the other webserver, dnscache also runs bound locally.
In my LAN, I have one "controller" server which runs dnscache on eth0 for the other clients in the LAN to obtain DNS info... resolv.conf points to this IP on all client machines. I also run tinydns bound to eth0:0 to serve up information for the LAN domain (linsec.vx, a "virtual" domain), so that I can make that server authoritative for the LAN (no mucking with /etc/hosts on each client). dnscache on that server knows to look at the virtual IP for information on the linsec.vx domain. So if I change an IP or hostname, I change it in one place.
Because I've been using this setup for so long without security worries or performance issues, I'm *really* curious to know what part of this setup isn't doing the "job" properly.
I you can provide facts and tests that says otherwise, please do not hesitateActually, you're the one who must bear the burden of proof. You're the one telling the list that djbdns doesn't do the "job", yet you're not providing any facts. =)
to enlighten me.
I don't have to supply anything. I've never indicated that bind doesn't do the job. Sure it does. My issue was with ISC's tyrannical approach to "security for a price". My issue was also with bind's crappy security history. Both of these are public information... someone who tells you ISC cares about the public and the users of their software, or tells you that bind is secure software, is smoking crack. I don't need to prove this.
What *you* need to prove is how djbdns doesn't do the "job", since you've mentioned it many times now with no fact whatsoever, other than "someone you trust told me this". That's not a very persuasive argument.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
