General DNS

How Nameservers work

The Domain Name System (DNS) is the system that converts domain names (domain.com) into IP addresses (1.2.3.4). This system is far simpler than most people realize.

There are 3 main components to the DNS system:

• Parent Nameservers (there are 13 of them in the world).
• Your domain name registrar (where you buy a domain).
• Your own Name Server (where you control the DNS values of a domain).

1. When you go to your registrar, you'll purchase a domain. When you purchase the domain, you'll specify the nameservers you want that domain to use. Your registrar will take this information (the domain name and the nameservers it uses) and will send that to the parent nameservers. This can sometimes take a few days to sync up. Once finished, any query of your domain to the parent nameservesr will return the names of the nameservers you specified with your domain. Subsequent queries will ask those nameservers (usually at your own server), using the zones and values you've set up through DirectAdmin.

2. If you wish to create your own nameservers for your domain (e.g., ns1.domain.com, ns2.domain.com, etc.), you'll have to go to your registrar to "register" your nameservers as custom nameservers before you can use them. The first step is usually to make sure they resolve. To do this, you can either go to Reseller Level -> Nameservers, and create nameservers there, or, to accomplish the same effect, simply go to manage your domain's zone (Admin Level -> DNS Admin -> domain.com) and add the 2 "A" records for ns1 and ns2, just like any other subdomain (e.g., the same as for www, ftp, pop, etc.). At the bottom of the page, use the "Add A Record" field to create:

ns1  A  1.2.3.4
ns2  A  1.2.3.5

where 1.2.3.4 and 1.2.3.5 are the IPs you want your nameservers to use. This is essentially all a nameserver needs to have in order to exist (on the part of your server anyway, the rest is at the registrar).

Once your ns1.domain.com and ns2.domain.com values resolve, go to your registrar and register them as nameservers.

If you would like to host your own domain.com on the same ns1/ns2.domain.com nameservers, you would have to create so called GLUE records on the registrar side. Some registrars are calling them A records. In general, you are assigning the desired IP addresses to ns1/ns2.domain.com on a registrar side.

3. Propagation of the new values might take upwards of a few days, so patience is important. Once they're registered, you can again go to your registrar and set your domain to use these new nameservers. You'll also need to go back to your domain's DNS management interface and set these new nameservers in the "NS" record values.

The order of events for a DNS lookup of www.domain.com is as follows:

1. A client queries his ISP's nameservers.
2. His ISP's nameservers query the parent DNS servers for domain.com, and they return its nameservers, (e.g., ns1.domain.com and ns2.domain.com).
3. His ISP's nameservers then query either ns1.domain.com or ns2.domain.com (the choice of which is random) for the value of www.domain.com.
4. Either ns1 or ns2 will return the IP address of the "www" A record for domain.com to the ISP's nameservers. The ISP's nameserver caches this value for usually about 4 hours (TTL value) so further queries are not required during that time. The IP is returned to the client to use to access the site on the server.

The locations in DirectAdmin where the NS records will be used, are specified at:

• Admin Level -> Admin Settings -> ns1/ns2: The main nameservers for the box. Use to give to new Admins and Resellers, and for fallback values. The IPs that these resolve to are the IPs used for "virtual" nameservers at the Reseller Level.
• Reseller Level -> Nameservers -> ns1/ns2 (bottom set): The default values that are given to newly created Users created by this Reseller. As an "Admin", these values will be given to a new Reseller if "personal DNS" is not enabled.
• Reseller Level -> List Users -> username -> ns1/ns2: The default values that are given to newly created domains by the User.

All of these settings ultimately end up changing just the NS records of a domain, so one could go about this by changing the NS values manually in the zone file, as those records are all that really matters.

What options do I have for setting up an external DNS server?

To add redundancy to your DNS system, it's often a good idea to set up a remote DNS server to mirror your zones so that if one were to go offline, you'd have a backup. With DirectAdmin, you have multiple options, varying in difficulty to set up.

1. Use the built-in DNS Clustering Tool.

