A Zone
| So, you have a domain registered, or you're going to register one (see Chapter 4, "Getting a Domain", and you want to set up DNS for your domain and network. As an example, I will set up zone files for the company Penguin AS, which owns the domain penguin.bv.bv is the TLD for Bouvet Island, a south Atlantic island that is a property of Norway (the choice of company name is a subliminal message about what OS the author likes). I have assigned the 192.168.55.0/255.255.255.0 subnet to the company. This is a private, internal network according to RFC 1597, so I can use it freely. NORID, which administrates bv, has decided not to assign any domains within the bv TLD. Therefore, I will appropriate it in examples because no one will be looking for bv domains and be confused if an RR escapes from their nameservers into DNS. The NORID policy has caused some lamentations from Dutch companies; "bv" is similar to the American "Inc." in Holland, and is therefore a highly desirable TLD to be under. The zone files for penguin.bv can be found on the book Web page in the penguin.tar.gz or penguin.zip file. A Forward ZoneLet's first look at some theory. The general format of a DNS record is as follows: name ttl class type data In the previous code, name is the DNS name to which the record belongs. In the next code listing, the DNS names are ns, mail, www, ftp, rms, esr, and so on. Note the special name @ used for the SOA record it is used for the zone origin penguin.bv in this case. If you look back at the 127.0.0 zone shown previously, you can see @ is also used there instead of 0.0.127.in-addr.arpa. You also can see that several lines do not have a name; for example, none of the HINFO records have names. If the name is left out, it defaults to the last seen name. Thus, the @ at the SOA is used as the default name for all the opening NS and MX records that follow the SOA record. ttl controls caching, which I will explain later when I explain the SOA record. BIND supports different classes of records, but we will concern ourselves only with the IN, or InterNet, class. The IN class is the default class for zones and doesn't need to be specified. Therefore, I won't bother specifying it here, which will save me some typing. The other classes of records are used for other kinds of networks, and in one case called Hesiod, which is an MIT project, they're used for user authentication data. This is similar to NIS, but it uses BIND as the database. type must be one of the known RR types. So far, I have used SOA, NS, A, and PTR. HINFO and MX will be introduced shortly. Others do exist, though see Chapter 13, "Resource Records," for a complete list. For the previous code, data depends on the type of record you're looking at. Some types, such as the SOA record, have many data fields; however, most types have only one data field. HINFO and MX are among those that have two data fields. penguin.bv is a small company, even though its products are used all over the world, so it doesn't have many machines. We're going to set up a zone with a Web server, an FTP server, a combined mail and nameserver, and some machines it uses internally. Starting with the configuration files from the caching nameserver, we first add the forward zone file pz/penguin.bv: 1 ; 2 ; penguin.bv zone 3 ; 4 $TTL 804800 ; 7 days 5 ; 6 @ 3600 SOA ns.penguin.bv. hostmaster.penguin.bv. ( 7 2000041300 ; serial 8 86400 ; refresh, 24h 9 7200 ; retry, 2h 10 3600000 ; expire, 1000h 11 172800 ; minimum, 2 days 12 ) 13 NS ns 14 NS ns.herring.bv. As you can see from the previous code, three mandatory bits exist in a zone file the $TTL line, the SOA RR, and the NS RR for the zone. The first line of the SOA RR (line 6) contains two important things. The first is the name of the zone origin server, namely ns.penguin.bv. This should be the name of the primary nameserver, not the zone name itself, unless they are the same. Secondly, it holds the email address of the contact person for the zone, which for our example is hostmaster.penguin.bv. This name should be taken to mean hostmaster@penguin.bv, replacing the first period (.) with the at sign (@). It is recommended that you maintain a hostmaster@domain email address, alias, or list so you always have a traditional contact address for DNS issues. In any case, email to the address you put here must be read because it is used to report bad DNS data, as well as security problems. You should be careful to avoid contact email addresses with periods in the username because of the "first period becomes @" rule. The next lines of the code contain several important values. The serial number, at line 7, must be changed every time you update the zone file, by incrementing the it. When slave servers want to check whether they are up to date, they retrieve the SOA record and compare the serial number of the zone file they have cached to the one on the primary server. If the serial number of the master is higher than that on the slave, a zone transfer is triggered and the updated zone is copied from the master to the slave. A popular, and useful, convention is to keep the serial number in YYYYMMDDNN format, in which the first eight digits denote the date of the last change and NN denotes the number of the change within that day. On the other hand, some software will maintain the number as a strict serial number, incrementing it by one for each edit. At line 8, the refresh interval is set to 24 hours. This is the interval between each time a slave server will check whether the master server has been updated. So, in this case, it might take up to 24 hours before the slave server checks whether the master has been updated. After these 24 hours have passed, the slave will check whether it is updated as described previously. If the zone changes often and the changes are important, this value should be lower. Zone transfers are a bit resource-demanding, so if you house very many zones, the cumulative load might be noticeable. On small nameservers, though, it is hardly noticeable and is nothing to worry about. The retry interval becomes relevant only if the slave server fails to raise the master server when the refresh interval has passed. If it fails to get the SOA record, it will retry after waiting out the retry interval, which in this case is two hours. If the SOA record query and zone transfer fail after the retry interval, the zone transfer will be retried repeatedly. But, after the expire interval has passed without contact with the master server, the zone will expire on the secondary. It will be removed from the slave server and will not answer queries for the zone anymore. This could be problematic, so the expire interval should be long enough that the zone will not expire in the case of a catastrophe that takes the primary DNS server site out for a long time. One thousand hours, which is 41 days or roughly 5 weeks, is usually sufficient. Often, though, one or two weeks is used, but that has repeatedly proven to be too short a time to restore the primary nameserver. You can use one other method to cause a zone to expire: If you make a typo when updating a zone file or the configuration file, the zone you edited, or even several zones, might be rejected out of hand by named. Unless you catch the typo, the zones will expire no matter how carefully you choose your expiry time. This chapter has already discussed the last value and the $TTL value. It is used to control the caching of records in the zone. Traditionally, the minimum ttl field of the SOA record was the default TTL value for all records in the zone. Recently, though, a transition has started, and has not yet ended at the time of this writing. The SOA TTL is the time to cache negative answers, meaning when a query fails, the fact is cached for that length of time. Enter $TTL. It specifies the default TTL of the records in the zone. Thus, a cache server will cache answers from the penguin.bv zone for seven days. If it does not get an answer for a penguin.bv name, that fact is cached for two days. Negative caching is described in detail in RFC 2308. You can override the TTL for each record, though. Above the SOA record, TTL has been overridden to 3,600 seconds, or one hour. The values used here are recommended in http://www.ripe.net/docs/ripe-203.html, which is an informative document that I recommend you read. These values are well suited for a zone that does not change often. However, if your zone or some specific records in the zone changes often, or if it is important that changes be known quickly when they are made, you should use other values. If you do use other values, remember that they can be overridden for selected records and that lower TTLs and refresh intervals are therefore necessary. Line 13 shows the third required bit the NS record for the zone. At least one NS record is required. We have two in our example, as we should because our friends at Herring Co. are hosting a secondary nameserver for us. You can't specify the server addresses in NS records; instead you must specify hostnames and then give the A records of the hosts that are within, or under, the current zone. The address of ns.penguin.bv is provided on line 19, shown later in this section. No address is given for ns.herring.bv within this zone, though, because its address can be found by other means. In addition, modern BINDs ignore records that do not belong in the zone file in which they occur. Thus, you are unable to specify the address of ns.herring.bv within the penguin.bv zone. If, on the other hand, a nameserver exists in the zones domain or in a subdomain of the zone, an A record must be supplied. This is because all lookups must go through the domain for which we're writing a zone file, and no other way is available to find the address of the nameserver. Configuring these three mandatory items correctly is important to ensure that lookups for your domain don't fail. So get it right! Now that you've gotten past all this red tape however important you can get on with the purpose of this file. Let's take a look at some more RRs. The two MX records for the domain are first, however: 15 MX 10 mail 16 MX 20 mail.herring.bv. MX records specify the Mail Exchangers for the zone. Mail Exchangers are the servers to which mail software sends mail for the domain, which in our example is penguin.bv. The MX record requires two data fields: the priority field and the name field for the mail server. Mail software attempts to deliver mail through the server with the lowest priority value first and then, if that fails, to the others sorted by priority. In other words, mail.penguin.bv is the primary mail server, and mail.herring.bv is the secondary mail server. Having many redundant mail servers is not a very high priority because the originating mail server saves mail for several days before the delivery fails. Three days is the norm for saving mail, so remember that in case something breaks and mail can't be delivered to the listed servers. The localhost line exists for a combination of reasons: 17 localhost A 127.0.0.1 UNIX software and users frequently refer to the localhost as localhost. Because of the name search heuristics you configure in resolv.conf, the name localhost is looked for in the domains listed to search. So, in the likely case of penguin.bv being in the search list on the penguin.bv machines, the name localhost.penguin.bv will be looked up. Next, you can start defining the first actual machine; ns.penguin.bv is defined to have the address 192.168.55.2: 18 ; Nameserver 19 ns A 192.168.55.2 20 21 ; Mailserver, same machine. 22 mail A 192.168.55.2 23 MX 10 mail 24 MX 20 mail.herring.bv. rr;"> 25 HINFO PC Tunes The next A record is for mail.penguin.bv, and it gives the same address. The mail server is also listed with MX records in case someone is trying to send mail to a user at @mail.penguin.bv. Again, the secondary is at mail.herring.bv. A new type of record, a HINFO record, is sometimes included. Some people, including me, like to use it, whereas others don't, arguing that these records don't provide many benefits and can possibly cause harm. HINFO records can pose a security threat, telling crackers what kind of OS a machine runs, which enables them to try only the break-in procedures known to work on that particular OS. The HINFO record carries two data fields as well, CPU and OS. CPU is often taken to mean what kind of computer rather than the specific CPU model, as it is here. Common CPU fields for PCs are x86, i386, and so on. A Sun Sparc Server 20 might be shown as Sun or SPARC or perhaps even Sun4, SS20, or any of the various names the computer or its architecture is known as. As you will see, I've been very consistent about how (un)specific I am in the CPU field; "SUN" is about as unspecific as "PC". The OS, on the other hand, is sometimes just an OS name, but sometimes also the version. If you want to include the version, the OS field must be quoted because a space is the field separator: lbt HINFO PC "Linux 2.3" The following continues our example: 27 ; WEB, both www.penguin.bv and 28 ; penguin.bv/ with A records 29 30 www A 192.168.55.3 31 ; People often send mail to webmaster@www.domain 32 MX 10 mail 33 MX 20 mail.herring.bv. 34 HINFO PC Tunes 35 @ A 192.168.55.3 With these A records, the Penguin Web server can be accessed as both www.penguin.bv/ and penguin.bv/. The HTTP protocol merely needs an A record for the server to which you want to connect. So, you simply give HTTP the address of the computer to which to connect: 37 ; FTP server 38 39 ftp A 192.168.55.4 40 HINFO PC BSD 41 42 ; The firewall/router: 43 44 gw A 192.168.55.1 45 A 192.168.55.129 Line 44 shows one host with two A records. Routers, gateways, and firewalls often have several network interfaces. DNS supports listing them all under the same hostname, but some people prefer to give each interface a separate name. The rest of the zone is as follows: 47 ; Internal hosts 48 49 rms A 192.168.55.130 50 HINFO PC HURD 51 52 esr A 192.168.55.131 53 HINFO PC Linux 54 55 lbt A 192.168.55.132 56 HINFO PC Linux 57 58 jkh A 192.168.55.134 59 HINFO PC BSD 60 61 dek A 192.168.55.135 62 HINFO SUN Solaris 63 64 tolk A 192.168.55.136 65 HINFO PCP PalmOS 66 67 laser A 192.168.55.137 68 HINFO Printer Postscript That concludes pz/penguin.bv. The following, however, is a small addition to the named.conf file: zone "penguin.bv" { type master; file "pz/penguin.bv"; }; That pretty much sums up what the zone is. The opening zone keyword takes one parameter, the zone's domain name or origin. If an $ORIGIN exists within the file, these must match. Because this is the master server, the zone goes in the file pz/penguin.bv. See the section "Secondary Servers" later in this chapter to find out how to set up secondary, or slave, servers for a zone. Run ndc reconfig and inspect the zone with Dig: $ dig mail.penguin.bv ANY ; <<>> DiG 8.2 <<>> mail.penguin.bv ANY ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; mail.penguin.bv, type = ANY, class = IN ;; ANSWER SECTION: mail.penguin.bv. 1w2d7h33m20s IN HINFO "PC" "Tunes" mail.penguin.bv. 1w2d7h33m20s IN MX 10 mail.penguin.bv. mail.penguin.bv. 1w2d7h33m20s IN MX 20 mail.herring.bv. mail.penguin.bv. 1w2d7h33m20s IN A 192.168.55.2 ;; AUTHORITY SECTION: penguin.bv. 1w2d7h33m20s IN NS ns.penguin.bv. penguin.bv. 1w2d7h33m20s IN NS ns.herring.bv. ;; ADDITIONAL SECTION: mail.penguin.bv. 1w2d7h33m20s IN A 192.168.55.2 ns.penguin.bv. 1w2d7h33m20s IN A 192.168.55.2 ;; Total query time: 16 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Apr 15 17:57:52 2000 ;; MSG SIZE sent: 33 rcvd: 191 This is exactly as expected. Now I'll insert a common typo in the zone file. Line 42 is changed to the following: MX 20 mail.herring.bv In other words, the trailing period is dropped on the second MX record for www.penguin.bv. After using the ndc reload command, dig provides the result: $ dig: www.penguin bv MX … www.penguin.bv. 1w2d7h33m20s IN MX 10 mail.penguin.bv. www.penguin.bv. 1w2d7h33m20s IN MX 20 mail.herring.bv.penguin.bv. … Most people make this error at one time or another, and the reason is simple. BIND considers all names to be relative to the zone origin, unless they are FQDNs by virtue of having a trailing period. When I removed the trailing period, the name mail.herring.bv was no longer seen as an FQDN and the zone origin penguin.bv was added to the end. The fix is trivial, of course you can just add a period to the end of all FQDNs. Small bugs like these also are a good reason to always inspect the changes you make in zone files for example, with dig no matter how trivial the changes were. In addition, you should also read the log files when reloading the zones. A Reverse ZoneNow let's look at the reverse zone. As you see in the following code, a reverse zone is simply an up-ended version of the forward zone: $TTL 804800 ; ~7 days ; @ 3600 SOA ns.penguin.bv. hostmaster.penguin.bv. ( 2000041300 ; serial 86400 ; refresh, 24h 7200 ; retry, 2h 3600000 ; expire, 1000h 172800 ; minimum, 2 days ) NS ns.penguin.bv. NS ns.herring.bv. ; Externally available hosts: 1 PTR gw.penguin.bv. 2 PTR mail.penguin.bv. 3 PTR www.penguin.bv. 4 PTR ftp.penguin.bv. ; Internal hosts: 129 PTR gw.penguin.bv. 130 PTR rms.penguin.bv. 131 PTR esr.penguin.bv. 132 PTR lbt.penguin.bv. 134 PTR jkh.penguin.bv. 135 PTR dek.penguin.bv. 136 PTR tolk.penguin.bv. 137 PTR laser.penguin.bv. Notice that all the machine names are typed out here. The origin of this file is 55.168.192.in-addr.arpa. On the other hand, the machine addresses are not typed out, so the records have names such as 1.55.168.192.in-addr.arpa, which is exactly what you want. The following adds it to named.conf: zone "55.168.192.in-addr.arpa" { type master; file "pz/192.168.55"; }; Here again the zone's domain name is on the zone line. Then, a closer description of the zone exists within the braces. An ndc reconfig and dig can be used to examine it: # dig 1.55.168.192.in-addr.arpa PTR ; <<>> DiG 8.2 <<>> 1.55.168.192.in-addr.arpa PTR ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUERY SECTION: ;; 1.55.168.192.in-addr.arpa, type = PTR, class = IN ;; ANSWER SECTION: 1.55.168.192.in-addr.arpa. 1w2d7h33m20s IN PTR gw.penguin.bv. ;; AUTHORITY SECTION: 55.168.192.in-addr.arpa. 1w2d7h33m20s IN NS ns.penguin.bv. 55.168.192.in-addr.arpa. 1w2d7h33m20s IN NS ns.herring.bv. ;; ADDITIONAL SECTION: ns.penguin.bv. 1w2d7h33m20s IN A 192.168.55.2 ;; Total query time: 36 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Apr 15 18:23:13 2000 ;; MSG SIZE sent: 43 rcvd: 151 As we already knew, 192.168.55.1 has the name gw.penguin.bv. But now we also know that the zone works. Another ZoneLet's take a quick look at a real set of forward and reverse zones. This example, which is based on a real zone, wasn't created by me so it's different from how I would set it up. zone/walrus.bvAs you see from the heading, this nameserver uses a slightly different naming convention. Instead of pz, the directory is called zone. The following are the file's contents: $TTL 1D @ IN SOA walrus.bv. root.walrus.bv. ( 199609206 ; todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds NS walrus.bv. NS ns2.psi.net. MX 10 walrus.bv. ; Primary Mail Exchanger TXT "goo goo g'joob." localhost A 127.0.0.1 router A 206.6.177.1 walrus.bv. A 206.6.177.2 ns A 206.6.177.3 www A 207.159.141.192 ftp CNAME walrus.bv. mail CNAME walrus.bv. news CNAME walrus.bv. www CNAME walrus.bv. funn A 206.6.177.2 ; ; Workstations ; ws-177200 A 206.6.177.200 MX 10 walrus.bv. ; Primary Mail Host ws-177201 A 206.6.177.201 MX 10 walrus.bv. ; Primary Mail Host ws-177202 A 206.6.177.202 MX 10 walrus.bv. ; Primary Mail Host ws-177203 A 206.6.177.203 MX 10 walrus.bv. ; Primary Mail Host ws-177204 A 206.6.177.204 MX 10 walrus.bv. ; Primary Mail Host ws-177205 A 206.6.177.205 MX 10 walrus.bv. ; Primary Mail Host … ws-177250 A 206.6.177.250 MX 10 walrus.bv. ; Primary Mail Host ws-177251 A 206.6.177.251 MX 10 walrus.bv. ; Primary Mail Host ws-177252 A 206.6.177.252 MX 10 walrus.bv. ; Primary Mail Host ws-177253 A 206.6.177.253 MX 10 walrus.bv. ; Primary Mail Host ws-177254 A 206.6.177.254 MX 10 walrus.bv. ; Primary Mail Host Notice that the times here are given with one-letter suffixes indicating hours, weeks, and days. This is a handy notation, eliminating the need to calculate how many seconds exist in a week, which can be time consuming. As you also can see, other values are used in the SOA record. The zone originates at walrus.bv, which is the name of the nameserver. Additionally, the zone contact is root@walrus.bv and the last update occurred on September 20, 1996. The secondaries will check with the master every 8 hours and retry every two hours if it fails. If it continues to fail, the secondaries will stop answering after one week. As stated earlier, one week might be too short in cases of emergency. The default ttl and minimum, negative caching ttl are one day. Also notice that only one digit is set aside for numbering the daily changes in the serial number. So, the zone file can be changed only 10 times per day. That might be sufficient for most people, but perhaps a tad too few if you're prone to mistakes and have to increment the serial number many times for each change you make. If that happens, you might run out on a given day. Hostnames also are provided for each kind of service, such as FTP, mail, and news, with CNAME records pointing to the main host. Providing service names in a domain is a good policy because it enables you to use, for example, ftp for all FTP services. Then, if the FTP server is moved to another host, the CNAME record can simply be changed. Therefore, users of the FTP service never have to be retrained to use another hostname. After the Web became so popular, this kind of naming policy became more prevalent, with www.domain being the most obvious example of it. This practice is also described in RFC 2219. In addition, each host has a name based on its IP number, instead of a "real" name. This often can be seen within large organizations. The idea here is that you always know what IP number a host is supposed to have, eliminating any confusion. Nowadays, the wide deployment of DHCP has made it less of a problem. Of course, some people prefer names for their machines and will feel like they're being treated as numbers, but you can't win 'em all. You also should notice that Walrus has its secondary nameserver offsite at its ISP, psi.net. As I've mentioned a few times before, it is good practice to keep your secondary nameservers offsite. zone/206.6.177The following shows the reverse zone: $TTL 1D @ IN SOA walrus.bv. root.walrus.bv. ( 199609206 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS walrus.bv. NS ns2.psi.net. ; ; Servers ; 1 PTR router.walrus.bv. 2 PTR walrus.bv. 2 PTR funn.walrus.bv. ; ; Workstations ; 200 PTR ws-177200.walrus.bv. 201 PTR ws-177201.walrus.bv. 202 PTR ws-177202.walrus.bv. 203 PTR ws-177203.walrus.bv. 204 PTR ws-177204.walrus.bv. 205 PTR ws-177205.walrus.bv. 250 PTR ws-177250.walrus.bv. 251 PTR ws-177251.walrus.bv. 252 PTR ws-177252.walrus.bv. 253 PTR ws-177253.walrus.bv. 254 PTR ws-177254.walrus.bv. The previous code contains no surprises. Here too we see an up-ended zone file and an offsite secondary nameserver. To make these zones operative, simply add the following lines to your named.conf file: zone "walrus.bv" } type master; file "zone/walrus.bv"; }; zone "177.6.206.in-addr.arpa" { type master; file "zone/206.6.177"; }; These sections are just as before; the only difference is the name of the directory in which the zone files are stored. |
EAN: 2147483647
Pages: 183