diff. between 9.3.2 and 9.2.6

[Dixon, Justin]

I have gotten BIND-9.3.2 running on an AIX 5.3 host in a chroot jail
after a week or two of attempts. The biggest issue I ran into were
permissions inside the jail and ensuring that there was a /tmp in the
jail that the user named was running under could write to.

Also make sure that you config files are in the correct place for
BIND-9.3.2 and that the user named is running under can read them. If
you compiled from source with no options, named will look for named.conf
in /usr/local/etc/ so you either need a link to /etc/named.conf or move
the config file to /usr/local/etc/. Of course if you have BIND running
in a chroot all of this is relative to the jailed directory...


Justin Dixon
justin.dixon at bbandt.com
 
-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Chris Buxton
Sent: Friday, July 28, 2006 16:32
To: Jaap Akkerhuis
Cc: pui ming Wong; comp-protocols-dns-bind at isc.org
Subject: Re: diff. between 9.3.2 and 9.2.6


On Jul 28, 2006, at 12:33 PM, Jaap Akkerhuis wrote:

>
>     Since your configuration worked with 9.2.6, the only thing I  
> know of
>     that would cause 9.3.2 to fail, given the exact same command line
>     parameters as you used with 9.2.6, is that 9.3 re-implements  
> syntax
>     checking. So if you, for example, used an underscore in any of  
> your
>     zones, or any other invalid character, BIND 9.2 wouldn't mind, but
>     9.3 would.
>
>     To easily test this, add the following substatement to your  
> options
>     statement:
>
>     	check-names master warn;
>
>     Then see if version 9.3.2 will start.
>
> It will be much better to run named-checkzone and named-checkconfig
> and find what the problem is with the zonefile and/or configuration
> file.

My suggestion was intended to isolate the problem to a check-names  
issue. If that doesn't solve it, then the re-introduction of check- 
names in 9.3 isn't the problem, and he should be looking for  
something else.

Also, if there are a lot of zones, your suggestion would lead to a  
lot of uses of named-checkzone. Quite tiresome and possibly error- 
prone. My suggestion would lead to a complaint in the log file  
(assuming messages are being logged somewhere) indicating the zone(s)  
and the problem(s). The admin can then determine what to do for each  
problem, rather than using a brute-force method to find (or possibly  
not find) errors.

named-checkzone is great if you've just modified a single zone. For  
this particular case, it would not be my first choice.

Chris Buxton
Men & Mice