The Domain Name System (DNS) ensures that when users enter a domain on their browser, the user will be able to obtain the IP address and access the website. The whole process requires the participation of multiple DNS servers connected to each other (DNS lookup link). Within that process, the authoritative nameserver is responsible for accurately pointing out which specific server to contact in order for the user to access the requested website or avail of a specific web service. But how do the authoritative nameserver knows which server to contact?
To resolve DNS queries, DNS utilizes a database of information called resource records (RR), or also known as DNS records. RR are records stored in authoritative nameservers which provide information about a domain and its corresponding address, and also instructions on how to handle a request on a particular domain, i.e. instruction on which specific host servers, name servers, web servers, or email servers to point to given a domain request. An RR is stored as the main element in a text file called the zone file. Understanding the zone file will provide us with a better understanding of what a RR is.
A zone file (or “master file”) is a text file containing the RR in plain text format and is used to authoritatively define a zone. A zone (or DNS zone) is any distinct, contiguous portion of the domain namespace in the DNS for which administrative responsibility has been delegated to a single manager. A zone can include a single domain name, a domain name with several subdomains, or many domain names. For the case of a single domain name, the zone is essentially the domain name.
A zone file provides information about a domain and instructions on how specific DNS servers will handle requests for that domain. Though in some cases, a zone file may also be a file used to list the contents of a DNS cache. Zone files are standard practice in the DNS industry and are very essential when migrating a domain zone to another DNS provider, or when creating a backup of your domain records to a secondary nameserver. Zone files are stored in the “named” working directory (/var/named/) by default, and can be exported from your DNS provider.
Below is an example of a zone file (source Wikipedia):
In order for the data in the zone file to be correctly processed, specific guidelines must be observed, else DNS cannot function properly (or the client will receive the error message SERVFAIL). For this reason, the zone file follows a DNS syntax defined in RFC 1035 Section 5. Wherein, each entry in a zone file follows a “line-oriented” sequence (i.e. one line per entry), and each line entry will either be a directive or a text description of a resource record.
Directives are optional, but resource records are required in order to provide DNS service to a zone. Each entry is composed of fields separated by any combination of white space (tabs and spaces), and ends with a line break, except inside a quoted string field value or a pair of enclosing parentheses (e.g. brackets). A line entry may end with comment text preceded by a semicolon ‘;’ (This way, information is created about a DNS record without the server processing the text.). Entries may occur in any order in a zone file, with a few exceptions. You may insert empty lines to structure your records. These are also simply ignored by the system during the readout.
Directives are control entries that affect the rest of the zone file. It tells the nameserver to perform tasks or apply special settings to the zone. They are usually found at the top of the zone file. The first field of a directive consists of a dollar sign ‘$’ followed by the name of the directive. Below are the commonly used directives:
- $ORIGIN followed by a domain name to be used as the origin (or root domain) for subsequent relative domain names. Any NAME used in RRs that do not end in a trailing period (.) are appended with the domain name specified in the origin.
- $INCLUDE followed by a file name and optional origin domain name to be used when interpreting its contents. Configures “named” directory to include another zone file in this zone file. This allows additional zone settings to be stored apart from the main zone file.
- $TTL is followed by a number to be used as the default TTL (time-to-live) for the zone. This is the length of time, in seconds, that a zone RR is valid. Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to proliferate RR changes. This is considered to be the global TTL of all the RRs. Adding this directive can allow the omission of the TTL field in the RRs. Though, if a RR specifies its TTL value, the value in this directive will be overridden.
- $GENERATE is a non-standard extension accepted by BIND software and some other nameserver software to insert multiple RRs with one entry, is followed by a concise representation of an increasing sequence of nonnegative numbers and then a template RR entry. A RR is added for each number in the sequence, using the template with unescaped “$” characters replaced by the number.
B. Resource Records
Resource records are categorized into several types of DNS records, each having specific information elements called fields to provide a specific name-resolution service. The values on the fields are the ones that DNS resolvers return upon the query. For example, for the DNS record type called A record, the most important field (RDATA) is the IPv4 Address, while for the DNS record type called CNAME record, the most important field is the canonical domain name.
Every DNS record contains different fields, however, they still share common fields. These common fields are described below:
- NAME – This field specifies the fully qualified domain name (FQDN), and also indicates the name of the owner of the record. If this field is left blank in a record, it will inherit the field from the previous record. If this field has a free-standing @, this denotes the current ORIGIN (or root domain) set in the directives. And if this field has “www”, or “ftp”, etc., this can denote a subdomain of the current ORIGIN.
- TYPE – This field is a 2-byte value that indicates the type of the RR. The type will determine the intended use of the record. A DNS name can have more than one type of records. For example, DNS name can have an A record (value =1) which is used to translate a domain name to its corresponding IPv4 address, a CNAME record (value = 5) is used to translate an alias to its corresponding canonical name, etc. A more detailed description for the most common types of DNS records will be provided in this article.
- CLASS – This field defines the protocol family for the record. Each class is an independent namespace with potentially different delegations of DNS zones. For this field, only the Internet (IN) class is possible, and it is assigned to common DNS records involving Internet hostnames, servers, or IP addresses. Historically, when RRs were first introduced, Hesiod (HS) and Chaos (CH) classes were also possible. However, both Hesiod and Chaos are no longer in operation today.
- TTL (Time To Live) – This field is the length of time for which a copy of the record will be cached on a server, and it is measured in seconds. Since servers will update the record (from the origin server) every after TTL, TTL can also indicate the frequency of caching a record. This means the lower the TTL value, the more frequently the record will be updated. The default TTL value is 3600 seconds (or 1 hour), and a zero TTL value implies that a server would not cache the record.
- RDLENGTH – This field is the data field’s length in octets.
- RDATA – This field is a resource data and its value varies depending on the record’s type. This is the data that is returned during a DNS search (i.e. “the answer” that users are looking for on a query). For example, the value can be the host’s IP address for A records, or the priority and hostname for MX records, etc. Well-known record types may use label compression in the RDATA field, but “unknown” record types must not. RDATA of the most common types of DNS records will be provided in the next section.
Note: When you make changes to a DNS record, It could take up to the length of the TTL time for the change to take into effect. And when you add a new record, it will be visible to Internet users in 5 minutes.