DNS and BIND 5th Edition_5 docx

There are more options to h2n than we've shown here. For the complete list of options, you'll have to look at the manpage. Of course, a few kinds of resource records aren't easy to generate from /etc/hosts − the necessary data simply aren't there. You may need to add these records manually. But since h2n always rewrites db files, won't your changes be overwritten? h2n provides a "back door" for inserting this kind of data. Put these special records in a file named spcl.DOMAIN, where DOMAIN is the domain name of your zone. When h2n finds this file, it will "include" it within the database files by adding the line: $INCLUDE spcl.DOMAIN to the end of the db.DOMAIN file. (The $INCLUDE directive is described later in this chapter.) For example, the administrator of movie.edu may add extra MX records into the file spcl.movie so that users can mail to movie.edu directly instead of sending mail to hosts within movie.edu. Upon finding this file, h2n would put the line: $INCLUDE spcl.movie at the end of the database file db.movie. 7.2.6 Keeping db.cache Current As explained in Chapter 4, the db.cache file tells your server where the servers for the "root" zone are. It must be updated periodically. The root name servers do not change very often, but they do change. A good practice is to check your db.cache file every month or two. In Chapter 4, we told you to get the servers by ftping to ftp.rs.internic.net. And that's probably your best method to keep current. If you have on your system a copy of dig, a utility that works a lot like nslookup and is included in the BIND distribution, you can retrieve the current list of roots just by running: % dig @a.root−servers.net . ns > db.cache 7.1 BIND Name Server Signals 7.3 Organizing Your Files [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 7.2.6 Keeping db.cache Current 213 Chapter 7 Maintaining BIND 7.3 Organizing Your Files When you first set up your domain, organizing your files was simple − you put them all in a single directory. There was one configuration file and a handful of db files. Over time, your responsibilities grew. More networks were added. Maybe a few subdomains were started. You started backing up zones for other sites. After a while, an ls of your name server directory no longer fits on a single screen. It's time to reorganize. BIND has a few features that will help with your organization. The configuration file for a 4.9 or later server can have a control entry, called include, which allows you to insert a new configuration file into the current configuration file. This allows you to take a very large configuration file and break it into smaller pieces. The database files (for all BIND versions) allow two control entries: $ORIGIN and $INCLUDE. $ORIGIN changes the origin, and $INCLUDE inserts a new file into the current file. The database control entries are not resource records; they facilitate the maintenance of DNS data. In particular, these statements make it easier for you to divide your domain into subdomains: they allow you to store the data for each subdomain in a separate database file. 7.3.1 Using Several Directories One way to organize your db files is to store them in separate directories. If your server is a primary master for several sites (both forward and reverse maps), you could store each site's db files in its own directory. Another division might be to store all the primary master files in one directory and all the slave backup files in a different directory. Let's look at what the version 4 configuration file might look like if you chose the primary/slave division: directory /usr/local/named ; ; These files are not specific to any zone ; cache . db.cache primary 0.0.127.in−addr.arpa db.127.0.0 ; ; These are our primary zone files ; primary movie.edu primary/db.movie primary 249.249.192.in−addr.arpa primary/db.192.249.249 primary 253.253.192.in−addr.arpa primary/db.192.253.253 ; ; These are our slave zone files ; secondary ora.com 198.112.208.25 slave/bak.ora secondary 208.112.198.in−addr.arpa 198.112.208.25 slave/bak.198.112.208 Here's the same configuration file in version 8 format: DNS & BIND 214 options { directory "/usr/local/named"; }; // // These files are not specific to any zone // zone "." { type hint; file "db.cache"; }; zone "0.0.127.in−addr.arpa" { type master; file "db.127.0.0"; }; // // These are our primary zone files // zone "movie.edu" { type master; file "primary/db.movie"; }; zone "249.249.192.in−addr.arpa" { type master; file "primary/db.192.249.249"; }; zone "253.253.192.in−addr.arpa" { type master; file "primary/db.192.253.253"; }; // // These are our slave zone files // zone "ora.com" { type slave; file "slave/bak.ora"; masters { 198.112.208.25; }; }; zone "208.112.192.in−addr.arpa" { type slave; file "slave/bak.198.112.208"; masters { 198.112.208.25; }; }; Another variation on this division is to break the configuration file into three files: the main file, a file that contains all the primary entries, and a file that contains all the secondary entries. Here's what the version 4 main configuration file might look like: directory /usr/local/named ; ; These files are not specific to any zone ; cache . db.cache primary 0.0.127.in−addr.arpa db.127.0.0 ; include conffile.primary include conffile.slave Here is conffile.primary (version 4): ; ; These are our primary zone files ; DNS & BIND 215 primary movie.edu primary/db.movie primary 249.249.192.in−addr.arpa primary/db.192.249.249 primary 253.253.192.in−addr.arpa primary/db.192.253.253 Here is conffile.slave (version 4): ; ; These are our slave zone files ; secondary ora.com 198.112.208.25 slave/bak.ora secondary 208.112.198.in−addr.arpa 198.112.208.25 slave/bak.198.112.208 Here are the same files in version 8 format: options { directory "/usr/local/named"; }; // // These files are not specific to any zone // zone "." { type hint; file "db.cache"; }; zone "0.0.127.in−addr.arpa" { type master; file "db.127.0.0"; }; // include "conffile.primary"; include "conffile.slave"; Here is conffile.primary (version 8): // // These are our primary zone files // zone "movie.edu" { type master; file "primary/db.movie"; }; zone "249.249.192.in−addr.arpa" { type master; file "primary/db.192.249.249"; }; zone "253.253.192.in−addr.arpa" { type master; file "primary/db.192.253.253"; }; Here is conffile.slave (version 8): // // These are our slave zone files // zone "ora.com" { type slave; file "slave/bak.ora"; masters { 198.112.208.25; }; }; zone "208.112.192.in−addr.arpa" { DNS & BIND 216 type slave; file "slave/bak.198.112.208"; masters { 198.112.208.25; }; }; You might think the organization would be better if you put the configuration file with the primary entries into the primary subdirectory, add a new directory line to change to this directory, and remove the primary/ from each of the file names, since the server is now in that directory. Then make comparable changes in the configuration file with the secondary lines. But things get rather confused when the name server keeps switching around to different directories − the slave backup files end up in the last directory the name server changed to, and when the name server is sent a HUP signal, it may not be able to find the main configuration file if it is not left in the directory where it started (if the configuration file is specified with a relative path name). 7.3.2 Changing the Origin in a Database File With BIND, the default origin for the DNS database files is the second field of the primary or secondary statement in the version 4 named.boot file or the second field of the zone statement in the version 8 named.conf file. The origin is a domain name that is appended automatically to all names not ending in a dot. This origin can be changed in the db file with $ORIGIN. In the db file, $ORIGIN is followed by a domain name. (Don't forget the trailing dot if you give the full domain name!) From this point on, all names not ending in a dot have the new origin appended. If your name server (e.g., movie.edu) is responsible for a number of subdomains, you can use the $ORIGIN entry to reset the origin and simplify the files. For example: $ORIGIN classics.movie.edu. maltese IN A 192.253.253.100 casablanca IN A 192.253.253.101 $ORIGIN comedy.movie.edu. mash IN A 192.253.253.200 twins IN A 192.253.253.201 We'll cover more on creating subdomains in Chapter 9, Parenting. 7.3.3 Including Other Database Files Once you've subdivided your domain like this, you might find it more convenient to keep the subdomain records in separate files. The $INCLUDE statement lets you do this: $ORIGIN classics.movie.edu. $INCLUDE db.classics $ORIGIN comedy.movie.edu. $INCLUDE db.comedy To simplify the file even further, the new origin can be specified on the $INCLUDE line: $INCLUDE db.classics classics.movie.edu. $INCLUDE db.comedy comedy.movie.edu. When you specify the origin on the $INCLUDE line, it only applies to the particular file that you're including. For example, the comedy.movie.edu origin only applies to the names in db.comedy. After db.comedy has been included, the origin returns to what it was before $INCLUDE, even if there was an DNS & BIND 7.3.2 Changing the Origin in a Database File 217 $ORIGIN entry within db.comedy. 7.2 Updating db Files 7.4 Changing BIND 8 System File Locations [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 7.3.2 Changing the Origin in a Database File 218 Chapter 7 Maintaining BIND 7.4 Changing BIND 8 System File Locations Version 8 allows you to change the name and location of the following system files: named.pid, named−xfer, named_dump.db, and named.stats. Most of you will not need to use this feature. Don't feel obligated to change the names or locations of these files just because you can change them. If you do change the default location of the files written by the name server (named.pid, named_dump.db, or named.stats), for security reasons, you should choose a directory that is not world−writable. While we don't know of any break−ins caused by these files, you should follow this guideline just to be safe. named.pid is usually /etc/named.pid or /var/run/named.pid. One reason you might change the default location of this file is if you find yourself running more than one name server on a single host. (Yikes! Why would someone do that?) Chapter 10, Advanced Features and Security, gives an example of running two name servers on one host. You can specify a different named.pid file in the configuration file for each server: options { pid−file "server1.pid"; }; named−xfer is usually /etc/named−xfer or /usr/sbin/named−xfer. It's used by a slave server for inbound zone transfers. One reason you might change the default location is to build and test a new version of BIND 8 in a local directory − your local version of named can be configured to use the local version of named−xfer: options { named−xfer "/home/rudy/named/named−xfer"; }; named_dump.db is left in the name server's current directory (version 8) when the name server dumps its database. Here is an example of to change its location: options { dump−file "/home/rudy/named/named_dump.db"; }; named.stats is left in the name server's current directory (version 8) when the name server writes its statistics to a file. Here is an example how to change its location: options { statistics−file "/home/rudy/named/named.stats"; }; 7.3 Organizing Your Files 7.5 BIND 8 Logging [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 219 Chapter 7 Maintaining BIND 7.5 BIND 8 Logging BIND 4 had an extensive logging system, writing information to a debug file and sending information to syslog. But, BIND 4 gave you limited control over this logging process − you could turn debugging on to a certain level. That's it. BIND 8 has the same logging system as BIND 4, but BIND 8 gives you control you didn't get with BIND 4. This control has its cost though − there's a lot to learn before you can be effective configuring this subsystem. If you don't have some time you can spend to experiment with logging, use the defaults and come back to this topic later. Most of you do not need to change the default logging behavior. Logging has two major topics you need to understand: channels and categories. A channel specifies where the logging data goes: to syslog, to a file, to stderr, or to the bit bucket. A category specifies what data is logged. Each category of data can be sent to a single channel or to multiple channels. In Figure 7.1, queries are logged to a file, statistics data is logged to a file and logged to syslog. Figure 7.1: Logging categories to channels Channels allow you to filter by message severity. Here is the list of severities: critical error warning notice info debug [level] dynamic The top five severities (critical, error, warning, notice, and info) are the familiar severity levels used by syslog. The other two (debug and dynamic) are unique to BIND 8. debug is name server debugging for which you can specify a debug level. If you omit the debug level, then the level is assumed to be one. If you specify a debug level, you will see messages of that level when name server debugging is turned on (i.e., if you specify "debug 3", then you will see level three debugging DNS & BIND 220 messages even when you only send one USR1 signal to the name server). If you specify dynamic severity, then the name server will log messages that match its debug level (i.e., if you send one USR1 signal to the name server, it will log messages from level one. If you send three USR1 signals to the name server, it will log messages from levels one through three.) The default severity is info, which means you won't see debug messages unless you specify the severity. NOTE: You can configure a channel to log both debug messages and syslog messages to a file. However the converse is not true − you cannot configure a channel to log both debug messages and syslog messages with syslog − only syslog messages can be sent to syslog. Let's configure a couple of channels to show you how this works. The first channel will go to syslog and will log with facility daemon, sending those messages of severity info and above. The second channel will go to a file, logging debug messages at any level as well as syslog messages. Here is the logging statement for the BIND 8 configuration file: logging { channel my_syslog { syslog daemon; // Debug messages will not be sent to syslog, so // there is no point to setting the severity to // debug or dynamic; use the lowest syslog level: info. severity info; }; channel my_file { file "log.msgs"; // Set the severity to dynamic to see all the debug messages. severity dynamic; }; }; Now that we've configured a couple of channels, we have to tell the name server exactly what to send to those channels. Let's implement what was pictured in Figure 7.1 with statistics going to syslog and to the file, and queries going to the file. The category specification is part of the logging statement, so we'll build on the previous logging statement: logging { channel my_syslog { syslog daemon; severity info; }; channel my_file { file "log.msgs"; severity dynamic; }; category statistics { my_syslog; my_file; }; category queries { my_file; }; }; With this logging statement in your configuration file, start your name server and send it a few queries. But nothing is written to log.msgs! (Well, if you wait long enough, the name server's statistics will show up in log.msgs.) You had expected those queries to be logged. Alas, you have to turn on name server debugging to get queries logged: # kill −USR1 `cat /etc/named.pid` DNS & BIND 221 Now send your name server some queries and they are logged in log.msgs. But look around: there's a new file called named.run. It has all the other debugging information written to it. You didn't want all this other debugging, though; you just wanted the statistics and queries. How do you get rid of named.run? There's a special category we haven't told you about: default. If you don't specify any channels for a category, the default category is used. Let's change the default category to discard all logging messages (there's a channel called null for this purpose): logging { channel my_syslog { syslog daemon; severity info; }; channel my_file { file "log.msgs"; severity dynamic; }; category default { null; }; category statistics { my_syslog; my_file; }; category queries { my_file; }; }; Now, start your server, turn on debugging to level one, and send some queries. The queries end up in log.msgs and named.run was created but the file is empty. Great! We're getting the hang of this after all. A few days pass. One of your co−workers notices that the name server is sending many fewer messages to syslog than it used to. In fact, the only syslog messages are statistics messages. The ones your co−worker watched, the zone transfer messages, are gone. What happened? Well, the default category is set up, by default, to send messages to both syslog and to the debug file (named.run). When the default category was configured to the null channel, the other syslog messages were turned off. Here's what we should have used: category default { my_syslog; }; This sends the syslog messages to syslog, but does not write debug or syslog messages to a file. Remember, we said you'd have to experiment for a while with logging to get exactly what you want. We hope this example gives you a clue what you might run into. Now, let's go over the details of logging. 7.5.1 The Logging Statement Here's the syntax of the logging statement. It's rather intimidating. We'll go over some more examples as we explain what each clause means: logging { [ channel channel_name { ( file path_name [ versions ( number | unlimited ) ] [ size size_spec ] | syslog ( kern | user | mail | daemon | auth | syslog | lpr | news | uucp | cron | authpriv | ftp | local0 | local1 | local2 | local3 | local4 | local5 | local6 | local7 ) DNS & BIND 7.5.1 The Logging Statement 222 [...]... except RNotNsQ and the items are arranged in a different order If your name server is newer than 8.1.2, the statistics may not look at all like those shown here − the BIND statistics may be replaced with the DNS server and resolver MIB extensions defined in RFC 1611 and RFC 1612 +++ Statistics Dump +++ (800708260) Wed May 17 03:57:40 1995 7.6.2 Understanding the BIND Statistics 237 DNS & BIND 746683 time... queries and decide if it makes sense for them to be making all those queries At some point you may decide that you need more servers to handle the load; we cover that situation in the next chapter 7.5 BIND 8 Logging 8 Growing Your Domain [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 7.6.2 Understanding the BIND Statistics 243 DNS & BIND Chapter... that BIND has run out of file descriptors BIND uses a fair number of file descriptors: two for each network interface it's listening on (one for UDP and one for TCP), and one for opening zone data files If that's more than the limit your operating system places on processes, BIND won't be able to get any more file descriptors and you'll see this message The priority will depend on which part of BIND. .. fast enough to handle the number of queries it receives, you should make sure the DNS traffic isn't placing undue load on your network On most LANs, DNS traffic will be too small a proportion of the network's bandwidth to worry about Over slow leased lines or dial−up connections, though, DNS traffic could consume enough bandwidth to merit concern To get a rough estimate of the volume of DNS traffic on... somewhat interesting We will explain all of the statistics, even the ones with zero counts, although you'll probably only find a handful of the statistics useful To make the statistics easier to read, you'll need a tool to 7.6.2 Understanding the BIND Statistics 239 DNS & BIND expand the statistics because the output format is rather compact We wrote a tool, called bstat, to do just this Here's what its... debug file (which by default is named.run) This means that all syslog messages of severity info and above are sent to syslog, and when debugging is turned on, the syslog messages and debug messages are written to named.run This more or less matches the BIND 4 behavior 7.5.1 The Logging Statement 223 DNS & BIND 7.5.2 Channel Details A channel may be defined to go to a file, to syslog, or to null 7.5.2.1... messages that interest you, configure your server to log only those messages 7.4 Changing BIND 8 System File Locations 7.6 Keeping Everything Running Smoothly [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 7.5.3 Category Details 228 DNS & BIND Chapter 7 Maintaining BIND 7.6 Keeping Everything Running Smoothly A significant part of maintenance is being... continues to run; it just isn't listening on any interfaces 7.6.2 Understanding the BIND Statistics Periodically, you should look over the statistics on some of your name servers, if only to see how busy they are We will show you an example of the name server statistics and discuss what each line means Name servers handle many queries and responses during normal operation, so first, we need to show you... delayed or lost by the underlying network, or perhaps the remote name server host might be busy with another application Figure 7.2: Example query/response exchange 7.6.2 Understanding the BIND Statistics 235 DNS & BIND Notice that a BIND name server is able to detect duplicate queries only while it is still trying to answer the original query The local name server detects the duplicate query from the application... resource limits on this system 229 DNS & BIND This means that your name server thinks your operating system does not support the getrlimit() and setrlimit() system calls, which are used when you try to define coresize, datasize, stacksize or files on a BIND 8 name server It doesn't matter whether you're actually using any of these substatements in your configuration file; BIND will print the message anyway . Files 7 .5 BIND 8 Logging [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 219 Chapter 7 Maintaining BIND 7 .5 BIND 8 Logging BIND. terminator named[ 356 5]: USAGE 824681342 824600 158 CPU=13.01u/3.26s CHILDCPU=9.99u/12.71s Feb 18 14:09:02 terminator named[ 356 5]: NSTATS 824681342 824600 158 A=4 PTR=2 DNS & BIND 230 Feb 18. zone files ; DNS & BIND 2 15 primary movie.edu primary/db.movie primary 249.249.192.in−addr.arpa primary/db.192.249.249 primary 253 . 253 .192.in−addr.arpa primary/db.192. 253 . 253 Here is conffile.slave