Directadmin Docs

Troubleshooting

Named is running but is not responding to requests

If named is running, your DNS settings are correct (as far as you know), then the usual cause is either a firewall, or /etc/named.conf setting.

  1. Ensure named is running and listening on all IPs:
netstat -lnp | grep named

You'll want to see all IPs listed, bound to port 53. If not, check the /etc/named.conf for a setting relating to the word "bind" or "listen" to ensure it's not just binding to local IPs.

  1. Often, named will be bound to all IPs, but instructed to only offer responses to local IPs. Check your /etc/named.conf and ensure this is NOT set:
allow-query     { localhost; };

as it will prevent external sources from querying your box.

  1. Remove these if you find them:
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };

If not removed, then Named is only listening on these IPs, let alone which IPs it allows to query it.

  1. Ensure you don't have a firewall blocking port 53. Shut off iptables to test:
service iptables stop

Or install and use CSF.

  1. Test a query from an external server. Using https://www.intodns.comopen in new window tends to be the easiest way of doing that. It will also give you more info about your DNS settings.

www.domain.com doesn't work, but domain.com works fine (or vice versa)

This is almost always a propagation issue which will resolve itself in a matter of hours.

The assumption is that most people access their domains with** www.domain.com vs domain.com** (without the www).

This means that your ISP's nameservers will have the www.domain.com in its cache.

When you make a change to your DNS (move the domain to a different server, or change an IP) all DNS values will need to be updated to the new value.

When you try to view www.domain.com again, you get your ISP's cached value, which will stay in the cache for several hours, so users will receive the old IP which will end up showing some errors (or either the Apache welcome page or the "this IP is shared among many domains" page).

The next common reaction is to check the domain with just "domain.com" (no www). Because the value hasn't been used yet, it will not be in the ISP's cache. The result is that the ISP will fetch the NEW/correct IP for the domain, thus "domain.com" will work fine, but "www.domain.com" will not.

The solution is to** wait to 4 hours** for the cache to expire at your ISP, at which time the new IP will be fetched.

The preemptive solution is to lower your TTL (in the 'named.db' template or the zone) to a value of several minutes instead of 4 hours, about a** day before you make any IP changes** to a domain.

A handy tool to check how domain.com and www.domain.com are resolving from different places around the globe is: https://www.whatsmydns.net/open in new window

sub.domain.com doesn't work, but domain.com/sub works fine

If you've created a subdomain and you can access it from www.domain.com/sub, but cannot access it from sub.domain.com, there are a few things you can check.

  1. Ensure the "sub" A record exists in the DNS. User Level -> DNS Control

  2. Manually query your server to see if the sub-domain resolves, e.g.,

dig sub.domain.com @127.0.0.1

If this does not return the correct IP, then try restarting named:

killall -9 named
service named restart

Then run the dig command again. If that resolves it, it's most likely just dns propagation, but it might also be that the task.queue is not being processed.

  1. Another possibility is that your domain is controlled at an external DNS location and not controlled by DA. This means that anytime you add a subdomain, you'll need to manually log into the remote DNS server to add the "A" record for that subdomain such that it resolves externally. You can check where you domain is controlled by going to https://www.intodns.comopen in new window. The parent nameservers are the DNS servers that control your domain. If they resolve to IPs that do not exist on your DA box, then you're using external DNS servers and must manually add the A records.

  2. If sub.domain.com resolves fine (if you see the shared IP page, or Apache page), then check below guide to ensure the VirtualHosts are being set up correctly, and that the IP that the sub-domain resolves to matches the IP in the VirtualHost.

Testing your DNS IPs from /etc/resolv.conf

If you get DNS lookup errors, it might be invalid IPs set in the file /etc/resolv.conf . The resolver will start at the first "nameserver" entry and work its way down.

A sample /etc/resolv.conf might look like this:

nameserver 8.8.8.8
nameserver 8.8.4.4

