The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Are these entries supposed to be in named.conf?

Discussion in 'General Discussion' started by Metro2, Oct 18, 2008.

  1. Metro2

    Metro2 Well-Known Member

    Joined:
    May 24, 2006
    Messages:
    376
    Likes Received:
    10
    Trophy Points:
    18
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    I have two dedicated cPanel servers using DNS Clustering with my own nameservers/dns and after encountering an issue with a couple of accounts on one box yesterday, I noticed some major differences in their respective named.conf files, and also what appears to be two problems. I know this is a long thread but the only way to explain is to give as much detail as possible. If anyone has the patience to check this out I would really appreciate it, as I'm not getting very far on my own.

    For the sake of example/explanation in this thread I'll just call the boxes "hostname1.example.com" and "hostname2.example.com"

    hostname1.example.com handles ns1.example.com and ns3.example.com

    hostname2.example.com handles ns2.example.com and ns4.example.com

    Both are running latest cPanel "Release", RHEL 4, Apache 2.2.6, PHP 5.2.6, mySQL 5.0.51a, BIND 9.2.4

    DNS Clustering handles the trust relationship between the two boxes and both are set to "Synchronize Changes" in Clustering Config.

    On hostname1.example.com the named.conf looks like this (the X's in trusted represent the IP addresses on BOTH servers):

    Code:
    include "/etc/rndc.key";
    
    controls {
            inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };
    };
    
    acl "trusted" {
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            127.0.0.1;
    };
    
    options {
        /* make named use port 53 for the source of all queries, to allow
             * firewalls to block all ports except 53:
             */
    
        // query-source    port 53;
    
        /* We no longer enable this by default as the dns posion exploit
            has forced many providers to open up their firewalls a bit */
    
        // Put files that named is allowed to write in the data/ directory:
            directory "/var/named";
            version "not currently available";
            allow-recursion { trusted; };
            allow-notify { trusted; };
            allow-transfer { trusted; };
            dump-file "/var/named/data/cache_dump.db";
            statistics-file "/var/named/data/named_stats.txt";
            /* memstatistics-file     "data/named_mem_stats.txt"; */
    };
    
    zone "." IN {
            type hint;
            file "/var/named/named.ca";
    };
    
    zone "localdomain" IN {
            type master;
            file "/var/named/localdomain.zone";
            allow-update { none; };
    };
    
    zone "localhost" IN {
            type master;
            file "/var/named/localhost.zone";
            allow-update { none; };
    
    };
    
    zone "0.0.127.in-addr.arpa" IN {
            type master;
            file "/var/named/named.local";
            allow-update { none; };
    };
    
    zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
            type master;
            file "/var/named/named.ip6.local";
            allow-update { none; };
    };
    
    zone "255.in-addr.arpa" IN {
            type master;
            file "/var/named/named.broadcast";
            allow-update { none; };
    };
    
    zone "0.in-addr.arpa" IN {
            type master;
            file "/var/named/named.zero";
            allow-update { none; };
    };
    
    zone "hostname1.example.com" {
            type master;
            file "/var/named/hostname1.example.com.db";
    };
    
    
    THEN MY CUSTOMER DOMAIN/ACCOUNT ZONES BEGIN...
    
    On hostname2.example.com the named.conf looks like this (the X's in trusted represent the IP addresses on BOTH servers):

    Code:
    include "/etc/rndc.key";
    
    controls {
            inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
    };
    
    acl "trusted" {
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            xx.xxx.xx.xxx;
            127.0.0.1;
    };
    
    options {
        /* make named use port 53 for the source of all queries, to allow
             * firewalls to block all ports except 53:
             */
    
        // query-source    port 53;
    
        /* We no longer enable this by default as the dns posion exploit
            has forced many providers to open up their firewalls a bit */
    
        // Put files that named is allowed to write in the data/ directory:
            directory "/var/named";
            version "not currently available";
            allow-recursion { trusted; };
            allow-notify { trusted; };
            allow-transfer { trusted; };
            dump-file "/var/named/data/cache_dump.db";
            statistics-file "/var/named/data/named_stats.txt";
            /* memstatistics-file     "data/named_mem_stats.txt"; */
    };
    
    logging {
    /*      If you want to enable debugging, eg. using the 'rndc trace' command,
     *      named will try to write the 'named.run' file in the $directory (/var/named).
     *      By default, SELinux policy does not allow named to modify the /var/named directory,
     *      so put the default debug log file in data/ :
     */
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
    };
    
    // All BIND 9 zones are in a "view", which allow different zones to be served
    // to different types of client addresses, and for options to be set for groups
    // of zones.
    //
    // By default, if named.conf contains no "view" clauses, all zones are in the
    // "default" view, which matches all clients.
    //
    // If named.conf contains any "view" clause, then all zones MUST be in a view;
    // so it is recommended to start off using views to avoid having to restructure
    // your configuration files in the future.
    
    view "localhost_resolver" {
    /* This view sets up named to be a localhost resolver ( caching only nameserver ).
     * If all you want is a caching-only nameserver, then you need only define this view:
     */
        match-clients         { 127.0.0.0/24; };
        match-destinations    { localhost; };
        recursion yes;
    
        zone "." IN {
            type hint;
            file "/var/named/named.ca";
        };
    
        /* these are zones that contain definitions for all the localhost
         * names and addresses, as recommended in RFC1912 - these names should
         * ONLY be served to localhost clients:
         */
        include "/var/named/named.rfc1912.zones";
    };
    
    view "internal" {
    /* This view will contain zones you want to serve only to "internal" clients
       that connect via your directly attached LAN interfaces - "localnets" .
     */
        match-clients        { localnets; };
        match-destinations    { localnets; };
        recursion yes;
    
        zone "." IN {
            type hint;
            file "/var/named/named.ca";
        };
    
        // include "/var/named/named.rfc1912.zones";
        // you should not serve your rfc1912 names to non-localhost clients.
    
        // These are your "authoritative" internal zones, and would probably
        // also be included in the "localhost_resolver" view above :
    
    
    THEN CUSTOMER DOMAIN/ACCOUNT ZONES BEGIN
    As you can see the named.conf files start out very different from each other, but the main differences I'm concerned about are:

    1. named.conf on hostname1.example.com contains a bunch of ARPA zone entires, while named.conf on hostname2.example.com does not contain any ARPA zone entries. Are those ARPA zone entries supposed to be there?

    2. hostname2 contains a LOGGING section while hostname1 does not. Also, hostname2 mentions something about SElinux, but I believe I have SElinux disabled. Should I remove the logging section from hostname2 or add it to hostname1, or neither?

    3. hostname2 contains - view "localhost_resolver" , view "internal" , and include "/var/named/named.rfc1912.zones" - sections, while hostname1 does not. Should I remove these sections from named.conf on hostname2, or add these sections to named.conf on hostname1, or neither?

    4. BOTH named.conf files contain a zone entry for "hostname1.example.com" but NEITHER named.conf files contain a zone entry for "hostname2.example.com". Should a zone entry for hostname2 be added to each named.conf file?

    5. Up until yesterday, when I started experiencing a problem with a couple customers who could not access sites on hostname2, there should typically be about 414 zones on hostname2. I ran /scripts/rebuildnsdzones as part of my troubleshooting process and now if I do "service named status" at shell it says "number of zones: 833" instead of 414. Seems like there is a duplicate named or something running. It still reports 414 zones in WHM DNS Cleanup, but say 833 in shell command. Any idea if this is a corrupt file that I can somehow fix?

    6. Also up until yesterday when I would run DNS Cleanup from WHM from either box, it would say "Cleaned up 420 zone(s) on hostname1. Cleaned up 414 zone(s) on hostname2". But now when I run DNS Cleanup from WHM on either box it says "Cleaned up 0 zone(s) on hostname1. Cleaned up 414 zone(s) on hostname2." Why would running DNS Cleanup in WHM suddenly start showing "0" zones for hostname1?

    At this point I'm very nervous that something could be very wrong, and I don't understand why the named.conf files on my two DNS Clustered servers are so different. I'm willing to pay for the proper assistance, but (and I hate to say this) I'm afraid to pay for such service at my data center because of the completely conflicting opinions/advice I've received from different techs there on even simpler issues recently.

    I'm hoping and praying that someone here can please help set me straight on what might be going on with this. A huge HUGE thank you to anyone willing to take a stab at replying to this and comparing my two named.conf partial sections shown above. My next step will likely be to submit a ticket to cPanel, which I don't like to do unless it's extremely necessary because I know they're very busy.
     
    #1 Metro2, Oct 18, 2008
    Last edited: Oct 18, 2008
Loading...

Share This Page