Section 6.1. DNS Basics

Although I just said this chapter assumes familiarity with DNS, let's clarify some important DNS terminology and concepts with an example.

Suppose someone (myhost.someisp.com in Figure 6-1) is surfing the Web and wishes to view the site http://www.dogpeople.org. Suppose also that this person's machine is configured to use the name server ns.someisp.com for DNS look-ups. Since the name "www.dogpeople.org" has no meaning to the routers through which the web query and its responses will pass, the user's web browser needs to learn the Internet Protocol (IP) address associated with http://www.dogpeople.org before attempting the web query.

First, myhost asks ns whether it knows the IP address. Since ns.someisp.com isn't authoritative for dogpeople.org and hasn't recently communicated with any host that is, it begins a query on the user's behalf. Making one or more queries in order to answer a previous query is called recursion.

Figure 6-1. A recursive DNS query

Ns.someisp.com begins its recursive query by asking a root name server for the IP address of a host that's authoritative for the zone dogpeople.org. (All Internet DNS servers use a static "hints" file to identify the 13 or so official root name servers. This list is maintained at ftp://ftp.rs.internic.net/domain and is called named.root.) In our example, ns asks E.ROOT-SERVERS.NET (an actual root server whose IP address is currently 193.203.230.10), who replies that DNS for dogpeople.org is handled by woofgang.dogpeople.org, whose IP address is 55.100.55.100.

Ns then asks woofgang (using woofgang's IP address, 55.100.55.100) for the IP of www.dogpeople.org. Woofgang returns the answer (55.100.55.244), which ns forwards back to myhost.someisp.com. Finally, myhost contacts 55.100.55.244 directly via http and performs the web query.

This is the most common type of name look-up. It and other single-host type look-ups are simply called queries; DNS queries are handled on UDP port 53.

Not all DNS transactions involve single-host look-ups, however. Sometimes it is necessary to transfer entire name-domain (zone) databases: this is called a zone transfer , and it happens when you use the end-user command host with the -l flag and dig with query-type set to axfr. The output from such a request is a complete list of all DNS records for the requested zone.

host and dig are normally used for diagnostic purposes, however; zone transfers are meant to be used by name servers that are authoritative for the same domain to stay in sync with each other (e.g., for "master to slave" updates). In fact, as we'll discuss shortly, a master server should refuse zone-transfer requests from any host that is not a known and allowed slave server. Zone transfers are handled on TCP port 53.

The last general DNS concept we'll touch on here is caching. Name servers cache all local zone files (i.e., their hints file plus all zone information for which they are authoritative), plus the results of all recursive queries they've performed since their last startup ? that is, almost all. Each resource record (RR) has its own (or inherits its zone file's default) time-to-live (TTL) setting. This value determines how long each RR can be cached before being refreshed.

This, of course, is only a fraction of what one needs to learn to fully understand and use BIND. But it's enough for the purposes of discussing BIND security.