This requires 2 copies of DA, one on each server. The 2 DirectAdmin installations can talk to each other, copying zones between themselves. To set it up, go to Admin Level -> MultiServer Setup (server A) and add the IP of the remote DirectAdmin server (server B) you'd like to transfer the zones to (send only). If you want the other DirectAdmin server (B) to also send its own zones back to the first server (A), then you'd do the same on it (Add A's IP in server B's MultiServer Setup page).

Note that this same process can be used to set up 3 or more (as many as you wish) servers, all talking together. More info can be found here.

2. Create your own transfer script, called by DA after each DNS write.

There is a custom post script called /usr/local/directadmin/scripts/custom/dns_write_post.sh that you can create (it does not exist, you have to write it) that will be called by DirectAdmin after each write of the DNS zones in /var/named/domain.com.db. You can add any language you want, DA will call it and pass all variables to it through the environment. Your job would be to write a script to transfer the DNS data over to your other DNS server using your own means.

Script info: http://directadmin.com/features.php?id=450

3. Create your own API for the MultiServer Setup to call.

This option is similar to option 1, except that DirectAdmin would connect to some other service, possibly Apache or anything you'd like, that you set up. The idea behind this is that you can mirror the commands that DA is calling and DA would call your scripts using the same command names and values. So, you would in turn make those commands execute the same way that another DirectAdmin box would function normally. This would be by far the most difficult of the methods, but would possibly be the most flexible and clean should you have a custom DNS backup that is possibly database driven.

The commands used by DA are listed here: http://directadmin.com/features.php?id=533

A recent third-party script has been implemented with a solution for this method.

Another remote tool DA can connect to: https://directslave.com

How the MultiServer DNS clustering works

This feature is often thought as being much more complex than it really is.

What is does, is transfers any zones on the given machine to the DA machines you add to the list.

So, if you have server A and add the IP for server B to the list, whenever you add a domain on server A, server B will receive a copy of the DNS zone. Server B will now also be able to resolve the domain. Since this uses the API, nothing is needed to be set up with regards to clustering on server B to get data from server A transferred over to server B.

A sample nameserver setup would be (you can add more/change them as you need):

ns1.domain.com  -> resolve to an IP on server A  
ns2.domain.com  -> resolve to an IP on server B  

Since server B is also running a perfectly good copy of DirectAdmin, there is no reason you can't cluster it with server A as well. Login to server B, and add the IP for server A to the list. You can use the same nameserver settings that you use on A.

For each IP in the list of external DNS servers, there are the options "Zone Transfer" and "Domain Check". You don't need to have these both on if the features they represent are not needed with your setup.

Example, if you still use local nameservers, but just want to prevent a user from adding a domain to server A that already exists on server B, then you disable the Zone Transfer, and just leave Domain Check.

If you are moving users between servers without deleting them from the original machine, and they share the same external DNS server, then you might need to disable the "Domain Check" option. Without disabling it, DA will tell you that the domain already exists in your system (on the external machine). When you disable the "Domain Check" and leave Zone Transfer enabled, DA will blindly add the domain to the external machine (it still checks locally of course), and will overwrite any zone information that might already be there.

If you need to transfer all of your zones from your current machine to the servers listed in your MultiServer IP list, then you can type:

echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue

which will rewrite all local zones, and thus trigger the transfer of them to the remote servers.

Master NS with multiple DA boxes pushing to it

Let's assume you have a master ns1 box where multiple DA boxes push just the DNS zone to it.

It's recommended you enable the master DNS subdomain owner check feature on that master NS server. What this does is enables hostname+user logging into the /etc/virtual/cluster_domainowners file on the master, so a user on box2 cannot create a subdomain from a full domain belonging to a User on box1. It's not needed if the remote domain check is being done on a DA box that has a User associated with the domain, since that remote DA can use the /etc/virtual/domainowners for this check. But as the zone transfer is DNS-only, without the feature, there is no User or hostname to figure out who actually owns it, hence the need for the option.

MultiServer Setup source IP selection

By default when connecting to remote DirectAdmin server source (local) IP address will be automatically selected by OS.

If for some reason there is need to force all outgoing connections to use a specific source IP address it can be set with cluster_ip_bind configuration option.

Example, force all multi-server outgoing connections to originate from 1.2.3.4 source (local) IP address:

