BIND 9.2.1 - experiments on stubs and listen-to

[Joseph S D Yao]

I have been trying to run some experiments to see how BIND 9.2.1 acts,
for use on firewalls, but I have run out of time to do experiments.  As
I might have saved time in the first place by asking if anyone has
actually tried these experiments [rather than looking at the code and
seeing what it should do], I'd like to ask and see.

First experiment:  Can a single view run "listen-on"ing only one of
multiple Ethernet interfaces?

Hypothesis:  Observing that the "listen-on" option is only in the
generic options{} statement and not documented [or in the code] as
being accepted in a view{} statement, I hypothesize that the actual
running 'named' will reject the latter configuration.  If set to
listen-on{any;}; [default], but only accept-query{} from some ACL that
only includes IP addresses on one of two network interfaces, I further
hypothesize that 'named' will accept connections on ALL Ethernet
interfaces, but will only respond to queries from one.

Procedure:  Run 'named' from BIND 9.2.1 on a multi-homed system with
different workstations on networks attached to the different Ethernet
interfaces.  Configure it in the different ways mentioned in the
hypothesis.  For those configurations that are accepted, attempt to
connect to port 52 from different Ethernet interfaces, and attempt to
do queries from the different Ethernet interfaces.

Conclusion:  If these hypotheses are correct, then to set up a generic
configuration that will not even answer on one or more Ethernet
interfaces, one must do a listen-on{} for the whole configuration,
carefully excluding those interfaces to be shunned [and remembering to
include 127.0.0.1!], and then carefully parse out which view{}
statements accept queries from which IP addresses.  This could be a
pain.  Alternately, the generic configuration should advise running one
'named' process per Ethernet interface to be used, also a pain.  The
question remains which is the lesser pain.  ;-)  If these hypotheses
were not correct, one would have to modify the advised generic
configuration.

Second experiment:  If I am running an internal "stub" server pointing
to an internal domain, and the domain name is also served [with
different information] on the outside, and the internal server goes
down or is inaccessible for any amount of time, will the cache for the
firewall 'named' be contaminated by the external DNS?

Hypothesis:  No hypothesis.  Under the given conditions, either the
name server will stop returning valid information, or it will be
contaminated with external information, as used to happen with BIND 4
under a slightly different configuration.

Procedure:  THIS ONE I TRIED, with surprising results.  I set up a name
server (an old SparcStation 5 running Linux and BIND 8.1.2) to serve
fake zone "tux.org" with internal (RFC 1918) IP addresses.  All the
times in the SOA were set to 10 seconds except for expire, which was
set to 20 seconds.  I also gave it the root.cache file, including our
proxy-only firewall IP address in it.
I also set up a test name server running BIND 9.2.1.  It had:
zone "tux.org"  IN      {
	type stub;
	masters { 198.81.161.69; };
	file "stub.tux";
};
as well as our usual forwarders [firewall], forward-only, etc.

Observation:  I got the external addresses.  I changed the zone above
to "tux.edu" [which does not exist in the outside world], and got no
replies.  On the test BIND 9.2.1 name server I progressively turned off
"forward only", and then all the forwarders, and still had this
problem.  I observed that the data was AXFR'ed over initially, but was
NOT being requested every 10 seconds or even every 20 seconds.  And the
fact that the NS and SOA information was brought over and stored in the
"stub.tux" file did not seem to mean that BIND 9.2.1 could give me any
information based on this data.

Conclusion:  If stub zones keep from being contaminated, they will be
cleaner than forwarding to internal name servers (I can't delegate, as
they have different parent domains).  If not, or if I can't figure out
how to do stub zones at all, I will keep on forwarding.

Sorry to make this so long, but I wanted to give you all relevant
information.  Any thoughts?

Thanks!

--
Joe Yao				jsdy at center.osis.gov - Joseph S. D. Yao
OSIS Center Systems Support					EMT-B
-----------------------------------------------------------------------
	    PLEASE ... send or Cc: all "OSIS Systems Support"
		     mail to sys-adm at center.osis.gov
-----------------------------------------------------------------------
   This message is not an official statement of OSIS Center policies.