first version of the knowledge base :)

20 - Knowledge/networking/dns-architecture.md

@@ -0,0 +1,66 @@
+---
+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)