How to set up custom private nameservers for your domain?

To set up custom private nameservers such as ns1.example.com and ns2.example.com, you need at least two IP addresses that run (or front) an authoritative DNS server. Register each nameserver hostname with its IP address at your registrar, in the section usually called "child nameservers", "host records" or "register nameserver". Add matching A and AAAA records for those hostnames in your DNS zone, update the zone's NS records, and then change your domain's nameservers to the new names. After the registry publishes the change and caches expire, your domain is served by nameservers that carry your own brand.

Private nameservers, also called vanity, branded or white-label nameservers, are popular with web hosts, agencies and businesses that want clients to see their name instead of a DNS provider's. This guide covers the options for where the DNS actually runs, how to register the hostnames at the registrar, how to set up the zone, a working BIND configuration for running your own pair of servers, the Route 53 white-label process, and how to verify everything.

What Private Nameservers Are

Every domain is delegated to nameservers by hostname. With a managed DNS provider, those are the provider's names:

dig +short example.com NS

ns-512.awsdns-00.net.
ns-1024.awsdns-00.org.

With private nameservers, the delegation uses names under your own domain:

ns1.example.com.
ns2.example.com.

Behind those names, the DNS can still be served by anyone: your own servers, a managed provider that supports white-labelling, or your hosting control panel. The branding only changes the names. What matters for reliability is who runs the servers at those IP addresses.

Because ns1.example.com is inside the domain it serves, resolvers can't look up its address without already reaching it. That's why the registry must publish its IP address alongside the delegation as a glue record. Registering the nameserver at your registrar is how that glue is created.

Choose Where the DNS Runs

Option	How it works	Good for
Your own servers	Run BIND, Knot, NSD or PowerDNS on two or more servers	Full control, hosting companies with infrastructure
Managed provider with white-label support	The provider gives you fixed IPs for its nameservers, and you put your names on them	Branding with managed reliability
Hosting control panel	cPanel/WHM, Plesk and similar run DNS on your hosting servers	Resellers and small hosts

Whichever you choose, follow two rules:

• At least two nameservers on separate networks: Two IPs on the same server isn't redundancy. If that server goes down, your domain and every client domain using it disappear.
• Stable IP addresses: Glue is cached for up to two days for .com and .net. Changing nameserver IPs often is painful.

Amazon Route 53 supports white-label nameservers through reusable delegation sets, and Cloudflare offers custom nameservers on its higher-tier plans. Check your provider's current documentation and plan limits before committing.

Step 1: Get the IP Addresses

For your own servers, these are simply the servers' public addresses. In this guide:

Nameserver	IPv4	IPv6
ns1.example.com	192.0.2.53	2001:db8:1::53
ns2.example.com	198.51.100.53	2001:db8:2::53

For a managed provider, look up the IPs of the nameservers it assigned to you. For example, with Route 53:

aws route53 create-reusable-delegation-set --caller-reference "vanity-$(date +%s)"

The response lists four nameservers in a DelegationSet. Find their addresses:

for ns in ns-512.awsdns-00.net ns-1024.awsdns-00.org ns-0.awsdns-00.com ns-1536.awsdns-00.co.uk; do
  echo "$ns $(dig +short $ns A) $(dig +short $ns AAAA)"
done

Then create your hosted zone using that delegation set, so it's served by those same four nameservers:

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "zone-$(date +%s)" \
  --delegation-set-id N1PA6795SAMPLE

A reusable delegation set keeps the same nameservers, and therefore the same IP addresses, across every hosted zone you create with it. That's what makes it suitable for branding.

Step 2: Register the Nameservers at Your Registrar

This creates the host objects and glue at the registry. Log in to the registrar where example.com is registered and look for a section with a name like:

• Child nameservers
• Register nameserver or Host names
• Personal DNS server
• Glue records

Add each nameserver with its addresses:

Hostname: ns1.example.com    IPv4: 192.0.2.53      IPv6: 2001:db8:1::53
Hostname: ns2.example.com    IPv4: 198.51.100.53   IPv6: 2001:db8:2::53

Not every registrar's form accepts IPv6. If yours doesn't, register IPv4 now and add IPv6 later if the option appears or support enables it.

You can only register host names under a domain you hold at that registrar. To register ns1.example.com, example.com must be in your account there.

Check the Registry Has the Hosts

Ask the TLD's nameservers directly:

dig @a.gtld-servers.net ns1.example.com A +norec +short
dig @a.gtld-servers.net ns2.example.com A +norec +short

For .com and .net you can also use Verisign's public RDAP service, which has a nameserver lookup:

curl -s https://rdap.verisign.com/com/v1/nameserver/ns1.example.com | jq '.ipAddresses'

{
  "v4": ["192.0.2.53"],
  "v6": ["2001:db8:1::53"]
}

Step 3: Set Up the Zone

Your zone needs A/AAAA records for the nameserver names, matching the glue exactly, and NS records listing the new names at the apex. It's also good practice to update the SOA record's primary nameserver field:

$ORIGIN example.com.
$TTL 3600
@       IN  SOA   ns1.example.com. hostmaster.example.com. (
                  2026101501 ; serial
                  7200       ; refresh
                  3600       ; retry
                  1209600    ; expire
                  3600 )     ; negative caching TTL

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

