Problems with Authoritive name server
Mark Andrews
Mark_Andrews at isc.org
Thu Jun 15 23:35:21 UTC 2006
> 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;
> };
> };
I don't see prosall.com in the chase view.
> 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.
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list