Introduction to DNS


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

  • Hierarchical, so that it provides quick responses to queries: DNS has a root, branches, and nodes.

  • Distributed, so that it offers fast access to servers. The DNS database is spread across thousands of systems worldwide; each system is referred to as a DNS server (or a domain server or nameserver).

  • Replicated, to enhance reliability. Because many systems hold the same information, when some systems fail, DNS does not stop functioning.

As implemented, DNS is

  • Secure, so that your browser or email is directed to the correct location.

  • Flexible, so that it can adapt to new names, deleted names, and names whose information changes.

  • Fast, so that Internet connections are not delayed by slow DNS lookups.

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 Subdomains

Each 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 structure


You 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.

Zones

For 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.

[1] There is a third type of query that is not covered in this book: inverse. An inverse query provides a domain name given a resource record. Reverse name resolution (page 729), not an inverse query, is used to query for a domain name given an IP address.

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 answer


Servers

There are three main types of DNS servers: primary (master), secondary (slave), and caching-only.

  • A primary master server, also called a primary server or master server, is the authoritative server that holds the master copy of zone data. It copies information from the zone or master file, a local file that the server administrator maintains. For security and efficiency, a primary master server should provide iterative answers only. A primary master server that provides recursive answers is more easily subverted by a DoS attack (page 1030) than one that provides iterative answers only.

  • Slave servers, also called secondary servers, are authoritative and copy zone information from the primary master server or another slave server. On some systems, when information on the primary master server changes, the primary master server sends a message to the slave servers. When a slave receives such a message, it uses a process called zone transfer to copy the new zone information from the master server to itself.

  • DNS caches, also called caching-only servers, are not authoritative. These servers store answers to previous queries in cache (memory). When a DNS cache receives a query, it answers it from cache if it can. If the DNS cache does not have the answer in cache, it forwards the query to an authoritative server.

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 Records

Information 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:

  • Name The domain name or IP address

  • TTL Time to live (not in all resource records; see page 1060)

  • Class Always IN for Internet (the only class that DNS supports)

  • Type Record type (discussed in the next section)

  • Data Varies with record type

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:

  1. Name Domain name, FQDN, or IP address for reverse name resolution

  2. Type Type of record requested (page 725)

  3. Class Always IN for Internet class

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:

  • Header record Information about this message

  • Query record Repeats the query

  • Answer records Resource records that answer the query

  • Authority records Resource records for servers that have authority for the answers

  • Additional records Additional resource records, such as NS records

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 Resolution

In 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.





A Practical Guide to Red Hat Linux
A Practical Guide to Red HatВ® LinuxВ®: Fedoraв„ў Core and Red Hat Enterprise Linux (3rd Edition)
ISBN: 0132280272
EAN: 2147483647
Year: 2006
Pages: 383

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net