Fedora iTOps Tube

Wednesday, November 16, 2011

Sample Reverse Zone File

Sample Reverse Zone File

Now you need to make sure that you can do a host query on all your home network's PCs and get their correct IP addresses. This is very important if you are running a mail server on your network, because sendmail typically relays mail only from hosts whose IP addresses resolve correctly in DNS. NFS, which is used in network-based file access, also requires valid reverse lookup capabilities.

This is an example of a zone file for the 192.168.1.x network. All the entries in the first column refer to the last octet of the IP address for the network, so the IP address 192.168.1.100 points to the name bigboy.my-site.com.

Notice how the main difference between forward and reverse zone files is that the reverse zone file only has PTR and NS records. Also the PTR records cannot have CNAME aliases.


;
; Filename: 192-168-1.zone
;
; Zone file for 192.168.1.x
;
$TTL 3D
@       IN        SOA        www.my-site.com.  hostmaster.my-site.com. (
                            200303301          ; serial number
                            8H                 ; refresh, seconds
                            2H                 ; retry, seconds
                            4W                 ; expire, seconds
                            1D )               ; minimum, seconds

                  NS         www                ; Nameserver Address

100                PTR        bigboy.my-site.com.
103                PTR        smallfry.my-site.com.
102                PTR        ochorios.my-site.com.
105                PTR        reggae.my-site.com.

32                 PTR        dhcp-192-168-1-32.my-site.com.
33                 PTR        dhcp-192-168-1-33.my-site.com.
34                 PTR        dhcp-192-168-1-34.my-site.com.
35                 PTR        dhcp-192-168-1-35.my-site.com.
36                 PTR        dhcp-192-168-1-36.my-site.com.

I included entries for addresses 192.168.1.32 to 192.168.1.36, which are the addresses the DHCP server issues. SMTP mail relay wouldn't work for PCs that get their IP addresses via DHCP if these lines weren't included.

You may also want to create a reverse zone file for the public NAT IP addresses for your home network. Unfortunately, ISPs won't usually delegate this ability for anyone with less than a Class C block of 256 IP addresses. Most home DSL sites wouldn't qualify.

Loading Your New Configuration Files

Make sure your configuration files are in the correct locations and the serial numbers of the zone files you may have modified have been updated. If all seems correct, restart BIND named daemon for the configuration to become active.


[root@bigboy tmp]# /etc/init.d/named restart

Take a look at the end of your /var/log/messages file to make sure there are no errors.

Make Sure Your /etc/hosts File Is Correctly Updated

Chapter 3, "Linux Networking", explains how to correctly configure your /etc/hosts file. Some programs, such as sendmail, require a correctly configured /etc/hosts file even though DNS is correctly configured.


Configure Your Firewall

The sample network assumes that the BIND name server and Apache Web server software run on the same machine protected by a router/firewall. The actual IP address of the server is 192.168.1.100, which is a private IP address. You'll have to use NAT for Internet users to be able to gain access to the server via the chosen public IP address, namely 97.158.253.26. If your firewall is a Linux box, you may want to consider taking a look at Chapter 14, "Linux Firewalls Using iptables", describes how to do the network address translation and allow DNS traffic through to your name server.


Fix Your Domain Registration

Remember to edit your domain registration for my-site.com, or whatever it is, so that at least one of the name servers is your new name server (97.158.253.26 in this case). Domain registrars, such as VeriSign and RegisterFree, usually provide a Web interface to help you manage your domain.

Once you've logged in with the registrar's username and password, you'll have take two steps:

1) Create a new name server record entry for the IP address 97.158.253.26 to map to ns.my-site.com or www.my-site.com or whatever your name server is called. (This screen prompts you for both the server's IP address and name.)
2) Assign ns.my-site.com to handle your domain. This screen will prompt you for the server name only.
Sometimes, the registrar requires at least two registered name servers per domain. If you only have one, then you could either create a second name server record entry with the same IP address, but different name, or you could give your Web server a second IP address using an IP alias, create a second NAT entry on your firewall and then create the second name server record entry with the new IP address, and different name.

It normally takes about three to four days for your updated DNS information to be propagated to all 13 of the world's root name servers. You'll therefore have to wait about this amount of time before starting to notice people hitting your new Web site.

You can use the chapter's troubleshooting section to test specific DNS servers for the information they have on your site. You'll most likely want to test your new DNS server, which should be up to date, plus a few well known ones, which should have delayed values.

