Introduction to DNS Structure, Functions, and Software
| DNS is a hierarchical protocol, operating across the Internet in a fashion similar to how routing works. A number of "root servers" are maintained by various university and government entities, distributed geographically around the Internet for redundancy reasons. The list of root servers is maintained by the Internet Corporation for Assigned Names and Numbers (ICANN), and their locations are listed at http://www.root-servers.org. Each domain name (for instance, example.com) is defined in backward order from the root zone, with the domain suffixcom, org, net, and so onbeing the topmost layer of the hierarchy directly under the . (a single dot), which refers to the root zone. Below each of the suffixes (commonly known as top-level domains, or TLDs) are the regular domain names, each typically defined not by the root servers but by individual DNS hosts on the Internet. The example.com domain, for example, would have its DNS administered by a server on its own network, such as ns1.example.com. This server is the "authoritative" DNS host for that domain. A central registryalso maintained by ICANNkeeps records of these individual domains so that the root servers can provide authoritative lookup information on them. You define these "host records" when setting up a new name server by submitting a form to a domain registrar such as Network Solutions or any of the hundreds of other accredited registrars that are recognized by ICANN. When a client makes a DNS request, it queries the name server configured in its TCP/IP settingsusually a server on its own network, as shown in Figure 32.1. If that server cannot answer the request, it passes the request on to its upstream DNS forwarder if one is available. If not, the request goes directly to the root servers. Figure 32.1. A diagram of a DNS lookup, showing the path from a client to the local DNS, the root servers, and the authoritative name server. The root servers don't maintain any authoritative DNS data of their own. All they have are host records, which you will come to know as NS records, which point to the authoritative name servers for each domain. The root servers send back a DNS response that refers the requester to the authoritative name server for the domain the client wants to find out about. This server sends back the requested DNS data to the local DNS machine, which passes it back through to the client. The local DNS might keep lookup information around in its cache for a period of time specified by the authoritative name server. This speeds up the query process, allowing local clients to get immediate responses to their DNS queries from the local server without the queries having to travel out over the Internet. However, this means that changes to DNS records at the authoritative DNS will not be available to the client until the expiration period has passed. Until that time, the DNS information the client sees is "stale" and potentially inaccurate. The time period between DNS cache updates can be controlled for each domain using the Time-To-Live (TTL) value, which you will learn more about later in this chapter. DNS Software: BINDDNS software is ubiquitous. For UNIX systems, which account for the vast majority of name servers on the Internet, the software of choice is BIND, by the Internet Software Consortium (ISC). BIND, short for Berkeley Internet Name Domain, consists of one major daemon program (named), a set of resolver libraries that provides the ability to perform name lookups, and various administrative tools. BIND is built into FreeBSD, although it is not enabled by default. ZonesBIND allows you to define zones, which are logical groupings of IP addresses and hostnames that exist at a certain level in the DNS naming hierarchy. For example, com. is a zone under the root (.) zone, and example.com. is a zone that exists underneath the com. zone. Note that zone names always end in a dot, referring to the root zonethis will be important when you create your zone files! Subdomains are zones managed by the individual domain name servers; cluster.example.com. is a zone that can have multiple machines inside itindeed, it can have as many further subdivisions within it as you are willing to configure. These zones provide forward DNS lookups, or mappings from names to IP addresses. Similarly, reverse DNS lookupsor mappings from IP addresses to hostnamesare managed in zones. Because DNS and IP addresses have their roots in the ARPAnet (see Chapter 22 for details) and have not changed fundamentally in structure since that time, a reverse DNS zone name is of the form CCC.BBB.AAA.in-addr.arpa. This is a name constructed of the IP address space in reverse order, with .in-addr.arpa appended to it. For example, the 64.41.131.* network would be defined by the zone 131.41.64.in-addr.arpa. Each zone that your name server will manage must be defined in a zone filea formatted text database of definitions that map hostnames to IP addresses (or vice versa) within the zone. A zone file also contains parameters for the behavior of the zone, such as the caching expiration period. The zone files are the most critical part of proper DNS configuration; we will be discussing them in detail later in this chapter. BIND Files and ProgramsBecause BIND is a built-in part of FreeBSD, you don't need to worry about installing it or making sure the proper files are in the proper places. It is worthwhile, though, to know what programs are involved in name server operations and where you will be making your configuration changes:
|