You might have IPs specified by your datacenter in order to use their nameservers.

To test the lookup the A record of a google.com domain with a specific DNS IP 8.8.8.8 run the following:

dig A google.com @8.8.8.8

You might get output like this:

# dig A google.com @8.8.8.8

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6 <<>> A google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15679
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             207     IN      A       216.123.194.119

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Sep 28 00:09:49 2015
;; MSG SIZE  rcvd: 284

Where the value you're looking for is the IP under the ;; ANSWER SECTION.

  • A return value can have many results, which should all be displayed if the domain resolves to more than one place.

  • If you get a** blank IP** in the result, it would imply that the nameserver is responding, but the domain in question is not on that server, and recursive queries are disabled. (we don't want recursive queries enabled).

  • If you cannot connect at all, ensure that "named" is running, and port 53 for both TCP and UDP are open in your firewall. Add the option +tcp or +notcp to explicitly test TCP and UDP, respectively. Lookups will usually be using UDP if not specified.

Why do I see "Apache is functioning normally" instead of my domain?

This guide refers to when you're seeing:

Apache is functioning normally

or

Hey, it worked !
The SSL/TLS-aware Apache webserver was
successfully installed on this website.

or

This IP is being shared among many domains.
To view the domain you are looking for, simply enter the domain name in the location bar of your web browser.

instead of your domain's contents when viewing your domain in the browser.

The cause of this is that either

  1. The value the domain resolves to at your computer is not matching the value Apache is using,

OR

  1. the virtualhost is not included in the Apache configs.

For 1) To check this, simply go to Admin Level -> Show All Users, look for the domain, and see what IP it's set to use. Next, you need to figure out what IP the domain resolves to. It's best to use an external server like dnsreport.com or some other free lookup services to determine the IP the domain resolves to. These 2 IPs need to match.

Note that if you've recently changed the IP of your domains, you'll have up to 4 hours of waiting before the new IP propagates to you. So seeing the above pages is normal during/following IP changes for up to 4 hours. To lower this time, lower your TTL before making the IP change.

For 2) There are a few things to check. The user httpd.conf files are:

/usr/local/directadmin/data/users/username/httpd.conf

and this file must be "Include"d into your main /etc/httpd/conf/httpd.conf via one of two possible ways, depending on your setup.

a. if you've got CustomBuild (usually Apache 2), then check the /etc/httpd/conf/httpd.conf. You should see the line:

Include conf/extra/directadmin-vhosts.conf

somewhere near the bottom of the file. Then in the /etc/httpd/conf/extra/directadmin-vhosts.conf file, you should see the Include line for the user httpd.conf

Include /usr/local/directadmin/data/users/username/httpd.conf

If you don't see that, you can rewrite all of the Apache confs with:

cd /usr/local/directadmin/custombuild
./build rewrite_confs

Make sure that you see:

apacheconf=/etc/httpd/conf/extra/directadmin-vhosts.conf

in your /usr/local/directadmin/conf/directadmin.conf for this setup.

LAN setup

If you're on a LAN, then your incoming device IP would be your LAN IP, and not the external IP. This would relate to the IP the VirtualHost has.

If you are running on a LAN, ensure you've followed all steps from this guide: http://www.directadmin.com/lan.shtmlopen in new window

Specifically, steps #4 and #5. Step 4 in the lan guide will link your LAN IP to the external IP, adding the LAN IP to the VirtualHost.

You can check which IP is used for incoming connections by creating /var/www/html/info.php containing the following code:

<?php phpinfo(); ?>

Then view it through Apache and check the variable:

_SERVER["SERVER_ADDR"]

The IP listed there is the IP that Apache sees. It's what you'd need to add to your VirtualHost...either with the linked IP system, or by changing the IP that the domain resolves to.

Error: Open DNS Server allow recursive lookups

The error basically means that anyone can use your nameservers to do DNS lookups on the internet.

Open DNS Server allow recursive lookups

