Re: in-addr.arpa problem - DNS

This is a discussion on Re: in-addr.arpa problem - DNS ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: in-addr.arpa problem

  1. Re: in-addr.arpa problem

    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.

    Thanks
    Justin



  2. Re: in-addr.arpa problem

    In article ,
    Justin Shore wrote:

    > 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";
    > };


    Those are not the correct names for in-addr.arpa zones. They should be:

    zone "96.71.64.in-addr.arpa" ...
    zone "97.71.64.in-addr.arpa" ...
    and so on.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***


+ Reply to Thread