The
db.space.net Zone Data File
Introduction
It's time
to start creating our zone files. We'll follow the
standard format, which is given in the DNS RFCs, in
order to keep everything neat and less confusing.
First step
is to decide on the domain we're using and I've
already chosen space.net. This means that the first
zone file will be
db.space.net. Note that this file is to
be placed on the Master DNS server for our domain.
We will progressively build our database by
populating it step by step and explaining each step
we take. At the end of the step by step example,
we'll grab each step's data and put it all together
so we can see how the final version of our file will
look. This, I believe, is the best method of
explaining how to create a zone file without
confusing the hell out of everyone !
Constructing db.space.net
Note:
The actual entries for our file are marked with
bold green
characters using
italic format. Anything else,
such as plain green coloured
characters, is used to help you identify specific
commands I'm talking about that have been used in
the zone file we are creating. Also, keep in mind we
are setting up a primary DNS server. For a simple
DNS caching or secondary name server, the setup is a
lot simpler and covered on other pages.
The first
entry for our file is the Default TTL - Time To
Live. This is defined using the $TTL control
statement. $TTL specifies the time to live for all
records in the file that follow the statement and
don't have an explicit TTL. We are going to set ours
to 3 hours.
$TTL 3h
Next up is
the SOA Record. The SOA (Start Of Authority)
resource record indicates that this name server is
the best source of information for the data within
this zone (this record is required in each db.DOMAIN
and db.ADDR file), which is the same as saying this
name server is Authoritative for this zone. There
can be only one SOA record in every data zone file (db.DOMAIN).
space.net. IN SOA voyager.space.net.
admin.voyager.space.net. (
1 ; Serial Number
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL
of 1 hour
Let's
explain the meaning of this:
space.net. is the
domain name and must always be stated in the first
column of our line, be sure you include the trailing
dot "." after the
domain name, I'll explain later on why this is
needed.
The
IN stands for Internet.
This is one class of data and while other classes
exist, you won't see them at all because they are
not used :)
The
SOA is an important
resource record. What follows is the actual primary
name server for space.net. In our example, this is
the server named "voyager"
and its Fully Qualified Domain Name (FQDN) is
voyager.space.net. Notice the trailing "."
is present here as well.
Next up is
the entry
admin.voyager.space.net. which is nothing but
the email of the person responsible for this domain.
Take the dot "." after
the admin entry and
replace it with with "@" and you have a valid email
address: admin@voyager.space.net. Most times you
will see root, postmaster or hostmaster where I have
placed "admin".
The "("
parentheses allow the SOA record to span more than
one line, while in most cases the fields that follow
are used by the secondary name servers and any other
name server requesting information about the domain.
The serial
number "1 ; Serial Number"
entry is used by the secondary name server to keep
track of changes that might have occured in the
master's zone file. When the secondary name server
contacts the primary name server, it will check to
see if this value is the same. If the secondary's
name server is lower than the primary's, then its
data is out of date and, when equal, it means the
data is up to date. This means when you make any
modifications to the primary's zone file, you must
increment the serial number at least by one.
The
refresh "3h ; Refresh after 3
hours" tells the secondary name server how
often to check that the data for this zone is up to
date.
If the
secondary name server tries to contact the primary
and fails, the retry "1 h ;
Retry after 1 hour" is used to tell the
secondary name server how long to wait until it
tries to contact the primary again.
If the
secondary name server fails to contact the primary
for longer than the time specified in the fourth
entry "1 w ; Expire after 1
week", then the zone data on the secondary
name server is considered too old and will expire.
The last
line "1 h ) ; Negative caching
TTL of 1 day" is how long a name server will
send negative responses about the zone. These
negative responses say that a particular domain or
type of data sought for a particular domain name
doesn't exist. Notice the SOA section finishes with
the ")" parentheses.
Next up
are the name server (NS) records:
; Name Servers defined here
space.net. IN NS voyager.space.net.
space.net. IN NS gateway.space.net.
These
entries define the two name servers (voyager
and gateway) for
our domain space.net. These entries will be also in
the db.ADDR file for this domain as we will see
later on.
It's time
to enter our MX records. These records define the
mail exchange servers for our domain, and this is
how any client, host or email server is able to find
a domain's email server:
; Mail Exchange servers defined here
space.net. IN MX 10 voyager.space.net.
space.net. IN MX 20 gateway.space.net.
Let's
explain what exactly these entries mean. The first
line specifies that
voyager.space.net is a mail exchanger for
space.net, just as the second line (...IN
MX 20 gateway...) specifies that
gateway.space.net is
also a mail exchanger for the domain. The
MX record is what
indicates that the following hosts are mail
exchangers and the numbers right after the
MX record (10, and 20)
indicate the priority level.
These
entries were introduced to prevent mail loops. When
another email server (unlikely for a private domain
like mine, but the same rule applies for the
Internet) wants to send mail to space.net, it will
try to contact first the mail exchanger with the
smallest number, which in our case is
voyager.space.net. The smaller the number, the
higher the priority if there are more than one mail
servers.
In our
example, if we replaced:
space.net. IN MX 10 voyager.space.net.
space.net. IN MX 20 gateway.space.net.
with
space.net. IN MX 50 voyager.space.net.
space.net. IN MX 100 gateway.space.net.
the result
in matter of priority, would be the same. Let's now
have a look our next part of our zone file: Host IP
Addresses and Alias records:
; Host addresses defined here
localhost.space.net. IN A 127.0.0.1
voyager.space.net. IN A 192.168.0.15
enterprise.space.net. IN A 192.168.0.5
gateway.space.net. IN A 192.168.0.10
admin.space.net. IN A 192.168.0.1
; Aliases
www.space.net. IN CNAME voyager.space.net.
Most
fields in this section are easy to understand. We
start by defining our localhost (local loopback) "localhost.space.net.
IN A 127.0.0.1" and continue with the servers
I have on my home network, these include voyager,
enterprise, gateway and admin (my workstation). The
"A" record stands for
IP Address. So "voyager.space.net.
IN A 192.168.0.15" translates to a host
called voyager located
in the space.net domain
with an INternet ip
Address of
192.168.0.15.
The second
block has the aliases table, where we created a
Canonical Name (CNAME) record. A CNAME record simply
maps an alias to its canonical name; in our example,
www is the alias and
voyager.space.net is
the canonical name. When a name server looks up a
name and finds CNAME records, it replaces the name
(alias - www) with its
canonical name (voyager.space.net) and looks up the
canonical name (voyager.space.net). For example,
when a name server looks up
www.space.net, it will replace the
www with
voyager and lookup the
IP Address for
voyager.space.net. This also explains the
meaning of "www" in our webbrowser, it's nothing
more than an alias which, ultimately, is replaced
with the CNAME record defined.
That
completes a simple domain setup! We have now created
a working zone file that looks like this:
$TTL 3h
space.net. IN SOA voyager.space.net.
admin.voyager.space.net. (
1 ; Serial Number
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL
of 1 day
; Name Servers defined here
space.net. IN NS voyager.space.net.
space.net. IN NS gateway.space.net.
; Mail Exchange servers defined here
space.net. IN MX 10 voyager.space.net.
space.net. IN MX 20 gateway.space.net.
; Host Addresses Defined Here
localhost.space.net. IN A 127.0.0.1
voyager.space.net. IN A 192.168.0.15
enterprise.space.net. IN A 192.168.0.5
gateway.space.net. IN A 192.168.0.10
admin.space.net. IN A 192.168.0.1
; Aliases
www.space.net. IN CNAME voyager.space.net.
A quick
glance at this file tells you a lot about my home
domain space.net! This is probably the best time to
explain why we should not omit the trailing dot at
the end of the domain name:
If we took
gateway.space.net as an
example and omitted the dot "."
at the end, that particular entry would turn out
like this:
gateway.space.net.space.net, not what you
intended at all! As you see, the space.net is
appended to the end of our Fully Qualified Domain
Name for the particular resource record (gateway).
This is why it's so important to never forget that
extra dot "." at the end!
Next is
our db.ADDR file, which will take the name
db.192.168.0.
|
