Public vs Private DNS: Key Differences and Use Cases

Every organization that operates networked infrastructure eventually confronts a fundamental architectural question: which DNS information should be visible to the world, and which should remain strictly internal? The distinction between public and private DNS is not merely academic — it directly shapes your security posture, operational flexibility, and how services are discovered by both internal users and external clients. Getting this separation right is one of the foundational decisions in any serious infrastructure build.

What Is DNS and Why Does Visibility Matter?

The Domain Name System translates human-readable names into IP addresses and other resource records. When a browser needs to reach solvethenetwork.com, it queries a resolver, which walks the DNS hierarchy from root servers down to the authoritative name server for that zone. The answer it gets — and crucially, whether it can get an answer at all — depends entirely on where the query originates and which DNS infrastructure handles it.

Public DNS is reachable by anyone on the internet. Private DNS operates within a controlled network boundary, typically serving RFC 1918 address space and internal hostnames that should never be exposed externally. Confusing the two, or failing to plan for both, leads to information leakage, broken internal resolution, and service disruptions that are notoriously difficult to debug under pressure.

Understanding Public DNS

Public DNS consists of two distinct components that are often conflated:

• Authoritative name servers — These hold the definitive zone data for a domain. When you register solvethenetwork.com and publish NS records pointing to ns1.solvethenetwork.com and ns2.solvethenetwork.com, those servers are the authoritative source. Any recursive resolver on the internet can query them.
• Public recursive resolvers — These accept queries from any source, cache results, and walk the DNS tree on behalf of clients. They are the resolvers typically configured on home routers or workstations without a managed private DNS server.

A public zone file for solvethenetwork.com typically contains records that are safe for global exposure: the apex A and AAAA records pointing to load balancers or CDN edge nodes, MX records for mail exchange, TXT records for SPF and DKIM, and CNAME records for external-facing services.

; Public zone file: solvethenetwork.com
; Hosted on authoritative server sw-infrarunbook-01
$ORIGIN solvethenetwork.com.
$TTL 3600

@       IN  SOA   ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
                  2026033001  ; Serial
                  3600        ; Refresh
                  900         ; Retry
                  604800      ; Expire
                  300 )       ; Negative cache TTL

        IN  NS    ns1.solvethenetwork.com.
        IN  NS    ns2.solvethenetwork.com.

        IN  A     203.0.113.10        ; Public-facing load balancer
        IN  MX 10 mail.solvethenetwork.com.

www     IN  A     203.0.113.10
mail    IN  A     203.0.113.20
ns1     IN  A     203.0.113.30
ns2     IN  A     203.0.113.31

; SPF record
@       IN  TXT   "v=spf1 ip4:203.0.113.0/24 ~all"

; DMARC
_dmarc  IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@solvethenetwork.com"

Notice what is intentionally absent: no RFC 1918 addresses, no internal hostnames, no records that would expose internal topology. Public zone data should be treated as a public document — because that is exactly what it is. Any record you publish here is permanently archived by passive DNS services and accessible to threat intelligence platforms worldwide.

Understanding Private DNS

Private DNS serves resolution requests for internal infrastructure. Its defining characteristic is that it answers queries with information that must never leave the organization's network boundary. This includes RFC 1918 address mappings, internal hostnames not registered in any public zone, internal subdomains of public domains via the split-horizon pattern, and reverse DNS zones for private address space.

A private DNS server running BIND9 on sw-infrarunbook-01 at address 192.168.10.5 might serve a zone file that looks like this:

; Private zone file: solvethenetwork.com (internal view)
; Served ONLY to RFC 1918 clients by sw-infrarunbook-01
$ORIGIN solvethenetwork.com.
$TTL 300

@       IN  SOA   sw-infrarunbook-01.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
                  2026033001
                  300
                  60
                  86400
                  60 )

        IN  NS    sw-infrarunbook-01.solvethenetwork.com.

; Internal-only records — RFC 1918 addresses
@           IN  A     192.168.10.1       ; Internal gateway VIP
www         IN  A     192.168.10.10      ; Internal web server
api         IN  A     192.168.10.20      ; Internal API server
db01        IN  A     192.168.10.30      ; Database primary node
monitoring  IN  A     192.168.10.40      ; Grafana/Prometheus stack
vpn         IN  A     192.168.10.50      ; VPN concentrator
sw-infrarunbook-01  IN  A  192.168.10.5 ; This DNS server itself

