...but this one's important. contact me at home (paul@vix.com) if nec'y.
Not to disrespect Mr. Vixie, or detract from the operational content
of the original post, but I'd like to recommend another solution to
these recently reported security holes in BIND: install djbdns
<http://www.djbdns.org/>.
-adam
Or DENTS <http://sourceforge.net/projects/dents/>, created by the
Mindspring technical team, spearheaded by Todd Lewis, whom I think is
hearabouts.
Certainly there are many approaches to DNS, and as several people have
mentioned this month, genetic diversity in service provision, especially
DNS, and most especially Root DNS, is A Good Thing.
Thanks, though, to Paul for the heads up; I'd missed the announcement
through other channels, and I'm pretty sure at least one breakin in
my last 6 months came through a BIND hole.
Cheers,
-- jra
asr@latency.net (Adam Rothschild) writes:
Not to disrespect Mr. Vixie, or detract from the operational content
of the original post, but I'd like to recommend another solution to
these recently reported security holes in BIND: install djbdns
<http://www.djbdns.org/>.
No disrespect taken. The README for 8.2.3 says:
Note that BIND 8 is in "end-of-life", having been replaced by BIND 9.
See http://www.isc.org/ for more details.
And indeed, BIND 9 has been in preparation for several years, has been in an
extended test release phase for the last 6 or 8 months, and with the release
of 9.1.0 a few weeks ago, is a far better choice than BIND 8.2.3 for most
systems. It's also compatible with BIND 8's configuration file syntax.
BIND 9's server shares not a single line of code with BIND 8's. So if genetic
diversity is what's worrying anybody, please check out BIND 9.1.0. But if you
just want the BIND 8 you already have (except, without certain security flaws)
then BIND 8.2.3 is just what you need.
Cool. Major version number bump; complete rewrite. That's the way
it's supposed to work.
Paul? Quick one sentence version of how far from "drop-in" the upgrade
is?
Cheers,
-- jra
Paul? Quick one sentence version of how far from "drop-in" the upgrade
is?
I just upgraded a server, and didn't have to change a line of config...
Jeff
That consitutes "good enough for me", I guess. 
Cheers,
-- jra
the only thing that I had to do when upgrading between 8.x and 9.x was at
add $TTL line to the top of every zone file.
/Vince
Without being aware of what your disclosure policies are, I'll go ahead
and ask... what are the flaws, and are they also in 8.2.2-p7?
I don't see anything at:
http://www.isc.org/products/BIND/bind-security.html
that mentions p7. Sure, I could diff a bunch of stuff...
Sorry to bring this to NANOG, but it's a bit more appropriate than gabbing
about what a root server is. Also, note that Bugtraq is gone until
Monday, so there'll be no talk of this there.
Thanks,
Charles
vince@penguin-power.com ("Vincent Power") writes:
the only thing that I had to do when upgrading between 8.x and 9.x was at
add $TTL line to the top of every zone file.
BIND 8.2.3 makes you do that, too.
Somebody asked about an in-place upgrade from BIND 8.x to BIND 9.1.0
(sorry I purged some mails before their time). Just for the sake of
readiness, be aware that there are some 8.x options which are unsupported
in 9.x. I did an in-place upgrade and had to make a few (mostly
insignificant) changes which may be problematic for larger sites.
http://www.isc.org/products/BIND/docs/config/options.html is the online
reference for the 8.x server
The global config entries I had to remove were:
fake-iquery yes
returns the original query as the answer when Inverse Query is
issued (rare). it was mostly useful for ancient versions of
nslookup, and probably is not used by anybody now. I used it for
testing purposes. I don't know if 9.x supports inverse queries
or not. No loss either way.
multiple-cnames yes
allows a domain name entry to have multiple CNAME references,
this is often used by sites to fake load distribution algorithms.
should not be used by anybody, but is anyway. I used it for
testing purposes. I would guess that 9.x finally gave up on
this legacy ghost. No loss for me, will be problematic for some,
despite all of the well-intentioned warnings.
rfc2308-type1 yes
from the online docs: If yes, the server will send NS records
along with the SOA record for negative answers. You need to set
this to no if you have an old BIND server using you as a
forwarder that does not understand negative answers which
contain both SOA and NS records or you have an old version of
sendmail. The correct fix is to upgrade the broken server or
sendmail. The default is no.
I had this enabled for testing purposes, but I can't remember
exactly why now. It may have been for compatibility testing
with some older servers but I can't remember. According to the
options document it should be allowed but 9.1.0 bitched about
it. No problems yet so no loss yet.
check-names slave ignore
lets you load a zone that contains A records with "illegal"
hostnames. the "slave ignore" paramater is needed with 8.x
in order to secondary for Active Directory (AD breaks the law
on allowable characters in hostnames by assinging an A record
with the AD domain name, especially annoying since a lot of
people want to use that A record for web activities). 8.x was
overly conservative in this regard (sometimes an A is not a
hostname), 9.x doesn't seem to stop you from defining A records
with illegal hostnames so no loss.
maintain-ixfr-base true
used to keep a transaction journal for incremental transfer
operations (IXFR). I haven't gotten IXFR tested out yet with
9.1.0 but apparently this is automagic now. the option is
listed as obsolete and is not recognized so I am probably
doing something wrong (or nsupdate is still broken).
There are lots of obsolete entries so an in-place upgrade for complex
configs really needs to be tested first. Also note that named.conf man
pages are not in the 9.1.0 build, so "man named.conf" will most likely
reuse your 8.x docs, which won't jive with the 9.1.0 options.
[ On Monday, January 29, 2001 at 01:36:42 (-0800), Eric A. Hall wrote: ]
Subject: Re: sorry to ruin several of your evenings...
Somebody asked about an in-place upgrade from BIND 8.x to BIND 9.1.0
(sorry I purged some mails before their time). Just for the sake of
readiness, be aware that there are some 8.x options which are unsupported
in 9.x. I did an in-place upgrade and had to make a few (mostly
insignificant) changes which may be problematic for larger sites.The global config entries I had to remove were:
fake-iquery yes
multiple-cnames yes
rfc2308-type1 yes
check-names slave ignore
maintain-ixfr-base true
That's just the beginning!
Jan 29 13:37:46 proven /usr/pkg/sbin/named[22298]: option 'memstatistics-file' is not yet implemented
Jan 29 13:37:46 proven /usr/pkg/sbin/named[22298]: the default for the 'auth-nxdomain' option is now 'no'
Jan 29 13:37:46 proven /usr/pkg/sbin/named[22298]: option 'host-statistics' is not yet implemented
Jan 29 13:37:46 proven /usr/pkg/sbin/named[22298]: option 'use-id-pool' is obsolete
Jan 29 13:37:46 proven /usr/pkg/sbin/named[22298]: option 'check-names' is not implemented
Jan 29 13:37:47 proven /usr/pkg/sbin/named[22298]: unknown logging category 'os' ignored
Jan 29 13:37:47 proven /usr/pkg/sbin/named[22298]: unknown logging category 'parser' ignored
Jan 29 13:37:47 proven /usr/pkg/sbin/named[22298]: unknown logging category 'load' ignored
Jan 29 13:37:47 proven /usr/pkg/sbin/named[22298]: unknown logging category 'panic' ignored
Jan 29 13:37:47 proven /usr/pkg/sbin/named[22298]: unknown logging category 'packet' ignored
Jan 29 13:37:47 proven /usr/pkg/sbin/named[22298]: unknown logging category 'eventlib' ignored
I don't yet know if "host-statistics" is still necessary to be able to
see the source of an RR in a dump file, or not, but if so then that'll
be a road-block in keeping me from using 9.1.0 in production.
I'm also very partial to 'check-names'. I've been happy using the
following in many locations:
check-names master fail;
check-names slave fail;
check-names response fail;
Even more critically the old 'ndc' program has been replaced by 'rndc',
which won't work until you've configured it (/etc/rndc.conf) *and* you
add "controls" statements to your /etc/named.conf to allow it to
connect, authenticate, and send commands. There doesn't seem to be a
default way of setting it up for local-only control. I haven't done
this yet
Even worse than that the new BIND-9 'named' not only doesn't handle
signals in the same way as previous versions, but it shuts down instead
of ignoring SIGINT (which used to generate a dump file, which is why
I've not yet successfully generated and viewed a dump file to see if the
source of the RR is recorded in there!). So:
WARNING: Anyone with scripts or other programs that use signals
(i.e. kill(1), or kill(2)) to control their named process will almost
certainly have to re-code to work with BIND-9 (and use 'rndc' and/or its
mechanisms)!
You'll also find that the new named-checkconf fails if you use:
options {
directory "/etc/namedb";
};
and then try to do something like:
include "named-rfc1918.conf";
include "named-slave.conf";
include "named-master.conf";
However the named process itself does seem to do the
chdir("/etc/namedb") before trying to do the "include"s,
and if you start named-checkconf from within the right
directory it'll work....
I recommend reading bind-9.1.0/doc/misc/options from the bind9
distribution, it explains what is implemented, isnt
implemented, or is obsolete.
Matthew S. Hallacy
XtraTyme Technologies
It complains about the absence of $TTL, but it doesn't "make you do it".
How many other sites got burned by non-RFC compliant SOA record formats
that used to work in every prior bind 8 / bind 4 version? I refuse to
believe I'm the only one. I had to write a pair of little perl scripts
and a bourne shell script to examine all our zone files and fix the ones
that needed fixing.
Oh, the regexes were many and nasty. I was burned back on my personal
nameserver a month or so ago on the 9.0.0 release, and fixed it by hand.
The 300 or so domains hosted on the work machines.. well, gross regexes.
You're bitching that you had to go back and do things the way they
should have been done in the first place?
Help me understand where you think Paul, or any of the ISC peoples,
is at fault?
Quit reading between the lines. You're not doing very well at it.
I didn't post that I was pissed at Paul for breaking bind. He was nice
enough to email me back over the weekend to explain the problem and say
that basically the fact that the broken zones ever worked was a long
standing bug in bind's zone parser.
I was just curious how many other people ran into the same problem.
Based on the responses I got, I definitely wasn't alone.
On the same topic but not in reply to anyone in particular, I thought this
should be mentioned:
[root@host bind-9.1.0]# dig @a.bind9.nameserver.com authors.bind chaos txt
; <<>> DiG 8.2 <<>> @a.bind9.nameserver.com authors.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; authors.bind, type = TXT, class = CHAOS
;; ANSWER SECTION:
authors.bind. 0S CHAOS TXT "Michael Sawyer"
authors.bind. 0S CHAOS TXT "Brian Wellington"
authors.bind. 0S CHAOS TXT "Andreas Gustafsson"
authors.bind. 0S CHAOS TXT "Bob Halley"
authors.bind. 0S CHAOS TXT "Mark Andrews"
authors.bind. 0S CHAOS TXT "James Brister"
authors.bind. 0S CHAOS TXT "Michael Graff"
authors.bind. 0S CHAOS TXT "David Lawrence"
;; Total query time: 1 msec
;; FROM: host to SERVER: a.bind9.nameserver 192.168.0.1
;; WHEN: Tue Jan 30 14:00:54 2001
;; MSG SIZE sent: 30 rcvd: 244
While it's not exactly a problem, it does give away that you're running
bind9 (I do like the new 'version' option where you can set the
version.bind reply) even if you change the version to appear to be a bind8
server.
Matthew S. Hallacy
XtraTyme Technologies
Systems/Network Administrator