Host subdomains with BIND9 and Apache in Ubuntu

Question

I have a domain betasquirrel.com purchased from GoDaddy and a VPS with Ubuntu 16.04. And I hosted the domain successfully using BIND9 as below:

Created virtual-host for betasquirrel.com in Apache and placed the files. Next created two hosts ns1.betasquirrel.com and ns2.betasquirrel.com in GoDaddy by pointing to VPS IP address.

Next configured BIND9,

/etc/bind/zones/master/db.betasquirrel.com

;
; BIND data file for betasquirrel.com
;
$TTL    3h
@       IN      SOA     ns1.betasquirrel.com. admin.betasquirrel.com. (
1        ; Serial
3h       ; Refresh after 3 hours
1h       ; Retry after 1 hour
1w       ; Expire after 1 week
1h )     ; Negative caching TTL of 1 day
;
@       IN      NS      ns1.betasquirrel.com.
@       IN      NS      ns2.betasquirrel.com.


betasquirrel.com.    IN      MX      10      mail.betasquirrel.com.
betasquirrel.com.    IN      A       144.217.163.139
ns1                     IN      A       144.217.163.139
ns2                     IN      A       144.217.163.139
www                     IN      CNAME   betasquirrel.com.
mail                    IN      A       144.217.163.139
ftp                     IN      CNAME   betasquirrel.com.

/etc/bind/zones/master/db.144.217.163

