DNS, authoritative service, and dnsDragon

You can self-host applications without self-hosting authoritative DNS on day one. A free or paid DNS host can publish your records while Saphira hosts web, mail, VPN, and firewall services. When you do want authority on Saphira, dnsDragon and BIND are deliberate server roles with public reachability, redundancy, and DNSSEC decisions—not just another checkbox.

# Ask the currently configured resolver.
dig +short A www.example.test
dig +short AAAA www.example.test

# Ask a named authoritative server directly.
dig @ns1.example.test example.test SOA +noall +answer
dig @ns1.example.test example.test MX +noall +answer

# BIND configuration check before a reload.
named-checkconf /etc/bind/named.conf

This is an intentionally small zone model for understanding record ownership. It is not a replacement for your registrar's delegation, a second authoritative nameserver, DNSSEC policy, or dnsDragon's own managed configuration. The important point is that public DNS names public addresses; internal server addresses belong in a separate internal zone or split-horizon view.

$TTL 3600
@   IN SOA ns1.example.test. hostmaster.example.test. (
        2026082701 3600 600 1209600 3600 )
    IN NS  ns1.example.test.
    IN NS  ns2.example.test.

ns1 IN A     203.0.113.53
ns1 IN AAAA  2001:db8:53::53
ns2 IN A     198.51.100.53

www IN A    203.0.113.10
www IN AAAA 2001:db8:100::10
mail IN A    203.0.113.25
mail IN AAAA 2001:db8:100::25
@    IN MX 10 mail.example.test.

A business often needs names such as git.office.example.test or mail-admin.office.example.test to resolve only on the management VLAN or VPN. The name, route, DNS advertisement, and firewall permission must agree. Returning a private address to a laptop that has no VPN route creates a name that resolves successfully but cannot be used.

1. 1. Choose an internal namespace and owner

   Record who maintains internal records and which resolver answers them. Avoid reusing a public hostname with a surprising private destination unless split-horizon behaviour is documented.

2. 2. Give clients the right resolver

   DHCPv4, DHCPv6, RA/RDNSS, or VPN configuration must advertise the resolver appropriate to that network.

3. 3. Test name plus path

   Use dig or getent to verify the answer, then ip route get or ip -6 route get to verify a route, then test the actual service.

• Carry private DNS through a management VPN
• Publish mail records without confusing internal names

A dnsDragon deployment can serve DNSSEC-signed authoritative zones through its BIND-based authoritative path. DNSSEC is not a cosmetic record: it adds cryptographic proof that an answer, including a proven non-existent answer, belongs to the zone owner. It has a second half outside the server: the parent zone must publish a DS record that links the signed child zone to the DNS root.

• Build and verify a DNSSEC chain of trust
• Read the dnsDragon DNSSEC implementation guide