ns1     IN  A     192.0.2.53
ns1     IN  AAAA  2001:db8:1::53
ns2     IN  A     198.51.100.53
ns2     IN  AAAA  2001:db8:2::53

@       IN  A     203.0.113.10
www     IN  CNAME example.com.
@       IN  MX    10 mail.example.com.
mail    IN  A     203.0.113.25

For a Route 53 hosted zone, create A and AAAA records for ns1 to ns4 pointing at the delegation set's IPs, then edit the zone's NS record set to list your four vanity names and update the SOA record to start with ns1.example.com..

Step 4: Run Your Own Nameservers With BIND

If you're hosting the DNS yourself, here's a minimal setup with one primary and one secondary on Debian or Ubuntu. Install BIND on both servers:

sudo apt update
sudo apt install bind9 bind9-utils

Create a TSIG Key for Zone Transfers

A shared key authenticates transfers between the two servers:

tsig-keygen -a hmac-sha256 transfer-key | sudo tee /etc/bind/transfer.key
sudo chown root:bind /etc/bind/transfer.key
sudo chmod 640 /etc/bind/transfer.key

Copy the same file to the secondary.

Primary Configuration

In /etc/bind/named.conf.options on ns1:

options {
    directory "/var/cache/bind";
    listen-on { any; };
    listen-on-v6 { any; };

    // Authoritative only: never act as an open resolver
    recursion no;
    allow-query { any; };
    allow-transfer { none; };
};

In /etc/bind/named.conf.local:

include "/etc/bind/transfer.key";

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

Save the zone file from Step 3 as /etc/bind/zones/db.example.com, then check and start:

sudo mkdir -p /etc/bind/zones
sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zones/db.example.com
sudo systemctl restart named

Secondary Configuration

On ns2, use the same options block, and in named.conf.local:

include "/etc/bind/transfer.key";

server 192.0.2.53 {
    keys { transfer-key; };
};

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

The server block tells BIND to sign requests to the primary with the TSIG key. The primary, secondary and primaries keywords are the current names, which replaced master, slave and masters from BIND 9.16 onwards.

sudo named-checkconf
sudo systemctl restart named

Allow DNS through each server's firewall on both UDP and TCP. With UFW:

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

Check that both servers answer authoritatively, with the aa flag:

dig @192.0.2.53 example.com SOA +norec
dig @198.51.100.53 example.com SOA +norec

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.        3600    IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 3600 1209600 3600

The serial number should match on both. If the secondary's is older, check journalctl -u named on both servers for transfer errors.

Step 5: Point the Domain at the New Nameservers

Only once both servers answer correctly, change the domain's nameservers at your registrar to:

ns1.example.com
ns2.example.com

Then confirm the delegation at the registry. The referral should include the glue in the additional section:

dig @a.gtld-servers.net example.com NS +norec

;; AUTHORITY SECTION:
example.com.        172800  IN  NS    ns1.example.com.
example.com.        172800  IN  NS    ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    172800  IN  A     192.0.2.53
ns1.example.com.    172800  IN  AAAA  2001:db8:1::53
ns2.example.com.    172800  IN  A     198.51.100.53
ns2.example.com.    172800  IN  AAAA  2001:db8:2::53

Run a full trace to make sure resolution works from the root down:

dig example.com A +trace

If DNSSEC was enabled with your previous provider, remove the old DS record at the registrar before this switch, and set up signing on the new servers afterwards.

Using Your Nameservers for Client Domains

Once ns1.example.com and ns2.example.com exist, other domains can use them too. A client domain such as client.example.net just sets its nameservers to your two names, and you add a zone for it on your servers. It doesn't need its own glue, because your nameserver names live in a different domain that already has glue.

Many hosting companies use a separate domain just for nameservers, such as ns1.examplehost-dns.net, so that problems with the main company domain, such as an expired registration or a billing dispute, can't take every client's DNS down with it.

Common Problems

1. Registering glue but forgetting the zone records: Some resolvers prefer the authoritative A record for ns1.example.com from your zone. If it's missing or different, you get inconsistent results.
2. Both nameservers on one machine: It works until that machine fails.
3. An open resolver: Leaving recursion yes on a public authoritative server lets anyone use it, which invites abuse in amplification attacks.
4. TCP blocked: DNS uses TCP for large responses and zone transfers. Allow port 53 over both protocols.
5. Changing nameserver IPs without updating glue: Update the host record at the registrar as well as the zone, and keep the old IP answering for a few days.

---

FAQ: Private Nameservers

---

Conclusion

Setting up custom private nameservers comes down to three linked pieces: host records with IP addresses at your registrar, matching A, AAAA and NS records in your zone, and a domain delegated to the new names. Behind the names, you can run your own servers with BIND, use a managed provider's white-label feature, or rely on a hosting control panel.

Remember that the branding is only skin deep. Reliability comes from what runs at those addresses, so use at least two servers on separate networks, keep their IPs stable, turn off recursion, and allow DNS over both UDP and TCP. Verify the glue and delegation with dig against the TLD servers, and your domain and any client domains will resolve through nameservers carrying your own name.