Setup Nameservers

Overview

BIND is installed on this image and ISPConfig’s DNS manager works, so you can create and edit zones in the control panel. The server does not answer DNS queries from the internet as shipped, and port 53 is closed in the firewall.

That is deliberate, and for most operators it is what you want. Domains are normally pointed at a registrar’s or a DNS provider’s nameservers, and a DNS server exposed to the internet is one more service to secure and keep available.

This page is for the case where you want your own nameservers, usually because you are running a hosting business and want your customers’ domains delegated to names you control. Because operators arrive here with different requirements, two routes are described. They are different designs, not two ways of doing the same thing. Read the comparison before you start, and pick one.

The approach most people try first, and why it is the worst one

The obvious move is to widen listen-on in /etc/named.conf, open port 53 to the world, and point the registrar at the instance. It is the wrong thing to do, for three separate reasons:

• One server is not a nameserver pair. Registrars require at least two nameservers on separate addresses before they will accept a delegation, so a single instance cannot satisfy them on its own.
• Your DNS dies with your instance. Every domain on the server stops resolving during a reboot, a resize or an outage, including the mail that depends on it.
• It arms an open resolver. The stock configuration ships recursion enabled directly beneath its own comment warning against it. Widening listen-on while recursion is on turns your server into an open resolver, which will be found within days and abused to amplify attacks against other people. Your address ends up on blocklists, which then breaks your mail.

Both routes below avoid all three. Neither needs a second instance, and neither needs glue records.

Choosing between the two routes

Do not try to combine them. Route 53 accepts no zone transfer in either direction, so it cannot act as a secondary for BIND and BIND cannot act as a secondary for it. Choose one route per domain.

Route 1: Hurricane Electric as your public nameservers

This is the hidden primary pattern, sometimes called a stealth master. Your instance holds the real zone and remains the thing you edit in ISPConfig. It is never named at the registrar and never answers a query from the public. Hurricane Electric’s five nameservers pull the zone from it and answer the world.

Hurricane Electric’s DNS service is free and has been for many years. You will need an account at dns.he.net.

Step 1: find the address Hurricane Electric transfers from

Everything in this route depends on one address, and a wrong value here fails silently: the zone simply never transfers, and nothing tells you why. Rather than trusting a number printed on a page, read it from Hurricane Electric’s own published record:

dig +short slave.dns.he.net

At the time of writing that returns 216.218.133.2. Use whatever your own lookup returns.

Step 2: let BIND answer that one address

Edit /etc/named.conf and add the instance’s own address to listen-on, keeping 127.0.0.1. Use the private address that ip -4 addr shows, not the public one, because AWS translates between them.

Leave recursion no exactly as it ships.

Then check the file and restart, and confirm the change actually reached the running process, which is the step most often skipped:

sudo named-checkconf
sudo systemctl restart named
sudo ss -lnup | grep ':53'

If ss still shows only 127.0.0.1, the edit has not taken effect and nothing later in this page will work. A configuration change that never reached the daemon is the single most common reason this procedure appears to fail.

Step 3: open port 53 to Hurricane Electric only

In your EC2 security group, add two inbound rules with the source set to that one address as a /32, never 0.0.0.0/0:

Both are needed. With TCP alone the first transfer succeeds and later updates are never noticed, so the zone quietly goes stale weeks later.

Then the same on the host firewall:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="216.218.133.2/32" port port="53" protocol="tcp" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="216.218.133.2/32" port port="53" protocol="udp" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Run the reload and then list the result. A rule added without a reload is not in force, and the list is what proves it.

Step 4: tell ISPConfig to allow the transfer

In the control panel go to DNS, open the zone, and select the Options tab.

• Allow zone transfers from: the address from step 1.
• Also notify: the same address. This is what pushes a change out immediately instead of waiting for the next scheduled check.

Save, then increase the zone’s serial so there is a change for them to collect.

