onsdagen den 20 november 2002 18.14 skrev Vincent Danen: > On Wednesday, November 20, 2002, at 05:16 AM, Oden Eriksson wrote: > > [...] > > >>> As 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. > > > > Well..., I meant that to _know_ what you talking about you have to > > present > > 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. > > 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.
Aha! I didn't realize we were speaking _security_ only, I may have been unclear. The only reason for me _not_ to ditch bind has nothing to do with security. If I was speaking security I would ditch bind, I would be using djbdns. > > Again, I do trust the words of a guy that have been working many years > > at the > > SE top domain that "tinydns" (part of djbdns by DJB) does not do the > > job > > properly. > > Ok, 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. > > 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. Well..., I have known this "expert" (electronically) since my early FIDONET years (since '93?). This guy has handled the swedish top domain (.se) for several years, maybe thousands, ten thousands or even hundred thousands of domain names. Wouldn't you say that is some sort of DNS experience? Do you really mean I should trust your word instead of his, no matter what? Good that it works for you. > 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. Brilliant! At this time I don't dare converting my clients 3000+ hosts, 12 C class nets, and let me see... (checking...) 200+ zones to djbdns... > 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 > > hesitate > > to enlighten me. > > Actually, 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. =) > > 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. No, you are wrong, I do not have to prove or provide anything. I will not even consider spending time hunting this information just becasue you seems to want to force me to. This is silly. I will however ask this "expert" next time I get an hold on him, is that satisfying enough for you? Chears. -- Regards // Oden Eriksson, Deserve-IT Networks Check the "Modules For Apache2" status page at: http://www.deserve-it.com/modules_for_apache2.html
