How to Create a Name Server on Your Own VPS with BIND9

To run your own authoritative name server, install BIND9 on a VPS with a stable public IP, open UDP and TCP port 53, create an authoritative zone, publish matching NS and A/AAAA records, register glue at your registrar, and replace the domain’s delegation. Use a second server on a different network when availability matters, and treat DNSSEC as a separate key-management project.

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

What you are building

An authoritative name server stores the definitive DNS records for a domain and returns them when recursive resolvers ask for that domain. It is different from a recursive resolver, which looks up answers on behalf of clients and caches results. For a self-hosted setup on Ubuntu or Debian, BIND9 is the standard open-source authoritative server; the dnsutils package supplies the dig tools used to test it.

#	Preview	Product	Price
1		DNS and BIND (5th Edition)	$38.88	Buy on Amazon
2		DNS & BIND Cookbook	$17.30	Buy on Amazon
3		DNS and BIND	$17.96	Buy on Amazon
4		DNS and BIND on IPv6: DNS for the Next-Generation Internet	$25.79	Buy on Amazon
5		DNS and BIND, Fourth Edition	$37.46	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

The four pieces that must agree

• The BIND configuration: declares the zone and where its data is stored.
• The zone file: contains the SOA, NS, address and other records served authoritatively.
• The parent delegation: at the registrar or parent-zone operator, lists your name-server hostnames.
• Glue records: supply the IP addresses of in-domain name servers so the parent can reach them without a circular lookup.

A delegation is healthy only when these layers are consistent. A correct zone file cannot compensate for a registrar still pointing at the old servers, a blocked port 53, or glue that points to the wrong address.

Choose the architecture first

Prerequisites and checks before installation

• A VPS with a stable, publicly routable IPv4 address. If you will publish an AAAA record, verify that the IPv6 address is assigned to the VPS and routed end to end.
• Administrative access, normally through SSH, and a supported Ubuntu or Debian release.
• Permission to create or edit DNS host records and name-server objects at your registrar.
• Provider security rules and a local firewall that can allow both UDP and TCP port 53. DNS normally uses UDP, but TCP is required for larger responses and several protocol operations.
• A zone name, an SOA mailbox such as hostmaster.example.com., and a plan for at least one additional server if the domain must survive a VPS or network outage.
• Documentation-address ranges in examples must be replaced with the real public addresses assigned to your VPSes.

Step 1: Prepare the VPS and open DNS traffic

Assign stable addresses

Record the public address of each VPS before writing the zone. Do not publish a temporary address, a private RFC 1918 address, a provider-only address or an address that is not routed to the machine. If you use two servers, place them with different providers, networks or regions where practical; two instances in one failed network do not provide meaningful independence.

#1 Best Overall

Sale

DNS and BIND (5th Edition)

$38.88

Buy on Amazon

Open UDP and TCP port 53

Allow DNS in both layers of filtering: the VPS provider’s security group or network firewall and the operating system firewall. With UFW, the essential rules are:

sudo ufw allow 53/udp
sudo ufw allow 53/tcp
sudo ufw status

Use the equivalent rules for nftables, firewalld or another firewall. Do not expose BIND’s recursive service to the public Internet merely to make an authoritative server work; an authoritative-only configuration should not provide open recursion.

Step 2: Install BIND9 and the testing tools

On Ubuntu or Debian, install the server and DNS utilities, then enable the service:

sudo apt update
sudo apt install bind9 dnsutils
sudo systemctl enable --now bind9
sudo systemctl status bind9

The package names and service unit are the conventional Ubuntu/Debian layout. Keep the distribution’s configuration structure unless you have a specific reason to redesign it. The next steps use /etc/bind/named.conf.local and a zone file under /etc/bind/.

Step 3: Declare the authoritative zone

Add a zone declaration

Edit /etc/bind/named.conf.local and add a declaration for the domain. The following example makes this VPS the primary (the current BIND terminology; older documentation may say “master”):

