On Wednesday, November 20, 2002, at 11:51 AM, Oden Eriksson wrote: [...]
What else did you think I cared about? Performance for lookups isn't as much of an issue... I'd gladly wait an extra second or two for a lookup to complete if the software was secure.Aha! I didn't realize we were speaking _security_ only, I may have beenTrue 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.
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.
[...]
No, not at all. But I would hope you would question what you were told. Simply telling you that "tinydns can't do the job" without anything to explain why isn't very effective. At least I've told you what tinydns *can* do, and mentioned it's limitations. I've not made any blanket statements without providing proof, or at least personal experience (I realize I haven't provided proof of djbdns being faster than bind... but having used both, I can notice a difference, and if I can notice it, then it isn't trivial).So finding out from this "expert" what "job" it is that djbdns cannotWell..., I have known this "expert" (electronically) since my early FIDONET
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.
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?
I never implied he wasn't experienced. I quoted "expert" in that you hadn't made any claims to his expertise. But I never said that he couldn't be, or wasn't, experienced. Please don't try to make this sound like I am attempting to dictate to you what you should or should not do with your systems. Hell, it's *your* system. You're the one who has to continually worry about the security of your system, and whether or not ISC will even disclose the problems to you (which seems questionable these days). That "luxury" is one I cannot afford. If others feel they can afford it, by all means, continue to use it. Quite frankly, I don't care what you use. I don't even care if you upgrade to the latest patched versions. Use an unpatched bind8 or bind4 for all I care. It does not impact *me* what *you* do on *your* system. *I* am not the one who has to deal with ISC (other than providing updates for people like you).
If you want to make this sound like an attempted religious conversion, be my guest. That has never been my intention. Obviously, djbdns is not for everyone. All the GUI-loving commandline-abhoring folk out there probably wouldn't touch it. People without the capacity or desire to learn something new probably won't touch it either. People who can't possibly conceive of running anything other than bind also probably won't. If you fit into one of those categories, good for you. If not, make another one and stick yourself in it. I'd be just as happy if you switched to dents or maradns. Would I cry if you didn't? Not at all. Please don't make it sound like I would.
I think so. If it didn't work, or only worked half-assed, I wouldn't use it.Good that it works for you.
[...]
Well, not brilliant, but it does do the job. And the only time to even think about it is when adding a new machine to the network or changing hostnames, etc. Normal maintenance.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,Why? Too much work? I already told you that using axfr-get makes this simple. I'm assuming that these 3000 hosts don't each run bind, so you're looking at one machine. One system to update. With some shell scripting and using axfr-get, I could do this in 2 hours.
and let me see... (checking...) 200+ zones to djbdns...
[...]
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. =)
[...]
No, you are wrong, I do not have to prove or provide anything. I will not evenHey, whatever you feel like providing is satisfying enough. I am not currently unsatisfied. I'd like to know why he feels tinydns couldn't do the job, yes, but it doesn't impact how *I* use it. I know for fact that it does "the job", for me, just fine. You're the one who is trying to indicate that it can't do the job without providing the basis for that statement. Again, the burden of proof is up to you. You are making a blanket statement that may or may not (probably not) be accurate. If you would like me to listen to you, and have me (and everyone else on this list) understand how you came to the conclusion that tinydns cannot do the job, then you must provide that information. I can't provide the evidence of *your* conclusion for you.
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?
And you're right. This is silly. So until you've got the info from your friend as to why tinydns does such a piss poor job of what bind can do so well, I really don't think this has to go any further, as it's not overly constructive.
You don't have the time to go hunting down supporting facts for your argument, and I don't have time to debate something that is unfounded. We're both probably too busy for that.
--
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