The critical point: the same domain returns entirely different answers depending on whether the query came from the internet or from inside 192.168.10.0/24. This is the split-horizon pattern, and it is the most prevalent architecture for organizations that need both a public presence and internal resolution under a unified namespace.

Split-Horizon DNS: Serving Different Answers by Source

Split-horizon DNS — also called split-brain DNS or split-view DNS — uses BIND's views directive to serve different zone content based on the source IP of the query. Internal clients querying api.solvethenetwork.com receive 192.168.10.20. The same query from an external internet host returns the external load balancer address. Neither side can see the other's answers.

The BIND named.conf configuration on sw-infrarunbook-01 implementing split-horizon with two views:

// /etc/named.conf on sw-infrarunbook-01 (192.168.10.5)
// Split-horizon configuration for solvethenetwork.com

options {
    listen-on { 192.168.10.5; 127.0.0.1; };
    directory "/var/named";
    recursion yes;
    allow-recursion { internal-nets; };
    dnssec-validation auto;
    forwarders { 1.1.1.1; 8.8.8.8; };
    forward only;
};

acl "internal-nets" {
    192.168.0.0/16;
    172.16.0.0/12;
    10.0.0.0/8;
    127.0.0.1;
};

// Internal view — served to RFC 1918 sources
view "internal" {
    match-clients { internal-nets; };
    recursion yes;

    zone "solvethenetwork.com" {
        type master;
        file "/var/named/internal/solvethenetwork.com.zone";
        allow-query   { internal-nets; };
        allow-transfer { none; };
    };

    zone "10.168.192.in-addr.arpa" {
        type master;
        file "/var/named/internal/192.168.10.rev";
        allow-query { internal-nets; };
    };
};

// External view — all other sources forwarded to public authoritatives
view "external" {
    match-clients { any; };
    recursion no;

    zone "solvethenetwork.com" {
        type forward;
        forwarders { 203.0.113.30; 203.0.113.31; };  // Public authoritative servers
    };
};

Order matters in BIND views. BIND evaluates views in the order they appear in named.conf and uses the first match. Always place more specific match-clients ACLs before broader ones. Placing the external view first would inadvertently serve all clients — including internal ones — with the external configuration.

Reverse DNS in Private Zones

Reverse DNS resolution — PTR records — in private address space requires dedicated in-addr.arpa zones maintained by your internal DNS server. IANA explicitly reserves the reverse zones for RFC 1918 blocks; public resolvers return NXDOMAIN for these queries. Internal applications including SSH, mail servers, and logging pipelines regularly perform reverse lookups, and unresolved PTR queries cause timeout delays that compound across a busy infrastructure.

; /var/named/internal/192.168.10.rev
; Reverse zone for 192.168.10.0/24 on sw-infrarunbook-01

$ORIGIN 10.168.192.in-addr.arpa.
$TTL 300

@   IN  SOA   sw-infrarunbook-01.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
              2026033001
              300
              60
              86400
              60 )

    IN  NS    sw-infrarunbook-01.solvethenetwork.com.

5   IN  PTR   sw-infrarunbook-01.solvethenetwork.com.
10  IN  PTR   www.solvethenetwork.com.
20  IN  PTR   api.solvethenetwork.com.
30  IN  PTR   db01.solvethenetwork.com.
40  IN  PTR   monitoring.solvethenetwork.com.
50  IN  PTR   vpn.solvethenetwork.com.

Securing Zone Transfers with TSIG

Zone transfers replicate zone data from a primary server to secondary name servers. In public DNS, this replication is necessary for redundancy. In private DNS, unprotected zone transfers represent a significant data leak — any host that can reach your internal name server on TCP 53 could enumerate your entire internal namespace in a single AXFR request. TSIG (Transaction Signature) uses HMAC-based shared secrets to ensure only authorized secondaries receive zone data.

Generate a TSIG key on sw-infrarunbook-01 and restrict transfers to authenticated secondaries only:

# Generate TSIG key as infrarunbook-admin on sw-infrarunbook-01
tsig-keygen -a hmac-sha256 internal-transfer-key

# Output saved to /etc/named/tsig-internal.key:
key "internal-transfer-key" {
    algorithm hmac-sha256;
    secret "kP3xQv8nLmR2wYjT5uZaGdFsHeNbVcXi7oA9qB4=";
};

