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

You can run an authoritative name server on a VPS by installing BIND9, defining your domain’s zone, publishing address records for ns1 and ns2, registering those hostnames and glue at your registrar, and changing the domain’s delegation. The VPS must have stable public addressing and accept DNS traffic on both UDP and TCP port 53. For production availability, use a second authoritative server on a different network.

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 actually building

A name server is a DNS service. An authoritative name server stores the definitive records for a domain and answers with data from that domain’s zone. It is different from a recursive resolver, which looks up answers on behalf of users and caches them.

#	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.

When a visitor requests www.example.com, the DNS hierarchy eventually reaches the parent zone for example.com. The parent publishes which name servers are authoritative for the domain. Those servers then return the zone’s SOA, NS, A, AAAA, MX, TXT and other records. Your VPS will be authoritative for the zone; it does not need to provide recursive service to the public.

The complete chain has to agree:

• The zone file on BIND9 must contain the intended NS records and address records.
• The parent delegation at the registrar must list the same authoritative nameserver hostnames.
• If a nameserver hostname is inside the domain it serves, the parent must also publish glue A and AAAA records for it.
• The addresses in glue must match the authoritative address records for those hostnames.

A mismatch at any layer can produce intermittent failures or SERVFAIL, even when the zone file itself looks correct.

#1 Best Overall

Sale

DNS and BIND (5th Edition)

$38.88

Buy on Amazon

Choose the architecture before installing anything

One VPS or two authoritative servers

BIND documentation recommends two or more authoritative servers on different networks for fault tolerance. A second VPS in the same facility or provider may still fail with the first during a shared outage, so geographic or network separation is more useful than merely using a second IP on one host.

Primary and secondary roles

The primary server holds the editable zone data. A secondary server obtains a replicated copy and serves it authoritatively. BIND documentation previously used the terms “master” and “slave”; current terminology is primary and secondary, although older configuration examples may still use type master and type slave.

You can begin with one primary while learning, then add a secondary before moving a critical domain. The parent delegation should list both servers once the secondary is answering correctly.

IPv4-only or dual stack

Every nameserver needs at least one reachable address. IPv4 is broadly available. Add an AAAA record only when the VPS has a real, routed IPv6 address and your firewall and provider rules allow IPv6 DNS traffic. Never publish an address that the server does not actually serve; an unreachable AAAA record can cause clients with IPv6 connectivity to wait or fail before trying IPv4.

Self-hosted or managed DNS

Self-hosting gives you control of the DNS software and zone data, and it is useful for learning BIND9 and operating systems. Managed DNS generally provides distributed infrastructure and reduces patching, monitoring and outage work. Choose self-hosting when control or education is the goal and you can maintain it; choose distributed managed infrastructure when availability matters more than running the service yourself.

Unsigned DNS or DNSSEC

Unsigned DNS is the straightforward starting point. DNSSEC adds authenticity records and a chain of trust, but it also adds key storage, rollover and parent-zone coordination. Treat DNSSEC as a separate project after ordinary authoritative service works.

Prerequisites and an addressing plan

Before changing delegation, collect the following:

• A domain whose registrar lets you set nameservers and create registered host (child nameserver) records.
• A VPS running a supported Ubuntu or Debian release, with a static public IP address.
• Administrative access through SSH or the provider console.
• Permission in the VPS firewall and the provider’s security rules to receive DNS on UDP port 53 and TCP port 53.
• A second VPS on another network if the domain must survive a single-host or network outage.

Use real addresses assigned to your servers. The following values are documentation addresses used only to illustrate the relationships:

Do not copy the documentation addresses into production. Decide the final hostnames and addresses first, because the zone file, glue records and registrar delegation must remain synchronized.

Rank #2

Sale

DNS & BIND Cookbook

$17.30

Buy on Amazon

Install BIND9 and DNS troubleshooting tools

On Ubuntu or Debian, install BIND9 and the dnsutils package:

sudo apt update
sudo apt install bind9 dnsutils

bind9 provides the authoritative server. dnsutils supplies tools such as dig for direct queries and delegation checks.

Permit both DNS transports in the local firewall. With UFW, the commands are:

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

Apply equivalent inbound rules in your VPS provider’s security group or network firewall. DNS commonly uses UDP, but TCP is required for responses that do not fit in a UDP packet and for some protocol operations. Blocking TCP can make a seemingly healthy server fail for particular queries.