da config-set cluster_ip_bind 1.2.3.4

ERRORS

If you've got an invalid value (eg: an IP to bind to, which is not on the system), you might get an error during a Multi-Server Setup test:

Unable to connect to 4.3.2.1: Invalid argument
Unable to open a socket

where 4.3.2.1 is the IP being connected to, not the IP being bound to.

If you see that error, check your cluster_ip_bind value. Note: Debug level for clustering is 136

How to add a 3rd nameserver (ns3)

The DirectAdmin interface currently only allows for 2 nameservers to be entered. You can add a 3rd nameserver to all old and new domains, but this requires some simple file editing.

We'll assume that the 3rd nameserver is called ns3.host.com and that the user domains are called domain.com.

1. First, set up the default ns template so that any newly created domains have the 3rd nameserver.

mkdir /usr/local/directadmin/data/templates/custom    (if doesn't already exist)
cd /usr/local/directadmin/data/templates/custom
cp ../dns_ns.conf .

Then edit the copied dns_ns.conf and add the following line to the bottom of it:

ns3.host.com.=|DOMAIN|.

Make sure you add the periods to the end of each value, as they're very important. This will now add a 3rd nameserver for all domains created after this point.

2. Next, to change the existing domains, we need to edit the named.db template temporarily. Type:

cd /usr/local/directadmin/data/templates

(without the /custom). Edit the named.db file. At the very bottom of the file, add:

|DOMAIN|.       14400   IN      NS      ns3.host.com.

Again paying special attention to the periods at the end of the values. Now, any rewrite done by DirectAdmin will add that line, so let's now issue a full DNS rewrite:

echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d400

At this point, all domains will have the ns3 value, but we don't want them to have multiple ns3 values after each rewrite (adding a subdomain, etc.), so we have to now remove the last line you've added from the named.db. Edit the named.db and remove your entry. You're done.

---

If you want the ns3 value to** vary per Reseller**, you can use if-then-else type statements in the dns_ns.conf, since all templates support scripting, e.g.,

|NS1|=|DOMAIN|.
|NS2|=|DOMAIN|.
|*if NS1="ns1.ofreseller1.com."|
ns3.ofreseller1.com.=|DOMAIN|.
|*else|
ns3.globalforeveryoneelse.com.=|DOMAIN|.
|*endif|

Setting up Nameservers with Godaddy for DirectAdmin

You've purchased a domain from Godaddy, added it to a User in DirectAdmin, and now you want DirectAdmin to manage the DNS.

Let's assume your domain is called , and you want to use:

.domain.com with

and

.domain.com with

Both 1.2.3.4 and should exist on your server. Many registrars allow you to use the same IP, if needed. Ask your hosting provided which 2 IPs to use (can be the same IPs as other nameservers on the box).

1. Set up the DNS as desired in your zone on DirectAdmin User Level -> DNS Management and add 2 "A" records for ns1/ns2:

ns1    A    1.2.3.4
ns2    A    

This will allow them to resolve once your nameserver is used.

2. On the same page, add 2 new NS records:

domain.com.    NS    ns1
domain.com.    NS    ns2

Pay attention to the trailing dot '.' characters, as they are significant.

3. Delete the other 2 NS records that were there before you added yours.

4. Now that the zone is set up on DirectAdmin, log in to your Godaddy account to set up the rest. First, we need to add "Host" or "GLUE" records, which are just like A records managed by the parent nameservers (Godaddy), so that the nameserver IPs are known, so clients know who to ask for a lookup. When logging into Godaddy, go to:

Manage Domain -> domain.com -> Manage DNS -> Host Names

Add ns1 for 1.2.3.4,
and ns2 for .

At the time of this writing, the URL for Host Names looks like: https://dcc.godaddy.com/manage/domain.com/dns/hosts

5. Now that the Host Names are set (may take a few minutes for them to make their way into the system), you'll need to change your NS records at Godaddy. To do that, go to:

Manage Domains -> domain.com -> Manage DNS -> Nameservers: Change

and set the custom nameservers to ns1.domain.com and ns2.domain.com, and remove anything else that was there.

Wait about 10 minutes, then check your domain status before you attempt to connect to your domain through your browser, at:

http://intodns.com/domain.com

If you wait until it resolves before trying it in your browser, you'll save propagation delays where your computer's/ISP's nameservers cache the "domain does not exist" or an old value for ~4+ hours. So, if you can wait until it resolves to the new NS servers before accessing it, you'll save yourself quite a bit of time, waiting for the cache to expire.

Once intodns.com shows the new NS records, wait another few minutes, then test your domain from a browser. If it still doesn't work, wait longer 😃 as it's probably still a propagation delay. As long as intodns.com shows the correct NS records, and doesn't show any red, then it should sort itself out eventually.

I do not want to run DNS services on my DirectAdmin server

If you wish to control all DNS services on another server and do not need to run named (bind) on your DirectAdmin server, you can disable it by doing the following.

1. Edit the /usr/local/directadmin/data/admin/services.status and set:

named=OFF

2. Stop named:

systemctl stop named
systemctl disable named
systemctl daemon-reload

3. Edit the /etc/init.d/named and set the file to show:

#!/bin/sh
exit 0;

This will let DirectAdmin think that it's reloading named, while the script will actually do nothing.

With these changes, the DNS settings will still be made, but no program will be running to host them so they will have no effect.

If you're running on a systemd setup (CentOS 7), then there won't be an /etc/init.d/named file. It will be at:

/etc/systemd/system/named.service

or

/usr/lib/systemd/system/named.service

and you'd need to make its contents look like:

[Unit]
Description=Named Placebo
After=syslog.target network.target
Requires=network.target
Documentation=http://help.directadmin.com/item.php?id=25

[Service]
Type=oneshot
ExecStart=/usr/bin/echo -n ''

which should just run the "echo" command without displaying anything, and should return a zero result. You might also need to run:

systemctl daemon-reload

to reload the new named.service script.

I wish to change the IP of my domain, but have no downtime

Check the article from General Usage guide.

How to add a reverse IP lookup on your IP (PTR record)

Any modern version of DA will be able to do this through the interface.

Go to: Admin Level -> DNS Administration

Scroll to the bottom to the "Add Zone" section and enter your information normally:

domain name:  server.hostname.com
ip:  1.2.3.4
ns1: ns1.hostname.com
ns2: ns2.hostname.com

where

• server.hostname.com is the hostname of your server.
• the IP is your server IP (license IP)
• and ns1/ns2 can be any NS your server uses.

Click the "Create Reverse IP Lookup" checkbox, then click "Add".

Wait a minute or so, then go into SSH to see if it worked:

dig -x 1.2.3.4

If it works, then you'll see a PTR record with your server name. If it doesn't, you'll see a value that says "SOA" with your datacenter's name likely beside it. This means that your datacenter has control over the lookup, so you'll have to contact them to set it up since your server isn't queried when the lookup is done, even if it's correctly set up on your server.

---

For example, the IP of directadmin.com is 66.51.122.131. To check who has authority over the lookup, we can use SOA in the dig to see who controls the lookup on the IP:

# dig SOA -x 66.51.122.131

; <<>> DiG 9.6.1-P1 <<>> SOA -x 66.51.122.131
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49196
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;131.122.51.66.in-addr.arpa.    IN      SOA

;; AUTHORITY SECTION:
122.51.66.in-addr.arpa. 1681    IN      SOA     tera-byte.com. hostmaster.tera-byte.com. 2010032522 3600 900 604800 1800

As we can see in this example, tera-byte.com controls the lookup of the IP. If we needed to change it, we'd contact the value just to the right, in this case hostmaster@tera-byte.com. We can confirm the lookup works because of the dig:

# dig -x 66.51.122.131

; <<>> DiG 9.6.1-P1 <<>> -x 66.51.122.131
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36799
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;131.122.51.66.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
131.122.51.66.in-addr.arpa. 3319 IN     PTR     ip-66-51-122-131.tera-byte.com.

How to hide the version number Named is using

If you wish to hide the version number that Named uses from the outside world, you can do so by adding:

version "secret";

into the options section of your /etc/named.conf, then restart named. Note the word "secret" can be set to whatever you want to be shown as the version.

How to disable AXFR

If you do a DNS check on your domain and see:

AXFR allowed

and you want to get rid of that message, simply add:

allow-transfer {"none";};

into the "options" section of your named.conf file, then restart Named.

What the period does at the end of a DNS value

Often times, we see clients making DNS changes incorrectly, generating values like one of these:

domain.com.domain.com.  A    1.2.3.4
domain.com.             NS    ns1.domain.com.domain.com.

Obviously, that doesn't look right; we don't need the domain to be repeated.

The cause of this relates to the all-important usage of the period, or "dot" at the very end of the value.

What a period does at the end of a value, is it tells Named that we do not want the domain added to the end of that value. If we leave the dot out, then Named will add the domain to the end of the value.

For example, if you see the above NS record, it means you might have entered something like this:

domain.com.     NS   ns1.domain.com

where there is no trailing period at the end of the NS value.

Note how there is a period at the end of the NS name (left side). In this case, what you actually want to see would be one of these entries:

domain.com.    NS    ns1.domain.com.
domain.com.    NS    ns1

where they're both equivalent values.

The shorter "ns1" entry is the exact same as "ns1.domain.com.", assuming the ns1 A record is in the same zone (e.g., you've created your own nameservers for this domain). Because there is no period at the end of the "ns1" value, bind adds domain.com. to the end of it.

If in doubt, use the full ns1.domain.com. with the period at the end.

Using views to make a domain resolve to a different value based on which IP is asking

In this example, we'll outline how to make the DNS system (Bind/Named) resolve a domain to a specific IP, based on which IP is doing the query. For this, we'll use Bind's "view" feature.

Assumptions

• We're on a LAN and we want the LAN computers to resolve the domain to .234
• All external IPs should resolve the domain to
• The domain already has a 1.2.3.4 zone at /var/named/.db
• The server's IP is 192.168.0.234 (where LAN computers should be sent to).

1. Create a LAN copy of the zone.

cd /var/named
cp -p "domain.com.db" "domain.com.lan.db"

2. Edit the domain.com.lan.db file, and change all 1.2.3.4 entries to 192.168.0.234

3. Edit your /etc/named.conf, things will need to be moved around. If after the "options" and "controls" section, move the line immediately after them:

include "/etc/rndc.key";

4. Immediately after the rndc.key include line, add these lines:

acl internal {
       192.168.0.0/24;
};

view "internal-view" {
       match-clients { internal; };
       zone "domain.com" { type master; file "domain.com.lan.db"; };
};

view "external-view" {
       match-clients { any; };

where the point of this is to surround all other "zone" lines in the external-view. When using views, all zones must be within a view.

5. At the very bottom of the named.conf, add this line:

}; //end external view

to close the external view after all external zones are added.

6. If you have more than 1 domain you want to make work internally in this manner, repeat steps 1, 2, 4, where you'd just be adding 1 line to the internal-view in step 4 for the extra domains.

7. Also, you might need to ensure that the 192.168.0.0/24 range does not include your incoming router IP, depending on which IP is incoming from the router, the external IP or the LAN IP (not 100% sure). So the above range may not be correct. Be sure to test your lookups both externally and internally to confirm the views are working correctly.

If you're not sure how ranges work, you can alternatively just add a list of IPs instead of the range. Don't forget the colon after each IP/line.

About DNS template files

DirectAdmin uses different files for DNS templates. They all are located in the /usr/local/directadmin/data/templates directory, starting with dns_ prefix, e.g.,

dns_aaaa.conf
dns_a.conf
dns_caa.conf
dns_cname.conf
dns_mx.conf
dns_ns.conf
dns_spf.conf
dns_srv.conf
dns_tlsa.conf
dns_txt.conf

Each could be customized via the regular template customization method, e.g.,

mkdir /usr/local/directadmin/data/templates/custom/
cd /usr/local/directadmin/data/templates/custom/
cp -p ../dns_txt.conf .

Then modify the newly copied dns_txt.conf file.

---

There might be cases where you'd want to know who the creator is when a new zone is added for a domain by a User. The CREATOR token has been added for the dns_a.conf style dns_*.conf templates.

Note that the value will not exist if a zone is created via the DNS Administration area, since it's not below a User.