Self-Hosted Authoritative DNS

Running authoritative DNS gives direct control of zone data but also makes you responsible for availability, correctness, security, monitoring, updates, and incident response.

Do Not Confuse Server Roles

An authoritative server publishes zones it controls. A recursive resolver performs lookups for clients. Do not expose an unrestricted recursive resolver to the public internet as part of an authoritative deployment.

Minimum Design Questions

Before self-hosting, decide:

• How many authoritative servers will serve the zone
• Whether they are on independent networks and failure domains
• How zone data is replicated
• Who can edit zones and sign changes
• How updates are reviewed and rolled back
• How software and operating systems are patched
• How UDP and TCP DNS on port 53 are monitored
• How logs, configuration, and keys are backed up
• How an outage will be detected from outside the network

Parent Delegation and Glue

The registration service delegates the domain to nameserver hostnames. If a nameserver hostname is inside the domain it serves, the parent may need glue address records to avoid a circular lookup.

Example circular dependency:

Zone:       example.dpdns.org
Nameserver: ns1.example.dpdns.org

Do not choose in-zone nameserver names unless the registration layer supports the required glue workflow and you understand how to maintain it.

Zone Essentials

An authoritative zone normally includes:

• One SOA record
• The authoritative NS record set
• Address or alias records for services
• Mail and verification records when used

All authoritative servers must publish consistent data. Validate zone files before loading them and increment the SOA serial according to the DNS software's update model.

Network Requirements

Authoritative DNS must answer both UDP and TCP on port 53. TCP is not an optional fallback to ignore; larger responses, transfers, and protocol behavior can require it.

Do not place all authoritative servers behind one machine, router, power supply, or network path and call that redundancy.

Pre-Delegation Test

Before changing registration-level nameservers:

dig @192.0.2.53 SOA example.dpdns.org
dig @192.0.2.53 NS example.dpdns.org
dig @192.0.2.53 A www.example.dpdns.org
dig +tcp @192.0.2.53 SOA example.dpdns.org

The documentation address must be replaced with the real server address.

Operational Standard

Do not delegate production domains until external monitoring can detect failures, a second authoritative server has been verified, backups have been restored in a test, and an operator other than the original builder can follow the recovery documentation.

Continue to Command Reference.