zone "example.com" {
    type primary;
    file "/etc/bind/db.example.com";
};

The file path can be different, but it must match the path you create and the BIND process must be able to read it.

Create the zone file

Create /etc/bind/db.example.com with an SOA record, an NS set and address records for every name-server hostname:

$TTL 3600
@   IN SOA ns1.example.com. hostmaster.example.com. (
        2026101501 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        3600 )     ; negative cache
    IN NS ns1.example.com.
    IN NS ns2.example.com.
ns1 IN A 203.0.113.10
ns2 IN A 198.51.100.20
@   IN A 203.0.113.10

The addresses 203.0.113.10 and 198.51.100.20 are documentation examples, not usable Internet addresses. Replace them with the actual public addresses of your first and second servers. Add AAAA records only for IPv6 addresses that are assigned and reachable:

Rank #2

Sale

DNS & BIND Cookbook

$17.30

Buy on Amazon

ns1 IN AAAA 2001:db8:1::10
ns2 IN AAAA 2001:db8:2::20

The trailing dots on the fully qualified names in the SOA and NS records are significant. Without a trailing dot, BIND can interpret a name as relative to the zone and produce an unintended hostname. An NS target must resolve to A and/or AAAA records; do not use a CNAME as an NS target.

Set authoritative-only behavior carefully

Review /etc/bind/named.conf.options and retain the distribution’s required includes. For an authoritative-only service, disable recursion rather than operating an open resolver. A minimal options block is conceptually:

options {
    directory "/var/cache/bind";
    recursion no;
    allow-query { any; };
    listen-on { any; };
    listen-on-v6 { any; };
};

Apply this only after checking the existing file and your distribution’s syntax. If IPv6 is not configured, do not enable a listener or publish AAAA records just because the directive is available. The goal is for BIND to answer authoritatively for your zone while refusing recursive service to arbitrary clients.

Step 4: Validate, load and maintain the zone

Check syntax before restarting

Run the configuration and zone validators before changing the running service:

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/db.example.com

A successful zone check reports the zone and its serial. If either command reports an error, fix it before reloading. Check ownership and permissions if BIND cannot read the file; the service must have read access to the zone file and traverse access to its parent directories.

Increase the SOA serial on every change

Secondaries and caches use the SOA serial to determine whether the zone has changed. Increase it whenever any record changes, even if the edit seems minor. A date-based format such as YYYYMMDDnn is a common convention; 2026101501 means the first revision on October 15, 2026 in this illustration. The only protocol requirement is that the new value be greater than the previous value.

After validation, reload rather than restarting when possible:

sudo systemctl reload bind9
sudo systemctl status bind9
sudo journalctl -u bind9 --since "10 minutes ago"

If a reload fails, the journal normally identifies the file and line that caused the problem. Do not keep increasing the serial while the zone is invalid; correct the syntax, validate again and then reload.

Rank #3

DNS and BIND

$17.96

Buy on Amazon

Step 5: Publish the name-server hostnames

Use names such as ns1.example.com and ns2.example.com. In the zone file, their A and optional AAAA records must point to the servers that actually run BIND. The NS records at the zone apex must list exactly those hostnames:

@ IN NS ns1.example.com.
@ IN NS ns2.example.com.

For a single-VPS experiment, both names can technically resolve to one machine, but that does not create redundancy. A second hostname on the same address only changes the label, not the failure mode. For production, use a genuinely separate server and keep the two zones synchronized.

Step 6: Create glue and change the parent delegation

Why glue is necessary

If your name-server hostname is inside the domain it serves, such as ns1.example.com for example.com, a resolver cannot discover the address by asking the child zone before it reaches the child zone. The parent therefore publishes glue A and AAAA data for the in-domain host. The glue addresses must match the authoritative A and AAAA records for that host.

Register host objects at the registrar