Sample Forward Zone File

Sample Forward Zone File

Now that you know the key elements of a zone file, it's time to examine a working example for the domain my-site.com.


;
; Zone file for my-site.com
;
; The full zone file
;
$TTL 3D
@       IN      SOA     ns1.my-site.com. hostmaster.my-site.com. (
                       200211152       ; serial#
                       3600            ; refresh, seconds
                       3600            ; retry, seconds
                       3600            ; expire, seconds
                       3600 )          ; minimum, seconds

                NS      www             ; Inet Address of nameserver
my-site.com.    MX      10 mail         ; Primary Mail Exchanger
  
localhost       A       127.0.0.1
bigboy          A       97.158.253.26
mail            A       97.158.253.27
ns1             CNAME   bigboy
www             CNAME   bigboy

Notice that in this example:

  • Server ns1.my-site.com is the name server for my-site.com. In corporate environments there may be a separate name server for this purpose. Primary name servers are more commonly called ns1 and secondary name servers ns2.
  • The minimum TTL value ($TTL) is three days, therefore remote DNS caching servers will store learned DNS information from your zone for three days before flushing it out of their caches.
  • ns1 is actually a CNAME or alias for the Web server www. So here you have an example of the name server, and Web server being the same machine. If they were all different machines, then you'd have an A record entry for each.

www                 A          97.158.253.26
ns                  A          97.158.253.125

It is a required practice to increment your serial number whenever you edit your zone file. When DNS is setup in a redundant configuration, the slave DNS servers periodically poll the master server for updated zone file information, and use the serial number to determine whether the data on the master has been updated. Failing to increment the serial number, even though the contents of the zone file have been modified, could cause your slaves to have outdated information.


Note: The DNS specification (RFC 2181) does not allow for an MX record to be a CNAME. It may work in most cases, but some mail servers may refuse to send to you because of this.

Configuring The Zone Files

Configuring The Zone Files

You need to keep a number of things in mind when configuring DNS zone files:

  • In all zone files, you can place a comment at the end of any line by inserting a semi-colon character then typing in the text of your comment.
  • By default, your zone files are located in the /var/named or /var/named/chroot/var/named or /etc/binddirectories depending on your Linux distribution.
  • Each zone file contains a variety of records (SOA, NS, MX, A, and CNAME) that govern different areas of BIND.

Take a closer look at these entries in the zone file.

Time to Live Value

The very first entry in the zone file is usually the zone's time to live (TTL) value. Caching DNS servers cache the responses to their queries from authoritative DNS servers. The authoritative servers not only provide the DNS answer but also provide the information's time to live, which is the period for which it's valid.

The purpose of a TTL is to reduce the number of DNS queries the authoritative DNS server has to answer. If the TTL is set to three days, then caching servers use the original stored response for three days before making the query again.


$TTL 3D

BIND recognizes several suffixes for time-related values. A D signifies days, a W signifies weeks, and an H signifies hours. In the absence of a suffix, BIND assumes the value is in seconds.

DNS Resource Records

The rest of the records in a zone file are usually BIND resource records. They define the nature of the DNS information in your zone files that's presented to querying DNS clients. They all have the general format:


Name    Class    Type    Data

There are different types of records for mail (MX), forward lookups (A), reverse lookups (PTR), aliases (CNAME) and overall zone definitions, Start of Authority (SOA). The data portion is formatted according to the record type and may consist of several values separated by spaces. Similarly, the name is also subject to interpretation based on this factor.

The SOA Record

The first resource record is the Start of Authority (SOA) record, which contains general administrative and control information about the domain. It has the format:


Name Class Type Name-Server Email-Address Serial-No Refresh Retry Expiry Minimum-TTL

The record can be long, and will sometimes wrap around on your screen. For the sake of formatting, you can insert new line characters between the fields as long as you insert parenthesis at the beginning and end of the insertion to alert BIND that part of the record will straddle multiple lines. You can also add comments to the end of each new line separated by a semicolon when you do this. Here is an example:


@       IN      SOA     ns1.my-site.com. hostmaster.my-site.com. (
                       2004100801      ; serial #
                       4H              ; refresh
                       1H              ; retry
                       1W              ; expiry
                       1D )            ; minimum

Table 18.4 explains what each field in the record means.

Table 18.4 The SOA Record Format

