understanding DNS zones

                             UNDERSTANDING DNS ZONES
DNS Zone

Every domain name, which is a part of the DNS system, has several DNS settings, also known as DNS records. In order for these DNS records to be kept in order, the DNS zone was created.

The DNS zone

A DNS zone refers to a certain portion or administrative space within the global Domain Name System (DNS). Each DNS zone represents a boundary of authority subject to management by certain entities. The total of all DNS zones, which are organized in a hierarchical tree-like order of cascading lower-level domains, form the DNS namespace.

The authority over each DNS zone is delegated to a legal entity or organization (i.e. a country-code top-level domain registry) or a company/individual registered to use a certain sub-domain within the system. Depending on the administrative rights delegated to a certain entity, DNS zones may consist of only one domain, or of many domains and sub-domains. Further authority over a sub-space could be delegated to other parties, if necessary.

The DNS Zone file

The DNS Zone file is the representation of the DNS Zone - it is the actual file, which contains all the records for a specific domain. In a DNS Zone file, each line can hold only one record, and each DNS Zone file must start with the TTL (Time to Live), which specifies for how long the records should be kept in the DNS Server's cache. The other mandatory record for a DNS Zone file is the SOA (Start of Authority) record - it specifies the primary authoritative name server for the DNS Zone.

After these two records are specified, additional records, such as A or NS records, can be added. When adding a record for a hostname, the hostname must end with a period (.). Hostnames, which do not end with a period, are considered relative to the main domain name, for which the DNS Zone was created. For example, when specifying the "www" record, there is no need to place a period after it.

Comments in the DNS Zone file must be started with a semicolon (;) and the start of a multiple line comment is represented by brackets ("("), and comments must again start with a semicolon. When the multiple lines end, they must be closed again with a bracket (")"), placed on a single line.

An example of DNS Zone file:

$ORIGIN example.com. ; designates the start of this zone file in the name space
$TTL 1h ; The default expiration time of a resource record without its own TTL value
example.com. IN SOA ns.example.com. root.example.com. (
2008120710 ; serial number of this zone file
1d ; slave refresh (1 day)
1d ; slave retry time in case of a problem (1 day)
4w ; slave expiration time (4 weeks)
1h ; minimum caching time in case of failed lookups (1 hour)
)
example.com. NS dns1.ntchosting.com. ; ns.example.com is the nameserver for example.com
example.com. NS dns2.ntchosting.com. ; ns.somewhere.com is a backup nameserver for example.com
example.com. MX 10 mx1.ntchosting.com
example.com. MX 10 mx2.ntchosting.com ; mail.example.com is the mailserver for example.com
example.com. A 209.25.134.47 ; ip address for "example.com"
www A 209.25.134.47

DNS Zone management

It includes a wide range of tasks, such as defining the name hierarchy within the zone, and name registration procedures maintaining the proper operation of the DNS servers. The amount of management actions depends on the size of authority standing behind a particular DNS zone. Through the user-friendly web hosting Control Panel that we, at NTC Hosting, provide you with, you can manage all the records in a DNS zone. DNS management is a feature, offered with all of our web hosting plans.

Primary zone

When a zone that this DNS server hosts is a primary zone, the DNS server is the primary source for information about this zone, and it stores the master copy of zone data in a local file or in AD DS. When the zone is stored in a file, by default the primary zone file is named zone_name.dns and it is located in the %windir%\System32\Dns folder on the server.

Secondary zone

When a zone that this DNS server hosts is a secondary zone, this DNS server is a secondary source for information about this zone. The zone at this server must be obtained from another remote DNS server computer that also hosts the zone. This DNS server must have network access to the remote DNS server that supplies this server with updated information about the zone. Because a secondary zone is merely a copy of a primary zone that is hosted on another server, it cannot be stored in AD DS.

Stub zone

When a zone that this DNS server hosts is a stub zone, this DNS server is a source only for information about the authoritative name servers for this zone. The zone at this server must be obtained from another DNS server that hosts the zone. This DNS server must have network access to the remote DNS server to copy the authoritative name server information about the zone.

You can use stub zones to:

• Keep delegated zone information current. By updating a stub zone for one of its child zones regularly, the DNS server that hosts both the parent zone and the stub zone will maintain a current list of authoritative DNS servers for the child zone.
• Improve name resolution. Stub zones enable a DNS server to perform recursion using the stub zone's list of name servers, without having to query the Internet or an internal root server for the DNS namespace.
• Simplify DNS administration. By using stub zones throughout your DNS infrastructure, you can distribute a list of the authoritative DNS servers for a zone without using secondary zones. However, stub zones do not serve the same purpose as secondary zones, and they are not an alternative for enhancing redundancy and load sharing.

