Problems with Authoritive name server

[lyle at lcrcomputer.net]

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.

Thanks in advance,
Lyle

Here's the pertient portions of named.conf from linux.lcrcomputer.com:

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 "xxxxxxxxxxxxxxxxx";
};
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"; };
};
view "external" {
    match-clients {any;};

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


Here's named.conf from one of the caching name servers:

acl "internal" {
        10.0.0.0/8; 127.0.0.0/8; 209.112.84.0/28; };
options {
        statistics-file"/etc/named/named.stats";
        allow-transfer { "internal"; } ;
        allow-recursion { "internal"; };
        directory "/etc/named";
        pid-file "named.pid";
        auth-nxdomain no;
        version "Hello from Chase Products";
        listen-on { 10.0.100.237; 209.112.84.13; 127.0.0.1; };
        notify-source 209.112.84.13;
};
logging {
          category "lame-servers"
                 { "null";};
};

        key rndc_key{
        algorithm hmac-md5;
        secret "xxxxxxxxxxxxxxxxxxx";
};
controls{
        inet 127.0.0.1 allow{
                localhost;
        }       keys{
                rndc_key;
        };
};


One of the 'affected' zones:

$ORIGIN .
$TTL 86400    ; 1 day
prosall.com        IN SOA    linux2.lcrcomputer.com. 
hostmaster.lcrcomputer.com. (
                2006050101 ; serial
                10800      ; refresh (3 hours)
                3600       ; retry (1 hour)
                604800     ; expire (1 week)
                86400      ; minimum (1 day)
                )
            NS    linux.lcrcomputer.com.
            NS    mail2.lcrcomputer.net.
            NS    linux2.lcrcomputer.com.
            A    209.112.84.9
            MX    10 127.0.0.1.
$ORIGIN prosall.com.
www            CNAME    prosall.com.