Field Description
NameThe root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particular database file.
ClassThere are a number of different DNS classes. Home/SOHO will be limited to the IN or Internet class used when defining IP address mapping information for BIND. Other classes exist for non Internet protocols and functions but are very rarely used.
TypeThe type of DNS resource record. In the example, this is an SOA resource record. Other types of records exist, which I'll cover later.
Name-serverFully qualified name of your primary name server. Must be followed by a period.
Email-addressThe e-mail address of the name server administrator. The regular @ in the e-mail address must be replaced with a period instead. The e-mail address must also be followed by a period.
Serial-noA serial number for the current configuration. You can use the date format YYYYMMDD with an incremented single digit number tagged to the end. This will allow you to do multiple edits each day with a serial number that both increments and reflects the date on which the change was made.
RefreshTells the slave DNS server how often it should check the master DNS server. Slaves aren't usually used in home / SOHO environments.
RetryThe slave's retry interval to connect the master in the event of a connection failure. Slaves aren't usually used in home / SOHO environments.
ExpiryTotal amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. Slaves aren't usually used in home/SOHO environments.
Minimum-TTLThere are times when remote clients will make queries for subdomains that don't exist. Your DNS server will respond with a no domain or NXDOMAIN response that the remote client caches. This value defines the caching duration your DNS includes in this response.

So in the example, the primary name server is defined as ns1.my-site.com with a contact e-mail address of hostmaster@my-site.com. The serial number is 2004100801 with refresh, retry, expiry, and minimum values of 4 hours, 1 hour, 1 week, and 1 day, respectively.

NS, MX, A And CNAME Records

Like the SOA record, the NS, MX, A, PTR and CNAME records each occupy a single line with a very similar general format. Table 18.5 outlines the way they are laid out.

Table 18.5 NS, MX, A, PTR and CNAME Record Formats

Record Type Name Field Class Field2 Type Field Data Field
NSUsually blank1 INNSIP address or CNAME of the name server
MXDomain to be used for mail. Usually the same as the domain of the zone file itself. INMXMail server DNS name
AName of a server in the domainIN AIP address of server
CNAME Server name aliasINCNAME "A" record name for the server
PTRLast octet of server's IP address INPTRFully qualified server name
  1. If the search key to a DNS resource record is blank it reuses the search key from the previous record which in this case of is the SOA @ sign.
  2. For most home / SOHO scenarios, the Class field will always be IN or Internet. You should also be aware that IN is the default Class, and BIND will assume a record is of this type unless otherwise stated.

If you don't put a period at the end of a host name in a SOA, NS, A, or CNAME record, BIND will automatically tack on the zone file's domain name to the name of the host. So, BIND assumes an A record with www refers to www.my-site.com. This may be acceptable in most cases, but if you forget to put the period after the domain in the MX record for my-site.com, BIND attaches the my-site.com at the end, and you will find your mail server accepting mail only for the domain my-site.com.mysite.com.

TXT Records

There is also a less frequently used DNS TXT record that can be configured to contain additional generic information. The data section of the record typically has the format "name=value", where "name" is the name to be given to the type of data, and "value" is the value assigned to the name as seen in this example.


my-web-site.org. TXT "v=spf1 -all"

TXT records are increasingly being used to help fight SPAM using the Sender Policy Framework (SPF) method. SPF TXT records are used by systems receiving mail to interrogate the DNS of the domain which appears in the email (the sender) and determine if the originating IP address of the mail (the source) is authorized to send mail for the sender's domain.

Further description of the use of TXT records is beyond the scope of this book, but you should at least be aware that they can be up to 255 characters in length and that this feature is often exploited in distributed denial of service (DDoS) attacks. The section on "Simple DNS Security" explains how to configure your DNS server to not participate in such an event.

Configuring BIND Views in named.conf

Configuring BIND Views in named.conf

Our sample scenario assumes that DNS queries will be coming from the Internet and that the zone files will return information related to the external 97.158.253.26 address of the Web server. What do the PCs on your home network need to see? They need to see DNS references to the real IP address of the Web server, 192.168.1.100, because NAT won't work properly if a PC on your home network attempts to connect to the external 97.158.253.26 NAT IP address of your Web server. Don't worry. BIND figures this out using its views feature which allows you to use predefined zone files for queries from certain subnets. This means it's possible to use one set of zone files for queries from the Internet and another set for queries from your home network. Here's a summary of how it's done:


1. If your DNS server is also acting as a caching DNS server, then you'll also need a view for localhost to use. We'll use a view called localhost_resolver for this.

