| In this section we'll create the zone files that will be used on both the master and slave servers that control our domain. First, let's look at the format that the zone files are based on, which is known as the Standard Resource Record Format (RR, for short). Several RRs have been defined, but we'll only use a few more common ones here, some of which are shown in Table 16.4. As with everything in computing, this list is expanding. For example, there are now resources that allow you to embed geographic positioning data for each host and others that let you embed digital signatures in the zone files. Table 16.4. Common Resource RecordsResource Record | Record Name | Resource Record | Record Name |
|---|
SOA | Start of Authority | HINFO | Host Info | NS | Name Server | AAAA | IPV6 address | A | IPV4 Address | MX | Mail Exchange | CNAME | Canonical Name | TXT | Text | PTR | Pointer to an address | RP | Responsible Person |
The reason for only using a few of the records is that many companies don't like providing unnecessary information about their systems, so often they only specify the minimal amount of records. Some records appear in every file, such as Start of Authority (SOA) records, while others only appear in one or two files. For example, we have A records in the forward files to define an IP address and CNAME records to define an alias for the host name, with PTR records in the reverse files to define a host name. SOA Records We showed earlier how the domain is broken down into smaller, manageable portions known as zones. The Start of Authority record is where we define which zone this name server is authoritative over. We'll create an SOA record that we can use as a template for all the zone files. This makes it as easy as possible to administer our DNS configuration and means that over time the only entry that will differ between them all will be the serial number, as the files increment independently. The record we'll use is shown below, so let's also see how we derive it: @ IN SOA solarisbootcamp.com. root.solarisbootcamp.com. ( 2001043001 ; Serial num - <yyyymmddxx> 86400 ; Refresh every 24 hours 7200 ; Retry every 2 hours 3600000 ; Expire in 1000 hours 172800) ; TTL is 2 days The "@" symbol is an abbreviation for the "origin," which is passed in from the boot file as the entry after the "zone" keyword. For example, if we look at the entry for the master reverse zone in the configuration file, we have the entry listed below. In this case, the origin is set to "44.168.192.in-addr.arpa": zone "44.168.192.in-addr.arpa" in { type master; file "master/192.168.44"; }; Because each entry in the boot file specifies its own origin in the zone file, this means we can use the "@" symbol in the SOA record of each file. Serial Number Whenever we make changes to any of the zone files we need to inform all the name servers that these changes are taking place. The way to do this is by updating the serial number field. It doesn't matter what number format you use, as long as the number increases; you could update it in increments of 1,000, for example, but then you may need to be careful you don't run out of numbers! To get around these sorts of problems, the recommended way is to base the serial number on a date format and add some additional digits to allow us to update the number several times per day. This translates to "YYYYMMDDxx," so if the date were October 22, 2001, then the first time we alter the file we would use the serial number 2001102201. The next update that day would be 2001102202 and so on. Updates the next day would revert back to 01 for the additional digits (i.e., 2001102301). This allows us to alter the file 99 times per day (which should be more than enough for anyone!). Once the serial number has been updated, we can inform named by either restarting it or by sending it an HUP signal as follows: antimony# kill -HUP `cat /etc/named.pid` antimony# Named will then reread its configuration files and, importantly, the slave servers will automatically pick up the changes. Refresh, Retry, Expire, and Time-to-Live Values These fields govern how long the data will be valid for and how often the secondary servers will try to reload this information. "Refresh" is the time interval before the secondary server checks with the primary to see if the data is still valid. "Retry" is the amount of time that the secondary server will try to check with the primary server if it has failed to refresh itself. "Expire" is the amount of time the data is valid if it fails to refresh its data. "TTL" is the time-to-live field. This is the amount of time that the data is valid before it is reloaded from the server. The times we have used are taken from the document "Ripe-203: Recommendations for DNS SOA Values" and should be adequate for "general" use. You may wish to adjust these to suit your site, but be careful about the values you use. Table 16.5 shows the range of values commonly seen and can be used as a guideline of the values to set. Table 16.5. Common SOA ValuesSOA Field | Range |
|---|
Refresh | 324 hours | Retry | 12 hours | Expire | 730 days | TTL | 17 days |
NS Records In a similar way to the SOA record, we'll define the records that will be used for the name server (NS) records in every zone file. The entries we'll use are shown below: ; ; name server definitions ; IN NS antimony.solarisbootcamp.com. IN NS tellurium.solarisbootcamp.com. This defines both machines as name servers (notice the trailing dot included with the domain name). Now that we've got some standard records we can use within our zone files, let's move on and create all the files that will be needed for both the master and slave servers. This can become a little awkward to keep track of because quite a few files need to be created, all of which look quite similar. To help things along, Figure 16.7 indicates which files are used where. Figure 16.7. The zone files. 
| 