There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

• The list of master servers from which the DNS server loads and updates a stub zone. A master server may be a primary or secondary DNS server for the zone. In both cases, it will have a complete list of the DNS servers for the zone.
• The list of the authoritative DNS servers for a zone. This list is contained in the stub zone using name server (NS) resource records.

When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the master servers, which can be in different locations, for the necessary resource records of the authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may contain a single server or multiple servers, and it can be changed anytime.
 Zone Files

Zone files contain information about a namespace and are stored in the named working directory, /var/named/, by default. Each zone file is named according to the file option data in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone.

Each zone file may contain directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. Directives are optional, but resource records are required to provide name service to a zone.

All directives and resource records should be entered on individual lines.

Comments can be placed after semicolon characters (;) in zone files.

 Zone File Directives

Directives begin with the dollar sign character ($) followed by the name of the directive. They usually appear at the top of the zone file.

The following are commonly used directives:

• $INCLUDE — Configures named to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart from the main zone file.
• $ORIGIN — Appends the domain name to unqualified records, such as those with the hostname and nothing more.

For example, a zone file may contain the following line:

$ORIGIN example.com.

Any names used in resource records that do not end in a trailing period (.) are appended with example.com.

	Note
	The use of the $ORIGIN directive is unnecessary if the zone is specified in /etc/named.conf because the zone name is used as the value for the $ORIGIN directive by default.

• $TTL — Sets the default Time to Live (TTL) value for the zone. This is the length of time, in seconds, a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive.

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 resource record changes.

 Zone File Resource Records

The primary component of a zone file is its resource records.

There are many types of zone file resource records. The following are used most frequently:

• A — Address record, which specifies an IP address to assign to a name, as in this example:

<host>     IN     A     <IP-address>

• If the <host> value is omitted, then an A record points to a default IP address for the top of the namespace. This system is the target for all non-FQDN requests.
• Consider the following A record examples for the example.com zone file:

IN     A       10.0.1.3 server1      IN     A       10.0.1.5

• Requests for example.com are pointed to 10.0.1.3, while requests for server1.example.com are pointed to 10.0.1.5.
• CNAME — Canonical name record, maps one name to another. This type of record is also known as an alias record.

The next example tells named that any requests sent to the <alias-name> should point to the host, <real-name>. CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers.

<alias-name>     IN     CNAME       <real-name>

In the following example, an A record binds a hostname to an IP address, while a CNAME record points the commonly used www hostname to it.

server1      IN     A       10.0.1.5 www          IN     CNAME   server1

• MX — Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.

IN     MX     <preference-value>  <email-server-name>

• In this example, the <preference-value> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The MX resource record with the lowest <preference-value> is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.
• The <email-server-name> may be a hostname or FQDN.

IN     MX     10     mail.example.com.       IN     MX     20     mail2.example.com.

• In this example, the first mail.example.com email server is preferred to the mail2.example.com email server when receiving email destined for the example.com domain.
• NS — NameServer record, which announces the authoritative nameservers for a particular zone.

This is an example of an NS record:

IN     NS     <nameserver-name>

The <nameserver-name> should be a FQDN.

Next, two nameservers are listed as authoritative for the domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.

IN     NS     dns1.example.com.       IN     NS     dns2.example.com.

• PTR — PoinTeR record, designed to point to another part of the namespace.

PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to Section 12.3.4 Reverse Name Resolution Zone Files for more examples of PTR records in use.

• SOA — Start Of Authority resource record, proclaims important authoritative information about a namespace to the nameserver.

Located after the directives, an SOA resource record is the first resource record in a zone file.

The following example shows the basic structure of an SOA resource record:

@     IN     SOA    <primary-name-server>     <hostmaster-email> (                     <serial-number>                     <time-to-refresh>                     <time-to-retry>                     <time-to-expire>                     <minimum-TTL> )

