UNIX System Administration Handbook - Evi Nemeth [242]
VERSION.BIND. 0S CHAOS TXT "wouldn't you like to know..."
Some sites configure BIND to conceal its version number on the theory that this provides some degree of “security through obscurity.” We don’t really endorse this practice, but it might help fend off some of the script kiddies. See page 417 for a more detailed discussion of this topic.
You can also usually tell what BIND version you have by inspecting the log files in /var/log or its equivalent on your system. The BIND server daemon, named, logs its version number to syslog (facility “daemon”) as it starts up. grep for lines like these:
Dec 13 16:32:27 disaster named[2399]: starting. named 4.9.7 Wed Sep 2 09:39:
12 GMT 1998 PHNE_14618
Dec 13 16:35:13 suod named[9325]: starting. named 8.2.2-P3 Wed Nov 10 17:
27:59 MST 1999 millert@haxrus /nfs/depot/src/cs/Bind/bind-8.2.2-
P3/obj/sun4+SunOS4/bin/named
See Chapter 11 for more information about syslog.
The first line is from HP-UX 11.00 as it is shipped, and the second is from a SunOS machine as we maintain it locally. The last line lies a bit since patch 4 for BIND 8.2.2 didn’t increment the patch level. It is really 8.2.2-P4.
If named is installed but your system does not normally start it at boot time, just run it by hand as root with no arguments. named will log its version number, realize that it has no configuration file, and exit.
Table 16.4 on the next page shows the versions of BIND that are included with our example systems. Versions less than 8.2.2-P3 have known security problems.
Table 16.4 Versions of BIND on our example systems
Red Hat has been known to freeze version numbers, then install patches, thus putting themselves out of sync with the rest of the community. Ergo, their 8.2 might be OK, although it violates the 8.2.2-P3 warning above. Red Hat’s internal version numbers are included in the names of package files and sometimes have an internal bug fix number or patch number appended. For example, bind-8.2-7.arch.rpm is Red Hat’s version 7 of isc.org’s version 8.2. Confusing.
Components of BIND
The BIND system has three components:
• A daemon called named that answers queries
• Library routines that resolve host queries by contacting the servers of the DNS distributed database
• Command-line interfaces to DNS: nslookup, dig, and host
In DNS parlance, a daemon like named (or the machine on which it runs) is called a “name server,” and the client code that contacts it is called a “resolver.” We briefly discuss the function of each component below but postpone the actual configuration of BIND until page 410.
named: the BIND name server
named answers queries about hostnames and IP addresses. If named doesn’t know the answer to a query, it asks other servers and caches their responses. named also performs “zone transfers” to copy data among the servers of a domain. (A “zone” is a domain minus its subdomains. Name servers deal with zones, but “domain” is often used where “zone” is really meant.)
Name servers can operate in several different modes. The distinctions among them fall along several axes, so the final categorization is often not very tidy. To make things even more confusing, a single server can play different roles with respect to different zones. Table 16.5 lists some of the adjectives used to describe name servers. Indented entries are loosely classified under their unindented headings.
Table 16.5 A name server taxonomy
a. A distribution server can be visible to anyone who knows its IP address.
b. Strictly speaking, “nonauthoritative” is an attribute of a DNS query response, not a server.
These categorizations are based on a name server’s source of data (authoritative, caching, master, slave), on the type of data saved (stub), on the query path (forwarders), on the type of answers handed out (recursive, nonrecursive), and finally, on the visibility of the server (distribution). The next few sections provide some additional details on the most important of these distinctions; the other distinctions