Unix Web Hosting for Developers

Parentheses While technically the SOA record should be on a single line, if it were, it would be difficult to read. Instead, standard zone files have this broken up into several lines, with the first opening parenthesis (or round bracket) indicating the line break. Each of the next five lines is part of the SOA record, with the record ending with the closing parenthesis. Serial Number The first piece is the serial number, which indicates the zone file’s version (|). While the serial number can be whatever you choose, it’s most convenient to use the date. You’ll usually see the date in YYYYMMDD format with two extra digits at the end. This serial number, 20010601, represents June 1, 2001. The extra two numbers in the serial number represent the number of times the file has changed in a day. For example, there have been times that I’ve had to update one domain a dozen times in one day, with each change requiring a serial number bump. Here’s how this works: Say I create the zone file on May 9, 2002, with the first serial number 2002050901. If I change the zone file on June 8, the serial number changes to 2002060801. If I then change the zone file a second time on that same day, the serial number changes to 2002060802. This system allows up to 100 changes in a day, or roughly one change every 15 minutes. If this isn’t enough for you, you need to rethink your work processes. The serial number is important, because every so often a slave server will contact the master server to see if the zone has updated. It determines whether there’s been an update by comparing the serial number of its cached copy to the master zone file’s serial number. If the master zone file’s serial number is greater than the one on the slave, the slave server determines that the zone file has been updated and downloads the latest domain information. Note If your secondary nameservers haven’t updated their zone files from the master nameserver, it’s probably a serial number problem. Even if you swear up and down that you incremented the serial number, increment the serial number again and try once more. It’ll probably work. Refresh The next number is the refresh value, in seconds (}). This number determines how frequently slave servers will contact the master server to check for an updated master file. In the localhost.rev file, a secondary nameserver would update every 3,600 seconds, or 60 minutes. If the slave cannot check its data against the master in a refresh attempt, it keeps giving answers with its current record that’s what a backup nameserver is for, after all! We’ll see exactly how this works in the “Refresh, Retry, and Expire in Practice” section. Retry The next number is the retry value, also in seconds (~). If the slave cannot reach the master nameserver, it will retry at this interval. Our sample file has a 900 second (15 minute) retry. If the secondary nameserver cannot update at the 1 hour mark, it will keep trying every 15 minutes until the master nameserver answers. Again, we’ll see exactly how this works in the “Refresh, Retry, and Expire in Practice” section. Expire Next we have the expire value, in seconds ( ). If a slave nameserver cannot update its records for this many seconds, it stops giving out its cached information. It’s at this point that the administrator thinks bad information is worse than no information. In our example we have 3,600,000 seconds (1,000 hours, or a little over 41 days). Minimum TTL The last number is the minimum time to live (j). In older implementations of BIND, this was used for the time to live for absolutely everything. Today, it’s only used for the TTL for negative answers. (Nameservers can cache negative answers.) For example, if you look up givememymoneyback. http://www.absolutebsd.com/, your nameserver will learn that there’s no such host. In localhost.rev, negative answers will be cached for 3,600 seconds (1 hour). 284

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services