DevOps

DNS 101: Should I Run My Own Nameserver?

Should you run your own nameserver? Probably not. For most people moving to a dedicated or cloud server, a managed DNS provider (or your registrar’s DNS) is more reliable and less work than running your own authoritative nameservers. Running your own makes sense in a few specific cases, and we’ll cover those below.

DNS setup is also a frequent source of confusion for customers moving onto their own servers. On shared hosting, the host handled it. On a dedicated server, unless you arrange otherwise, it’s now your job.

DNS vs. nameserver: what’s the difference?

DNS, the Domain Name System, is the internet’s directory: it turns names like example.com into IP addresses. A nameserver is a server that answers DNS questions. The ones that matter here are authoritative nameservers, which hold the official records for your domain. (A recursive resolver, the kind your ISP runs or 1.1.1.1, looks answers up on a visitor’s behalf. That’s a different job.)

If you have a domain that works, you’re already using authoritative nameservers. Your registrar, your host, a DNS company or you are running them. The question is which of those should be.

Your options

Managed DNS provider

Companies like Cloudflare, Amazon Route 53 and DNS Made Easy run authoritative DNS as a core business. You get nameservers in many locations, usually on an anycast network, plus an API and DNSSEC signing that’s often a single setting. Cloudflare’s DNS comes with its free plan, and the paid services cost little for a typical site. This is our default recommendation.

Your registrar’s DNS

Most registrars include basic DNS with the domain, managed from the same panel where you renew it. It’s fine for a simple site with a handful of records. The downside is that it’s often an afterthought: fewer record types, a weaker API, and support that knows domains better than DNS.

Your hosting provider’s nameservers

Shared hosts usually require their own nameservers. Once you move to a dedicated or cloud server, you’ll typically pick one of the other options.

Running your own

This is common on cPanel servers, because cPanel creates and updates DNS zones automatically when you add an account. cPanel defaults to PowerDNS; BIND is the other choice, and it isn’t available on Ubuntu servers. That convenience is real, but the hard part isn’t the software. It’s keeping two or more nameservers online, on separate networks, all the time.

If you do run your own, the mainstream authoritative servers are:

  • BIND 9: the classic. Use the 9.20 branch, which ISC now maintains; upstream support for 9.18 ended in June 2026. Debian 12 and Ubuntu 24.04 still ship 9.18 with their own security patches, so the distro package is fine while that release is supported.
  • PowerDNS Authoritative: can serve records from a SQL database, and has a good API. It’s what cPanel uses by default.
  • Knot DNS and NSD: lean, fast, authoritative-only servers from CZ.NIC and NLnet Labs.

Two things that make self-hosting harder than it looks

Secondary DNS isn’t optional

Registrars generally ask for at least two nameservers per domain, and RFC 2182 says they should sit on separate networks in separate places. Two nameservers on the same server, or in the same rack, mean your site disappears the moment that box goes down, even if a backup web server is ready to take over. If you run a primary yourself, at least pay a managed provider to act as secondary and pull your zones by zone transfer.

DNSSEC adds key management

DNSSEC signs your records so resolvers can detect tampering. With a managed provider it’s usually one setting. Self-hosted, you own key rollovers and the DS record at your registrar. Modern BIND, PowerDNS and Knot can automate most of the signing, but if a rollover goes wrong, resolvers that validate DNSSEC return errors instead of your records. For everyone behind those resolvers, your domain is simply gone.

When running your own does make sense

  • You host many domains on cPanel and want zones created automatically. Even then, consider a managed secondary.
  • You need records generated by your own systems faster than a provider’s API allows.
  • You have a policy reason to keep DNS data in-house, and the staff to run it on two or more networks.

If none of those fit, put your domains on a managed DNS provider, point the records at your server, and spend the time you saved on the server itself. Moving to a dedicated server and not sure how to handle DNS? Tell us what you’re running and we’ll talk it through.