in-addr.arpa problem
Kevin Darcy
kcd at chrysler.com
Fri Nov 7 22:58:31 UTC 2008
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
More information about the bind-users
mailing list