Check that BIND is running and listening after installation:

sudo systemctl enable --now bind9
sudo systemctl status bind9
sudo ss -lntu | grep ':53'

The listener should be reachable on the public interface, not only on loopback. Distribution defaults can vary, so inspect BIND’s options if it is listening only on 127.0.0.1 or ::1.

Define an authoritative zone

1. Add the zone declaration

Tell BIND where the zone file is stored by editing /etc/bind/named.conf.local:

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

type master is accepted in many existing BIND configurations and is the older spelling for a primary zone. On releases that document the newer terminology, type primary expresses the same role. Keep the spelling consistent with the examples and version documentation for your installed BIND package.

Rank #3

DNS and BIND

$17.96

Buy on Amazon

2. Create the zone file

Create /etc/bind/db.example.com with an SOA record, two NS records and address records:

$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

Replace the domain and addresses with your own values. The trailing dots on fully qualified names are significant: ns1.example.com. is an absolute DNS name, while a name without a trailing dot can be interpreted relative to the zone.

• SOA: identifies the primary server, a responsible mailbox written with a dot instead of @, and timing values used by secondaries and caches.
• NS: publishes the authoritative nameserver set for the zone.
• Address records: make the nameserver hostnames resolvable. An NS target must resolve to A and/or AAAA records; do not use a CNAME as an NS target.
• Zone apex A: the @ record in the example makes example.com resolve to the primary address. Add records for applications such as www, mail or verification services as needed.

If IPv6 is genuinely available, add an AAAA record for the relevant host, for example ns1 IN AAAA 2001:db8::10, and publish matching glue. Omit it when the address is not routed and filtered correctly.

3. Increase the SOA serial for every change

Secondaries and caches use the SOA serial to determine whether the zone changed. Increase it whenever you edit any record, then reload BIND. A date-based format such as YYYYMMDDnn is a common convention; the only requirement is that each new value is greater than the previous one. The example serial 2026101501 means the first revision recorded on 15 October 2026 in that convention.

Validate the configuration before exposing it

Run syntax and zone checks before restarting:

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

named-checkconf checks BIND configuration syntax. named-checkzone checks the zone name and file contents, including common SOA and record-format errors. Fix every reported error rather than restarting with a partially parsed configuration.

Reload after a record-only change, or restart after a broader configuration change:

sudo systemctl reload bind9
# If a reload is not sufficient:
sudo systemctl restart bind9
sudo journalctl -u bind9 --no-pager -n 100

Keep the zone file readable by the BIND service account and follow the permissions used by the distribution’s existing files. A syntax-correct file that BIND cannot read will still fail at load time.

Register hostnames and glue at the registrar

Why glue is necessary

If your nameservers are ns1.example.com and ns2.example.com, they are inside the same domain they serve. A resolver cannot obtain the address of ns1.example.com from example.com until it knows how to reach a server for example.com; that circular dependency is broken by glue in the parent zone.

Rank #4

Sale

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

• Used Book in Good Condition

$25.79

Buy on Amazon

IANA’s technical requirements state that when a nameserver has an IP address listed as glue, the glue address must match the authoritative A and AAAA records for that host. Keep the registrar’s host records and your zone file identical.

Register each child nameserver

Registrar interfaces use labels such as Register nameserver, Child nameservers, Host records or Nameserver registration. For each host:

1. Create ns1.example.com with the primary VPS’s public A address.
2. Create ns2.example.com with the secondary VPS’s public A address.
3. Add AAAA addresses only when those IPv6 addresses are real and reachable.
4. Save the host records and wait for the registrar to publish them to the parent zone.

Do not create a normal subdomain A record and assume it is glue. The registrar’s child-nameserver function publishes the address information at the parent level.

Delegate the domain to your new servers

In the domain’s nameserver settings, replace the old NS set with:

ns1.example.com
ns2.example.com

Use the registrar’s exact nameserver fields; do not paste IP addresses into fields that request hostnames. The parent delegation and the NS set served by your zone should agree. If the parent lists one set while the child zone returns another, resolvers can receive inconsistent answers.

Delegation changes are cached according to the parent’s TTL. A resolver may continue to show the old servers until that cache expires, even after the registrar reports the change as complete. Test from more than one network and do not remove the old service until the new delegation is answering reliably.

Verify the complete DNS chain from outside the VPS

Run these checks from a machine that is not the VPS, or from an external monitoring location.

