DNS and BIND 5th Edition_4 doc

You must modify /etc/named.conf on the slave name server host. For version 4, change every occurrence of primary to secondary except for 0.0.127.in−addr.arpa. Before the filename on each of these lines, add the IP address of the primary master server you just set up. For example, if the original version 4 configuration file line was this: primary movie.edu db.movie then the modified line looks like: secondary movie.edu 192.249.249.3 db.movie If the original version 8 configuration file line was: zone "movie.edu" in { type master; file "db.movie"; }; change master to slave and add a masters line with the IP address of the master server: zone "movie.edu" in { type slave; file "db.movie"; masters { 192.249.249.3; }; }; This tells the name server that it is a slave for the zone movie.edu and that it should track the version of this zone that is being kept on the host 192.249.249.3. The slave name server will keep a backup copy of this zone in the local file db.movie. For Movie U., we set up our slave name server on wormhole. Recall that the configuration file on terminator (the primary master) looked like this: directory /usr/local/named primary movie.edu db.movie primary 249.249.192.in−addr.arpa db.192.249.249 primary 253.253.192.in−addr.arpa db.192.253.253 primary 0.0.127.in−addr.arpa db.127.0.0 cache . db.cache We copied /etc/named.conf, db.cache, and db.127.0.0 to wormhole and edited the configuration file as described above. The version 4 configuration file on wormhole now looks like this: directory /usr/local/named secondary movie.edu 192.249.249.3 db.movie secondary 249.249.192.in−addr.arpa 192.249.249.3 db.192.249.249 secondary 253.253.192.in−addr.arpa 192.249.249.3 db.192.253.253 primary 0.0.127.in−addr.arpa db.127.0.0 cache . db.cache The equivalent version 8 configuration file looks like this: options { directory "/usr/local/named"; DNS & BIND 160 }; zone "movie.edu" in { type slave; file "db.movie"; masters { 192.249.249.3; }; }; zone "249.249.192.in−addr.arpa" in { type slave; file "db.192.249.249"; masters { 192.249.249.3; }; }; zone "253.253.192.in−addr.arpa" in { type slave; file "db.192.253.253"; masters { 192.249.249.3; }; }; zone "0.0.127.in−addr.arpa" in { type master; file "db.127.0.0"; }; zone "." in { type hint; file "db.cache"; }; This causes the name server on wormhole to load movie.edu, 249.249.192.in−addr.arpa, and 253.253.192.in−addr.arpa over the network from 192.249.249.3 (terminator). It also saves a backup copy of these files in /usr/local/named. You may find it handy to isolate the backup files in a subdirectory or to name them with a unique suffix like .bak; on rare occasions, you may have to delete all of the backup files manually. We'll cover more on backup files later. Start up the slave name server. Check for error messages in the syslog file as you did for the primary master server. As on the primary master, the command to start up a name server is: # /etc/named One extra check to make on the slave that you didn't have to make on the primary master is to see that the name server created the backup files. Shortly after we started our slave name server on wormhole, we saw db.movie, db.192.249.249, and db.192.253.253 show up in the /usr/local/named directory. This means the slave has successfully loaded these zones from the primary master and has saved a backup copy. To complete setting up your slave name server, try looking up the same names you looked up when the primary master server was started. This time nslookup must be run on the slave name server host so that the slave server is queried. If your slave is working fine, add the proper lines to your system startup files so that the slave name server is started when your system boots up and hostname(1) is set to a domain name. 4.8.2 Backup Files Slave servers are not required to save a backup copy of the zone data. If there is a backup copy, the slave server reads it on startup and later checks with the master server to see if the master server has a newer copy, instead of loading a new copy of the zone immediately. If the master server has a newer copy, the slave pulls DNS & BIND 4.8.2 Backup Files 161 it over and saves it in the backup file. Why save a backup copy? Suppose the master server is down when the slave starts up. The slave will be unable to transfer the zone and therefore won't function as a server for that zone until the master server is up. With a backup copy, the slave has some data, although it might be slightly out of date. Since the slave does not rely on the master server always being up, it is a more robust system. To run without a backup copy, omit the filename at the end of the secondary lines in the version 4 configuration file. In version 8, remove the file line. We recommend having all your slave servers save backup copies, though. There is very little extra cost to having a backup file, but there is a very high cost if you get caught without a backup file when you need it most. 4.8.3 Multiple Master Servers Are there other ways to make your slave server configuration more robust? Yes, you can specify up to ten IP addresses of master servers. In a version 4 configuration file, just add them after the first IP address, before the backup filename. In a version 8 configuration file, add them after the first IP address and terminate them with semicolons: masters { 192.249.249.3; 192.249.249.4; }; The slave will try the master server at each IP address, in the order listed, until it successfully transfers the zone. The intent of this feature is to allow you to list all the IP addresses of the host running the primary master for the zone if that host is multihomed. But, since there is no check made that the contacted server is a primary master or slave, you can list the IP addresses of hosts running slave servers for the zone, if that makes sense for your setup. 4.8.4 SOA Values Remember this SOA record? movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day We never explained what the values in between the parentheses were for. The serial number applies to all the data within the zone. We chose to start our serial number at 1, a logical place to start. But, many people find it more useful to use the date in the serial number instead, like 1997102301. This format is YYYYMMDDNN, where Y is the year, M is the month, D is the day, and NN is a count of how many times the zone data were modified that day. Whatever you choose, it's important that this number always increase when you update your zone data. When a slave name server contacts a master server for zone data, it first asks for the serial number on the data. If the slave's serial number is lower than the master server's, the slave's zone data are out of date. In this case, the slave pulls a new copy of the zone. When a slave starts up and there is no backup file to read, it always loads the zone. As you might guess, when you modify the db files on the primary master, you must increment the serial number. Updating your db files is covered in Chapter 7. DNS & BIND 4.8.3 Multiple Master Servers 162 The next four fields specify various time intervals in seconds: refresh The refresh interval tells the slave how often to check that its data are up to date. To give you an idea of the system load this feature causes, a slave will make one SOA query per zone per refresh interval. The value we choose, three hours, is reasonably aggressive. Most users will tolerate a delay of half of a working day for things like name server data to propagate when they are waiting for their new workstation to be operational. If you provide one−day service for your site, consider raising this value to eight hours. If your data don't change very often, or if all of your slaves are spread over long distances (as the root name servers are), consider a value that is even longer: 24 hours. retry If the slave fails to reach the master name server(s) after the refresh period (the host(s) could be down), then it starts trying to connect every retry seconds. Normally, the retry interval is shorter than the refresh interval, but it doesn't have to be. expire If the slave fails to contact the master server(s) for expire seconds, the slave expires its data. Expiring the data means the slave stops giving out answers about the data because the data are too old to be useful. Essentially, this field says: at some point, the data are so old that having no data is better than having stale data. Expire times on the order of a week are common − longer (up to a month) if you frequently have problems reaching your updating source. The expiration time should always be much larger than the retry and refresh intervals; if the expire time is smaller than the refresh interval, your slaves will expire their data before trying to load new data. TTL TTL stands for time to live. This value applies to all the resource records in the db file. The name server supplies this TTL in query responses, allowing other servers to cache the data for the TTL interval. If your data don't change much, you might consider using a minimum TTL of several days. One week is about the longest value that makes sense. A value as short as one hour can be used, but it is not recommended because of the amount of DNS traffic it causes. What values you choose for your SOA record will depend upon the needs of your site. In general, longer times cause less load on your systems and lengthen the propagation of changes; shorter times increase the load on your systems and speed up the propagation of changes. The values we use in this book should work well for most sites. RFC 1537 recommends the following values for top−level domain servers: 86400 ; Refresh 24 hours 7200 ; Retry 2 hours 2592000 ; Expire 30 days 345600 ; Minimum TTL 4 days There is one implementation feature you need to be aware of. Older versions (pre−4.8.3) of BIND slaves stopped answering queries during a zone load. As a result, BIND was modified to spread out the zone loads, reducing the periods of unavailability. So, even if you set a low refresh interval, your slaves may not check as often as you request. BIND attempts a certain number of zone loads and then waits 15 minutes before trying another batch. DNS & BIND 4.8.3 Multiple Master Servers 163 Now that we've told you all about how slave servers poll to keep their data up−to−date, BIND version 8 changed how zone data propagates! The polling feature is still there, but version 8 adds a notification when zone data changes. If both your primary master server and your slaves are version 8, the primary master will notify the slave that a zone has changed within 15 minutes of loading a new copy of that zone. The notification causes the slave server to shorten the refresh interval and attempt to load the zone immediately. We'll discuss this more in Chapter 10. 4.7 Running a Primary Master Name Server 4.9 Adding More Domains [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 4.8.3 Multiple Master Servers 164 Chapter 4 Setting Up BIND 4.9 Adding More Domains Now that you have your name servers running, you might want to support more domains. What needs to be done? Nothing special, really. All you need to do is add more primary or secondary statements (version 4) or zone statements (version 8) to your configuration file. You can even add secondary lines to your primary master server, and primary lines to your slave server. (You may have already noticed that your slave server was primary master for 0.0.127.in−addr.arpa.) At this point, it's useful to repeat something we said in an earlier chapter. Calling a given name server a primary master name server or a slave name server is a little silly. Name servers can be authoritative for more than one zone. A name server can be a primary master for one zone, and a slave for another. Most name servers, however, are either primary master for most of the zones they load or slave for most of the zones they load. So if we call a particular name server a primary master or a slave, we mean that it's the primary master or a slave for most of the zones it loads. 4.8 Running a Slave Name Server 4.10 What Next? [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 165 Chapter 4 Setting Up BIND 4.10 What Next? In this chapter, we showed you how to create name server data files by translating /etc/hosts to equivalent name server data, and how to set up a primary master and a slave name server. There is more work to do to complete setting up your local domain: you need to modify your DNS data for email, configure the other hosts in your domain to use name servers, and you may need to start up more name servers. These topics are covered in the next few chapters. 4.9 Adding More Domains 5. DNS and Electronic Mail [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 166 Chapter 5 5. DNS and Electronic Mail Contents: MX Records What's a Mail Exchanger, Again? The MX Algorithm And here Alice began to get rather sleepy, and went on saying to herself, in a dreamy sort of way, "Do cats eat bats? Do cats eat bats?" and sometimes "Do bats eat cats?" for, you see, as she couldn't answer either question, it didn't much matter which way she put it. I'll bet you're drowsy too, after that looong chapter. Thankfully, this next chapter discusses a topic that will probably be very interesting to you system administrators and postmasters: how DNS impacts electronic mail. And even if it isn't interesting to you, at least it's shorter than the last chapter. One of the advantages of the Domain Name System over host tables is its support of advanced mail routing. When mailers only had the HOSTS.TXT file (and its derivative, /etc/hosts) to work with, the best they could do was to attempt delivery to a host's IP address. If that failed, they could either defer delivery of the message and try again later, or bounce the message back to the sender. DNS offers a mechanism for specifying backup hosts for mail delivery. The mechanism also allows hosts to assume mail handling responsibilities for other hosts. This lets diskless hosts that don't run mailers, for example, have mail addressed to them processed by their server. Together, these features give administrators much more flexibility in configuring electronic mail on their network. 5.1 MX Records DNS uses a single type of resource record to implement enhanced mail routing, the MX record. Originally, this functionality was split between two records, the MD (mail destination) and MF (mail forwarder) records. MD specified the final destination to which a message addressed to a given domain name should be delivered. MF specified a host that would forward mail on to the eventual destination, should that destination be unreachable. Early experience with DNS on the Internet showed that separating the functionality didn't work very well. A mailer needed both the MD and MF records attached to a domain name (if both existed) to decide where to send the mail − one or the other alone wouldn't do. But an explicit lookup of one type or another (either MD or MF) would cause a name server to cache just that record type. So mailers either had to do two queries, one for MD and one for MF data, or they could no longer accept cached answers. This meant that the overhead of running mail was higher than that of running other services, and was eventually deemed unacceptable. DNS & BIND 5. DNS and Electronic Mail 167 The two records were integrated into a single record type, MX, to solve this problem. Now a mailer just needed all the MX records for a particular domain name destination to make a mail routing decision. Using cached MX records was fine, as long as the TTLs matched. MX records specify a mail exchanger for a domain name: a host that will either process or forward mail for the domain name (through a firewall, for example). "Processing" the mail means either delivering it to the individual it's addressed to, or gatewaying it to another mail transport, like UUCP. "Forwarding" means sending it to its final destination or to another mail exchanger "closer" to the destination via SMTP, the Internet's Simple Mail Transfer Protocol. Sometimes forwarding the mail involves queuing it for some amount of time, too. In order to prevent mail routing loops, the MX record has an extra parameter, besides the domain name of the mail exchanger: a preference value. The preference value is an unsigned 16−bit number (between 0 and 65535) that indicates the mail exchanger's priority. For example, the MX record: peets.mpk.ca.us. IN MX 10 relay.hp.com. specifies that relay.hp.com is a mail exchanger for peets.mpk.ca.us at preference value 10. Taken together, the preference values of a host's mail exchangers determine the order in which a mailer should use them. The preference value itself isn't important, only its relationship to the values of other mail exchangers: is it higher or lower than the values of this host's other mail exchangers? Unless there are other records involved: plange.puntacana.dr. IN MX 1 listo.puntacana.dr. plange.puntacana.dr. IN MX 2 hep.puntacana.dr. does exactly the same thing as: plange.puntacana.dr. IN MX 50 listo.puntacana.dr. plange.puntacana.dr. IN MX 100 hep.puntacana.dr. Mailers should attempt delivery to the mail exchangers with the lowest preference values first. This seems a little counterintuitive at first − the most preferred mail exchanger has the lowest preference value. But since the preference value is an unsigned quantity, this lets you specify a "best" mail exchanger at preference value 0. If delivery to the most preferred mail exchanger(s) fails, mailers should attempt delivery to less preferred mail exchangers (those with higher preference values), in order of increasing preference value. That is, mailers should try more preferred mail exchangers before they try less preferred mail exchangers. More than one mail exchanger may share the same preference value, too. This gives the mailer its choice of which to send to first.[1] The mailer should try all the mail exchangers at a given preference value before proceeding to the next higher value, though. [1] The newest version of sendmail, version 8, will actually choose randomly among mail exchangers at the same preference. For example, the MX records for ora.com might be: ora.com. IN MX 0 ora.ora.com. ora.com. IN MX 10 ruby.ora.com. ora.com. IN MX 10 opal.ora.com. DNS & BIND 5. DNS and Electronic Mail 168 Interpreted together, these MX records instruct mailers to attempt delivery to ora.com by sending to: 1. ora.ora.com first 2. Either ruby.ora.com or opal.ora.com next, and finally 3. The remaining preference 10 mail exchanger (the one not used in 2) Of course, once the mailer successfully delivers the mail to one of ora.com's mail exchangers, it can stop. A mailer successfully delivering ora.com mail to ora.ora.com doesn't need to try ruby or opal. What if a host doesn't have any MX records? Will a mailer simply not deliver mail to that host? Actually, you can compile recent versions of sendmail to do just that. Most vendors, however, have compiled their sendmails to be more forgiving: if no MX records exist, they'll at least attempt delivery to the host's address. sendmail version 8, compiled "out of the box," will try the address of a mail destination without MX records. Check your vendor's documentation if you're not sure which variety your sendmail is. Even though nearly all mailers will deliver mail to a host with just an address, and no MX records, it's still a good idea to have at least one MX record for each host. sendmail will request MX records for a host each time it needs to deliver mail. If the host doesn't have any MX records, a name server − usually one of your authoritative name servers − still ends up answering that query. If you simply add an MX record for the host pointing to itself, sendmail will have its first query answered, and the mailer's local name server will cache the MX record for future use. 4.10 What Next? 5.2 What's a Mail Exchanger, Again? [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 5. DNS and Electronic Mail 169 [...]... into much detail about this option here, primarily because this process is now well−documented and nearly automated in the newest DNS distribution The process itself usually involves creating a new libc.so − the standard, shared C library − by pulling out routines that call NIS and replacing them with pure 192 DNS & BIND DNS versions Although Sun generously provides the necessary replacement routines,... oddball service is NFS The mount command can handle domain names just fine, and you can put domain names into /etc/fstab (your vendor may call it /etc/checklist), too But watch out for /etc/exports and 187 DNS & BIND /etc/netgroup /etc/exports controls which filesystems you allow various clients to NFS−mount You can also assign a name to a group of hosts in netgroup and then allow them access via exports... example in mind, because we'll use it again later 5.1 MX Records 5.3 The MX Algorithm [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 171 DNS & BIND Chapter 5 DNS and Electronic Mail 5.3 The MX Algorithm That's the basic idea behind MX records and mail exchangers, but there are a few more wrinkles you should know about To avoid routing loops, mailers... for names typed at the command line that might be incomplete − that is, that might not be fully qualified domain names Most UNIX networking commands that take a domain name as an argument, like telnet, ftp, rlogin, and rsh, apply the search list to those arguments Both the way the default search list is derived and the way the search list is applied changed from DNS 4.8.3 to DNS 4.9 If your resolver... including DNS 8.1.2,[2] you'll see the improvements in the 4.9 resolver [2] Though the ISC added lots of new server functionality in DNS 8, the resolver is nearly identical to the DNS 4.9 resolver With any DNS resolver, a user can indicate that a domain name is fully qualified by adding a trailing dot to it.[3] For example, the trailing dot in the command: [3] Note that we said that the resolver can handle... Comments Also introduced with DNS 4.9 resolvers, and about time, if you ask us, is the ability to put comments in the resolv.conf file Lines that begin with a pound sign or semi−colon in the first column are interpreted as comments and ignored by the resolver 6.1.6 The options Directive 183 DNS & BIND 6.1.8 A Note on the 4.9 Resolver Directives If you're just moving to a DNS 4.9.3 or 4.9.4 resolver,... and Suffering [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 186 DNS & BIND Chapter 6 Configuring Hosts 6.3 Minimizing Pain and Suffering Now that you've configured your host to use DNS, what's going to change? Will your users be forced to type long domain names? Will they have to change their mail addresses and mailing lists? Thanks to the search... Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 174 DNS & BIND Chapter 6 6 Configuring Hosts Contents: The Resolver Sample Resolver Configurations Minimizing Pain and Suffering Vendor−Specific Options They were indeed a queer−looking party that assembled on the bank − the birds with draggled feathers, the animals with their fur clinging close to them, and. .. alias files, and have each point the HOSTALIASES variable in his shell startup file to his personal alias file 6.2 Sample Resolver Configurations 6.4 Vendor−Specific Options [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 6.3.4 Providing Aliases 191 DNS & BIND Chapter 6 Configuring Hosts 6.4 Vendor−Specific Options UNIX is ostensibly a standard operating... may also want to add aliases, both for your users' convenience and to minimize the shock of the conversion to DNS This chapter covers these topics, and also describes configuring the resolver in many common versions of UNIX and in Microsoft's Windows 95 and Windows NT 6.1 The Resolver We introduced resolvers way back in Chapter 2, How Does DNS Work?, but we didn't say much more about them The resolver, . /usr/local/named secondary movie.edu 192. 249 . 249 .3 db.movie secondary 249 . 249 .192.in−addr.arpa 192. 249 . 249 .3 db.192. 249 . 249 secondary 253.253.192.in−addr.arpa 192. 249 . 249 .3 db.192.253.253 primary 0.0.127.in−addr.arpa. Domains 5. DNS and Electronic Mail [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 166 Chapter 5 5. DNS and Electronic. loads. 4. 8 Running a Slave Name Server 4. 10 What Next? [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 165 Chapter 4 Setting