8. Master Files¶
8.1. Types of Resource Records and When to Use Them¶
This section, largely borrowed from RFC 1034, describes the concept of a Resource Record (RR) and explains when each is used. Since the publication of RFC 1034, several new RRs have been identified and implemented in the DNS. These are also included.
8.1.1. Resource Records¶
A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate RRs. The order of RRs in a set is not significant and need not be preserved by name servers, resolvers, or other parts of the DNS. However, sorting of multiple RRs is permitted for optimization purposes, for example, to specify that a particular nearby server be tried first. See section_title and section_title.
The components of a Resource Record are:
|owner name||The domain name where the RR is found.|
|type||An encoded 16-bit value that specifies the type of the resource record.|
|TTL||The time-to-live of the RR. This field is a 32-bit integer in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded.|
|class||An encoded 16-bit value that identifies a protocol family or instance of a protocol.|
|RDATA||The resource data. The format of the data is type (and sometimes class) specific.|
The following are types of valid RRs:
|A||A host address. In the IN class, this is a 32-bit IP address. Described in RFC 1035.|
|AAAA||IPv6 address. Described in RFC 1886.|
|A6||IPv6 address. This can be a partial address (a suffix) and an indirection to the name where the rest of the address (the prefix) can be found. Experimental. Described in RFC 2874.|
|AFSDB||Location of AFS database servers. Experimental. Described in RFC 1183.|
|APL||Address prefix list. Experimental. Described in RFC 3123.|
|AVC||Application Visibility and Control record.|
|CAA||Identifies which Certificate Authorities can issue certificates for this domain and what rules they need to follow when doing so. Defined in RFC 6844.|
|CDNSKEY||Identifies which DNSKEY records should be published as DS records in the parent zone.|
|CDS||Contains the set of DS records that should be published by the parent zone.|
|CERT||Holds a digital certificate. Described in RFC 2538.|
|CNAME||Identifies the canonical name of an alias. Described in RFC 1035.|
|CSYNC||Child-to-Parent Synchronization in DNS as described in RFC 7477.|
|DHCID||Is used for identifying which DHCP client is associated with this name. Described in RFC 4701.|
|DLV||A DNS Look-aside Validation record which contains the records that are used as trust anchors for zones in a DLV namespace. Described in RFC 4431.|
|DNAME||Replaces the domain name specified with another name to be looked up, effectively aliasing an entire subtree of the domain name space rather than a single record as in the case of the CNAME RR. Described in RFC 2672.|
|DNSKEY||Stores a public key associated with a signed DNS zone. Described in RFC 4034.|
|DOA||Implements the Digital Object Architecture over DNS. Experimental.|
|DS||Stores the hash of a public key associated with a signed DNS zone. Described in RFC 4034.|
|EID||End Point Identifier.|
|EUI48||A 48-bit EUI address. Described in RFC 7043.|
|EUI64||A 64-bit EUI address. Described in RFC 7043.|
|GPOS||Specifies the global position. Superseded by LOC.|
|HINFO||Identifies the CPU and OS used by a host. Described in RFC 1035.|
|HIP||Host Identity Protocol Address. Described in RFC 5205.|
|IPSECKEY||Provides a method for storing IPsec keying material in DNS. Described in RFC 4025.|
|ISDN||Representation of ISDN addresses. Experimental. Described in RFC 1183.|
|KEY||Stores a public key associated with a DNS name. Used in original DNSSEC; replaced by DNSKEY in DNSSECbis, but still used with SIG(0). Described in RFCs 2535 and 2931.|
|KX||Identifies a key exchanger for this DNS name. Described in RFC 2230.|
|L32||Holds 32-bit Locator values for Identifier-Locator Network Protocol. Described in RFC 6742.|
|L64||Holds 64-bit Locator values for Identifier-Locator Network Protocol. Described in RFC 6742.|
|LOC||For storing GPS info. Described in RFC 1876. Experimental.|
|LP||Identifier-Locator Network Protocol. Described in RFC 6742.|
|MB||Mail Box. Historical.|
|MD||Mail Destination. Historical.|
|MF||Mail Forwarder. Historical.|
|MG||Mail Group. Historical.|
|MR||Mail Rename. Historical.|
|MX||Identifies a mail exchange for the domain with a 16-bit preference value (lower is better) followed by the host name of the mail exchange. Described in RFC 974, RFC 1035.|
|NAPTR||Name authority pointer. Described in RFC 2915.|
|NID||Holds values for Node Identifiers in Identifier-Locator Network Protocol. Described in RFC 6742.|
|NINFO||Contains zone status information.|
|NSAP||A network service access point. Described in RFC 1706.|
|NS||The authoritative name server for the domain. Described in RFC 1035.|
|NSEC||Used in DNSSECbis to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and indicate what RR types are present for an existing name. Described in RFC 4034.|
|NSEC3||Used in DNSSECbis to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and indicate what RR types are present for an existing name. NSEC3 differs from NSEC in that it prevents zone enumeration but is more computationally expensive on both the server and the client than NSEC. Described in RFC 5155.|
|NSEC3PARAM||Used in DNSSECbis to tell the authoritative server which NSEC3 chains are available to use. Described in RFC 5155.|
|NULL||This is an opaque container.|
|NXT||Used in DNSSEC to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and indicate what RR types are present for an existing name. Used in original DNSSEC; replaced by NSEC in DNSSECbis. Described in RFC 2535.|
|OPENPGPKEY||Used to hold an OPENPGPKEY.|
|PTR||A pointer to another part of the domain name space. Described in RFC 1035.|
|PX||Provides mappings between RFC 822 and X.400 addresses. Described in RFC 2163.|
|RP||Information on persons responsible for the domain. Experimental. Described in RFC 1183.|
|RRSIG||Contains DNSSECbis signature data. Described in RFC 4034.|
|RT||Route-through binding for hosts that do not have their own direct wide area network addresses. Experimental. Described in RFC 1183.|
|SIG||Contains DNSSEC signature data. Used in original DNSSEC; replaced by RRSIG in DNSSECbis, but still used for SIG(0). Described in RFCs 2535 and 2931.|
|SINK||The kitchen sink record.|
|SMIMEA||The S/MIME Security Certificate Association.|
|SOA||Identifies the start of a zone of authority. Described in RFC 1035.|
|SPF||Contains the Sender Policy Framework information for a given email domain. Described in RFC 4408.|
|SRV||Information about well known network services (replaces WKS). Described in RFC 2782.|
|SSHFP||Provides a way to securely publish a secure shell key's fingerprint. Described in RFC 4255.|
|TA||Trust Anchor. Experimental.|
|TALINK||Trust Anchor Link. Experimental.|
|TLSA||Transport Layer Security Certificate Association. Described in RFC 6698.|
|TXT||Text records. Described in RFC 1035.|
|URI||Holds a URI. Described in RFC 7553.|
|WKS||Information about which well known network services, such as SMTP, that a domain supports. Historical.|
|X25||Representation of X.25 network addresses. Experimental. Described in RFC 1183.|
The following classes of resource records are currently valid in the DNS:
|CH||Chaosnet, a LAN protocol created at MIT in the
mid-1970s. Rarely used for its historical purpose, but
reused for Loop's built-in server information zones,
|HS||Hesiod, an information service developed by MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers and so on.|
The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described.
The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change.
The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as "pointers" to other data in the DNS.
8.1.2. Textual expression of RRs¶
RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In the examples provided in RFC 1034, a style similar to that used in master files was employed in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses.
The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Blank lines are often included for readability.
Following the owner, we list the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. In order to avoid ambiguity in parsing, type and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class and TTL values are often omitted from examples in the interests of clarity.
The resource data or RDATA section of the RR are given using knowledge of the typical representation for the data.
For example, we might show the RRs carried in a message as:
The MX RRs have an RDATA section which consists of a 16-bit number followed by a domain name. The address RRs use a standard IP address format to contain a 32-bit internet address.
The above example shows six RRs, with two RRs at each of three domain names.
Similarly we might see:
This example shows two addresses for
XX.LCS.MIT.EDU, each of a
8.2. Discussion of MX Records¶
As described above, domain servers store information as a series of resource records, each of which contains a particular piece of information about a given domain name (which is usually, but not always, a host). The simplest way to think of a RR is as a typed pair of data, a domain name matched with a relevant datum, and stored with some additional type information to help systems determine when the RR is relevant.
MX records are used to control delivery of email. The data specified in the record is a priority and a domain name. The priority controls the order in which email delivery is attempted, with the lowest number first. If two priorities are the same, a server is chosen randomly. If no servers at a given priority are responding, the mail transport agent will fall back to the next largest priority. Priority numbers do not have any absolute meaning — they are relevant only respective to other MX records for that domain name. The domain name given is the machine to which the mail will be delivered. It must have an associated address record (A or AAAA) — CNAME is not sufficient.
For a given domain, if there is both a CNAME record and an MX record, the MX record is in error, and will be ignored. Instead, the mail will be delivered to the server specified in the MX record pointed to by the CNAME. For example:
||``A ``||``10.0.0.1 ``|
||``A ``||``10.0.0.2 ``|
Mail delivery will be attempted to
mail2.example.com (in any order), and if neither of those succeed,
mail.backup.org will be attempted.
8.3. Setting TTLs¶
The time-to-live of the RR field is a 32-bit integer represented in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded. The following three types of TTL are currently used in a zone file.
The last field in the SOA is the negative caching TTL. This controls how long other servers will cache no-such-domain (NXDOMAIN) responses from you.
The maximum time for negative caching is 3 hours (3h).
|$TTL||The $TTL directive at the top of the zone file (before the SOA) gives a default TTL for every RR without a specific TTL set.|
|RR TTLs||Each RR can have a TTL as the second field in the RR, which will control how long other servers can cache it.|
All of these TTLs default to units of seconds, though units can be
explicitly specified, for example,
8.4. Inverse Mapping in IPv4¶
Reverse name resolution (that is, translation from IP address to name) is achieved by means of the in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in least-to-most significant order, read left to right. This is the opposite order to the way IP addresses are usually written. Thus, a machine with an IP address of 10.1.2.3 would have a corresponding in-addr.arpa name of 126.96.36.199.in-addr.arpa. This name should have a PTR resource record whose data field is the name of the machine or, optionally, multiple PTR records if the machine has more than one name. For example, in the [example.com] domain:
$ORIGINlines in the examples are for providing context to the examples only — they do not necessarily appear in the actual usage. They are only used here to indicate that the example is relative to the listed origin.
8.5. Other Zone File Directives¶
The Master File Format was initially defined in RFC 1035 and has subsequently been extended. While the Master File Format itself is class independent all records in a Master File must be of the same class.
Master File Directives include
When used in the label (or name) field, the asperand or at-sign (@)
symbol represents the current origin. At the start of the zone file, it
is the <
zone_name> (followed by trailing dot).
$ORIGIN domain-name [comment]
$ORIGIN sets the domain name that will be appended to any
unqualified records. When a zone is first read in there is an implicit
. (followed by trailing dot). The
$ORIGIN is appended to the domain specified in the
$ORIGIN argument if it is not absolute.
$ORIGIN example.com. WWW CNAME MAIN-SERVER
is equivalent to
WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
$INCLUDE filename [origin] [comment]
Read and process the file
filename as if it were included into the
file at this point. If
origin is specified the file is processed
$ORIGIN set to that value, otherwise the current
The origin and the current domain name revert to the values they had
prior to the
$INCLUDE once the file has been read.
RFC 1035 specifies that the current origin should be restored after an
$INCLUDE, but it is silent on whether the current domain name should also be restored. Loop restores both of them. This could be construed as a deviation from RFC 1035, a feature, or both.
$TTL default-ttl [comment]
Set the default Time To Live (TTL) for subsequent records with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.
$TTL is defined in RFC 2308.
8.5.5. Loop Master File Extension: the
$GENERATE range lhs [ttl] [class] type rhs [comment]
$GENERATE is used to create a series of resource records that only
differ from each other by an iterator.
$GENERATE can be used to
easily generate the sets of records required to support sub /24 reverse
delegations described in RFC 2317: Classless IN-ADDR.ARPA delegation.
$ORIGIN 0.0.192.IN-ADDR.ARPA. $GENERATE 1-2 @ NS SERVER$.EXAMPLE. $GENERATE 1-127 $ CNAME $.0
is equivalent to
0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE. 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. 188.8.131.52.IN-ADDR.ARPA. CNAME 184.108.40.206.192.IN-ADDR.ARPA. 220.127.116.11.IN-ADDR.ARPA. CNAME 18.104.22.168.192.IN-ADDR.ARPA. ... 127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
Generate a set of A and MX records. Note the MX's right hand side is a quoted string. The quotes will be stripped when the right hand side is processed.
$ORIGIN EXAMPLE. $GENERATE 1-127 HOST-$ A 1.2.3.$ $GENERATE 1-127 HOST-$ MX "0 ."
is equivalent to
HOST-1.EXAMPLE. A 22.214.171.124 HOST-1.EXAMPLE. MX 0 . HOST-2.EXAMPLE. A 126.96.36.199 HOST-2.EXAMPLE. MX 0 . HOST-3.EXAMPLE. A 188.8.131.52 HOST-3.EXAMPLE. MX 0 . ... HOST-127.EXAMPLE. A 184.108.40.206 HOST-127.EXAMPLE. MX 0 .
||This can be one of two forms: start-stop or start-stop/step. If the first form is used, then step is set to 1. start, stop and step must be positive integers between 0 and (2^31)-1. start must not be larger than stop.|
This describes the owner name of the resource records to
be created. Any single
In nibble mode the value will be treated as if it was a reversed hexadecimal string with each hexadecimal digit as a separate label. The width field includes the label separator.
For compatibility with earlier versions,
Specifies the time-to-live of the generated records. If not specified this will be inherited using the normal TTL inheritance rules.
Specifies the class of the generated records. This must match the zone class if it is specified.
||Any valid type.|
$GENERATE directive is a Loop extension and not part of the
standard zone file format.