|
|
 |  |
BIND 9.2.4From: Jerry Pasker Date: Thursday, November 4, 2004
Time: 6:23:22 pmFirst, a little background:
I was migrating from QDNS 3.5.3 under Classic to QDNS+BIND (version
of the day) under OS X. Running an ISP, I used QDNS Pro for zone
serving (just over a hundred zones), and as a resolving DNS server
for my dial/broadband customers. (thousands) Having DNS problems for
me would not only bring my business to a halt, but would cause
irreparable damage to my reputation as a reliable provider. It's not
something I care to gamble with.
Not trusting BIND any further than I could throw it, (years of
experience with my Colo clients having their x86 Linux boxes Ow3d
from BIND exploits) and being totally spoiled by a DNS server who's
install was "drag over folder containing application & zone data
folder, and optionally, move a preference file with it's serial
number if moving to a new machine" I was hesitant to ever
upgrade/change since a problem with DNS grinds my entire ISP to a
halt. After years of putting up with QDNS 3.5.3's spotty stability,
(a PATHETIC 99.956% up time) I decided the pain of change was less
than the pain of status quo and decided to go down the path of BIND.
I set up a test server, and let it run for a few days, serving only a
vanity domain, and resolving only for my laptop as it's sole client.
It was painfully slow doing lookups, but after the initially lookup
would fail, or maybe succeed with a time of a few thousand
milliseconds, re querying it would be a success, and it would be
rather quick. (3-50ms) Digging, nslookup, or any type of host
resolving would yeild the same results.
Within a day of figuring this out, the posts started hitting the
mailing list about all the unixy foo-foo that can be done to "fix"
these problems. Lots of talk of "-4 options" (that would brake BIND)
and then of compiling (beta) versions of BIND that used this
"undocumented flag" These weren't fixes that inspired any sort of
confidence, what so ever. I'm a Mac guy because I want tools that
solve problems, not create them. That's why I based my ISP on on
Macs when I started it 8 years ago. If I wanted to compile things, I
would have chosen Linux years ago.
Anyway....
I decided to migrate another test machine a few days ago, and I
discovered a file in the /pub/quickdns directory on
ftp.menandmice.com, called named.macosx.noipv6.gz. The info on the
FTP server shows it dated Friday October 29th, 2004. I gunzipped
it, to find a single file, named. With all the talk of compiling
(I'm a Mac guy, remember? I *DON'T* compile my software) I killed
named, replaced my named (version 9.2.3) with this file, did a sudo
chmod 755, rebooted and did a named -v and it returned BIND 9.2.4.
My lookups are now as fast as I'd expect. Everything worked so well,
in fact, that I migrated all my DNS servers last night. It all
tested out perfectly. I haven't heard a single complaint from my
customer support department. Doing some research, I couldn't find
any real information about BIND 9.2.4, including security holes (no
news is good news, right?). If I shouldn't be using that file, I
would appreciate a reply.
This brings up a few questions:
1) Where did that file come from? I'm sure it was put there for a
reason, so I used it.
2) If it appeared there on October 29th, it would appear that Men
and Mice has an official solution to this OS X BIND problem.
2a) Why wasn't this mentioned to the list as something to try?
3) If it's just as simple as replacing named with a new named file
downloaded from menandmice's ftp server, why is there so much talk of
compiling BIND 9.3.0?
4) If it really is just that simple, why isn't there a simple disk
image with an installer that goes and replaces named with the new
named?
-Jerry
|
Messages In This Thread:- BIND 9.2.4 by Jerry Pasker on Nov 4, 2004 at 6:23:22 pm
|

Return to Digital Point Solutions' Home Page |