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

References

• Cloudflare Learning Center: What is DNS?
• RFC 1034: Domain Concepts and Facilities
• RFC 1035: Domain Implementation and Specification