This post deals exclusively with the zone files. I have written another post that deals with the installation of a bind server.
For all practical purposes Zone files are separate files that are included from the main configuration file (typically named.conf ).
These zine files follow a specific syntax and define all the specific domain records for a specific domain.
To include a zone file for domain.dom we would add something like this in the named.conf configuration file.
zone "domain.dom" {
type master;
file "/usr/local/etc/namedb/dynamic/db.domain.dom";
};
Obviously “/usr/local/etc/namedb/dynamic/db.domain.dom” would be the location of the zone file and it would need to be readable by the user that runs bind server, (typically thus user is bind and has an id of 53). Typically you would make sure that all zones files are owned by “bind”.
On the slave server you will need to add a slightly different entry:
zone "domain.dom" {
type slave;
masters { 10.10.1.3; }
file "/usr/local/etc/namedb/dynamic/db.domain.dom";
};
In this case you will no write the zone file, you only need to make sure that “bind” has writing privileges to the directory you are pointing at (“/usr/local/etc/namedb/dynamic/”).
Let’s look at a sample zone file:
$TTL 86400
$ORIGIN domain.dom
@ IN SOA ns1.server.dom. hostmaster.server.dom. (
2020032602; Serial
3H; Refresh
15M; Retry
2W; Expiry
1D ); Minimum
86400 NS ns1.server.dom.
86400 NS ns2.server.dom.
3600 A 10.0.0.1
3600 MX 10 mail.mailserver.dom
3600 TXT v=DMARC1; adkim=s; aspf=s; p=reject; sp=none; rua=mailto:dmarc@mailserver.dom; ruf=mailto:dmarc@mailserver.dom
3600 TXT v=spf1 include:server.dom -all
dkim._domainkey 3600 TXT v=DKIM1; p=the dkim string goes here
www 3600 CNAME @
Both TTL and ORIGIN work essentially as defaults, if nothing else is specified TTL will define the time to live and ORIGIN will define the domain.
The next session is the Start of Authority (SOA). Basically this part provides them main name sever info (ns1.server.dom in this example) and an email to use expressed as hostmaster.server.dom. where the first dot would be replaced by a ‘@’.
Next, between the two parentheses you have a series of information that are mostly useful for another name server requesting the latest information on this domain.
You have a serial number, which effectively will tell any caching server whether things might have changed in this record, it must be changed since the last time it was loaded in order for the slave server to reload the information.
Then you have 4 more info, Refresh, Retry, Expiry and Minimum. This effectively say, if you have cached the info and you want to know if anything changed, you should retry only 15 minutes later. After 3 hours you should refresh the info, in two weeks you should consider the information you have cached to be expired and, as a minimum, you should check it after one day.
The settings listed here are reasonable defaults for most configurations, feel free to look up more info if you have some specific need to refresh the zone information more frequently.
Now, let’s assume we have created the new domain in the master server, how does the slave server know to look the information up?
Once we have created the file we will have to run a few commands to make it active.
First we should make sure we did not break something in named.conf file:
named-checkconf /usr/local/etc/namedb/named.conf
A empty response is what we are looking for.
Next let’s make sure we didn’t make any error creating the zone file:
named-checkzone domain.dom /usr/local/etc/namedb/dynamic/db.domain.dom
In this case we expect a response, and it should look like this:
zone domain.dom/IN: loaded serial 2020040301
OK
Great. We are ready to reload the configuration:
rndc reload
Finally, let’s reload the configuration on the slave server as well (this requires that we have added the call for this domain as described before).
rndc -s 10.10.2.5 reload
Done. At this point we should have an active authoritative domain name server. We are ready to configure our domain name servers as the DNS servers for this domain.
You will likely take care of it in the control panel of your domain name registrar.
You’d think we are done, but wait! There is one more thing that we should do. While the setup as described to this point would work, there is an additional step that should be taken. It is called DNSSEC and i will get into it in a separate post.