// named.conf — restrict zone transfers using TSIG
include "/etc/named/tsig-internal.key";

view "internal" {
    match-clients { internal-nets; };

    zone "solvethenetwork.com" {
        type master;
        file "/var/named/internal/solvethenetwork.com.zone";
        allow-transfer { key internal-transfer-key; };  // TSIG-only transfers
        also-notify   { 192.168.10.6; };                // Secondary DNS server
    };
};

Response Policy Zones for Private DNS Security

Response Policy Zones (RPZ) allow a private recursive resolver to intercept and rewrite query responses, enabling policy-based DNS filtering at the resolver level. This is exclusively a private DNS feature — public authoritative servers do not perform recursive resolution and therefore cannot implement RPZ. In private DNS infrastructure, RPZ is a powerful control: it blocks known malware command-and-control domains, enforces safe-search policies, and intercepts DNS tunneling attempts before data leaves the network.

// RPZ configuration in named.conf — internal view only on sw-infrarunbook-01
view "internal" {
    match-clients { internal-nets; };
    recursion yes;

    response-policy {
        zone "rpz.solvethenetwork.com" policy NXDOMAIN;
    };

    zone "rpz.solvethenetwork.com" {
        type master;
        file "/var/named/rpz/blocklist.zone";
        allow-query    { none; };    // RPZ zones must not be directly queryable
        allow-transfer { none; };
    };
};

; /var/named/rpz/blocklist.zone
; RPZ policy zone — clients querying blocked names receive NXDOMAIN
$TTL 300
@   IN  SOA  sw-infrarunbook-01.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
             2026033001 300 60 86400 60 )
    IN  NS   sw-infrarunbook-01.solvethenetwork.com.

; CNAME to "." signals NXDOMAIN policy for matched names
malware-c2-domain.net.rpz.solvethenetwork.com.   IN  CNAME  .
dns-tunnel-service.io.rpz.solvethenetwork.com.   IN  CNAME  .

DNS over TLS for Private Resolver Traffic

DNS over TLS (DoT) is frequently associated with public resolvers, but it is equally applicable inside private infrastructure. Encrypting DNS traffic between internal clients and sw-infrarunbook-01 prevents passive observation of internal hostnames on the wire — particularly important in environments with strict data classification requirements, shared hosting scenarios, or partially untrusted network segments such as guest VLANs or cloud transit networks.

; /etc/stunnel/dns-tls.conf
; stunnel wraps BIND on sw-infrarunbook-01 for DoT on port 853

[dns-tls]
accept  = 192.168.10.5:853
connect = 127.0.0.1:53
cert    = /etc/stunnel/certs/sw-infrarunbook-01.crt
key     = /etc/stunnel/certs/sw-infrarunbook-01.key
CAfile  = /etc/stunnel/certs/internal-ca.crt
verify  = 2

Query Logging on Private DNS Servers

DNS query logs from your private resolver are one of the most valuable sources of security telemetry in your environment. Every internal resolution request appears here: beacon traffic to C2 infrastructure, DNS exfiltration payloads embedded in query strings, and misconfigured clients hammering non-existent names. BIND's logging facility writes structured query logs to a dedicated channel that can be forwarded to a SIEM for correlation.

// BIND query logging configuration for sw-infrarunbook-01
logging {
    channel query_log {
        file "/var/log/named/queries.log" versions 7 size 100m;
        severity dynamic;
        print-time yes;
        print-severity yes;
        print-category yes;
    };

    category queries       { query_log; };
    category query-errors  { query_log; };
};

Key Differences: Public vs Private DNS at a Glance

• Scope of visibility: Public DNS is globally queryable by any internet host. Private DNS is accessible only to clients within defined network boundaries enforced by ACLs, firewalls, and VPN tunnels.
• Address space in records: Public DNS records reference globally routable IP addresses. Private DNS records reference RFC 1918 space and may return different results for the same name compared to the public zone.
• Recursion policy: Public authoritative servers must disable recursion to prevent open resolver abuse and DNS amplification attacks. Private resolvers enable recursion for internal clients and forward unknown queries upstream to public resolvers.
• Security controls: Private DNS supports RPZ filtering, TSIG-protected zone transfers, strict allow-query ACLs, and full query logging. Public authoritative DNS focuses on DNSSEC signing, query rate limiting, and DDoS mitigation.
• TTL strategy: Public zones use longer TTLs (3600–86400 seconds) to reduce recursive resolver load and improve global cache hit rates. Private zones use shorter TTLs (60–300 seconds) to accommodate faster infrastructure changes and rapid failover.
• Zone transfer exposure: Private zone transfers must be restricted with TSIG authentication. Even between internal servers, unauthenticated AXFR exposes the full internal namespace to anyone who can reach the listener.
• Reverse DNS authority: RFC 1918 reverse zones are the responsibility of the private DNS server. Public resolvers have no authority over 10.in-addr.arpa or 192.168.in-addr.arpa and will return NXDOMAIN for any query into these spaces.