Registrars use different labels, but the operation is usually called “register nameserver,” “child nameserver,” “host object” or “glue record.” Create a host object for each in-domain server:

1. Enter ns1.example.com and its real public IPv4 address; add its IPv6 address only if it is valid and routed.
2. Repeat for ns2.example.com and the second server’s addresses.
3. Save the host objects and confirm that the registrar shows the expected values.

Do not confuse this with an ordinary A record editor. The glue must be published in the parent zone by the registrar or registry.

Replace the domain’s delegation

In the domain’s nameserver or delegation settings, replace the old NS set with ns1.example.com and ns2.example.com. The parent NS set and the NS set returned by your authoritative zone should agree. Keep the old servers only during a deliberate migration window; leaving an unintended mixture can produce different answers depending on which parent record a resolver receives.

Parent changes are cached according to TTL values. A successful registrar update does not make every recursive resolver switch immediately; continue testing the parent and your servers directly while caches age out.

Step 7: Verify the complete chain from outside

Query each server directly

Run these commands from a machine outside the VPS network, not only from localhost:

Rank #4

Sale

DNS and BIND on IPv6: DNS for the Next-Generation Internet

• Used Book in Good Condition

$25.79

Buy on Amazon

dig @203.0.113.10 example.com SOA +norecurse
dig @203.0.113.10 example.com NS +norecurse
dig @198.51.100.20 example.com SOA +norecurse
dig @198.51.100.20 example.com NS +norecurse

Replace the example addresses with your real server IPs. Each server should return an authoritative answer for the zone, the same NS set and the same SOA serial. The answer’s authority section and flags should be consistent with an authoritative response; an answer obtained only from a local cache does not prove that the public server works.

Check the name-server hostnames

dig @203.0.113.10 ns1.example.com A +norecurse
dig @203.0.113.10 ns2.example.com A +norecurse
dig @203.0.113.10 ns1.example.com AAAA +norecurse

Repeat for any AAAA records and verify that every returned address is intentional. An unreachable AAAA record can cause intermittent failures for clients that prefer IPv6.

Trace from the root to your VPS

dig +trace example.com

The trace should move from the root and the TLD servers to the parent delegation, then to your listed name servers and finally to the zone answer. If the trace stops at the parent, investigate delegation or glue. If it reaches your IP but receives no answer, investigate the firewall, BIND listener and zone configuration.

Test through a recursive resolver

dig @1.1.1.1 example.com SOA
dig @8.8.8.8 example.com NS

These queries test what a public recursive resolver currently sees, so cached old data can remain for the duration of the previous TTL. Direct queries and +trace distinguish a cache delay from an authoritative failure.

Build a real second server with primary/secondary DNS

A secondary should serve a copy of the zone rather than pointing both names to one VPS. BIND calls the editable server “primary” and the replicated server “secondary”; older guides may use “master” and “slave.”

Permit transfer only to the secondary

On the primary, add transfer controls inside the zone declaration. Replace the example address with the secondary’s real address:

zone "example.com" {
    type primary;
    file "/etc/bind/db.example.com";
    allow-transfer { 198.51.100.20; };
    also-notify { 198.51.100.20; };
};

Restrict transfers to the intended secondary rather than allowing arbitrary hosts to copy the zone. For sensitive zones, use transaction signatures (TSIG) and corresponding transfer policy instead of relying only on an IP address.

Configure the secondary

On the second VPS, install BIND9 and create a secondary declaration. The cache directory is commonly writable by the BIND service:

Best Value

Sale

DNS and BIND, Fourth Edition

• Used Book in Good Condition

$37.46

Buy on Amazon

zone "example.com" {
    type secondary;
    primaries { 203.0.113.10; };
    file "/var/cache/bind/db.example.com";
};

Allow TCP port 53 between the servers as well as UDP. Validate the secondary configuration, reload BIND and query it directly. A successful transfer creates the secondary copy and gives it the primary’s SOA serial.

Keep both servers demonstrably current

