You normally use DNS when you display a Web page. For example, to display Red Hat's home page, you enter its name, www.redhat.com, in a browser and the browser displays the page you want. You never enter or see the IP address for the displayed page. However, without the IP address, the browser could not display the page. DNS works behind the scenes to find the IP address when you enter the name in the browser. The DNS database is
As implemented, DNS is
History The mapping that DNS does was originally done statically in a /etc/hosts file (page 452) on each system on a network. Small LANs still make use of this file. As networksspecifically the Internetgrew, a dynamic mapping system was required. DNS was specified in 1983 and BIND became part of BSD in 1985.
Security BIND is by far the most popular implementation of a DNS. However, recently concerns about its security have arisen. You may want to run BIND inside a chroot jail (page 750) or under SELinux (page 400) and use transaction signatures (TSIG, page 748) to improve security.
host and dig The host and dig utilities (page 368) query DNS servers. The host utility is simpler, is easier to use, and returns less information than dig. This chapter uses both tools to explore DNS. Nodes, Domains, and SubdomainsEach node in the hierarchical DNS database is called a domain and is labeled with a (domain) name. As with the Linux file structure, the node at the top of the DNS hierarchy is called the root node or root domain. While the Linux file structure separates the nodes (directory and ordinary files) with slashes (/) and labels the root node (directory) with a slash, the DNS structure uses periods (Figure 24-1). Figure 24-1. The DNS domain structureYou read an absolute pathname in a Linux filesystem from left to right: It starts with the root directory (/) at the left and, as you read to the right, describes the path to the file being identified (for example, /var/named/named.ca). Unlike a Linux pathname, you read a DNS domain name from right to left: It starts with the root domain at the right (represented by a period [.]) and, as you read to the left, works its way down through the top-level and second-level domains to a subdomain or host. Frequently the name of the root domain (the period at the right) is omitted from a domain name. The term domain refers both to a single node in the DNS domain structure and to a catenated, period-separated list (path) of domain names that describes the location of a domain.
FQDN A fully qualified domain name (FQDN) is the DNS equivalent of a filesystem's absolute pathname: It is a pointer that positively locates a domain on the Internet. Just as you (and Linux) can identify an absolute pathname by its leading slash (/) that names the root directory, so an FQDN can be identified by its trailing period (.) that names the root domain (Figure 24-2). Figure 24-2. A fully qualified domain name (FQDN)
Resolver The resolver comprises the routines that turn an unqualified domain name into an FQDN that is passed to DNS to be mapped to an IP address. The resolver can append several domains, one at a time, to an unqualified domain name, producing several FQDNs that it passes, one at a time, to DNS. For each FQDN, DNS reports success (it found the FQDN and is returning the corresponding IP address) or failure (the FQDN does not exist). The resolver always appends the root domain (.) to an unqualified domain name first, allowing you to type www.redhat.com instead of www.redhat.com. (including the trailing period) in a browser. You can specify other domains for the resolver to try if the root domain fails. Put the domain names, in the order you want them tried, after the search keyword in /etc/resolv.conf (page 455). For example, if your search domains include redhat.com., then the domains rhn and rhn.redhat.com. resolve to the same address.
Subdomains Each node in the domain hierarchy is a domain. Each domain that has a parent (that is, every domain except the root domain) is also a subdomain, regardless of whether it has children. All subdomains can resolve to hostseven those with children. For example, the redhat.com. domain resolves to the host that serves the Red Hat Web site, without preventing its childrendomains such as fedora.redhat.com.from resolving. The leftmost part of an FQDN is often called the hostname.
Hostnames In the past, hostnames could contain only characters from the set az, AZ, 09, and . As of March 2004, however, hostnames can include various accents, umlauts, and so on (www.switch.ch/id/idn). DNS considers uppercase and lowercase letters to be the same (it is not case sensitive), so www.sobell.com is the same as WWW.sObEll.coM. ZonesFor administrative purposes, domains are grouped into zones that extend downward from a domain (Figure 24-3). A single DNS server is responsible for (holds the information required to resolve) all domains within a zone. The DNS server for a zone also holds pointers to DNS servers that are responsible for the zones immediately below the zone it is responsible for. Information about zones originates in zone files, one zone per file. Figure 24-3. DNS structure showing zones
Root domain The highest zone, the one containing the root domain, does not contain any hosts. Instead, this domain delegates to the DNS servers for the top-level domains (Figure 24-1, page 721).
Authority Each zone has at least one authoritative DNS server. This server holds all information about the zone. A DNS query returns information about a domain and specifies which DNS server is authoritative for that domain. DNS employs a hierarchical structure to keep track of names and authority. At the top or root of the structure is the root domain, which employs 13 authoritative nameservers. These are the only servers that are authoritative for the root and top-level domains.
Delegation of authority When referring to DNS, the term delegation means delegation of authority. ICANN (Internet Corporation for Assigned Names and Numbers, www.icann.org) delegates authority to the root and top-level domains. In other words, ICANN says which servers are authoritative for these domains. Authority is delegated to each domain below the top-level domains by the authoritative server at the next-higher-level domain. ICANN is not authoritative for most second-level domains. For example, Red Hat is authoritative for the redhat.com domain. This scheme of delegating authority allows for local control over segments of the DNS database while making all segments available to the public. Queries
Iterative query There are two types of DNS queries: iterative and recursive.[1] An iterative query sends a domain name to a DNS server and asks the server to return either the IP address of the domain or the name of the DNS server that is authoritative for the domain or one of its parents: The server does not query other servers when seeking an answer. Nameservers typically send each other iterative queries.
Recursive query A recursive query sends a domain name to a DNS server and asks the server to return the IP address of the domain: The server may need to query other servers to get the answer. Both types of queries can fail, in which case the server returns a message saying it is unable to locate the domain. When a client, such as a browser, needs the IP address that corresponds to a domain name, the client queries a resolver. Most resolvers are quite simple and require a DNS server to do most of the work: That is, they send recursive queries. The resolver communicates with a single DNS server, which can perform multiple iterative queries in response to the resolver's recursive query. All DNS servers must answer iterative queries. DNS servers can also be set up to answer recursive queries. A DNS server that is not set up to answer recursive queries treats a recursive query as though it is an iterative query. In Figure 24-4, the resolver on a client system is trying to discover the address of the server ftp.site1.example.com. on the network with the DNS layout shown in Figure 24-3 on page 723. The resolver on the client sends a recursive query to its primary DNS server. This server interrogates the root server and one additional server for each zone until it receives an answer, which it returns to the resolver on the client. In practice, the query would not start with the root server because most servers usually have the location of the authoritative nameserver for the com. domain stored in cache (memory). Figure 24-4. A recursive query that starts several iterative queries to find the answerServersThere are three main types of DNS servers: primary (master), secondary (slave), and caching-only.
It is possiblebut for reasons of security not recommendedfor the same server to be the primary master server (authoritative) for some zones and a DNS cache for others. When the same server acts as both a DNS cache and a master server, if a malicious local user or malfunctioning resolver on the local network floods the DNS cache with more traffic than it can handle (a DoS attack), users may be prevented from accessing the public servers that the primary master server handles. Conversely, if the authoritative server is compromised, the attacker can subvert all traffic leaving the network. Resource RecordsInformation about nodes (domains) in the DNS database is stored in resource records. Resource records are kept in zone files (page 741). The zone that a resource record pertains to is defined by the zone file that contains the resource record. The zone is named in the named.conf file (page 739) that references the zone file. A resource record has the following fields:
If the Name field is missing, the resource record inherits the name from the previous resource record in the same file. Cached resource records become out-of-date when the information in the record changes on the authoritative server. The TTL field indicates the maximum time a server may keep a record in cache before checking whether a newer one is available. Typically, the TTL is on the order of days. A TTL of 0 means that the resource record should not be cached. More than 30 types of resource records exist, ranging from common types, such as address records that store the address of a host, to those that contain geographical information. The following paragraphs describe the types of resource records you are most likely to encounter.
A IPv4 Address Maps a domain name to the IPv4 address of a host. There must be at least one address record for each domain; multiple address records can point to the same IP address. The Name field holds the domain name, which is assumed to be in the same zone as the domain. The Data field holds the IP address associated with the name. The following address resource record maps the ns domain in the zone to 192.168.0.1: ns IN A 192.168.0.1
AAAA IPv6 Address Maps a domain name to the IPv6 address of a host. The following address resource record maps the ns domain in the zone to an IPv6 address: ns IN AAAA 2001:630:d0:131:a00:20ff:feb5:ef1e
CNAME Canonical Name Maps an alias or nickname to a domain name. The Name field holds the alias or nickname; the Data field holds the official or canonical name. CNAME is useful for specifying an easy-to-remember name or multiple names for the same domain. It is also useful when a system changes names or IP addresses. In this case the alias can point to the real name that must resolve to an IP address. When a query returns a CNAME, a client or DNS tool performs a DNS lookup on the domain name returned with the CNAME. It is acceptable to provide multiple levels of CNAME records. The following resource record maps ftp in the zone to www.sam.net.: ftp IN CNAME www.sam.net.
MX Mail Exchange Specifies a destination for mail addressed to the domain. MX records must always point to A (or AAAA) records. The Name field holds the domain name, which is assumed to be in the zone; the Data field holds the name of a mail server preceded by its priority. Unlike A records, MX records contain a priority number that allows mail delivery agents to fall back to a backup server in case the primary server is down. Several mail servers can be ranked in priority order, where the lowest number has the highest priority. DNS selects randomly from among mail servers with the same priority. The following resource records forward mail sent to speedy in the zone first to mail in the zone and then, if that fails, to mail.sam.net.. The value of speedy in the Name field on the second line is implicit. speedy MX 10 mail MX 20 mail.sam.net.
NS Nameserver Specifies the name of the system that provides domain service (DNS records) for the domain. The Name field holds the domain name; the Data field holds the name of the DNS server. Each domain must have at least one NS record. DNS servers do not need to reside in the domain and, in fact, it is better if at least one does not. The system name ns is frequently used to specify a nameserver, but this name is not required and does not have any significance beyond assisting humans in identifying a nameserver. The following resource record specifies ns.max.net. as a nameserver for peach in the zone: peach NS ns.max.net.
PTR Pointer Maps an IP address to a domain name and is used for reverse name resolution. The Name field holds the IP address; the Data field holds the domain name. Do not use PTR resource records with aliases. The following resource record maps 3 in a reverse zone (for example, 3 in the 0.168.192.in-addr.arpa zone is 192.168.0.3) to grape in the zone: 3 IN PTR grape For more information refer to "Reverse Name Resolution" on page 729.
SOA Start of Authority Designates the start of a zone. Each zone must have exactly one SOA record. An authoritative server maintains the SOA record for the zone it is authoritative for. All zone files must have one SOA resource record, which must be the first resource record in the file. The Name field holds the name of the domain at the start of the zone. The Data field holds the name of the host the data was created on, the email address of the person responsible for the zone, and the following information enclosed within parentheses (the opening parenthesis must appear on the first physical line of an SOA record): serial A value in the range 12,147,483,647. A change in this number indicates that the zone data has changed. By convention, this field is set to the string yyyymmddnn (year, month, day, change number). Along with the date, the final two digitsthat is, the change numbershould be incremented each time you change the SOA record. refresh The elapsed time after which the primary master server notifies slave (secondary) servers to refresh the record; the time between updates. retry The time to wait after a refresh fails before trying to refresh again. expiry The elapsed time after which the zone is no longer authoritative and the root servers must be queried. The expiry applies to slave servers only. minimum The negative caching TTL, which is the amount of time that a nonexistent domain error (NXDOMAIN) can be held in a slave server's cache. A negative caching TTL is the same as a normal TTL except that it applies to domains that do not exist rather than to domains that do exist. The $TTL directive (page 742) specifies the default zone TTL (the maximum amount of time that data stays in a slave server's cache). Jointly, the default zone TTL and the negative caching TTL encompass all types of replies the server can generate. The following two SOA resource records are equivalent: @ IN SOA ns.zach.net. mgs@sobell.com. ( 2005111247 8H 2H 4W 1D ) @ IN SOA ns.zach.net. mgs@sobell.com. ( 2005111247 ; serial 8H ; refresh 2H ; retry 4W ; expire 1D ) ; minimum The second format is more readable because of its layout and the comments. The at symbol (@) at the start of the SOA resource record stands for the zone name, also called the origin, as specified in the named.conf file. Because the named.conf file specifies the zone name to be zach.net, you could rewrite the first line as follows: zach.net. IN SOA ns.zach.net. mgs@sobell.com. ( The host utility returns something closer to the first format with each of the times specified in seconds: $ host -t soa zach.net zach.net. SOA ns.zach.net. mgs\@sobell.com. 03111 28800 7200 2419200 86400
TXT Text Associates a character string with a domain. The Name field holds the domain name. The data field can contain up to 256 characters and must be enclosed within quotation marks. TXT records can contain any arbitrary text value. As well as general information, they can be used for things such as public key distribution. Following is a TXT resource record that specifies a company name: zach.net IN TXT "Sobell Associates Inc." DNS Query and Response
Query A DNS query has three parts:
Cache Most DNS servers store in cache memory the query responses from other DNS servers. When a DNS server receives a query, it first tries to resolve the query from its cache. Failing that, the server may query other servers to get an answer. Because DNS uses cache, when you make a change to a DNS record, the change takes timesometimes a matter of daysto propagate through the DNS hierarchy.
Response A DNS message that is sent in response to a query has the following structure:
The dig utility does not consult /etc/nsswitch.conf (page 435) to determine which server to query. The following example uses dig to query a DNS server: $ dig fedora.redhat.com ... ;; QUESTION SECTION: ;fedora.redhat.com. IN A ;; ANSWER SECTION: fedora.redhat.com. 600 IN CNAME www.redhat.com. www.redhat.com. 330 IN A 209.132.177.50 ;; AUTHORITY SECTION: redhat.com. 409 IN NS ns1.redhat.com. redhat.com. 409 IN NS ns2.redhat.com. redhat.com. 409 IN NS ns3.redhat.com. ;; ADDITIONAL SECTION: ns1.redhat.com. 300 IN A 66.187.233.210 ns2.redhat.com. 600 IN A 66.187.224.210 ns3.redhat.com. 600 IN A 66.187.229.10 ... Reverse Name ResolutionIn addition to normal or forward name resolution, DNS provides reverse name resolution, also referred to as inverse mapping or reverse mapping, so that you can look up domain names given an IP address. Because resource records in the forward DNS database are indexed hierarchically by domain name, DNS cannot perform an efficient search by IP address on this database. DNS implements reverse name resolution by means of a special domain named in-addr.arpa (IPv4) or ip6.arpa (IPv6). Resource records in these domains have Name fields that hold IP addresses; the records are indexed hierarchically by IP address. The Data fields hold the FQDN that corresponds to the IP address. Reverse name resolution can verify that someone is who he says he is or at least is from the domain he says he is from. In general, it allows a server to retrieve and record the domain names of the clients it provides services to. For example, legitimate mail contains the domain of the sender and the IP address of the sending machine. A mail server can verify the stated domain of a sender by checking the domain associated with the IP address. Reverse name resolution is also used by anonymous FTP servers to verify that a domain specified in an email address used as a password is legitimate. For example, to determine the domain name that corresponds to an IP address of 209.132.177.110, a resolver would query DNS for information about the domain named 110.177.132.209.in-addr.arpa (Figure 24-5, next page). Figure 24-5. Reverse name resolution and the in-addr.arpa domain
The following example uses dig to query DNS for the IP address that corresponds to rhn.redhat.com, which is 209.132.177.110. The second command line uses the dig utility to query the same IP address, reversed, and appended with .in-addr.arpa: 110.177.132.209.in-addr.arpa to display a PTR resource record (page 727). The data portion of the resultant resource record is the domain name from the original query: rhn.redhat.com. $ dig rhn.redhat.com ... ;; QUESTION SECTION: ;rhn.redhat.com. IN A ;; ANSWER SECTION: rhn.redhat.com. 60 IN A 209.132.177.110 ... $ dig 110.177.132.209.in-addr.arpa PTR ... ;; QUESTION SECTION: ;110.177.132.209.in-addr.arpa. IN PTR ;; ANSWER SECTION: 110.177.132.209.in-addr.arpa. 600 IN PTR rhn.redhat.com. ... Instead of reformatting the IP address as in the preceding example, you can use the x option to dig to perform a reverse query: $ dig -x 209.132.177.110 ... ;; QUESTION SECTION: ;110.177.132.209.in-addr.arpa. IN PTR ;; ANSWER SECTION: 110.177.132.209.in-addr.arpa. 456 IN PTR rhn.redhat.com. ... Or you can just use host: $ host 209.132.177.110 110.177.132.209.in-addr.arpa domain name pointer rhn.redhat.com. |