It's considered a security risk to allow recursive lookups on an authoritative server. You can disable the recursion by adding

allow-recursion {localnets; };

to the "options {" section in your named.conf file.

Newer versions of Named may require this setting instead
allow-query     { any; };
allow-transfer  { none; };
allow-recursion { localhost; };
recursion yes;

in order to allow local recursion, but block remote recursion.

Long TXT records are broken into strings on multiple lines

As bind (named) has a line length limit, the DNS system does allow for multi-line records. We make use of this feature because long DKIM keysopen in new window wouldn't fit on one line, as they'd be too long.

This is the change to DA where we enabled multi-line records: http://www.directadmin.com/features.php?id=1387open in new window

For example, the DKIM TXT record we use for directadmin.com looks like this in the db file:

x._domainkey    14400   IN      TXT     ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApxJI+ldB/P7ocCsU4MjgC0iK+sIQ2g1Ft1RG3LuqquzaY8dmK+SsLVQi8uuo8t7DzAhsAGcHgHNOi189twbtQEz"
                                       "4R3KOLhESd3xGUYP0FTvyejDOaAeZzvjCzI6oj42Y0pNDRrmuOgAd61qJy46+smfKc+QrI4E1DGHnjrlXzrsBK73DMqX9JuD9oGRaXDghakGdAebBjNcRsZfjIv84DPmrHE9/nqacqUnpK8Z71jAEc"
                                       "nklPIfC6LNmrWPzG7+6fN+LbAAUSjvXGw0GpB6EkhRsrcSwilE+vPe+S42aE4dBCvAbLjcZgJIA/gVqnNlm8jfL8qshXpQjIUObfd+o4wIDAQAB" )

And the output of the DNS lookup looks like this:

[root@jbmc-software public_html]# dig TXT x._domainkey.directadmin.com +short
"v=DKIM1\; k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApxJI+ldB/P7ocCsU4MjgC0iK+sIQ2g1Ft1RG3LuqquzaY8dmK+SsLVQi8uuo8t7DzAhsAGcHgHNOi189twbtQEz" "4R3KOLhESd3xGUYP0FTvyejDOaAeZzvjCzI6oj42Y0pNDRrmuOgAd61qJy46+smfKc+QrI4E1DGHnjrlXzrsBK73DMqX9JuD9oGRaXDghakGdAebBjNcRsZfjIv84DPmrHE9/nqacqUnpK8Z71jAEc" "nklPIfC6LNmrWPzG7+6fN+LbAAUSjvXGw0GpB6EkhRsrcSwilE+vPe+S42aE4dBCvAbLjcZgJIA/gVqnNlm8jfL8qshXpQjIUObfd+o4wIDAQAB"
[root@jbmc-software public_html]#

where you'll note that dig does return multiple strings in the result, but this is normal.

If a program is doing a check on this type of record value, it's up to that program to assemble the string into one long value. For example, Exim uses this string, and does know how to assemble the value.

Some other URLs describing multi-line TXT records:

http://www.zytrax.com/books/dns/ch8/txt.htmlopen in new window

http://razzed.com/2009/03/05/dkim-txt-records-in-dns-exceeding-255-characters/open in new window

http://superuser.com/questions/657789/format-of-txt-data-in-dns-recordopen in new window

Manually checking if an IP is in RBL using dig

There are already great RBL checking tools like http://www.dnsbl.info/dnsbl-database-check.phpopen in new window, if you're trying to find out if you're listed, but if you want more manual control, like getting the raw return value for a specific IP in a specific RBL list, you can use "dig".

To do this, you simply do a lookup, of the IPv4 IP in reverse order, as a subdomain of the RBL list.

For example, let's say you want to check IP: 12.34.56.78 in the RBL list: hostkarma.junkemailfilter.com

To do this, you'd run the query:

dig 78.56.34.12.hostkarma.junkemailfilter.com

and check the result.

Last Updated: