A zone is a part of the DNS tree (see the DNS Overview) that is served by a group of Authoritative DNS servers.

The actual contents of a zone is basically just a list of Resource records (RRs). There are different kinds of RRs that do different things, and together, they make up the zone. In the document on Resource records, the different kinds of RRs and their uses are discussed, as well as how they can be represented in text form.

This article provides a general overview of what any zone should and/or could consist of.

Every zone has exactly one SOA record. This record contains the following information:

• the primary DNS server for the zone
• the e-mail address of the person in charge of the zone
• information for secondary DNS servers (see Authoritative DNS)
• the amount of time a Caching DNS server may save information about the non-existence of a domain in the zone
• the zone serial number: this is increased whenever the zone changes so that secondaries can check whether the zone has changed

NS records, attached to the zone root, list the DNS servers for the zone by their domain names. These DNS servers can either be in your own zone (in that case, obviously, you should add their addresses to the zone, too), or in an other zone, for example, if you use secondary DNS services provided by the likes of secondary.com and twisted4life.com.

The SOA and NS records together make up the base skeleton of your zone. An example skeleton, with one internal DNS server and one external DNS server, would be:

acdam.net.     2h  SOA ns1.acdam.net.   4h 2h 1w 2h
acdam.net.     2h  NS  ns1.acdam.net.
acdam.net.     2h  NS  ns2.acdam.com.
ns1.acdam.net. 2h  A   

What other records to add, depends on what you want to do with your zone. Some pointers:

• You can see Using DNS for naming hosts (i.e., assign addresses to domain names, the most common task of DNS)
• You can see Using DNS for e-mail (you need to add entries to the DNS if you want mail delivered to your domains)
• You can see Reverse mapping if you want to map IP numbers back to domain names (this is done in a special part of the DNS tree)
• If you want to delegate the authority of some subdomains of your zone to someone else, see the article about Delegation.

Apart from these uses, there are many other, less frequently used, types of records in the DNS tree as well. For example, you can add free-form text to your domain names using TXT records. Some other RR types are listed in the Resource Records article.

One other topic that deserves mentioning here is the concept of aliasing: you can define one domain name to be an alias of another domain (the target domain is called the canonical name) by means of the CNAME record (see Resource records). For example, in this case:

webserver.acdam.net. CNAME www.acdam.net.

The domain webserver.acdam.net. is an alias to www.acdam.net., and www.acdam.net. is the canonical name. For example, if www.acdam.net. has address , and a query for the address of webserver.acdam.net. is done, it will return the same address.

Note that, as a general rule, domain names that appear in other resource records (e.g. as a nameserver in a NS record, or as a mail server in a MX record) should not be aliases! For NS records, this may even cause your domains not to work. Quoting 1912:

 Having NS records pointing to a CNAME is bad and may conflict badly
 with current BIND servers.  In fact, current BIND implementations
 will ignore such records, possibly leading to a lame delegation.
 There is a certain amount of security checking done in BIND to
 prevent spoofing DNS NS records.  Also, older BIND servers reportedly
 will get caught in an infinite query loop trying to figure out the
 address for the aliased nameserver, causing a continuous stream of
 DNS requests to be sent.

Posadis, for one, doesn’t support CNAME’d NS records either, and 974 states that MX records should have a direct (canonical) domain name, too.

If you want to match all subdomains of a specific domain name, you can use wildcard domain names in your authoritative zones. If you create a *. domain name, all non-existent subdomains of will match this wildcard domain name, though not non-existent subdomains of a subdomains of . For example, given the following record:

• *.acdam.net. CNAME www.acdam.net.

For example, bar.acdam.net. will be matched against *.acdam.net (if it does not exist), as well as foo.bar.acdam.net., but not foo.www.acdam.net. (if www.acdam.net. exists).

Note that existent domains will not match if a query is done for a RR that does not exist. For example, if ftpd.acdam.net. exists but does not have a MX RR, a query for the MX record of ftpd.acdam.net. will not match any MX records that may exist for *.acdam.net.. Yeah… :)