2. Place your zone statements in the /etc/named.conf file in one of two other view sections. The first section is called internal and lists the zone files to be used by your internal network. The second view called external lists the zone files to be used for Internet users.

For example; you could have a reference to a zone file called my-site.zone for lookups related to the 97.158.253.X network which Internet users would see. This /etc/named.conf entry would be inserted in the external section. You could also have a file called my-site-home.zone for lookups by home users on the 192.168.1.0 network. This entry would be inserted in the internal section. Creating the my-site-home.zone file is fairly easy: Copy it from the my-site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X.

3. You must also tell the DNS server which addresses you feel are internal and external. To do this, you must first define the internal and external networks with access control lists (ACLs) and then refer to these lists within their respective view section with the match-clients statement. Some built-in ACLs can save you time:

  • localhost: Refers to the DNS server itself
  • localnets: Refers to all the networks to which the DNS server is directly connected
  • any: which is self explanatory.

Let's examine BIND views more carefully using a number of sample configuration snippets from the /etc/named.conf file I use for my home network. All the statements below were inserted after the options and controls sections in the file. I have selected generic names internal, for views given to trusted hosts (home, non-internet or corporate users), and external for the views given to Internet clients, but they can be named whatever you wish.


First let's talk about how we should refer to the zone files in each view.

Forward Zone File References in named.conf

Let's describe how we point to forward zone files in a typical named.conf file.

In this example the zone file is named my-site.zone, and, although not explicitly stated, the file my-site.zone should be located in the default directory of /var/named/chroot/var/named in a chroot configuration or in /var/named in a regular one. With Debian / Ubuntu, references to the full file path will have to be used. Use the code:


zone "my-web-site.org" {

   type master;
   notify no;
   allow-query { any; };
   file "my-site.zone";

};

In addition, you can insert more entries in the named.conf file to reference other Web domains you host. Here is an example for another-site.com using a zone file named another-site.zone.



   type master;
   notify no;
   allow-query { any; };
   file "another-site.zone";

};

Note: The allow-query directive defines the networks that are allowed to query your DNS server for information on any zone. For example, to limit queries to only your 192.168.1.0 network, you could modify the directive to:


allow-query { 192.168.1.0/24; };

Reverse Zone File References in named.conf

Here's how to format entries that refer to zone files used for reverse lookups for your IP addresses.

In most cases, your ISP handles the reverse zone entries for your public IP addresses, but you will have to create reverse zone entries for your SOHO/home environment using the 192.168.1.0/24 address space. This isn't important for the Windows clients on your network, but some Linux applications require valid forward and reverse entries to operate correctly.

The forward domain lookup process for mysite.com scans the FQDN from right to left to get to get increasingly more specific information about the authoritative servers to use. Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about an address.

The similarity in both methods is that increasingly specific information is sought, but the noticeable difference is that for forward lookups the scan is from right to left, and for reverse lookups the scan is from left to right. This difference can be seen in the formatting of the zone statement for a reverse zone in /etc/named.conf file where the main in-addr.arpa domain, to which all IP addresses belong, is followed by the first 3 octets of the IP address in reverse order. This order is important to remember or else the configuration will fail. This reverse zone definition for named.conf uses a reverse zone file named 192-168-1.zone for the 192.168.1.0/24 network.


zone "1.168.192.in-addr.arpa" {
   type master;
   notify no;
   allow-query { any; };
   file "192-168-1.zone";
};

Your patience will soon be rewarded. It's time to talk about the views! Let's go!

The Caching Nameserver localhost_resolver View

The localhost_resolver view is used for your caching DNS server configuration and should look like this:


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           { localhost; };
        match-destinations      { localhost; };

        // As your caching name server clients will be using this server
        // for DNS lookups to get to sites all over the Web you'll need to 
        // turn on recursion
        recursion yes;
  
        // All views used by caching nameserver clients must 
        // contain the root hints zone. Recursive lookups to DNS domains
        // you don't own (non-authoritative) starts here.
        zone "." IN {
             type hint;
             file "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 "/etc/named.rfc1912.zones";
 
        /*
         *  Include zonefiles for internal zones
         */
        include "/var/named/zones/internal/internal_zones.conf";
};


There are some quick facts you should be aware of with your caching name server configuration:

1. If you want your server to be only a caching DNS server, then delete all other views in named.conf and restart the named daemon.


[root@bigboy tmp]# /etc/init.d/named restart

