Problems with Authoritive name server

[ly...@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.

[Barry Margolin]

In article <e6rth8$711$1...@sf1.isc.org>,
"ly...@lcrcomputer.net" <ly...@lcrcomputer.net> wrote:

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, bar...@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 ***

[Mark Andrews]

I don't see prosall.com in the chase view.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

[Barry Margolin]

In article <e6sr2d$tip$1...@sf1.isc.org>,
Mark Andrews <Mark_A...@isc.org> wrote:

> I don't see prosall.com in the chase view.

Well, that's a useless response. You're telling him something he

already knew, since he wrote:

> One of the zones
> is prosall.com and it's outside the 'chase view' below.

See my response, where I explained *why* that's a problem.

I honestly don't understand why you bother sometimes. Your frequently
terse responses often assume the poster understands the issues, but if
they did they wouldn't have gotten into the situation in the first place.

[Lyle Giese]

Barry Margolin wrote:
> In article <e6rth8$711$1...@sf1.isc.org>,
> "ly...@lcrcomputer.net" <ly...@lcrcomputer.net> wrote:
>
>

> 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";
//***********************

};

[smal...@juno.com]

ly...@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.

2006050101 ; serial
How are you updating serial numbers when you make changes?

[Lyle Giese]

smal...@juno.com wrote:

> ly...@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.
>
>

> 2006050101 ; serial
> How are you updating serial numbers when you make changes?
>
>

These are manual zones that we hand edit. They don't change very often.
Looks like I touched it last on May 1, 2006 for some reason.

Lyle

[Fredrik Söderlund]

On Thursday 15 June 2006 22.40, you wrote:

> ly...@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.
>

> 2006050101 ; serial
> How are you updating serial numbers when you make changes?

Whit the possibility to sound real stupid
but what you meant is when you change you're Zone it wouldent change to the
slaves ore other either if you don't change to a higher amount value on
yyyymmdd ; serial

20060521 ; serial # the next time you edit it ore yast it
20060522 ; serial # ore otherwise it wouldent change it only would bee the
cashed zone that being forwarded in other words it wont read the new
records....

Refuards Fille
--
Keep emotionally active. Cater to your favorite neurosis.