BIND 9.1.0 segmentation fault

[Mark.Andrews at nominum.com]

> 
> Greetings all,
> 
> I have been scouring the web for any similar incidents but haven't found
> any, so it may be only my machine, but:
> 
> I came in this morning to users complaining about slow Internet access. A
> little investigating revealed that the named process was consuming 99% of
> the CPU cycles. I stopped and started named and, while that cleared up CPU
> cycles, named failed to start at all. I don't mean it gave me an error on
> the config files or anything - it just suffers a segmentation fault and
> dies.
> 
> Here's what I have so far:
> 
> Redhat 2.0.36, BIND 9.1.0 (upgraded from 8.2.2p7) working fine for well over
> a week. This server is simply our private internal DNS - not our
> authoritative one.
> 
> Log files indicate that the last time named did anything was here:
> ----
> Feb 11 07:05:36 perrin named[485]: XX+/128.239.101.6/version.bind/TXT/CHAOS
> Feb 11 07:06:06 perrin named[485]: XX /128.239.101.6/version.bind/TXT/CHAOS
> ---

	These are BIND 8 messages.  You failed to stop the old server and
	start the new server.

	My bet is you just got hacked.

> 
> Any attempts to restart named only yield the following:
> ---
> Feb 12 12:50:09 perrin named[9123]: starting BIND 9.1.0
> Feb 12 12:50:09 perrin named[9123]: using 1 CPU
> ---
> 
> Manually running named with the -c /etc/named.conf -d 255 -g options yield
> the following:
> ---
> Feb 12 17:15:17.698 starting BIND 9.1.1rc1 -c /etc/named.conf -d 255 -g
> 
> Feb 12 17:15:18.099 using 1 CPU
> Segmentation fault
> ---
> 
> df reveals no full partitions and nothing else looks untoward.
> 
> A programmer stopped by and showed me the use of gdb which output the
> following:
> 
> gdb /usr/local/sbin/named
> GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...
> (gdb) run
> Starting program: /usr/local/sbin/named
> Linux thread target has modified Unknown signal handling
> 
> Program exited normally.
> Linux thread target has restored Unknown signal handling
> (gdb)
> 
> 
> He just shrugged and said the program exited normally. Eh? Why? It doesn't
> even seem to get to the point where it can read the conf file to decide
> whether or not its some config error.

	Linux threads suck.   Apply the kernel patch shipped with 9.1 or
	compile w/o threads 'configure --disable-threads'.  You should
	then atleast be able to see the fault.

> 
> Does anyone have any ideas? Is there some other file or software that has a
> problem with it that might affect named? And (this may be a different list
> altogether) how do you go about resolving a segmentation fault?

	Get a good stack backtrace and go from there.  Log a bug report 
	with bind9-bugs at isc.org once you have a good stack backtrace.
> 
> Oh, yes. I have tried ./configure, make clean, make, make install several
> times incase it turned out to be a corrupt binary, but no such luck.
> 
> Thanks for any clues.
> 
> C.
> 
> 
	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com