Common Use Cases in Practice

Microservices service discovery: Internal services register themselves in the private DNS zone. Service A locates Service B by querying api.solvethenetwork.com and receiving 192.168.10.20. No hardcoded IPs are required, and failover is handled by updating a single DNS record with a 60-second TTL.

VPN split DNS: Remote workers connect via VPN to 192.168.10.0/24. Their DNS search domain is pushed via DHCP option 6 to query sw-infrarunbook-01 for solvethenetwork.com names, while public internet queries use a local resolver. Internal resources are reachable by name without routing all DNS traffic over the tunnel.

Regulated environments: Compliance requirements mandate that database hostnames never appear in publicly queryable DNS. The private zone serves db01.solvethenetwork.com → 192.168.10.30 exclusively. The public zone has no record for this name — an external query returns NXDOMAIN and reveals nothing about internal topology.

Blue-green deployments: A 60-second TTL on the internal A record for api.solvethenetwork.com allows traffic to shift between blue and green environments within one TTL cycle by updating a single record. The public DNS entry points to a CDN with a 300-second TTL, decoupled from the internal routing decision entirely.

Operational Pitfalls to Avoid

Open recursion on public authoritative servers: Enabling recursion on an internet-facing authoritative server turns it into an open resolver that can be exploited in DNS amplification attacks. Always set

recursion no;

in the options block of any public-facing BIND instance and verify with a tool like dig from an external host.

DNS leakage via split tunneling: If remote users' DNS queries for internal names are resolved by public resolvers, those queries return NXDOMAIN or — worse — a squatted domain. Ensure VPN configurations push the correct DNS server address and domain search list to remote clients.

Stale private records after decommissioning: Private zones accumulate ghost records over time. Short TTLs and automated DNS updates via dynamic DNS or DHCP integration help, but a periodic audit process to remove records for decommissioned hosts is essential hygiene.

Missing reverse zones for internal space: Applications that perform reverse lookups will time out if sw-infrarunbook-01 is not authoritative for the relevant reverse zones. Define all in-addr.arpa zones covering your RFC 1918 allocations and keep PTR records in sync with forward records.

---

Frequently Asked Questions

Q: Can I use the same domain name for both public and private DNS?

A: Yes — this is the split-horizon (split-view) pattern. BIND's views directive lets you serve different zone content for the same domain based on the source IP of the query. Internal clients querying solvethenetwork.com receive RFC 1918 addresses; external clients receive public routable addresses. The internal resolver on sw-infrarunbook-01 is authoritative for the internal view, and internal clients must be configured to use it as their resolver rather than any public recursive service.

Q: Should my internal DNS server be reachable from the internet?

A: No. Your private DNS server at 192.168.10.5 should be firewalled from internet access entirely. Exposing it allows zone enumeration, exploitation of BIND vulnerabilities affecting your version, and direct information disclosure of internal topology. Only your public authoritative servers should be internet-reachable, and they must have recursion disabled to prevent open resolver abuse.

Q: What is the difference between a private resolver and a private authoritative server?

A: A private authoritative server holds the canonical zone data for internal zones — it is the master of record for the solvethenetwork.com private view. A private resolver accepts queries from internal clients, checks its cache, queries authoritative servers on their behalf, and caches results. In small environments these roles often share a single BIND instance on sw-infrarunbook-01, but in larger deployments they are separated: dedicated authoritative servers hold zone data, and dedicated resolvers handle client queries with their own cache.

Q: How do I prevent internal zone data from being leaked via zone transfers?

A: Set

allow-transfer { none; };

