4.3 Mô hình hoạt động của hệ thống DNS
4.3.6 Các kiểu hoạt động của máy chủ DNS
DNS servers play a wide variety of roles—a single name server may be a master for some zones, a slave for others, and provide caching or forwarding services for still others. Indeed, much of BIND 9’s power comes from allowing fine-grained control over operational functionality.
The role of the name server is controlled by its configuration file, which in the case of BIND 9 is called named.conf. The combination of global parameters in the named.conf file (defined in an options clause) and the zones being serviced (defined in one or more zone clauses) determine the complete functionality of the name server. Depending on the requirements, such configurations can become very complex. In order to provide an approachable starting point to what can become a task of daunting complexity, this chapter breaks down configuration of the name server into a number of basic types such as a master server type and an authoritative-only server type. I describe their characteristics and properties in isolation in order to create a series of building blocks from which progressively more complex configurations can be constructed. In some cases, the basic types may themselves be sufficient to create the required name server such as a caching-only server type (a resolver) or a forwarding server type; in other cases, the required name server may consist of, for example, many master server types,
many slave server types, and a caching server type. Indeed, in later chapters of this book, you will meet many examples that combine a number of these basic types to create unique solutions.
In order to most effectively introduce the characteristics of each basic name server type, some BIND 9 configuration file (named.conf) fragments are used where appropriate. The term clause is used to describe a group of related statements that can appear in the named.conf file. This terminology is applied rigorously throughout this book in the interests of consistency and ease of understanding rather than the myriad terms used in other documentation on this subject. The full format and layout of the named.conf file is described in Chapter 12, but the following identifies some important clauses and statements used in this file and which appear in the upcoming fragments:
The options clause groups together statements that control the global behavior of the name server. In some cases, the global statements may be overridden in specific clauses, such as the zone clause.
The zone clause groups statements that relate to specific zones within the configuration—the zone clause for example.com will define all the characteristics or properties of the zone.
The type statement is used within a zone clause and defines how the name server will act for the specific zone (for example, it may act as a master or as a slave for the zone).
The recursion statement controls whether recursive queries are supported or not.
Caching is an artifact of recursion; therefore, this statement effectively controls the provision of caching services in the name server. This statement may appear either in a global options clause or a view clause. By default, BIND 9 will support
recursive queries and hence provides caching.
The file statement is used to define the physical location of the zone file and appears in a zone clause.
BIND 10 (covered in an online chapter of this book) has chosen a radically different method to
control configuration. Later versions of BIND 10 are planned to parse and accept a named.conf file for compatibility and conversion purposes. However, BIND 10's normal control and configuration method consists of run-time commands that are saved in a configuration file and can, therefore, be reloaded in the event of a restart. While the user can edit the BIND 10 saved configuration information, this is discouraged. BIND 9 may thus be characterized as a batch system whereas BIND 10 is optimized to run continuously and to react to real-time stimuli such as configuration (behavior) changes, added or
deleted zones, or modified zone data.
4.3.6.1 Master (Primary) Name Servers
A master DNS configuration, also known as a zone master configuration, contains one or more zone files for which this DNS is authoritative and that it reads from a local file system. The term master is related to the location of the zone file rather than any other operational characteristics. A master may be requested to transfer zone files—using zone transfer operations (described in Chapter 3)—to one or more slave
servers whenever the zone file changes.
Zone master status for a zone is defined in BIND 9 by including type master in the zone clause of the named.conf file as shown in the following fragment:
// example.com fragment from named.conf
// defines this server as a zone master for example.com zone "example.com" in{
type master;
file "master.example.com";
};
In this fragment, zone "example.com" defines the zone to which the following statements apply, type master defines this DNS to be the zone master for example.com, and file "master.example.com" defines the name of the zone file on the filesystem containing the resource records (RRs) for example.com.
Figure 4–1 illustrates a zone master DNS.
A zone master obtains the zone data from a local zone file as opposed to a zone slave, which obtains its zone data via a zone transfer operation from the zone master. This seemingly trivial point means that
it is possible to have any number of zone masters for any zone if that makes operational sense. Zone file changes need to be synchronized between zone masters by a manual or automated process. This may be easier to manage than securing the zone transfer operations inherent in a master-slave configuration.
A master name server can indicate (using NOTIFY messages) zone changes to slave servers. This ensures that zone changes are rapidly propagated to the slaves rather than simply waiting for the slave to poll for changes at each SOA RR refresh interval. The BIND default is to automatically NOTIFY all the name servers defined in NS records for the zone.
NOTIFY messages may be disabled by use of the configuration statement notify no in BIND’s named.conf file in the zone clause for the domain.
When a DNS server that is a master for one or more zones receives a query for a zone for which it is not a master or a slave, it will act as configured. In BIND 9, this behavior is defined in the named.conf file as such:
1.If caching behavior is permitted and recursive queries are allowed (described in Chapter 3), the server will completely answer the request or return an error.
2.If caching behavior is permitted and iterative (nonrecursive) queries only are allowed, the server can respond with the complete answer if it is already in the cache because of another request, a referral, or return an error.
3.If caching behavior is not permitted (an authoritative-only DNS server), the server will return a referral or an error.
4.3.6.2 Slave (Secondary) Name Servers
The critical nature of DNS—no Internet services can work without it—requires that there be at least two name servers to support each domain or zone; larger or more active domains may rely on many more.
For instance, examination of the NS resource records using the dig tool (see Chapter 9) shows a typical range from 4 to 9 name servers for a number of high-profile zones. It is possible to run multiple master name servers, but any changed zone files must be copied to all masters. Apart from the obvious problem of synchronization when multiple masters are used, each master must be reloaded to use the new zone files, thus taking the name server out of service for a short period of time. With larger sites being hit hundreds of times per second, even modest out-of-service times can lose thousands of DNS
transactions—effectively making the site unreachable or slowing down access. To resolve this problem, the DNS specifications provide a feature—zone transfer—whereby one name server, the slave, can be updated from a zone master while continuing to provide responses to queries for the zone.
A slave name server obtains its zone information from a zone master, but it will respond as authoritative for those zones for which it is defined to be a slave and for which it has valid zone records
(the zone records have not expired). The act of transferring the zone may be viewed as having delegated authority for the zone to the slave for the time period defined in the expiry value of the SOA record (described in Chapter 2) and thus enables the slave to respond authoritatively to queries.
_Note There is no visible difference to other name servers (resolvers) between the response from a zone master
and the response from a zone slave.
Slave status is defined in BIND by including type slave in the zone clause of the named.conf file, as shown:
// example.com fragment from named.conf // defines this server as a zone slave zone "example.com" in{
type slave;
file "slave.example.com";
masters {192.168.23.17;};
};
Here, zone "example.com" defines the zone for which the following statements apply, and type slave; indicates that this name server will act as a slave for example.com. The statement file
"slave.example.com"; is optional and allows the zone data to be saved to the specified file. If the name server is reloaded, it can read the zone data from this file rather than forcing a new zone transfer from the master, as would be the case if no file statement were present. The file statement can save considerable time and resources. The statement masters {192.168.23.17}; defines the IP address of the name server(s) that hold the master zone file for this zone. One or more IP addresses may be present.
There can be more than one master DNS for any zone.
A slave server attempts to update the zone records when the refresh parameter of the SOA RR is reached. If a failure occurs, the slave will periodically try to reach the zone master(s) every retry period. If a slave has still not reached the master DNS when the expiry time of the SOA RR for the zone has been
reached, it will stop responding to queries for the zone. The slave will not use time-expired data.
As previously mentioned, slave servers will respond as authoritative to queries for the domain as long as they hold valid zone records. This feature provides the user with a lot of flexibility when registering name servers for a given domain. When registering such name servers, the only requirement is that the servers listed will respond as authoritative to queries for the domain or zone. It is not necessary to define the zone master as one of these name servers; two or more slave servers will satisfy the requirement. This
Trang 150
flexibility allows the zone master to be hidden from public access if required (a.k.a. a hidden master). To illustrate why such a strategy may be useful, consider the following scenario: if a slave zone file becomes corrupted through a malicious attack, it can be quickly restored from the master by a zone transfer. If the master zone file were to become similarly corrupted, the zone files may have to be restored from backup media, which could take some time. One way to prevent such a problem is simply to avoid it by not making the master publicly visible. It is visible to the slave only using the masters parameter of BIND’s named.conf but would not appear in any NS RR for the zone. Every name server, master, or slave that the user wishes to make visible must be defined using an NS RR in the zone.
Figure 4–2 illustrates a typical master and single slave configuration, and Figure 4–3 illustrates a slave server when used with a hidden master.
Slave vs. Cache
A zone slave obtains all the zone data for which it is acting as a slave via zone transfer operations. This process should not be confused with a cache. The slave server uses the refresh and expiry values from the SOA RR to time-out its zone data and then retransfers all the zone data. A cache, on the other hand, contains individual RRs obtained in response to a specific query originating from a resolver or another name server acting on behalf of a resolver and discards each RR when its TTL is reached. In addition, a slave server always responds authoritatively to requests for information about its zone. A cache will only respond authoritatively with zone data the first time it obtains the data (directly from the zone’s master or slave). Thereafter, when reading from its cache, the data is not marked as authoritative. Failure to understand the difference between slave servers and caching can lead to lame delegation. Only zone master or slave authoritative servers can appear in any NS RRs for the zone since only these server types can answer authoritatively for the zone.
Change Propagation Using NOTIFY
The slave will periodically poll the zone master for changes at a time interval defined by the refresh parameter of the zone’s SOA RR. In this scenario, the refresh parameter, which typically may be 12 hours or longer, controls the time taken to propagate zone changes. If NOTIFY behavior is enabled in the zone master—BIND’s default—then every time the zone is loaded or reloaded, a NOTIFY message is sent to all the slave servers defined in the NS RRs of the zone file. On receipt of a NOTIFY message, the slave will request a copy of the zone’s SOA RR. If the serial number of the current zone data is lower than the serial number of the newly requested SOA RR, the slave initiates a zone transfer to completely update its zone data. There can be zero, one, or more slave name servers for any given zone.
The NOTIFY message—and its subsequent zone transfer operation—presents a potential security threat. To minimize this threat, BIND’s default behavior is to only accept NOTIFY messages from the zone master (name servers listed in the masters statement). Other acceptable NOTIFY sources can be defined
using the allow-notify statement in the named.conf file.
4.3.6.3 Caching Name Servers
A caching name server (a.k.a. caching resolver, DNS cache, or, most commonly, resolver) obtains
Trang 162
specific information in the form of one or more resource records about a domain by querying a zone’s authoritative name server (master or slave) in order to answer a host/client query and subsequently saves (caches) the data locally. On a subsequent request for the same data, the caching server will respond with its locally stored data from the cache. This process will continue until the Time to Live (TTL) value of the RR expires, at which time the RR will be discarded from the cache. The next request for this RR will result in the resolver again querying an authoritative name server for the zone. Caches considerably increase DNS performance for local PCs or hosts and can also significantly reduce network loads by obtaining a single copy of frequently accessed data and making it available many times with no additional overhead. Consider the example zone file in which the mail server was defined using the following RR:
3w IN MX 10 mail.example.com.
The effect of caching in this case is that every request for the mail server for example.com for the next three weeks will be satisfied from the cache and will require no further—possibly slow—network access.
If a caching name server (a resolver) is reloaded or restarted, then caches are usually erased and the process begins again. It is worth emphasizing at this point that the only way RR data is removed from a cache is by either its TTL expiring or the resolver being reloaded. This means that changes to the preceding MX record will take up to three weeks to propagate throughout the Internet and thus only
stable RRs, such as mail servers, would typically have such very long TTL values.
If the resolver obtains its data directly from an authoritative DNS, then it too will respond as authoritative. Otherwise, if the data is supplied from its cache, the response is nonauthoritative.
By default, BIND 9 will cache resource records. This behavior is defined using the recursion parameter—
the default is recursion yes;—in BIND 9’s named.conf file. This may seem a little strange at first, but caching is essentially an artifact of recursive query behavior.
A BIND 9 caching server (resolver) will have a named.conf file that includes the following fragment:
// options clause fragment of named.conf // recursion yes is the default and may be omitted options {
recursion yes;
allow-recursion {10.2/16;192.168.2/24;}; // limits (closes) recursion };
// zone clause ....
// the DOT indicates the root domain = all domains zone "." IN {
type hint;
file "root.servers";
};
The options clause indicates the following statements apply to all zones in the configuration unless explicitly overridden with another statement; recursion yes; turns on caching behavior, which is the BIND default and could be omitted. The allow-recursion {10.2/16;192.168.2/24;}; statement defines those IP addresses that are allowed to issue recursive queries. If this statement were not present, this would be an OPEN caching name server and as such could be used by malicious third parties in DDoS attacks. Indeed, so serious is this problem that since BIND 9.4+ failure to provide any limits on recursion will cause the configuration to default to accepting recursive queries only from locally connected hosts.
For more information see the “Resolver (Caching-Only)” section in Chapter 7 and Chapter 12 for allowrecursion, allow-recursion-on, allow-query-cache, and allow-query-cache-on statements.
The zone "."; clause defines the normally silent root domain and is used to access any zone that is not defined in the remainder of the configuration; type hint; simply indicates the zone references the root domain and is only ever used in conjunction with a zone "."; clause. The statement file
"root.servers"; locates the zone file that contains the Address (A) RRs of the root-servers.
_Tip The root.servers zone file, which may be called named.ca or named.root, is normally supplied with BIND
9 distributions. Chapter 7 illustrates an example root.servers zone file.
Caching Implications
To cache or not to cache is a crucial question in the world of DNS, since it incurs substantial
performance overheads. Also, because it interfaces with the external network, you run the risk of cache poisoning or corruption through malicious attacks. This downside must be offset against the significant performance gains that are obtained when using a resolver. The most common uses of DNS caching configurations are as follows:
As a name server acting as master or slave for one or more zones (domains) and as a caching server for all other queries. A general-purpose name server.
As a caching-only name server (resolver)—typically used to support standard PCbased resolvers (stub resolvers), which as you may recall from Chapter 1, require
recursive query support that is only provided by a caching name server. One or more caching-only servers are typically present in networks such as ISPs or large