Configuring BIND 4


Another thing you will find in the 4.9.7 tar ball (it is in the BIND 8 distribution as well) is the BIND Operations Guide (BOG), which might or might not be included with your vendor BIND. The BOG is a very complete DNS manual; although it is somewhat abrupt about using new terms and is just a bit dated.

BIND 4 does not have the wealth of configurability that BIND 8 does; it does, however, have more possibilities than you can usually find in the named man page. Zone files used by BIND 4 are identical to the zone files used by BIND 8, except for the $TTL directive that BIND 4 does not support. A BIND 4 slave with a BIND 8 master, which uses $TTL, will give TTL values that are inconsistent with what the BIND 8 master does, if the $TTL value differs from the TTL given in the SOA record. Some registrar zone test scripts have been known to decline validating new zones for this reason.

Zones

The BIND 4 configuration file, which is a flat text file, is called named.boot. Each line starts with a keyword, followed by arguments and values. This is a simple file, corresponding roughly to the examples in Chapter 2, "DNS in Practice." Here is an example :

 directory       /var/named cache           .                                       root.hints primary         0.0.127.in-addr.arpa                    pz/127.0.0 secondary       penguin.bv              192.168.55.2    sz/penguin.bv secondary       55.168.55.in-addr.arpa  192.168.55.2    sz/192.168.55 stub            walruss.bv              10.1.0.2        sz/walruss.bv 

As you can see from this example, no quotes are used here. The directory line controls in which directory BIND looks for files. The cache line is similar to the root hints zone notice that a dot is in there. The primary line has three fields: the keyword, zone name, and zone filename. These are similar to the zones of type master. The secondary lines are similar to zones of type slave and have four fields: the keyword, zone name, and as many master IP numbers as you want. The last word on the secondary line should be the name of the zone file, which should start with an alphabetic character, not a number, so BIND can tell it from the master IP numbers. stub lines have the same format and work the same way as zones of type stub in BIND 8 .

Glue Fetching

Glue fetching can cause cache poisoning and is time-consuming. You can disable it with the following command :

 options       no-fetch-glue 

If you need the glue for specific zones, you might be better off turning off glue fetching and using the stub zone directive previously described instead.

Forwarders

Forwarding provides the same capabilities as in BIND 8. Here's its syntax:

 forwarders      10.1.0.2 192.168.55.2 options         forward-only 

Without the forward-only option, it acts as BIND 8's forward-first. Old versions of BIND 4 don't understand the forward-only option; instead, they implement the following slave directive, which is synonymous :

 slave 

This has nothing to do with the slave zones of BIND 8; this only controls forwarding.

Recursive Servers

In BIND 8, you can elect for whom you want to be a recursive server. BIND 4 either is recursive or is not it can't be controlled with ACLs :

 options        no-recursion 

Query Logging

In BIND 8 you can log queries, but only to a file, not via syslogd at all. This is because any server with more than a few clients causes a lot of logging, which bogs down the syslog facility. BIND 4, though, supports query logging only through syslog. So, if you turn it on, expect your syslogd to increase its CPU usage. Here is its syntax :

 options        query-log 

Other ways to enable logging are by starting named with the -q switch, and by sending it the SIGWINCH signal with the kill command. Please note that this uses a lot of disk space. And I do mean a lot, even for a very small server with few clients. Be sure you watch your disk the first few times you try this. According to Murphy's law, it will fill up and cause things to go wrong the moment you look away .

Zone Transfers

You cannot limit who gets to perform zone transfers from you on a zone-by-zone basis only one access list exists for all zones:

 xfrnets          172.16.25.66                   ; Illegal xfrnets          172.16.0.0                     ; Legal, net xfrnets          172.16.25.66&255.255.255.255   ; Legal, host 

