Problems with Authoritive name server

[Lyle Giese]

Barry Margolin wrote:
> In article <e6rth8$711$1 at sf1.isc.org>,
>  "lyle at lcrcomputer.net" <lyle at lcrcomputer.net> wrote:
> 
> 
>>I am having a problem with Bind on a couple of Linux systems.  Various
>>Linux distributions involved, all have Bind 9.3.2 installed from source. 
>>It would
>>appear that an authoritive name server is not responding with the A 
>>record when
>>the zone is not in it's memory cache.  It's possible that it's somthing 
>>in my config,
>>but I certainly cann't see it.
>>
>>I have one customer that has about 60 domains, mostly to cover their
>>trade names in the .com TLD.  I am having some problems with resolving
>>some of these names and have been able to duplicate the sympton via +trace.
>>
>>I host the DNS here at LCR and they have their own web & email servers
>>and I setup Bind 9.3.2 as caching name servers at their site.  Because
>>of their size and their internal security concerns all users surf via
>>proxy servers.  We found that sometimes, the proxy servers would report
>>a DNS failure resolving one of their domain names that are in-frequently
>>used.  The local named was reporting no A record.  Doing
>>'dig @linux.lcrcomputer.com <domainname.com>', it would respond with the
>>A record.  Doing an flush via rndc on the local caching server, now the 
>>local
>>named would resolve the ip address for the A record.  What the???
>>
>>I started doing some traces using DIG and found that if I picked one of
>>these infrequently accessed domains, sure enough, the authoritive name
>>server at Linux.lcrcomputer.com, would report the NS records for the
>>zone, but not report back the ip address of the A record.  Trace would
>>then loop back to the root servers, walk back to linux.lcrcomputer.com,
>>get no A record and loop back until we get the 'too many hops' error and
>>bail out.
>>
>>Then if I did a dig @linux.lcrcomputer.com <domainname.com>, I would get
>>the A record back and then immediatly redoing the dig +trace 
>><domainname.com>,
>>I now get the A record with IP address from linux.lcrcomputer.com while
>>doing dig +trace !?!
>>
>>1) linux.lcrcomputer.com should be doing recursive queries for the
>>queries coming from the ip addresses at my customer.
>>
>>2) linux.lcrcomputer.com should be authoritive for <domainname.com>, but
>>was not giving back the A record unless that zone was in it's cache when 
>>hit with dig +trace.
>>
>>3) Is this even a meanfull test for this problem?
>>
>>I am not sure where to take this or if it's a bug in Bind or if I am 
>>fighting a different problem.
>>
>>The remote site is Chase Products and it's public range is 
>>209.112.84.0/28.  One of the zones
>>is prosall.com and it's outside the 'chase view' below.
> 
> 
> You need to put the zone inside the chase view.  Here's what's happening:
> 
> Your server receives a query for something in prosall.com.  The client 
> matches the chase view, so it looks in the view's configuration.  It 
> doesn't find the zone, so the server cannot answer authoritatively.  The 
> view says that recursion is allowed, so it starts to recurse by querying 
> a .com server.  The NS records in this response include 
> linux.lcrcomputer.com -- but when a server is given a delegation to 
> itself, it's obviously an error (since the delegation implies that the 
> server should be authoritative, and if it were authoritative it wouldn't 
> have recursed in the first place).
> 
> The chase view should contain all your public zones, in addition to all 
> the private zones that are used just for chase.
> 

Includes work just fine here.  Then it's just one place to put the zones 
both views have in common. Just have to specifically name the zone(s) 
that are seperate in each view and put the rest in a single file.

Thanks,
Lyle

acl "internal" {
	192.168.0.0/32; 209.172.152.0/24; 127.0.0.1; 209.112.84.0/28; 
209.112.65.13; 209.172.128.0/24; 168.103.151.8/29; 209.172.165.9; 
65.104.164.252; };
options {
	statistics-file"/home/lyle/perl/named.stats";
	allow-transfer { "internal"; } ;
	allow-recursion { "internal"; };
	directory "/usr/local/named";
	pid-file "named.pid";
	auth-nxdomain no;
	version "Hello from LCR Computer";
	query-source address 209.172.152.2;
	listen-on { 209.172.152.2; 127.0.0.1; };
	notify-source 209.172.52.2;
};
logging {
	category "lame-servers"
		{ "null";};
};
key rndc_key{
	algorithm hmac-md5;
	secret "xxxxxxxxxxxxxxxxxxxxxx";
};
controls{
	inet 127.0.0.1 allow{
		localhost;
	}	keys{
		rndc_key;
	};
};
view "chase" {
	//Internal Chase Products use only.
	match-clients { 209.112.84.0/28; 209.172.165.9; };
	//Provide recursive service to Chase.
	recursion yes;
	// Provide internal view of chaseproducts.com zone
	zone "chaseproducts.com" {
		type master;
		file "db.chaseproducts.com.internal"; };
	zone "100.0.10.in-addr.arpa" {
		type master;
		file "db.10.0.100"; };
	zone "78.0.10.in-addr.arpa" {
		type master;
		file "db.10.0.78"; };

	//************************
	include "public.zones";
	//************************

};
view "external" {
	match-clients {any;};

zone "." {
	type hint;
	file "db.cache";
};
zone "chaseproducts.com"{
	type slave;
	file "db.chaseproducts.com";
	masters{
		209.172.152.3;
	};
};

//************************
include "public.zones";
//***********************

};