4.3 Mô hình hoạt động của hệ thống DNS
4.3.2 Cấu trúc dữ liệu DNS – Resource Record
(IBM Red books, 2006) - 12.1.9 Domain Name System resource records
The Domain Name System's distributed database is composed of resource records (RRs), which are divided into classes for different kinds of networks. We only discuss the Internet class of records. Resource records provide a mapping between domain names and network objects. The most common network objects are the addresses of Internet hosts, but the Domain Name System is designed to accommodate a wide range of different objects.
A zone consists of a group of resource records, beginning with a Start of
Authority (SOA) record. The SOA record identifies the domain name of the zone.
There will be a name server (NS) record for the primary name server for this zone. There might also be NS records for the secondary name servers. The NS records are used to identify which of the name servers are authoritative (see
“Domain name resolver operation” on page 434). Following these records are the resource records, which might map names to IP addresses or aliases to names.
The following figure shows the general format of a resource record (Figure 12-4).
Where:
Name The domain name to be defined. The Domain Name System is very general in its rules for the composition of domain names.
However, it recommends a syntax for domain names that minimizes the likelihood of applications that use a DNS resolver (that is, nearly all TCP/IP applications) from
misinterpreting a domain name. A domain name adhering to this recommended syntax will consist of a series of labels consisting of alphanumeric characters or hyphens, each label having a length of between 1 and 63 characters, starting with an alphabetic character. Each pair of labels is separated by a dot (period) in human-readable form, but not in the form used within DNS messages. Domain names are not case-sensitive.
Type Identifies the type of the resource in this record. There are numerous possible values, but some of the more common ones, along with the RFCs which define them, are listed in Table 12-2 on page 438.
Class Identifies the protocol family. The only commonly used value is IN (the Internet system), though other values are defined by
RFC 1035 and include:
• CS (value 2): The CSNET class. This has been obsoleted.
• CH (value 3): The CHAOS class.
• HS (value 4): The Hesiod class.
TTL The time-to-live (TTL) time in seconds for which this resource record will be valid in a name server cache. This is stored in the DNS as an unsigned 32-bit value. A typical value for records pointing to IP addresses is 86400 (one day).
RDlength An unsigned 16-bit integer that specifies the length, in octets, of the RData field.
RData A variable length string of octets that describes the resource.
The format of this information varies according to the Type and Class of the resource record.
4.3.2.1 The SOA Resource Record
(Aitchison, 2011) - The SOA Resource Record
The SOA Resource Record defines the key characteristics and attributes for the zone or domain and is standardized in RFC 1035. As befits the most important RR in the zone file, it’s among the most complex and takes a significant number of parameters. The formal syntax of the SOA RR is as follows:
name ttl class rr name-server e-mail sn refresh retry expiry min
Here is the SOA RR from the example zone file:
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; sn = serial number
3h ; refresh time
15m ; retry = refresh retry 3w ; expiry
3h ; nx = nxdomain ttl )
The SOA RR illustrates two layout rules previously described:
It typically uses the standard multiline format where the open parenthesis must appear on the first line; the closing parenthesis can appear on the same or any subsequent line.
The separators between fields can be either spaces or tabs. In zone files, tabs are traditionally used to make a more attractive layout and to clearly indicate which fields are missing.
Table 2–1 maps the values from the example file to the formal syntax.
4.3.2.2 The NS Resource Record
The NS Resource Record is standardized in RFC 1035 and defines the authoritative name servers (there must be at least two) for the domain or zone. The NS RR syntax is as follows:
name ttl class rr name
Let’s return to the example file:
; name servers Resource Records for the domain IN NS ns1.example.com.
; the second name server is
; external to this zone (domain).
IN NS ns2.example.net.
Table 2–2 wraps the formal syntax to the first NS record used in the example zone file, which is
internal to the zone.
The second NS RR from the example file is as follows:
IN NS ns2.example.net.
This is the classic method of defining a second name server for the domain. In the event that one name server is not available, the alternate server (ideally at a geographically different location) will be
used, thus ensuring access to services such as mail even if the main site is not available due to backbone, power, or other system outages.
The second NS RR is defined to be in a foreign or external zone and therefore does not require an A RR if IPv4 (or AAAA RR if IPv6) is defined. In addition, it MUST be defined using an FQDN; in other
words, it must terminate with a dot. To illustrate the possible errors that may be caused inadvertently by
$ORIGIN substitution, assume that the terminating dot on this RR was omitted in error, that is, it was written as ns2.example.net (without a terminating dot). DNS software would apply substitution and
create a name of ns2.example.net.example.com.—not the desired result!
4.3.2.3 The MX Resource Record
The MX RR is standardized in RFC 1035 and defines the mail servers (or mail exchangers in the quaint DNS jargon) for the domain or zone. The formal syntax is as follows:
name ttl class rr preference name
In the example file, the following MX RRs are defined:
; mail server Resource Records for the zone (domain) 3w IN MX 10 mail.example.com.
; the second mail server is
; external to the zone (domain) IN MX 20 mail.example.net.
Table 2–3 maps the formal syntax to the first MX record used in the example file, which is internal to the domain.
The second MX RR from the example file is as follows:
IN MX 20 mail.example.net.
This is the classic method of defining a backup mail server, which has a lower preference value (20 in the example). In the event that the first mail server is not available, the backup mail server (ideally at a geographically different location) would be used. This backup mail server would normally be defined as a simple forwarding mail server for the domain, constantly attempting to pass the mail to the most preferred (or primary) mail server (mail.example.com) when service is happily restored.
The second MX RR is defined to be in a foreign or external domain and therefore does not require an A RR if IPv4 (or an AAAA RR if IPv6) is defined and MUST always be an FQDN (in other words, it must
end with a dot).
4.3.2.4 The A Resource Record
The A RR is standardized in RFC 1035 and defines the IPv4 address of a particular host in the domain or zone. The equivalent RR for IPv6 is the AAAA RR described in Chapter 5. The formal syntax of the Address RR is as follows:
name ttl class rr ipv4
In the example file, the following A RRs are defined:
ns1 IN A 192.168.254.2 mail IN A 192.168.254.4 joe IN A 192.168.254.6 www IN A 192.168.254.7
Table 2–4 maps the formal syntax to the first A RR used in the example zone file.
It is permissible to define the same IP address with multiple names as shown in the following fragment (here the name server and the web server are co-located on the same machine):
ns1 IN A 192.168.254.2 mail IN A 192.168.254.4 joe IN A 192.168.254.6
; this A RR has the same IPv4 address as ns1 above www IN A 192.168.254.2
The same result can be achieved using a CNAME record (see the next section). Multiple IP addresses can also be defined for the same host as in this fragment, where three IPv4 addresses are provided for the host www.example.com:
www IN A 192.168.254.2 IN A 192.168.254.7 IN A 192.168.254.8
DNS software will supply the defined IP address in a round-robin or random order (defined by
configuration directives) to successive queries. This feature may be used to provide load balancing and is further described in Chapter 8. The preceding fragment also illustrates the use of a null or blank name to inherit the previous name; that is, all the entries with a blank name relate to www (and assuming an
$ORIGIN directive of example.com will define www.example.com).
4.3.2.5 CNAME Resource Record
The CNAME RR is standardized in RFC 1035 and defines an alias for an existing host defined by an A RR.
The formal syntax is as follows:
name ttl class rr canonical-name
In the example file, the following CNAME RR is defined:
ftp IN CNAME ftp.example.net.
Table 2–5 maps the formal syntax to the CNAME RR used in the example zone file.
CNAME RRs are often used when assigning service names to existing hosts; for example, if a host is
actually called bill but runs an FTP and a web service, then CNAME RRs are frequently used to define these services, as shown in the following fragment:
ftp IN CNAME bill www IN CNAME bill bill IN A 192.168.254.21
CNAME RRs have some limitations. It is permissible but considered very bad practice to chain CNAME records.
ns1 IN A 192.168.254.2 mail IN A 192.168.254.3
joe IN CNAME www.example.com.
www IN CNAME mail.example.com.
CNAME records should not be used with either NS or MX records; thus in the example file, if the mail server and web server were co-located on the same host, the following would be technically invalid but would typically work; this is an approach that is widely used!
IN MX mail.example.com.
mail IN CNAME www.example.com.
www IN A 192.168.254.7
The following fragment is valid and achieves the same result:
IN MX mail.example.com.
mail IN A 192.168.254.7
www IN CNAME mail.example.com.
The rule defining the preceding example (RFC 1034 section 3.6.2) is cautious in regard to use of excessive indirection and says that if a name appears on the right-hand side of an RR (as
mail.example.com does in the preceding MX RR in the fragment), it should not appear in the left-hand name of a CNAME RR. Many working configurations use this construct routinely. There is always a risk that one day the specification may be tightened and the configuration may not work.
You need to be aware of two other consequences when using CNAME RR. First, CNAME causes the name server to do more work because both the CNAME and the CNAME’d RR must be looked up by the name server. In high-volume name servers, this additional workload may be a consideration. Second, the CNAME RR and the target (CNAME’d) RR record are returned in the answer. When dealing with large answers, this may cause the response to exceed the 512-byte limit of a DNS UDP transaction, thus reducing performance.
When CNAME Records Must Be Used
As noted in the previous section, CNAME RRs are frequently and commonly used to map services such as FTP, web, gopher, and others onto a single host. In these cases, multiple A RRs may also be used to achieve the same result. In general, the only time a CNAME must be used is when the real or canonical host lies in a foreign or external domain, as illustrated in the example file where ftp.example.com is aliased to ftp.example.net. A CNAME RR is frequently used when the user wishes to address a web site using either www.example.com or just example.com. In this case, the functionality would typically be implemented using the following fragment:
; define an IP that resolves to example.com IN A 192.168.254.7
; alias www.example.com to example.com www IN CNAME example.com.
Here, defining the WWW RR as a simple A RR will achieve exactly the same result. Either form will require a configuration change to your web server, which is fully covered in Chapter 8.
4.3.2.6 Additional Resource Records
In this chapter, you have seen the main RRs used in constructing zone files. Many more RR types exist;
these are documented with examples in Chapter 13. For the sake of completeness, some of the more commonly used additional or specialized RRs are briefly described in the following sections.
PTR Resource Records
Pointer (PTR) RRs are used only for reverse-mapping zones and are the corollary of the Address RRs. PTR RRs map an IPv4 address to a name; an A RR forward-maps a name to an IPv4 address. Reverse mapping and PTR records are described in Chapter 3. PTR RRs are also used when reverse mapping an IPv6 zone, as you’ll see in Chapter 5.
TXT Resource Records
Text (TXT) RRs were historically used to define generic text to be associated with a name. The text may be anything the user wishes. The Sender Policy Framework (SPF) and DKIM antispam initiatives both use the TXT RR to carry information. You’ll find the SPF and DKIM formats defined in Chapter 8 and the generic TXT RR in Chapter 13.
CHAPTER 2 _ ZONE FILES AND RESOURCE RECORDS
39
AAAA Resource Records
The AAAA RR is used to define forward mapping of IPv6 hosts, which is covered in Chapter 5.
Trang 140
NSEC, RRSIG, DS, DNSKEY, and KEY Resource Records
These RRs are used in Secure DNS (DNSSEC) configurations as described in Chapters 10 and 11.
SRV Resource Records
Service (SRV) RRs are used to map services onto hosts. Chapter 13 describes the SRV RR, and Chapter 8 contains a discussion of the use of SRV records in load balancing and resilience.