The interesting part of the previous code is that BIND knows which network class the IP number is in and limits the zone transfer not to the given IP number, but to the implied network. Which class a network has is implied by the first octet in the address. The range 1 127 are A networks and have an implied subnet mask of 255.0.0.0. Networks 128 191 are B networks with a 255.255.0.0 subnet mask. Finally, networks 191 223 are C networks with 255.255.255.0 as the subnet mask. 172.16.25.66 then is a class B network, but BIND requires that you write the host part of the address as 0s, so the first line is illegal. The second line matches 172.16.0.0/255.255.0.0 because 172 networks are B networks. To match a single host, or a classless network, you can specify the mask using the syntax in the third line. (Be sure you don't put a space before or after the ampersand [&].)

This option was called tcplist for a short while. It is still a synonym.

Resource Limits

BIND 4 implements very few, but important, resource limits. All these are 1:1 with the corresponding BIND 8 options :

 limit        datasize             64m limit        files                1024 limit        transfers-in         10 limit        transfers-per-ns     2 

BIND will die, or just act strangely, when the data size and file limits are exceeded; therefore, you probably should raise the limits from the OS defaults. Whether data size and file limits are implemented, and adjustable, is dependent on your OS and the port of BIND to it. The Bourne shell command ulimit -a and the C shell command limit show the limits in force on your OS.

The values shown for limiting zone transfers are the default values. In old versions of BIND 4, the max-fetch directive was used instead of the transfers-in limit :

 max-fetch       10 

Address Sorting

BIND 4 has a feature called address sorting. When a host has two A records, BIND tries to find out which record is best for the querying party to use, and makes sure that this is the first record in the answer. This feature still exists in BIND 8, but not in the same manner. And in cases in which several A records exist, their order is now randomized, or round-robined, by default. As described in Chapter 3, this can serve as a load distribution mechanism .

BIND easily can make the wrong decision about which address is best, so what BIND thinks can be overridden with the sortlist directive . It has the same syntax as the xfrnets directive, and the same knowledge of network classes:

 sortlist       10.10.86.0&255.255.255.0 sortlist       192.168.24.0 

Any address appearing in the sort list is sorted before any address not appearing in the sort list. In some ways, this is worse than what BIND 4 does by default because no way is available to take the source address of the query into account. sortlist makes the sorting static.

In any case, sortlist is potentially useless the resolver that receives the answer can process the answer in any order it wants. If the resolver needs address sorting, it should do it itself because it has a better chance of knowing its local network topology than the resolver, which might draw incorrect conclusions based on the data available to it. Additionally, an optimal answer today is not optimal tomorrow. The BOG (anno 1993) largely concludes that address sorting should be smarter than it is, but it is probably best left to a device other than the DNS server. Other documentation calls it "useless" outright. In short, you might not want to use, or rely on, this feature. In BIND 8, the answer order is random instead .

A newer use for this feature, and the sort lists, in BIND 4 is that BIND tries to guess which nameserver is closer if several are available to ask. BIND 8 and 9 are switching to measuring the Round Trip Time (RTT) for queries and asking the server with the better RTT record.

Bogus Nameservers

As described in Chapter 8, "Security Concerns," you might not want to use some nameservers. In addition, because the black hole feature is not present in BIND 8, you at least should list the addresses the AUS-CERT advisory discussed in Chapter 8 as bogus. This will enable you to ensure that your server can't be spoofed by those addresses. This is achieved with the bogusns directive, which has the same syntax as xfrnets :

 bogusns 0.0.0.0&255.0.0.0       ; Null address bogusns 1.0.0.0&255.0.0.0       ; IANA reserved, popular fakes bogusns 2.0.0.0&255.0.0.0 bogusns 192.0.2.0&255.255.255.0 ; Test address bogusns 224.0.0.0&224.0.0.0     ; Multicast addresses ; These may be used internally in your organization, remove them if so. bogusns 10.0.0.0&255.0.0.0 bogusns 172.16.0.0&255.240.0.0 bogusns 192.168.0.0&255.255.0.0 

These servers will not be queried, and the answers they might supply would not be used anyway. As with BIND 8, zones for which any real servers that bogusns lists as authoritative will not be reachable. They will not be queried no matter how authoritative they are and the domains they serve will not resolve for you. Therefore, use bogusns with care .

Inverse Query

Ancient DNS specified an IQUERY query. It is no longer supported by default, and according to the documentation, only poorly written software ever used it and for no good purpose. BIND 4 can fake IQUERY answers :

 options fake-iquery 

Query Domain

The domain directive is supported by some very old BIND 4s. If queries for non-FQDN names are made, BIND appends the specified domain to the queried name and tries to resolve it:

 domain berkeley.edu 

For example, queries for ucbvax would be changed to ucbvax.berkeley.edu and then resolved. This feature is now in the resolver where it belongs and is controlled with the search and domain directives in resolv.conf.

Name Checking

BIND 4.9.4 introduced name checking , enforcing the restrictions on which characters can be used in names. This causes some surprises, though most notably, the slash (/) and underscore (_) are not allowed. Various levels of checking are performed on different types of data. Here are the defaults:

 check-names primary fail check-names secondary warn check-names response ignore 

If your primary zones contain any illegal names, you can override the primary default setting it to warn or ignore and fix it as time allows. See Chapter 17, "Miscellany," for more information about check-names.



The Concise Guide to DNS and BIND
The Concise Guide to DNS and BIND
ISBN: 0789722739
EAN: 2147483647
Year: 1999
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net