Master files
Master files are a standard way to store the contents of a zone in. Most major DNS servers support DNS master files either natively or with some import facility.
Bascially, a master file is just a list of Resource records: one RR per line, in the usual text representation:
The SOA
record of a zone should always be the first record of a master file.
The fields are separated by one or more spaces or tabs. Everything after a semicolon (;
) is ignored, which is useful for comments. Records can be span over multiple lines by placing a free-standing (
on the first line of the record, and a free-standing )
on the last line. This is commonly used for SOA
records, e.g.:
acdam.net. 2h IN SOA ( ns1.acdam.net. ; primary server ; contact ; serial number 4h ; refresh 2h ; retry 1w ; expire 2h ) ; ncache ttl
There are a few short notations that can be used. First of all, all domain names in a Resource Record, both in the
field and in the
field, are considered relative to the zone root. This means any domain name that does not end with a dot gets the zone root appended, e.g. mail
becomes mail.acdam.net.
in the acdam.net.
zone. The @
domain is short notation for the root domain of the zone.
For example, in the acdam.net.
zone, the following records are equivalent:
@ 2h MX 10 mail acdam.net. 2h MX 10 mail.acdam.net.
The domain name to which domain names are considered relative can be changed with the $origin
directive. For example, after the following line:
$origin europe.acdam.net.
all following RRs are considered relative to europe.acdam.net.
. The domain name in the $origin
directive itself is always relative to the zone root, so we could have written $origin europe
as well.
Since all records in a zone are in the same class (pretty much always IN
), the class can be left away. Also, if no domain name is given (i.e., the first character of a line is a space), then the domain name of a record is presumed to be the same as the last domain. For example, the following specifies two A
records for www.acdam.net.
:
www.acdam.net. 2h A 2h A
We can leave the TTL unspecified as well. In that case, the TTL of the SOA
record is used. We can set the default TTL with the $ttl
directive. Consider this somewhat forced example:
acdam.net. 2h SOA ns1.acdam.net. 4h 2h 1w 2h ns1.acdam.net. 4h A acdam.net. NS ns1.acdam.net. $ttl 4h acdam.net. NS ns2.acdam.com.
In this case, the first record has an explicit TTL of two hours. The SOA
record should always have a TTL, unless there is a $ttl
directive in front of it. The second record has an explicit TTL of four hours. The third record has an implicit TTL of two hours, taken from the SOA
record, and the last record has an implicit TTL of four hours, taken from the $ttl
directive.
Finally, there is an $include
directive that can be used include an other master file in the current file. This is not currently supported by Posadis, but we mention it for completeness. It looks like this:
$include
The
fields is the master file to include, and the
field, which is optional, is the origin for domain names in the new master file. $origin
and $ttl
settings and implicit domain names are not inherited from the $include
d master file. Let’s do an example master file for the acdam.net.
zone. Read What makes up a zone for what all this records are about:
; ----- master file for acdam.net. zone ----- $origin acdam.net. ; set the origin to acdam.net (not nessecary, just for clarity) $ttl 2h ; set default TTL to 2h @ SOA ( ns1.acdam.net. ; primary server ; contact ; serial number 4h ; refresh 2h ; retry 1w ; expire 2h ) ; ncache ttl TXT "ACDAM.net zone" ; free-form text NS ns1 NS ns2.acdam.com. MX 5 mail MX 10 fallback.acdam.com. ns1 A www A webserver CNAME www ; webserver is alias for www mail A ; delegation for europe.acdam.net. $origin europe $ttl 4h @ NS ns1 @ NS ns2.acdam.com. ns1 A