2. Make all the other machines on your network point to the caching DNS server as their primary DNS server.

3. Remember that all DNS queries done on your DNS server appear to come from localhost. If your server is also an authoritative server for your domain, you will have to include a reference to your domain's zone files in this section for the server's own DNS lookups to work. If not, queries from clients defined by the internal and external ACLs will work correctly, but queries for the domain from the server itself will fail. In this example we have included a reference to the internal_zones.conf zone file which we'll visit again soon. This line can be deleted if your server isn't an authoritative server for your domain.

Note: If you have a localhost only view like this, make sure you don't reference localhost in any of your other views as one view will take precedence over the other for queries from your server. This could lead to unpredictable results.

The Internal View

In this example I included an ACL for network 192.168.17.0 /24 called safe-subnet to help clarify the use of ACLs in more complex environments. Once the ACL was defined, I then inserted a reference to the safe-subnet in the match-clients statement in the internal view. Therefore the local network (192.168.1.0 /24), the other trusted network (192.168.17.0), and localhost get DNS data from the zone files in the internal view.


// ACL statement

acl "safe-subnet" { 192.168.17.0/24; };

view "internal" { // What the home network will see
 
   match-clients      { localnets; localhost; safe-subnet; };
   match-destinations { localnets; localhost; safe-subnet; };

   // As your caching name server clients will be using this server
   // for DNS lookups to get to sites all over the Web you'll need to 
   // turn on recursion
   recursion yes;
  
   // All views used by caching nameserver clients must 
   // contain the root hints zone. Recursive lookups to DNS domains
   // you don't own (non-authoritative) starts here.
   zone "." IN {
        type hint;
        file "named.ca";
   };

   // These are your "authoritative" internal zones, and would probably
   // also be included in the "localhost_resolver" view above :

   /*
   *  Include zonefiles for internal zones
   */
   include "/var/named/zones/internal/internal_zones.conf";

};


The question you may have on your mind is, "Where are the zone file definitions?". Don't worry, there is an include statement that refers to a file named internal_zones.conf that contains them all as we see here:


// File internal_zones.conf

zone "1.168.192.in-addr.arpa" IN {
   type master;
   file "/var/named/zones/internal/192.168.1.zone";
   allow-update { none; };
};

zone "my-web-site.org" IN {
   type master;
   file "/var/named/zones/internal/my-web-site.org.zone";
   allow-update { none; };
};

I'll discuss how to handle queries from clients outside your trusted networks in the next section where an external view can be used.

The External View

You can also setup an external view that will be used for DNS queries from clients outside your network, such as the Internet. In this case external queries get results from zone files in the /var/named/zones/external directory.


view "external" { // What the Internet will see
 
   /* This view will contain zones you want to serve only to "external"
    * clients that have addresses that are not on your directly attached 
    * LAN interface subnets:
    */

   match-clients      { any; };
   match-destinations { any; };
 
   // you'd probably want to deny recursion to external clients, so you don't
   // end up providing free DNS service to all takers
   recursion no;

   // These are your "authoritative" external zones, and would probably
   // contain entries for just your web and mail servers:

   zone "253.158.97.in-addr.arpa" IN {
      type master;
      file "/var/named/zones/external/97.158.253.zone";
      allow-update { none; };
   };
  
   zone "my-web-site.org" IN {
      type master;
      file "/var/named/zones/external/my-web-site.org.zone";
      allow-update { none; };
   };
};

Notice that the reverse zone file gives results for public internet addresses, and of course, the forward zone file should only provide responses with Internet accessible addresses.

Note: In the external view, you may be tempted to use an exclamation mark (!) to eliminate networks used in the internal view like this. Be careful, it is best to use "any;" for your external view as the exclamation mark (!) is not honored with some versions of BIND in views named "external".


; !!! CAUTION !!!

match-clients      { !localnets; !localhost; !safe-subnet; };
match-destinations { !localnets; !localhost; !safe-subnet; };


The views listed here are purely to illustrate their use. The sample home network we have been using doesn't need to have the ACL statement at all as the built in ACLs localnets and localhost are sufficient. The sample network won't need the safe-subnet section in the match-clients line either as there is only one subnet in the configuration.

Views are also not just for NAT. If you run an Internet data center, you can set up your DNS server to act as a caching server to servers on all the Internet networks you own and no one else, and then provide authoritative responses to your customers' domains to everyone. Views can be very useful.