DNS Architecture

Summary

DNS architecture defines how names are assigned, resolved, delegated, and operated across internal and external systems. In self-hosted environments, good DNS design reduces configuration drift, improves service discoverability, and simplifies remote access.

Why it matters

DNS is a foundational dependency for reverse proxies, TLS, service discovery, monitoring, and operator workflows. Weak DNS design creates brittle systems that depend on hard-coded IP addresses and manual recovery steps.

Core concepts

Authoritative DNS: the source of truth for a zone
Recursive resolution: the process clients use to resolve names
Internal DNS: records intended only for private services
Split-horizon DNS: different answers depending on the client context
TTL: cache lifetime that affects propagation and change speed

Practical usage

A practical self-hosted DNS model often includes:

Public DNS for internet-facing records
Internal DNS for management and private services
Reverse proxy hostnames for application routing
Stable names for infrastructure services such as hypervisors, backup targets, and monitoring systems

Example record set:

proxy.example.net        A      198.51.100.20
grafana.internal.example A      192.0.2.20
gitea.internal.example   CNAME  proxy.internal.example

Best practices

Use DNS names instead of embedding IP addresses in application config
Separate public and private naming where trust boundaries differ
Keep TTLs appropriate for the change rate of the record
Treat authoritative DNS as critical infrastructure with backup and access control

Pitfalls

Reusing the same name for unrelated services over time
Forgetting that split DNS can confuse troubleshooting if undocumented
Leaving DNS ownership unclear across platforms and providers
Building service dependencies on local /etc/hosts entries

2.4 KiB Raw Blame History