67 lines
2.4 KiB
Markdown
67 lines
2.4 KiB
Markdown
---
|
|
title: DNS Architecture
|
|
description: Core DNS architecture patterns for self-hosted and homelab environments
|
|
tags:
|
|
- dns
|
|
- networking
|
|
- infrastructure
|
|
category: networking
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# 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:
|
|
|
|
```text
|
|
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?](https://www.cloudflare.com/learning/dns/what-is-dns/)
|
|
- [RFC 1034: Domain Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034)
|
|
- [RFC 1035: Domain Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035)
|