Few Questions

[Jim Reid]

>>>>> "Mark" == Mark Miller <mmiller at unix.sprint.net> writes:

    Mark> First of all I am trying to compile BIND 8.2.1 for Solaris
    Mark> 2.7.  I change the Makefile.set in /src/port/solaris to have
    Mark> DESTETC and DESTRUN both be "/etc".  When I compile and try
    Mark> to run the binary, in.named fails to start because the link
    Mark> for /usr/local/etc/named.conf doesn't exist.  We NFS mount
    Mark> /usr/local, so I need to have the above changes to take
    Mark> effect since /etc is local to the machine.  Is there another
    Mark> file that I need to change in order to have these changes
    Mark> take effect.  I have removed ".settings" and ran "make
    Mark> clean", but to no avail.

It looks like you have screwed up the installation. Start again from
clean source. You probably want to change the locations of DESTETC and
DESTRUN in port/solaris/Makefile.set *before* you do a "make links"
followed by a compile.

The value of DESTETC is used at compile time to hard-wire the default
directory for named.conf. [Take a look at pathtemplate.h and
pathnames.h in your-build-dir/bin/named.] For Solaris, that is
/usr/local/etc. So if /usr/local/etc/named.conf doesn't exist, your
BIND8 name server won't start because that's where it expects to find
its config file. You could use the -c argument to tell named to use
something other than this default pathname for its config file.

It's probably not a good idea to make the name server NFS mount things
that are needed for DNS service. That makes your name server dependent
on your file server, which introduces a whole set of new trouble
sources. I guess that's why you're trying to get everything installed
in /etc on the server's local file system?

    Mark> Second question, is there a way to tell BIND which interface
    Mark> to use on a given machine.  I have a nameserver with an hme0
    Mark> and hme1 interface.  Does BIND randomly choose an interface?

By default BIND8 will listen on all the system's network interfaces.
It will periodically the system for changes, adding or removing
interfaces that have come up or come down. Outgoing queries will use
whatever interface is best - ie the one with the lowest routing metric
(hop count) - to reach the remote server. So depending on the
stability of your network's routing tables, the address used can be
effectively "random": whatever happened to be the best choice at the
time the packet was sent.

These defaults can be over-ridden with through the options{} statement
in named.conf. Take a look at the html directory in the doc tarball.
options.html tells you about the listen-on, interface-interval and
query-source directives. These can be used to control which network
interfaces the name server listens for requests, how often it scans
for new interfaces and what address/port number it uses for outgoing
queries.

    Mark> The reason I ask is because I have the allow-transfer set up
    Mark> in the options statement so all zones have the same acl.
    Mark> All zones seem to use the hme0 interface except one which
    Mark> uses hme1.  I know this because /var/adm/messages complains
    Mark> about unapproved AXFR for the zone due to acl.

I think I know what you mean here. One of the zone's slave name
servers connects to the address of interface hme1 when it transfers
the zone, not hme0. Well, that's decided my the masters{} entries for
that zone on the slave server's named.conf or whatever the file is
called on that slave (secondary) server. If you tell it to use the IP
address of hme1 on the master server, the slave will try that IP
address when it checks SOA records and does zone transfers. Do you
*really* only want zone transfers to only use one of the name server's
network interfaces? What if that fails? And meantime, there's another
interface that's up and running which could be used if only the other
servers knew about it and were allowed to reach it.

Personally, I think ACLs on zone transfers and queries are a waste of
time and effort. [Why should anything care which address is used by a
slave server for transferring a zone? What difference does it *actually*
make?] It doesn't really make things "more secure". It does make the
DNS administration harder, for sure. Witness your problems with an ACL
that's denying access to presumably valid zone transfers.