as the default for all zones, then selectively allow transfers using TSIG key authorization for authenticated secondary servers. Combine this with firewall rules blocking TCP 53 from untrusted network segments to your internal DNS servers. TSIG-authenticated transfers ensure that even if an attacker reaches the DNS port, they cannot receive zone data without the shared HMAC secret.

Q: How does DNSSEC interact with split-horizon DNS?

A: DNSSEC signs the public zone data with zone-signing keys, allowing resolvers to verify record authenticity via a chain of trust. With split-horizon, the internal view serves different records that cannot be signed with the same keys — a validating resolver receiving the internal answer alongside the public RRSIG would detect a signature mismatch. In practice, most organizations sign only the public zone and leave the internal view unsigned. Internal clients are typically configured with

dnssec-validation no;

for the internal view, or DNSSEC validation is bypassed for the internal zone via a negative trust anchor.

Q: What TTL should I use for internal DNS records?

A: Use short TTLs in the range of 60–300 seconds for most internal records, especially for services subject to failover or frequent redeployment. The cache-miss performance cost is negligible on a LAN. Reserve longer TTLs of 600–900 seconds for stable infrastructure like sw-infrarunbook-01 itself, core routers, and storage nodes whose addresses rarely change. Avoid copying public zone TTL values into private zones — the operational tradeoff is entirely different.

Q: Can I use public resolvers like 1.1.1.1 for internal clients?

A: Only for external domain resolution. If internal clients use public resolvers for solvethenetwork.com queries, those resolvers will query your public authoritative servers and return the external load balancer IP instead of the internal address. Internal clients must have sw-infrarunbook-01 (192.168.10.5) as their primary DNS server. Public resolvers can be configured as forwarders within your private resolver for queries to zones it is not authoritative for — the private resolver queries them on the client's behalf while the client itself only ever talks to the internal server.

Q: What is DNS leakage and how does it affect private DNS?

A: DNS leakage occurs when queries intended for your private resolver are sent to a public resolver instead — typically due to misconfigured VPN split tunneling, incorrect DHCP option 6 assignments, or client-side DNS override settings applied by software. The symptom is internal hostnames failing to resolve for remote users, or internal query patterns appearing in public resolver logs. Prevent it by enforcing DNS server assignments via DHCP and VPN push configurations, and audit client resolver settings regularly using

resolvectl status

on Linux or

ipconfig /all

on Windows hosts.

Q: How should I handle DNS for services deployed in cloud environments?

A: Cloud-deployed services that need to reach on-premises internal names require either a VPN or Direct Connect back to your private DNS server at 192.168.10.5, or a forwarding rule in the cloud provider's DNS resolver that sends queries for solvethenetwork.com to sw-infrarunbook-01. Most major cloud providers support conditional forwarding rules in their managed DNS services. Avoid publishing RFC 1918 records to a cloud-hosted public DNS zone — this recreates the information disclosure problem in a new environment.

Q: What happens if my private DNS server goes down?

A: Internal name resolution fails for all clients pointing to it, causing widespread service disruption — applications cannot reach databases, APIs, or monitoring systems by hostname. Always deploy a secondary private DNS server (e.g., 192.168.10.6) with TSIG-protected zone transfers configured from the primary. DHCP should distribute both server IPs in the DNS server option so clients have an automatic fallback. Monitor your DNS servers with the same priority as core infrastructure — a DNS outage is operationally equivalent to a network outage.

Q: Is it safe to publish internal-only subdomains in a public zone?

A: No. Publishing internal hostnames or RFC 1918 addresses in your public zone is an information disclosure vulnerability. Even if the RFC 1918 address itself is unreachable from the internet, knowing that db01.solvethenetwork.com resolves to 192.168.10.30 reveals your internal subnet layout, naming conventions, and service topology to passive DNS aggregators and potential attackers. Audit your public zone regularly and ensure internal records exist only in the private view served by sw-infrarunbook-01.

Q: How do RPZ zones differ between public and private DNS deployments?

A: RPZ is exclusively a feature of recursive resolvers and has no role on public authoritative servers, which do not perform recursion. In private DNS infrastructure, RPZ gives your resolver on sw-infrarunbook-01 the ability to intercept queries for known-bad domains and return NXDOMAIN or redirect to a sinkhole before the client establishes any connection. Commercial and open-source threat intelligence feeds are available in RPZ format and can be ingested directly into BIND, giving you continuously updated blocking without client-side agents or firewall rule churn.