After every primary edit, increase the serial, validate and reload. Query both addresses and compare:

dig @PRIMARY_IP example.com SOA +norecurse
dig @SECONDARY_IP example.com SOA +norecurse
dig @PRIMARY_IP example.com NS +norecurse
dig @SECONDARY_IP example.com NS +norecurse

If the serials differ, inspect transfer permissions, TCP filtering, the primary address in the secondary declaration and BIND’s journal. Do not change the secondary zone file manually; fix the transfer path so the copy can be regenerated from the primary.

Add DNSSEC only as a planned second project

DNSSEC does not replace authoritative DNS; it adds signatures that allow validating resolvers to authenticate records. A signed zone introduces DNSKEY and RRSIG records and normally requires a DS record in the parent. Ubuntu documents DNSSEC as a layer added to an existing authoritative BIND9 zone.

Before enabling it, prepare all of the following:

• A secure backup of the signing keys, separate from the VPS.
• A documented rollover schedule and an operator who can perform it.
• A registrar or parent operator that accepts DS records.
• Accurate system time on every signing server.
• A rollback plan for an expired signature, removed key or incorrect DS.

Publish the DS only after the signed zone is serving the matching DNSKEY and RRSIG data. A DS record that does not match the active key makes validating resolvers return a failure even when ordinary unsigned queries appear correct. During an incident, check DNSKEY and RRSIG coverage, key state, system time and the parent DS before changing unrelated records.

Troubleshoot by locating the broken layer

Operate the service after launch

Make changes predictably

Keep the zone file under version control or another auditable backup method. For each change, edit the file, increase the serial, run both validation commands, reload BIND and query both authoritative servers. Record the reason for the change and the expected TTL behavior so a later incident is not confused with a cache delay.

Monitor from outside the host

Local service status cannot tell you whether the Internet can reach the VPS. Monitor UDP and TCP DNS queries from an external location, check that both name servers return the expected SOA serial, and alert when one server stops answering or falls behind. Review BIND logs for failed transfers, malformed requests and repeated service restarts.

Patch and protect the VPS

Apply operating-system and BIND security updates, restrict SSH access, use key-based administration and keep backups of configuration and zone data. Disable recursion unless you intentionally operate a controlled recursive service. Limit zone transfers to approved secondaries and use authenticated transfers for zones whose contents require stronger protection.

Plan failure recovery

Keep the zone files, registrar account recovery details, glue values and DNSSEC keys (if used) in a separate, protected backup. Test restoring BIND on a fresh VPS before an outage. A second authoritative server reduces dependence on one host, but it does not remove the need to renew the domain, maintain glue and keep both servers patched.

Quick Recap

SaleBestseller No. 1

DNS and BIND (5th Edition)

$38.88

SaleBestseller No. 2

DNS & BIND Cookbook

$17.30

Bestseller No. 3

DNS and BIND

$17.96

SaleBestseller No. 4

DNS and BIND on IPv6: DNS for the Next-Generation Internet

Used Book in Good Condition

$25.79

SaleBestseller No. 5

DNS and BIND, Fourth Edition

Used Book in Good Condition

$37.46

A practical launch checklist

1. Confirm stable public IPv4 addresses and any genuinely routed IPv6 addresses.
2. Open UDP and TCP port 53 at the provider and on the VPS.
3. Install bind9 and dnsutils.
4. Declare the zone in named.conf.local.
5. Create an SOA, monotonically increasing serial, NS set and address records.
6. Run named-checkconf and named-checkzone.
7. Reload BIND and inspect the service journal.
8. Create registrar host objects and glue for each in-domain name server.
9. Replace the parent delegation with the new NS set.
10. Use direct dig queries, dig +trace and recursive-resolver queries from outside the VPS.
11. For production, add a secondary on a different network and verify matching serials.
12. Only then design DNSSEC keys, DS submission and rollover procedures if authenticated DNS is required.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.