BIND 9.2.1 - experiments on stubs and listen-to

[Mark_Andrews at isc.org]

> 
> 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?

	Yes.

	Use match-destination to select the traffic for the view.
	listen-on must include the interface.
 
> 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.

	Well you needed to override the global forwarding.

	zone "tux.org" {
		type stub;
		masters { 198.81.161.69; };
		file "stub.tux";
		forwarders { /* empty */ };
	};
 
> 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.
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org