Running your own authoritative DNS — when to bother, BIND on a VPS

Most people put their zones at Cloudflare / Route 53 / their registrar and never think about it. Running your own authoritative nameserver on a VPS is a real option with real tradeoffs — useful when you want full control of TTLs, response logging, dynamic DNS updates from your own automation, or just want to learn how DNS actually works. This article covers when it's worth doing and how to set it up.

When to consider running your own

• You're already comfortable with Linux operations; DNS is one more service to maintain rather than a new skill to learn.
• You want very specific TTL behavior (low TTLs for fast failover, custom min/max) that hosted DNS providers may charge for or rate-limit.
• You want detailed query logging — what's resolving your zones, how often, from where.
• You want programmatic zone updates via API or direct file/database changes without dealing with a third party's API.
• You're hosting infrastructure for clients and want to delegate sub-zones cleanly under your nameservers.

When NOT to bother

• You just want to set up a website with an A record. Use the registrar's free DNS or Cloudflare.
• You can't tolerate any DNS downtime. Hosted DNS providers have anycast networks across dozens of POPs; your single VPS has whatever availability it has (≥ 99.9% per LYLIX's SLA, but that's still ~8 hours/year). DNS being down means EVERYTHING that depends on it is down.
• You're not going to monitor it. Silent DNS failures (zone won't load, daemon crashed, disk full) cascade fast — better to use a provider that monitors itself.

The resilience problem

DNS requires at least 2 nameservers on different networks. One LYLIX VPS gives you one. Options for the second:

• Another LYLIX VPS in the same region — improved resilience for in-VPS-failure cases, not for datacenter-wide events. Adequate for hobby use.
• A second VPS at a different host — covers datacenter-wide failures. Pair with a tool that syncs the zone files (rsync over SSH, or BIND's native master/slave replication).
• Pair your VPS with a hosted secondary DNS — services like buddyns.com, Hurricane Electric's free dns.he.net, or NS1's secondary DNS offering. Your VPS is the master; their network serves as additional authoritative slaves. Best resilience for hobby cost.

See the separate brief in this category on running auth DNS from a single host for the practical implications if you do go single-server.

BIND on a VPS — minimal setup

# Debian/Ubuntu
apt install bind9 bind9-utils dnsutils

# AlmaLinux
dnf install bind bind-utils

systemctl enable named

Edit /etc/bind/named.conf.options (Debian) or /etc/named.conf (Alma) for the basics:

options {
    directory "/var/cache/bind";
    listen-on { any; };
    listen-on-v6 { any; };
    allow-query { any; };           // public auth server — anyone may query our zones
    recursion no;                   // CRITICAL: no recursion (don't be an open resolver)
    allow-recursion { none; };
    minimal-responses yes;
    version "DNS";                  // hide BIND version
};

Define a zone in /etc/bind/named.conf.local:

zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { 192.0.2.10; };  // your secondary's IP
    notify yes;
};

And the zone file at /etc/bind/zones/example.com.zone:

$TTL 3600

example.com.    IN SOA ns1.example.com. hostmaster.example.com. (
                        2026062201 ; serial — bump on every change!
                        10800
                        3600
                        604800
                        3600
                        )

example.com.    IN NS  ns1.example.com.
example.com.    IN NS  ns2.example.com.
example.com.    IN A   192.0.2.10

ns1.example.com.  IN A 192.0.2.10
ns2.example.com.  IN A 192.0.2.11

www             IN CNAME example.com.
mail            IN A     192.0.2.10
example.com.    IN MX 10 mail.example.com.

Validate and load:

named-checkconf
named-checkzone example.com /etc/bind/zones/example.com.zone

systemctl restart named
systemctl status named

Register the nameservers at your registrar

Once BIND serves the zone, you need to tell your registrar to delegate to your nameservers:

1. At your registrar, create "child nameservers" (sometimes called "glue records" or "host records"): ns1.example.com → 192.0.2.10, ns2.example.com → 192.0.2.11.
2. Set the domain's nameservers to ns1.example.com and ns2.example.com.

Propagation typically takes 4–48 hours depending on the TLD. Verify with dig +trace example.com — once your nameservers show up in the chain from root → TLD → your zone, you're authoritative.

Monitoring

At minimum, set up external monitoring (a service in a different network) that queries your nameservers every 5 minutes and alerts on:

• NXDOMAIN or SERVFAIL for a known-good record.
• Latency over a threshold (slow nameserver = slow web for everyone).
• Mismatched serial between your masters and secondaries.

Free options: Healthchecks.io with a custom check, UptimeRobot's free DNS monitoring, or a small script on a different VPS that runs dig periodically and pings a healthcheck on success.

When you'd migrate AWAY from running your own

Common reasons people start with self-hosted and move back to a provider:

• Anycast latency wins matter for global traffic (a single-VPS auth NS has whatever latency the VPS has from each client's POP).
• DDoS resilience — public auth nameservers are common targets; you don't want to deal with that.
• Operational fatigue — the moment you realize the zone file got rolled back during a server restore and didn't propagate for 4 days, you start considering whether the savings are worth it.