Justin Shore wrote:
> I wasn't going to post all of this to the full list but I'm hurting for 
> a solution right now so I will.
>
> Unfortunately I can't hand it out unmodified.  I don't want the acls 
> known for one thing.  Here's what I'm using on the master.  The slave is 
> a near mirror copy only it includes files that loads slave versions of 
> the config for each zone.
>
> //
> // named.conf for Red Hat caching-nameserver
> //
>
> options {
>          directory "/var/named";
>          dump-file "/var/named/data/cache_dump.db";
>          pid-file "/var/run/named/named.pid";
>          statistics-file "/var/named/data/named_stats.txt";
>          memstatistics-file "/var/named/data/named.memstats";
>          zone-statistics yes;
>
>          allow-transfer {
>          // The hosts in the "xfer" ACL are permitted to perform zone 
> transfers
>                  xfer;
>          };
>
>          allow-query {
>          // This change prevents non-SKT IPs from making recursibe queries.
>          // Queries from our zones are permitted in the views below.
>                  skt;
>          };
>
>          blackhole {
>                  none;
>          };
>
>          version "SKT DNS";
>
>          notify no;
>          transfer-format many-answers;
>          max-transfer-time-in 60;
>          interface-interval 0;
>
>          /*
>           * If there is a firewall between you and nameservers you want
>           * to talk to, you might need to uncomment the query-source
>           * directive below.  Previous versions of BIND always asked
>           * questions using port 53, but BIND 8.1 uses an unprivileged
>           * port by default.
>           */
>           // query-source address * port 53;
> };
>
> //  ###  ACLs  ###
> acl "xfer" {
>          // "xfer" contains the hosts that are allowed to do zone transfers
>          // Must be in full CIDR notation.
>          127.0.0.1/32;
>       //MUNGED
>          };
>
> acl "skt" {
>          // "skt" contains all public and private hosts that may make 
> DNS queries
>          127.0.0.1/32;
>       //MUNGED
>          };
>
> acl "skt-ns" {
>          // "skt-ns" contains the IPs of the name servers allowed to 
> request zone transfers
>          127.0.0.1/32;
>       //MUNGED
>          };
>
> //
> // a caching only nameserver config
> //
> controls {
>          inet 127.0.0.1 allow { localhost; } keys { rndckey; };
> };
>
> include "/etc/named/rndc.key";
>
> logging {
>          category lame-servers { null; };
>          category edns-disabled { null; };
>          };
>
>
>
> //  ###  VIEWS  ###
> // BEGIN "trusted" view
> view "trusted" in {
>          // Our internal (trusted) view. We permit the internal networks
>          // to freely access this view. We perform recursion for our
>          // internal hosts, and retrieve data from the cache for them.
>
>          match-clients { skt; };
>          recursion yes;
>          additional-from-auth yes;
>          additional-from-cache yes;
>          provide-ixfr yes;
>          allow-transfer { skt-ns; };
>
>          ixfr-from-differences yes;
>          notify yes;
>
>          // Provide root hints
>          zone "." IN {
>                  type hint;
>                  file "named.ca";
>          };
>
>          // default-zones.conf contains all default zones with transfers
>          // and updates disabled and queries enabled from "any".
>          include "/etc/named/default-zones.conf";
>
>          include "/etc/named/skt-forward-master.conf";
>          include "/etc/named/skt-reverse-master.conf";
>
>          include "/etc/named/customer-forward-master.conf";
>
> };
> // END "trusted" view
>
> // BEGIN "non-trusted" view
> view "non-trusted" in {
>          // Our internal (non-trusted) view. We permit the internal networks
>          // to freely access this view. We perform recursion for our
>          // internal hosts, and retrieve data from the cache for them.
>
>          match-clients { any; };
>          recursion no;
>          additional-from-auth no;
>          additional-from-cache no;
>
>          allow-query { any; };
>          allow-transfer { skt-ns; };
>          ixfr-from-differences yes;
>          provide-ixfr yes;
>
>          // Provide root hints
>          zone "." IN {
>                  type hint;
>                  file "named.ca";
>          };
>
>          // default-zones.conf contains all default zones with transfers
>          // and updates disabled and queries enabled from "any".
>          //include "/etc/named/default-zones.conf";
>
>          include "/etc/named/skt-forward-master.conf";
>          include "/etc/named/skt-reverse-master.conf";
>
>          include "/etc/named/customer-forward-master.conf";
>
>          //include "/etc/named/spyware-domains.conf";
> };
> // END "non-trusted" view
>
> // BEGIN "non-trusted-chaos" view
> view "non-trusted-chaos" chaos {
>          // Our internal (non-trusted-chaos) view. We permit the 
> internal networks
>          // to freely access this view. We perform recursion for our
>          // internal hosts, and retrieve data from the cache for them.
>
>          match-clients { any; };
>          recursion no;
>
>          // Provide root hints
>          zone "." {
>                  type hint;
>                  file "/dev/null";
>          };
>
>          zone "bind" {
>                  type master;
>                  file "db.bind";
>
>                  allow-query { skt; };
>                  allow-transfer { none; };
>          };
>
> //      include "/etc/named/skt-forward-master.conf";
> //      include "/etc/named/skt-reverse-master.conf";
>
> //      include "/etc/named/customer-forward-master.conf";
>
> };
> // END "non-trusted-chaos" view
>
>
>
>
> I include a number of additional conf files in the config. 
> default-zones.conf has localhost, localdomains, 127/8 in-addr.arpa, etc. 
>   skt-forward-master.conf has the forward lookup zones and reverse has 
> the rDNS zones.  Here's a snapshot of the forward (which appears to be 
> working ok at this time):
>
> zone "brdadsl.sktc.net" {
>          type master;
>          allow-transfer { skt-ns; };
>          file "skt/skt-zones/brdadsl.sktc.net.master";
> };
>
> zone "brdcable.sktc.net" {
>          type master;
>          allow-transfer { skt-ns; };
>          file "skt/skt-zones/brdcable.sktc.net.master";
> };
>
>
> It's just a long list of zones being loaded like that.  Here's a small 
> snapshot of the rDNS zones' config:
>
> zone "64.71.96" {
>          type master;
>          allow-transfer { skt-ns; };
>          file "skt/skt-zones/in-addr.arpa/64.71.96.master";
> };
>
> zone "64.71.97" {
>          type master;
>          allow-transfer { skt-ns; };
>          file "skt/skt-zones/in-addr.arpa/64.71.97.master";
> };
>
> zone "64.71.98" {
>          type master;
>          allow-transfer { skt-ns; };
>          file "skt/skt-zones/in-addr.arpa/64.71.98.master";
> };
>
> It's basically the same too.  I don't see any glaring mistakes in my 
> in-addr.arpa zones either.  I found and fixed a few typos this morning 
> but nothing severe enough to keep bind from loading.  Here's the zone 
> that contains the servers I'm doing the testing from:
>
>
> ;       @(#)97.rev      5.1 (Berkeley) 6/30/90
> $TTL    6h
> @       IN      SOA     ns3.sktc.net.   ip-admin.sktice.com.    (
>
>                                  2008110702      ; Serial
>                                  7200            ; Refresh (2 hours)
>                                  300             ; Retry (5 minutes)
>                                  360000          ; Expire (100 hours)
>                                  900     )       ; Minumum (15 minutes)
>
>
> ;;97.71.64.in-addr.arpa.        IN      NS      ns1.sktc.net.
> ;;                      IN      NS      ns2.sktc.net.
>
>          IN      NS      ns3.sktc.net.
>          IN      NS      ns4.sktc.net.
>
> 1       IN      PTR     3750-1.clr.sktc.net.
>
> 6       IN      PTR     ns3.sktc.net.
>
> ;;12    IN      PTR     maple.sktc.net.
> 10      IN      PTR     maple.sktc.net.
> 12      IN      PTR     oak1.sktc.net.
> 13      IN      PTR     oak2.sktc.net.
> 14      IN      PTR     oak-old.sktc.net.
> ;15     IN      PTR     spruce.sktc.net.
> 15      IN      PTR     smtpout1.sktc.net.
> 16      IN      PTR     poplar.sktc.net.
> 17      IN      PTR     oak-1.sktc.net.
> 18      IN      PTR     noc.sktc.net.
>
> 22      IN      PTR     server1.daxolomix.com.
>
> 25      IN      PTR     smtpout1.sktc.net.
> 26      IN      PTR     smtpout1.sktc.net.
> 27      IN      PTR     smtpout1.sktc.net.
> 28      IN      PTR     smtpout1.sktc.net.
>
> 50      IN      PTR     7206-1.clr.sktc.net.
> 51      IN      PTR     3660-1.clr.sktc.net.
>
> 66      IN      PTR     7206-2.clr.sktc.net.
> ;67     IN      PTR     3660-2.clr.sktc.net.
>
> 68      IN      PTR     5300-1.clr.sktc.net.
> 69      IN      PTR     5300-2.clr.sktc.net.
>
>
> Pretty basic stuff.  The MTA in question is a Barracuda spam filter so I 
> don't have much of any details on it (other than that it's a POS).  It's 
> not a Cuda problem though.  That Nagios SMTP check on the Cuda was just 
> the thing that clued me in that there was a problem.  rDNS is affecting 
> everything, not just this one box.  We have a Hosted Exchange 
> environment that is affected plus all our customer-run MTAs.  If it 
> wouldn't take so long to process I'd have ARIN switch the records back. 
>   I didn't anticipate a problem with rDNS since all the forward lookups 
> were working so well for all these months on the same servers.  rDNS 
> never appeared be having any problems.
>
> I also gathered some debugging info.  Here's the pertinent output of a 
> query from the NS itself to the NS for 64.71.97.18:
>
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: UDP request
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: view trusted: using 
> view 'trusted'
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: view trusted: request 
> is not signed
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: view trusted: recursion 
> available
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: view trusted: query
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: view trusted: query 
> (cache) '18.97.71.64.in-addr.arpa/PTR/IN' approved
> 07-Nov-2008 08:58:18.547 client 127.0.0.1#33324: view trusted: replace
> 07-Nov-2008 08:58:18.547 clientmgr @0xb7f5a1e0: createclients
> 07-Nov-2008 08:58:18.547 clientmgr @0xb7f5a1e0: recycle
> 07-Nov-2008 08:58:18.547 createfetch: 18.97.71.64.in-addr.arpa PTR
> 07-Nov-2008 08:58:18.547 client @0xb5644008: udprecv
> 07-Nov-2008 08:58:18.547 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> create
> 07-Nov-2008 08:58:18.547 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> join
> 07-Nov-2008 08:58:18.547 fetch 0xb4d18000 (fctx 
> 0xb4c42008(18.97.71.64.in-addr.arpa/PTR)): created
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> start
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): try
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> cancelqueries
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> getaddresses
> 07-Nov-2008 08:58:18.548 dns_adb_destroyfind on find 0xb546a6f0
> 07-Nov-2008 08:58:18.548 dns_adb_destroyfind on find 0xb546a6f0
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> no addresses
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> done
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> stopeverything
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> cancelqueries
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> sendevents
> 07-Nov-2008 08:58:18.548 fetch 0xb4d18000 (fctx 
> 0xb4c42008(18.97.71.64.in-addr.arpa/PTR)): destroyfetch
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> shutdown
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> doshutdown
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> stopeverything
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> cancelqueries
> 07-Nov-2008 08:58:18.548 client 127.0.0.1#33324: view trusted: error
> 07-Nov-2008 08:58:18.548 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> destroy
> 07-Nov-2008 08:58:18.548 client 127.0.0.1#33324: view trusted: send
> 07-Nov-2008 08:58:18.548 client 127.0.0.1#33324: view trusted: sendto
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: senddone
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: next
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: endrequest
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: UDP request
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: using 
> view 'trusted'
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: request 
> is not signed
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: recursion 
> available
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: query
> 07-Nov-2008 08:58:18.549 client 127.0.0.1#33324: view trusted: query 
> (cache) '18.97.71.64.in-addr.arpa/PTR/IN' approved
> 07-Nov-2008 08:58:18.550 client 127.0.0.1#33324: view trusted: replace
> 07-Nov-2008 08:58:18.550 clientmgr @0xb7f5a1e0: createclients
> 07-Nov-2008 08:58:18.550 clientmgr @0xb7f5a1e0: recycle
> 07-Nov-2008 08:58:18.550 createfetch: 18.97.71.64.in-addr.arpa PTR
> 07-Nov-2008 08:58:18.550 client @0xb429b008: udprecv
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> create
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> join
> 07-Nov-2008 08:58:18.550 fetch 0xb4d18000 (fctx 
> 0xb4c42008(18.97.71.64.in-addr.arpa/PTR)): created
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> start
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): try
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> cancelqueries
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> getaddresses
> 07-Nov-2008 08:58:18.550 dns_adb_destroyfind on find 0xb546a6f0
> 07-Nov-2008 08:58:18.550 dns_adb_destroyfind on find 0xb546a6f0
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> no addresses
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> done
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> stopeverything
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> cancelqueries
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> sendevents
> 07-Nov-2008 08:58:18.550 fetch 0xb4d18000 (fctx 
> 0xb4c42008(18.97.71.64.in-addr.arpa/PTR)): destroyfetch
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> shutdown
> 07-Nov-2008 08:58:18.550 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> doshutdown
> 07-Nov-2008 08:58:18.551 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> stopeverything
> 07-Nov-2008 08:58:18.551 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> cancelqueries
> 07-Nov-2008 08:58:18.551 fctx 0xb4c42008(18.97.71.64.in-addr.arpa/PTR'): 
> destroy
> 07-Nov-2008 08:58:18.551 client 127.0.0.1#33324: view trusted: error
> 07-Nov-2008 08:58:18.551 client 127.0.0.1#33324: view trusted: send
> 07-Nov-2008 08:58:18.551 client 127.0.0.1#33324: view trusted: sendto
> 07-Nov-2008 08:58:18.551 client 127.0.0.1#33324: view trusted: senddone
> 07-Nov-2008 08:58:18.551 client 127.0.0.1#33324: view trusted: next
> 07-Nov-2008 08:58:18.551 client 127.0.0.1#33324: view trusted: endrequest
>
> To be honest I'm not exactly sure what most of this means.  I'm not 
> familiar with the innards of bind.
>
>
> Any ideas?  I can't find anything wrong in my zone files or my config. 
> I must be missing something though.  All rDNS queries result in a 
> SERVFAIL error.
>
>   

You can't just load these zones with arbitrary origins, e.g."64.71.97". 
If the reverse lookups you want to serve are for addresses in the 
64.71.97.* range, you'll need to load the reverse zone as 
97.71.64.in-addr.arpa, otherwise it won't match the last 5 labels of the 
reverse queries you're receiving.

                                                                         
                  - Kevin


Reply via email to