SOA RecordThe second line in the zone file uses the special @ name that you saw earlier. Here, it stands for 0.0.127.in-addr.arpa, to which the SOA (Start of Authority) record belongs. The rest of the fields (continued until the closing parenthesis) contain SOA-specific data.
The first data field in the SOA record is the fully qualified name of the master nameserver for the domain. The second field is the email address of the contact person for the zone. Replacing the @ sign with a . writes it as a DNS name; [email protected] would be written as foo.example.com (note the trailing .).
Do not use an address such as [email protected] because it is written as a.b.example.com and will later be misinterpreted as [email protected].
It is important to ensure that mail to the contact email address specified in the SOA field is frequently read because it is used to report DNS setup problems and other potentially useful information.
The next several numeric fields specify various characteristics of this zone. These values must be correctly configured, and to do so, you must understand each field. As shown in the comments (note that zone file comments are not the in the same syntax as named.conf comments), the fields are serial number, refresh interval, retry time, expire period, and minimum TTL.
Serial numbers are 32-bit quantities that can hold values between 0 and 4,294,967,295 (2??-1). Every time the zone data is changed, the serial number must be incremented. This change serves as a signal to slaves that they need to transfer the contents of the zone again. It is conventional to assign serial numbers in the format YYYYMMDDnn; that is, the date of the change and a two-digit revision number (for example, 2007060101). For changes made on the same day, you increment only the revision. This reasonably assumes that you make no more than 99 changes to a zone in one day. For changes on the next day, the date is changed and the revision number starts from 01 again.
The refresh interval specifies how often a slave server should check whether the master data has been updated. It has been set to 24 hours here, but if the zone changes often, the value should be lower. Slaves can reload the zone much sooner if both they and the master support the DNS NOTIFY mechanism, and most DNS software does.
The retry time is relevant only when a slave fails to contact the master after the refresh time has elapsed. It specifies how long it should wait before trying again. (It is set to two hours here.) If the slave is consistently unable to contact the master for the length of the expire period (usually because of some catastrophic failure), it discards the zone data it already has and stops answering queries for the zone. Thus, the expire period should be long enough to allow for the recovery of the master nameserver. It has been repeatedly shown that a value of one or two weeks is too short. One thousand hours (about six weeks) is accepted as a good default.
As you read earlier, every RR has a TTL field that specifies how long it can be cached before the origin of the data must be consulted again. If the RR definition does not explicitly specify a TTL value, the default TTL (set by the $TTL directive) is used instead. This enables individual RRs to override the default TTL value as required.
The SOA TTL, the last numeric field in the SOA record, is used to determine how long negative responses (NXDOMAIN) should be cached. (That is, if a query results in an NXDOMAIN response, that fact is cached for as long as indicated by the SOA TTL.) Older versions of BIND used the SOA minimum TTL to set the default TTL, but BIND 9 no longer does so. The default TTL of 2 (two days) and SOA TTL of 1 (one hour) are recommended for cache friendliness.
The values used previously are good defaults for zones that do not change often. You might have to adjust them a bit for zones with different requirements. In that case, the website at http://www.ripe.net/docs/ripe- 203.html is recommended reading.
The next two lines in the zone file create NS and PTR records. The NS record has no explicit name specified, so it uses the last one, which is the @ of the SOA record. Thus, the nameserver for 0.0.127.in-addr.arpa is defined to be localhost.
The PTR record has the name 1, which becomes 1.0.0.127.in- addr.arpa (which is how you write the address 127.0.0.1 as a DNS name). When qualified, the PTR record name 1 becomes localhost. (You will see some of the numerous other RR types later when we configure our nameserver to be authoritative for a real domain.)
TXT Records and SPFOne record not already mentioned is the TXT record. This record is usually used for documentation purposes in DNS, but a recent proposal uses the TXT record to help in the fight against email address forgery, spam, and phishing attacks. One problem with email and SMTP is that when email is being delivered, the sender can claim that the email is coming from trusted.bank.com, when really it is coming from smalltime.crook.com. When the recipient of the email gets the email, it looks like valid instructions from trusted.bank.com; but if the receiver trusts the email and follows its instructions, his bank accounts can become vulnerable. These situations can be controlled by using
Domains can publish the valid IP address of their email servers in specially formatted TXT records. A TXT record could look like this:
trusted.bank.com. IN TXT 'v=spf1 ip4:37.21.50.80 -all'
This record specifies that only one IP address is allowed to send mail for trusted.bank.com.
Receiving email servers can then do one extra check with incoming email. When an email arrives, they know the IP address that the email is coming from. They also know that the sender claims to be coming from trusted.bank.com, for example. The receiving email server can look up the DNS TXT record for trusted.bank.com, extract the allowed IP addresses, and compare them to the IP address that the email really is coming from. If they match, it is an extremely good indication that the email really is coming from trusted.bank.com. If they do not match, it is a very good indication that the email is bogus and should be deleted or investigated further.
The SPF system does rely on cooperation between senders and receivers. Senders must publish their TXT records in DNS, and receivers must check the records with incoming email. If you want more details on SPF, visit the home page at http://spf.pobox.com/.
Logging
The example now has all the elements of a minimal functioning DNS server, but before experimenting further, some extra logging will allow you to see exactly what named is doing. Log options are configured in a logging section in named.conf, and the various options are described in detail in the BIND 9 ARM.
All log messages go to one or more channels — each of which can write messages to the syslog, to an ordinary file, stderr, or null. (Log messages written to null are discarded.) Categories of messages exist, such as those generated while parsing configuration files, those caused by OS errors, and so on. Your logging statement must define some channels and associate them with the categories of messages that you want to see.
BIND logging is very flexible, but complicated, so we examine only a simple log configuration here. The