;
; BIND reverse data file for 163.217.144.in-addr.arpa
;
$TTL    604800
163.217.144.in-addr.arpa.      IN      SOA     ns1.betasquirrel.com. admin.betasquirrel.com. (
                          1         ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 day
;
163.217.144.in-addr.arpa.       IN      NS      ns1.betasquirrel.com.
163.217.144.in-addr.arpa.       IN      NS      ns2.betasquirrel.com.

139.163.217.144.in-addr.arpa.   IN      PTR     betasquirrel.com.

/etc/bind/named.conf.local

zone "betasquirrel.com" {
       type master;
       file "/etc/bind/zones/master/db.betasquirrel.com";
};

zone "163.217.144.in-addr.arpa" {
       type master;
       file "/etc/bind/zones/master/db.144.217.163";
};

In named.conf.options

forwarders {
    213.186.33.99;
};

/etc/init.d/bind9 restart

Next added the name-servers ns1.betasquirrel.com and ns2.betasquirrel.com in GoDaddy and the site started working.

Now how can I host sub-domains like demo.betasquirrel.com. I have just created virtual-hosts and it's not working.

/etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
search demo.betasquirrel.com
search betasquirrel.com
nameserver 213.186.33.99
search local

/etc/apache2/sites-available/betasquirrel.com.conf

<VirtualHost *:80>
  ServerName betasquirrel.com
  ServerAlias www.betasquirrel.com
  DocumentRoot /var/www/html/betasquirrel.com/htdocs
  DirectoryIndex index.php index.html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

/etc/apache2/sites-available/demo.betasquirrel.com.conf

<VirtualHost *:80>
  ServerName demo.betasquirrel.com
  ServerAlias www.demo.betasquirrel.com
  DocumentRoot /var/www/html/demo.betasquirrel.com/htdocs
  DirectoryIndex index.php index.html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

You are strongly encouraged *not* to host your own authoritative DNS on a VPS, particularly since it is impossible to satisfy [BCP 16](https://tools.ietf.org/html/bcp16#section-3) with a single routable network/IP address. (Related Q&A's: [Should we host our own nameservers?](http://serverfault.com/q/23744/152073), [Why is geo-redundant DNS necessary for small sites?](http://serverfault.com/q/710108/152073)) — Andrew B, Jan 03 '17 at 17:49
I concur with Andrew. Also, what vhosted site is not working? Does the name resolve correctly? If it does, it's not a DNS issue, so post the relevant httpd config section. — Dylan Knoll, Jan 03 '17 at 17:57
@AndrewB So I should have another VPS and domain to act as nameservers or I should by some other third-party nameservers? — Anshad Vattapoyil, Jan 04 '17 at 03:49
Third party is always the best option until you have experience running private nameservers under your belt. There are many good providers that are free/cheap. — Andrew B, Jan 04 '17 at 04:00
According to whois data, `mydomain.com` was registered in 1995. Did you really have it lying around for 21 years before trying to use it? Also, "it's not working" is a completely worthless problem description. — Calle Dybedahl, Jan 04 '17 at 08:59
@devo If you want to munge your domain name, use the ones set aside for the purpose. That would be example.TLD, i.e. example.com, example.net, etc. Better still would be to actually *not* hide accurate and useful information. — Jenny D, Jan 05 '17 at 17:20
You thought it would be helpful to not give accurate information to those helping you debug your issue? I cannot even... — Jenny D, Jan 05 '17 at 17:27
@JennyD No, nothing like that. I used example domain when I posted my question. Now I have updated my question with accurate information only. — Anshad Vattapoyil, Jan 05 '17 at 17:32
@AndrewB Following requirement to have multiple DNS servers in different subnets is kind of stupid when you only have a single server that answers on that domen. If it fails, having redundant DNS won't change anything - it will still be inaccessible to anyone. So I say having even a single DNS server is fine in that particular case... — Anubioz, Jan 05 '17 at 17:37
@Anubioz It may sound "stupid", but the Serverfault community has had this debate several times already. [Please read the Q&A I linked earlier](http://serverfault.com/q/710108/152073) and the included comments...we created that after the last debate and there are no compelling facts being presented here that suggest it is worth having again. — Andrew B, Jan 05 '17 at 19:46

score 3 · Answer 1 · edited Oct 07 '21 at 06:58

Your problem seems to lie in the fact that your BIND does not appear to be correctly configured, so, no hosts within your zone appear to resolve, at least not externally.

Your glue records are correctly configured with your registrar, so, there's nothing that needs changing there:

% dig @a.gtld-servers.net. ns1.BETASQUIRREL.COM. | egrep "^[[:alnum:]]"
BETASQUIRREL.COM.       172800  IN      NS      ns2.BETASQUIRREL.COM.
BETASQUIRREL.COM.       172800  IN      NS      ns1.BETASQUIRREL.COM.
ns2.BETASQUIRREL.COM.   172800  IN      A       144.217.163.139
ns1.BETASQUIRREL.COM.   172800  IN      A       144.217.163.139

Your server does appear to be online, so, it's not a firewall issue:

% dig @144.217.163.139 version.bind txt chaos +short
"9.10.3-P4-Ubuntu"

However, your BIND does not appear to be acting as an authoritative server for your domain zone:

% dig @144.217.163.139 ns1.BETASQUIRREL.COM. a +short
%

Compare with what happens when the name is properly configured:

% dig @216.218.131.2 ns2.he.net a +short
216.218.131.2
%

Note that not a single host within your domain name appears to work; if some do work for you, it's probably related to caching of the earlier entries from the time when some hosts did work.

Additionally, note that configuring the reverse zone, 163.217.144.in-addr.arpa., is only appropriate when you have purchased at least 256 IPv4 addresses, in a single /24, and have received the complete delegation for the zone. Sometimes providers also support "classless" delegation, e.g., as per https://www.rfc-editor.org/rfc/rfc2317, however, with the value and cloud providers as OVH, it's probably most common to simply use their interface to set up reverse record on their own servers, without a need to run any extra zones on your end.

Note that configuring forwarders { 8.8.4.4; }; would only be correct if you intend to run a local recursive DNS server; it is separate and independent from running an authoritative DNS server as you're originally tried to do. It's generally a bad idea to run both as part of the same daemon, due to the issue of potential cache poisoning.

Moreover, using 8.8.4.4 is a bad idea for reasons too long for this answer, and you're already using 213.186.33.99 (cdns.ovh.net.) in /etc/resolv.conf, which must be the recursive server of your provider, and is likely the best choice for the setting.

Suggested solution: it appears that you're trying to solve multiple independent issues all smashed together. You should probably remove the forwarders setting from BIND; determine why it doesn't act as your authoritative server (look into its logs to see what may be going on), and, failing that, simply delegate the job of running the nameservers for a third party.

Most hosting providers already support authoritative DNS servers at little or no charge (if you're a customer), and have a web-interface where things could be configured. Else, there are also many free providers; the most common one being http://dns.he.net/ -- it's free and really fast, and they let you edit your settings online.

Alternatively, I may also suggest scrapping your BIND and Apache settings, and trying to go with NSD3 and nginx.

BTW, I've also just noticed that your question lists `/etc/resolve.conf` -- there should not be such a file on your system, the correct filename for the file you describe is `/etc/resolv.conf` — cnst, Jan 05 '17 at 21:28
I have removed entries for `demo` from zone file and the main domain started working.Also updated forwards, all updated in question as well. I am just a beginner for this, so please debug once again and help me with right config. — Anshad Vattapoyil, Jan 06 '17 at 03:46

score 2 · Accepted Answer · edited Apr 13 '17 at 12:14

As per the prior troubleshooting, your domain zone wasn't being served at all from your BIND, even though the server itself was running, and delegation was correct.

As per your comment, you've removed the demo entries, and the rest of your domain started working again, which leads us to the actual entries that were removed, which were all wrong taken together:

-demo.betasquirrel.com. IN A 144.217.163.139
-demo IN A 144.217.163.139
-demo IN CNAME demo.betasquirrel.com.

First of all, the first two entries are identical -- after expansion, both the left and the right sides are identical between the two, which might result in an error, because the same identical entry is effectively present twice.
However, the most problematic issue comes from the presence of both the A and CNAME records at the same time -- the CNAME record means that this name refers to a different host instead; and as such, the name cannot simultaneously contain ANY other records, as it's merely an alias.

To put it in filesystem terms, an A record is like a line in a file, and can coexist with pretty much any other record (lines in the same file). However, a CNAME is like a symbolic link -- if a given file is a symbolic link, it cannot itself also contain any other random lines, too.
Moreover, looking more closely into your CNAME, it's actually a link from itself to itself (after the expansion), which is also entirely wrong in itself.

Solution:

Either add a CNAME record, or an A record; the difference is in semantics, and there's no "right" or "wrong" solution here. You cannot add both at the same time, however. Moreover, if adding a CNAME record, it must point to an existing record that contains the required A record, and it definitely cannot simply point back to itself.

Option 0:

+demo IN A 144.217.163.139

Option 1a:

+demo IN CNAME @

Option 1b:

+demo IN CNAME betasquirrel.com.

Option 2a:

+demo IN CNAME www

Option 2b:

+demo IN CNAME www.betasquirrel.com.

You cannot take all the options simultaneously at the same time!!!

No, like seriously, you can't! It just won't work at all. Don't blame us for it.

Note that options a and b are identical -- the only difference is in the syntax that you use in your config file, but when it's loaded by the server into the structures representing the DNS protocol, there should not be any difference between either notation.

P.S. Also note that the + sign in front of the examples signifies the line that you must add, it shouldn't be the actual part of the file.

wurtel · Answer 3 · 2017-01-06T11:35:39.913

If you want to start using demo as a subdomain, you will need to add an A or CNAME record to your zone file, just like you did for ns1, ns2, and mail.

So your zonefile should look like this:

;
; BIND data file for betasquirrel.com
;
$TTL    3h
@       IN      SOA     ns1.betasquirrel.com. admin.betasquirrel.com. (
                        2        ; Serial
                        3h       ; Refresh after 3 hours
                        1h       ; Retry after 1 hour
                        1w       ; Expire after 1 week
                        1h )     ; Negative caching TTL of 1 hour

@       IN      NS      ns1
@       IN      NS      ns2

@       IN      MX      10      mail
@       IN      A       144.217.163.139
ns1                     IN      A       144.217.163.139
ns2                     IN      A       144.217.163.139
www                     IN      A       144.217.163.139
mail                    IN      A       144.217.163.139
ftp                     IN      CNAME   www
demo                    IN      CNAME   www

Note the addition of the last line. Now your DNS server knows how to respond when you ask for demo.betasquirrel.com.

Also don't forget to increment the serial when you make changes.

BTW, using CNAME on a subdomain to loop back to the top domain is something I wouldn't do... so I've changed that as well. And @ is short-cut for the curent origin (i.e. domain name).

Host subdomains with BIND9 and Apache in Ubuntu

3 Answers3

Solution:

You cannot take all the options simultaneously at the same time!!!