Lecture 12

BIND and Name Service

A severe security problem exists in every version of BIND before 8.2.3. You mst NEVER use a bind version numbered lower than 8.2.3 if you want to be any where near safe.

I do not believe that bind is installed on your systems. Use apt-get to retrieve the current distributed version of bind so you will be able to provide name service.

Once you've got a zone to administer, then you need to provide files that tell named how to do its work. For BIND 8 or 9, these files include:

1. /etc/bind/named.conf, your named configuration file
2. /etc/bind/db.*, your own zone files, one describing each zone you administer, and zone files describing zones for which you are a slave server.

A master or primary is supposed to provide accurate information for a zone. Such a name server is said to be authoritative because it is authorized to give you this information.

A slave or secondary name server keeps copies of all the information a primary name server provides and will provide that same information for the zone. Most other name servers will cache only that information they encounter as a result of resolving specific names from other primary name servers. The slave keeps all the information from a set of zone files.

The information provided by a slave nameserver is authoritative, just like the information provided by the master. Information provided by any nameserver about a name outside its zone is non-authoritative.

The process of iteratively contacting each nameserver down the hierarchy to resolve a name assumes we are contacting non-recursive name servers. Most programs are incapable of dealing with responses (forwarding the process to another name server) provided by non-recursive nameservers. Most processes expect to contact a name server that does recursive resolution (making the extra requests by itself).

The top-level servers in the Internet name hierarchy are not recursive. Can you guess why?

The default for BIND 9 is to provide recursive name service to every requesting entity. A name server can, however, be set to be non-recursive (by setting the recursion option to value no) or can be recursive only for a given CIDR block (presumably its zone) and iterative for every other zone by setting the allow-recursion option in the appropriate configuration file (see below):

allow-recursion 128.227.170.64/27;

BIND Specifics for your machines

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind/README.Debian for information on the 
// structure of BIND configuration files in Debian for BIND versions 8.2.1 
// and later, *BEFORE* you customize this configuration file.
//

include "/etc/bind/named.conf.options";

// reduce log verbosity on issues outside our control
logging {
	category lame-servers { null; };
	category cname { null; };
};

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

zone "unix-ippd.cise.ufl.edu" {
	type master;
	file "/etc/bind/db.unix-ippd";
};

zone "unix-ippd.170.227.128.in-addr.arpa" {
	type master;
	file "/etc/bind/db.128.227.170.unix-ippd";
};

// add local zone definitions here
include "/etc/bind/named.conf.local";

• directory "/var/cache/bind";
  This tells where to cache slave files grabbed from master servers.

• fetch-glue no;
  This disables an obsolete practice of fetching what are called glue records when construction responses (now considered to be a bad idea).

We'll start by talking about the "." zone and the db.root file. This db.root file comes from ftp://ftp.rs.internic.net/domain/named.root. It tells about the name servers for ".".

The other files contain several types of information. db.unix-ippd which describes zone "unix-ippd.cise.ufl.edu" looks like this:

;
; BIND data file for unix-ippd.cise.ufl.edu
;
$TTL	604800
@	IN	SOA	delorean.unix-ippd.cise.ufl.edu. mfoster.cise.ufl.edu. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
	IN	NS	delorean.unix-ippd.cise.ufl.edu.

localhost	IN	A	127.0.0.1

unix-ippd.cise.ufl.edu.	IN	A	128.227.170.67

delorean	IN	A	128.227.170.67

The first entry in this file is a TTL, time-to-live. This tells how long positive name information is valid in this file. All your time-to-lives should be quite short. Perhaps as little as 1 hour. In that way, any machine (like butch) who caches information for your name server will reset its information soon after any mess-up you might make in your zone files. What do you think about the TTL value in our file?

The file contains an SOA record (Start of Authority) that tells the name of the zone and an email address for the zone contact and information about timeout values for slave name servers. The @ (at-sign) in the SOA refers to the current zone name. At this point, it is the zone name associated with this zone file in the named.conf file, namely unix-ippd.cise.ufl.edu.

The first machine name listed after SOA is the name server for domain.
The entry that follows is an email address of the person to contact about that zone. (Note the quirky use of a dot instead of @ for associating the account with its mail host.)
The next entry is a list of numbers:

• The serial number.
  This must be a 32 bit integer, and it must be reset to a higher number whenever you change your file if slave name servers are to discover that new data is being reported.

  It is customary to use a date followed by a two digit sequence number (e.g. YYYYMMDDSS). Since 2^31 - 1 is 2147483647, this plan will fail in the year 2138. I will make sure to roll my numbers back in 2147 if the IETF hasn't come up with a new plan by then.

  What do you think of the serial number in our file?

• The second number is the refresh interval. This tells how often a slave name server should wait before checking with the master to see if the serial number of the file has changed. What relationship do you think this should have to the TTL?

• The next number, the retry interval tells how often a slave should attempt to get the zone file information again if it has failed to connect after the refresh interval. This interval should be short, since downtimes may be followed by changes to name service.

• This is followed by the expire period, which tells how long the slave is to continue giving data about the master's domain without being able to contact the master. This generally should be a week or more since a disastrous outage of one machine shouldn't force you to have to reconfigure name service for your whole network.

• The last number is the minimum. In older versions of BIND, this was the same as TTL. Now, it tells the amount of time to cache negative answers about the zone.

IN NS delorean.unix-ippd.cise.ufl.edu

zone [ttl] IN NS hostname

Finally, it contains an A (address) record telling what addresses various names map to on this local network. The form of an A record is:

name [ttl] IN A ipaddr

At this time, the only name bound in the unix-ippd.cise.ufl.edu domain is delorean. The rest of your machines need to be added to this file with their associated static ip addresses. A sample entry might be the following:

;-------------- team 1 --------------
johnnybgood     IN A 128.227.170.70 ; team 1 host
team01          IN CNAME johnnybgood     ; alias (easy to remember) for this machine

Note that the name for localhost and the other records are not fully qualified. Any name that does not end with a dot will have the zone name appended to it. Thus, the A record for localhost is really an A record for localhost.unix-ippd.cise.ufl.edu.

The CNAME records identify aliases (alternate names) for hosts. A CNAME associates a given name with a source host name. When receiving a CNAME record in response to a query on a name, a name server will switch its query to one for the source host name. BIND will allow an 8-deep nesting of CNAME records.

The db.128.227.170.unix-ippd file that describes zone "unix-ippd.170.227.128.in-addr.arpa" contains reverse pointer information. It looks like this:

;
; BIND reverse data file for local loopback interface
;
$TTL	604800
@	IN	SOA	delorean.unix-ippd.cise.ufl.edu. mfoster.cise.ufl.edu. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
	IN	NS	delorean.unix-ippd.cise.ufl.edu.
;
67	IN	PTR	delorean.unix-ippd.cise.ulf.edu.

A PTR record associates an IP address in the domain with the machine name associated with that address. If the A records and the PTR records do not match (if they have different associated names), this will cause no end of trouble connecting to services such as netstat, tcpd, sendmail, sshd, X Windows, syslogd, fingerd, ftpd, and rlogind (did I say rlogind???) each of which will require a match between forward and reverse mapping of a name in order to trust a connection.

There needs to be an entry for each of your machines in this file. These entries should be something like the following:

70 IN PTR johnnybgood.unix-ippd.cise.ufl.edu.

;
; BIND reverse data file for local loopback interface
;
$TTL	604800
@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	localhost.
1.0.0	IN	PTR	localhost.

When you resolve a host name (convert if from a host name into an IP address), you must do it with respect to some underlying domain. By default, the domain the name is resolved in is the top level domain (.). If you want name searches to be resolved with respect to the current domain, you must set the domain name in the file /etc/resolv.conf! You may want to set a search path of domains against which names should be resolved (in order). The file /etc/resolv.conf on delorean looks like this:

nameserver 128.227.170.67
domain unix-ippd.cise.ufl.edu
search unix-ippd.cise.ufl.edu cise.ufl.edu ufl.edu

You can use nslookup (now considered obsolete) or dig to look up a name. To look up a name using dig, applying the search path specified in resolv.conf, you execute a command like the following:

dig +search johnnybgood

; <<>> DiG 9.2.4rc7 <<>> +search johnnybgood
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38480
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;johnnybgood.unix-ippd.cise.ufl.edu. IN A

;; ANSWER SECTION:
johnnybgood.unix-ippd.cise.ufl.edu. 604800 IN A 128.227.170.70

;; AUTHORITY SECTION:
unix-ippd.cise.ufl.edu. 604800  IN      NS      delorean.unix-ippd.cise.ufl.edu.

;; ADDITIONAL SECTION:
delorean.unix-ippd.cise.ufl.edu. 604800 IN A    128.227.170.67

;; Query time: 0 msec
;; SERVER: 128.227.170.67#53(128.227.170.67)
;; WHEN: Wed Sep 29 11:41:16 2004
;; MSG SIZE  rcvd: 107