Problems with Authoritive name server

[Barry Margolin]

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.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***