Step 5: point the zone’s NS records at Hurricane Electric

ISPConfig creates NS records naming your own server. Under the zone’s Records tab, replace them so the zone names the nameservers that will actually answer for it:

The delegation at the registrar and the NS records inside the zone must agree. If they disagree, some resolvers follow one and some the other, and the fault is intermittent and very hard to read.

Step 6: add the zone at Hurricane Electric

At dns.he.net, add the domain as a secondary zone, giving your instance’s public address as the master. They will attempt a transfer straight away.

Step 7: prove it worked, both ways

First, that the transfer happened. On the instance:

sudo journalctl -u named --since "10 minutes ago" | grep -i transfer

You are looking for a line naming your zone and their address, with AXFR started and then AXFR ended. In the Hurricane Electric panel the zone stops showing as pending.

Then ask their nameserver directly, from any machine:

dig @ns1.he.net yourdomain.com SOA +short

Now the control that matters more. From your own machine, not the server, confirm that nobody else can download your zone:

dig @<your-instance-public-ip> yourdomain.com AXFR

This must fail, with “Transfer failed” or a refusal. If it returns your records, your transfer restriction is wrong and anyone on the internet can download every hostname, mail server and internal name in the zone. Fix it before going any further.

Step 8: delegate at the registrar

Last, because it is the step that makes it live: set the domain’s nameservers at your registrar to ns1.he.net through ns5.he.net. Allow for propagation, which is governed by the old delegation’s TTL rather than by anything on your server.

Optional: a second provider for redundancy

Hurricane Electric alone already gives you five anycast nameservers on separate networks, which is more resilient than most self-run pairs. If you want independence from a single provider as well, any secondary DNS service that accepts AXFR can be added the same way: BuddyNS is a reasonable choice with a free tier. Add its transfer address alongside the first in both the security group and the zone’s Options tab, and add its nameservers to the NS records and to the registrar.

Note that Hetzner DNS and deSEC do not accept AXFR from an external zone, so neither can be used this way.

Route 2: Amazon Route 53

This is a different design, not a variation of Route 1. The zone lives at AWS, Route 53 answers every query, and BIND on your instance serves nothing at all. ISPConfig’s DNS module stops being the place your records live.

It is the simplest route to operate and the one most AWS users already understand. It charges a monthly fee per hosted zone, so for an operator carrying many customer domains it is a real recurring line item. Check current pricing before committing to it at scale.

1. In the AWS console, create a hosted zone for the domain.
2. If the domain already exists in ISPConfig, you do not have to retype the records. ISPConfig writes a standard BIND zone file, and Route 53 can import a zone file directly. The files are under /var/named/.
3. Take the four nameservers Route 53 assigns to that zone. They are specific to the zone, so do not copy them from another one.
4. Set those as the domain’s nameservers at your registrar.

From this point ISPConfig’s DNS manager is not the source of truth for that domain. Editing a record in the panel will appear to work and will change nothing that the world can see. If you take this route, decide it per domain and write down which domains are which, because the two are indistinguishable from inside the control panel.

Nothing needs to change on the instance for this route. Leave port 53 closed and leave listen-on alone.

Things that must stay true whichever route you take

• Never set the transfer restriction to allow everyone. An open zone transfer hands anyone a complete list of every host, mail server and internal name you have. It is the DNS equivalent of leaving a directory listing on.
• Never turn recursion back on while the server is reachable from the internet. It is the single change that converts a working nameserver into an open resolver, and it will be abused within days.
• Never open port 53 to 0.0.0.0/0 on this image. Neither route requires it. If you have opened it, close it.
• Use an Elastic IP. On Route 1 the secondary reaches your instance by address. If that address changes because the instance was stopped and started, transfers stop and the zone expires quietly some days later.

Next step

If you have not yet put your own domain and a trusted certificate on the control panel, see Associating Your Domain. For the ports this image uses and the ones it deliberately leaves closed, see Requirement.