Query the primary directly

dig @203.0.113.10 example.com SOA +noall +answer
dig @203.0.113.10 example.com NS +noall +answer
dig @203.0.113.10 ns1.example.com A +short
dig @203.0.113.10 ns2.example.com A +short

The SOA query should return the serial you published. The NS query should return both nameservers, and the address queries should return the intended VPS addresses.

Best Value

Sale

DNS and BIND, Fourth Edition

• Used Book in Good Condition

$37.46

Buy on Amazon

Query each nameserver independently

dig @203.0.113.10 example.com SOA +noall +answer
dig @198.51.100.20 example.com SOA +noall +answer

When both servers are configured, compare their SOA serials and NS records. A secondary with an older serial has not transferred the latest zone; a timeout usually points to an address, routing, firewall or service problem.

Follow the delegation

dig NS example.com +noall +answer
dig +trace example.com

dig NS example.com shows what a normal recursive resolver currently sees. dig +trace walks from the root through the parent to the authoritative servers and is useful for finding a broken delegation or missing glue. Test the public name as well as direct queries, because a direct query can succeed even when the parent still points elsewhere.

Add a secondary server for resilience

Install BIND9 and dnsutils on the second VPS, open UDP and TCP 53 there, and give it a distinct public address. Configure the zone as a secondary that obtains data from the primary. A representative declaration is:

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

Use the primary’s actual address and a writable cache path appropriate to your distribution. On the primary, authorize zone transfer to the secondary rather than allowing unrestricted transfers. If you use transfer authentication, keep the shared key outside publicly readable files and document its rotation procedure.

After the initial transfer, change a harmless record on the primary, increment the SOA serial, reload BIND, and confirm that the secondary obtains the new serial. Only then publish the secondary in the parent delegation. Both servers must return the same NS set; their SOA serials should converge after a transfer.

Enable DNSSEC only with a key and rollover plan

DNSSEC signs a zone with DNSKEY material and publishes RRSIG records. The parent normally receives a DS record that identifies the active signing key. This creates authenticity protection for validating resolvers, but it also creates failure modes if keys are lost, signatures expire or the parent DS no longer matches.

Before enabling it:

• Back up the signing keys securely and test that they can be restored.
• Decide how you will generate signatures and perform key rollovers.
• Confirm that the registrar accepts DS submissions for your top-level domain.
• Plan a change window and a way to remove or replace a DS record if signing must be disabled.

Ubuntu documents DNSSEC as a layer added to an existing authoritative BIND9 zone. Finish the unsigned setup and delegation first. After signing, verify DNSKEY and RRSIG responses and confirm that the DS published by the parent corresponds to the active key.

Troubleshoot common failures

Operate the service safely after cutover

• Keep BIND9 and the operating system patched through the normal package update process.
• Restrict recursive service; an authoritative public server should not become an open resolver. Review the distribution’s options and allow recursion only for networks that genuinely need it.
• Back up the zone files, configuration and, if enabled, DNSSEC keys. A backup is useful only if restoration has been tested.
• Monitor both authoritative IPs from outside the VPS. Alert on timeouts, mismatched SOA serials and unexpected NS changes.
• Record every zone edit and increment the serial before reloading. A consistent serial convention makes secondary synchronization easy to diagnose.
• Keep registrar host records, parent NS delegation and child-zone NS records synchronized whenever an address or hostname changes.

Final cutover checklist

1. The VPS has a stable public address and the operating system is supported.
2. BIND9 and dnsutils are installed, enabled and listening.
3. UDP and TCP port 53 are allowed by both local and provider firewalls.
4. named-checkconf and named-checkzone complete without errors.
5. The zone contains an SOA, matching NS records and address records for every nameserver hostname.
6. The SOA serial is increased for every edit.
7. Child nameservers and matching glue are registered at the registrar.
8. The parent delegation lists the intended NS hostnames.
9. Direct dig queries return the expected data from every server.
10. dig +trace reaches your VPS, and public recursive queries show the new delegation after caching settles.
11. A second server is configured and tested if the domain requires availability through a single VPS or network failure.
12. DNSSEC is enabled only after key backup, rollover planning and DS support are confirmed.

Once these checks pass, your VPS is functioning as an authoritative nameserver rather than merely hosting a DNS process. The reliability of the result depends on keeping the delegation, glue, zone data, network reachability and (when used) DNSSEC keys in agreement.

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

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.