The @ symbol places the $ORIGIN directive (or the zone's name, if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record. The hostname of the primary nameserver that is authoritative for this domain is the <primary-name-server> directive, and the email of the person to contact about this namespace is the <hostmaster-email> directive.

The <serial-number> directive is a numerical value incremented every time the zone file is altered to indicate it is time for named to reload the zone. The <time-to-refresh> directive is the numerical value slave servers use to determine how long to wait before asking the master nameserver if any changes have been made to the zone. The <serial-number> directive is a numerical value used by the slave servers to determine if it is using outdated zone data and should therefore refresh it.

The <time-to-retry> directive is a numerical value used by slave servers to determine the length of time to wait before issuing a refresh request in the event the master nameserver is not answering. If the master has not replied to a refresh request before the amount of time specified in the <time-to-expire> directive elapses, the slave servers stop responding as an authority for requests concerning that namespace.

The <minimum-TTL> directive is the quantity of time other nameservers cache the zone's information.

When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (M), hours (H), days (D), and weeks (W). The table in Table 12-1 shows an amount of time in seconds and the equivalent time in another format.

Seconds	Other Time Units
60	1M
1800	30M
3600	1H
10800	3H
21600	6H
43200	12H
86400	1D
259200	3D
604800	1W
31536000	365D

Table 12-1. Seconds compared to other time units

The following example illustrates the form an SOA resource record might take when it is populated with real values.

@     IN     SOA    dns1.example.com.     hostmaster.example.com. (                     2001062501 ; serial                     21600      ; refresh after 6 hours                     3600       ; retry after 1 hour                     604800     ; expire after 1 week                     86400 )    ; minimum TTL of 1 day

 Example Zone File

Seen individually, directives and resource records can be difficult to grasp. However, when placed together in a single file, they become easier to understand.

The following example shows a very basic zone file.

$ORIGIN example.com. $TTL 86400 @     IN     SOA    dns1.example.com.     hostmaster.example.com. (                     2001062501 ; serial                     21600      ; refresh after 6 hours                     3600       ; retry after 1 hour                     604800     ; expire after 1 week                     86400 )    ; minimum TTL of 1 day       IN     NS     dns1.example.com.       IN     NS     dns2.example.com.       IN     MX     10     mail.example.com.       IN     MX     20     mail2.example.com.              IN     A       10.0.1.5 server1      IN     A       10.0.1.5 server2      IN     A       10.0.1.7 dns1         IN     A       10.0.1.2 dns2         IN     A       10.0.1.3 ftp          IN     CNAME   server1 mail         IN     CNAME   server1 mail2        IN     CNAME   server2 www          IN     CNAME   server2

In this example, standard directives and SOA values are used. The authoritative nameservers are set as dns1.example.com and dns2.example.com, which have A records that tie them to 10.0.1.2 and 10.0.1.3, respectively.

The email servers configured with the MX records point to server1 and server2 via CNAME records. Since the server1 and server2 names do not end in a trailing period (.), the $ORIGIN domain is placed after them, expanding them to server1.example.com and server2.example.com. Through the related A resource records, their IP addresses can be determined.

FTP and Web services, available at the standard ftp.example.com and www.example.com names, are pointed at the appropriate servers using CNAME records.

 Reverse Name Resolution Zone Files

A reverse name resolution zone file is used to translate an IP address in a particular namespace into a FQDN. It looks very similar to a standard zone file, except that PTR resource records are used to link the IP addresses to a fully qualified domain name.

A PTR record looks similar to this:

<last-IP-digit>      IN     PTR    <FQDN-of-system>

The <last-IP-digit> is the last number in an IP address which points to a particular system's FQDN.

In the follow example, IP addresses 10.0.1.20 through 10.0.1.25 are pointed to corresponding FQDNs.

$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @     IN     SOA    dns1.example.com.     hostmaster.example.com. (                     2001062501 ; serial                     21600      ; refresh after 6 hours                     3600       ; retry after 1 hour                     604800     ; expire after 1 week                     86400 )    ; minimum TTL of 1 day       IN     NS     dns1.example.com.       IN     NS     dns2.example.com. 20    IN     PTR    alice.example.com. 21    IN     PTR    betty.example.com. 22    IN     PTR    charlie.example.com. 23    IN     PTR    doug.example.com. 24    IN     PTR    ernest.example.com. 25    IN     PTR    fanny.example.com.

This zone file would be called into service with a zone statement in the named.conf file which looks similar to the following:

zone "1.0.10.in-addr.arpa" IN {   type master;   file "example.com.rr.zone";   allow-update { none; }; };

There is very little difference between this example and a standard zone statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by .in-addr.arpa. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.