Software and Versions Used
This explanation applies to:
- DNS Protocol: RFC 1035 (Domain Names standard)
- Resolvers: systemd-resolved, dnsmasq, unbound
- Nameservers: BIND 9.18+, PowerDNS 4.7+, Knot DNS 3.2+
- Context: Distribution-independent DNS fundamentals
DNS is a distributed translation system without a central authority
The Domain Name System (DNS) translates human-readable names into numeric IP addresses. This is accomplished through hierarchical name resolution. A query for matrix.example.com passes through several stages of resolution: Root servers (.) → Top-Level Domain servers (.com) → Authoritative server (example.com) → Response containing IP addresses. DNS works identically on all operating systems.
Article 1 explained IP addresses as unique network identifiers. DNS extends this concept by providing more readable names without changing the underlying technical foundation. A web server still listens on 192.168.1.100:80—DNS simply allows access through webserver.local instead of the numeric address.
DNS records define different types of mappings: A records for IPv4 addresses, AAAA records for IPv6, CNAME records for aliases, and MX records for mail servers. A dig matrix.example.com A query explicitly requests IPv4 addresses, while dig matrix.example.com AAAA requests IPv6 addresses. These record types can exist in parallel—the same domain can have both IPv4 and IPv6 addresses.
The DNS hierarchy works like an inverted tree
Root servers (.) manage the highest level of the DNS tree and know all Top-Level Domains (TLDs). Thirteen root server clusters worldwide (a.root-servers.net through m.root-servers.net) answer DNS queries and refer them to the appropriate TLD server. This distribution eliminates single points of failure and provides global DNS redundancy.
TLD servers manage domains such as .com, .org, and .de, and know the authoritative nameservers for registered domains. A query for example.com is referred by the .com TLD servers to the nameservers specified in the domain registration. This delegation allows domain owners to manage their own DNS records.
Authoritative nameservers provide the definitive answers for the domains assigned to them. The nameserver for example.com provides authoritative responses for queries such as www.example.com, mail.example.com, or matrix.example.com. This server authority makes additional queries unnecessary—the response is final.
Resolvers perform recursive queries
DNS resolvers receive queries from applications and perform the complete resolution process. A recursive resolver queries the root servers, TLD servers, and authoritative servers in sequence until it receives a final answer. Stub resolvers delegate this work to configured recursive resolvers.
Caching significantly reduces DNS traffic and improves response times. A resolver stores DNS responses according to their TTL (Time To Live). A TTL of 3600 seconds means that the record remains valid in the cache for one hour. Once it expires, the next query triggers a new DNS resolution.
Modern resolvers use various optimizations: Prefetching refreshes popular domains before their TTL expires, Query Minimization reduces the amount of transmitted information, and DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) encrypt DNS queries to protect them from surveillance.
Container DNS resolution works through separate resolvers
Docker containers receive automatically configured DNS resolvers that translate container names into bridge IP addresses. A container named web can reach the database container using the name database—Docker’s built-in DNS server translates it to 172.17.0.3. This automatic name resolution works only within the same Docker bridge or user-defined networks.
The host’s DNS configuration does not automatically affect containers. Containers use Docker’s DNS server (127.0.0.11) as their primary resolver, with fallback to the host system configuration. This separation explains why /etc/hosts entries on the host are not available inside containers.
User-defined networks allow dedicated DNS servers to be configured per network. Containers can use local DNS servers (Unbound, dnsmasq) instead of Docker’s default mechanism.
Local DNS servers increase independence
Running your own DNS servers reduces external dependencies and enables local domain resolution. Unbound functions as a validating, recursive resolver without external dependencies—it queries the root servers directly instead of relying on other resolvers. This configuration eliminates DNS providers as potential points of surveillance or censorship.
dnsmasq combines a DNS server and a DHCP server for small networks. Local /etc/hosts entries are automatically made available as DNS records. An entry such as 192.168.1.100 server.local in /etc/hosts makes server.local available to all clients on the network. This integration greatly simplifies local service discovery.
Pi-hole blocks advertisements and tracking through DNS sinkholing: Known advertising domains resolve to 0.0.0.0. This method works network-wide for all devices without requiring client software. A single Pi-hole server filters DNS requests for smartphones, smart TVs, and IoT devices alike.
DNS Security Extensions (DNSSEC) authenticate DNS responses
DNSSEC prevents DNS spoofing through cryptographic signatures. Every DNS record is signed with a private key, and resolvers verify the signatures using the corresponding public keys. This chain of trust extends from the root servers to individual DNS records, making DNS manipulation detectable.
Validating resolvers automatically verify DNSSEC signatures and discard invalid responses. A compromised DNS server cannot forge signed records without the corresponding private key. DNSSEC effectively protects against man-in-the-middle attacks at the DNS layer.
DNSSEC requires correct time synchronization for signature validation. Expired signatures are discarded even if they are technically valid. NTP synchronization is therefore essential for DNSSEC-capable resolvers. A server with an incorrect system clock cannot process validated DNS responses.
Reverse DNS resolves IP addresses to names
PTR records enable reverse DNS lookups from IP addresses to domain names. A dig -x 192.168.1.100 query requests the PTR record for that IP address. Mail servers use reverse DNS for spam evaluation: Missing or mismatched PTR records increase spam scores.
IPv4 reverse DNS uses special .in-addr.arpa domains: 192.168.1.100 becomes 100.1.168.192.in-addr.arpa. This reversal enables hierarchical delegation of reverse zones according to the IP address block structure. A /24 network corresponds to a single reverse zone.
IPv6 reverse DNS uses .ip6.arpa with hexadecimal digit reversal. The IPv6 address 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Expanding and reversing every hexadecimal digit enables granular delegation down to individual IP addresses.
Alternative DNS strategies for enhanced privacy
DNS-over-HTTPS (DoH) tunnels DNS queries through HTTPS connections, making them invisible to network monitoring. Browsers such as Firefox use DoH by default with Cloudflare (1.1.1.1) or Quad9 (9.9.9.9). This encryption prevents DNS-based censorship and tracking by Internet service providers.
DNS-over-TLS (DoT) encrypts DNS traffic over TLS on port 853. Unbound and systemd-resolved support DoT natively. A DoT configuration using Quad9 transparently encrypts all DNS queries without requiring changes at the application layer. DoT provides better performance than DoH while offering comparable privacy.
Tor-based DNS resolution routes DNS queries through the Tor network for maximum anonymity. This configuration completely prevents DNS-based user tracking but significantly increases latency. Tor DNS is suitable for highly sensitive applications with corresponding performance requirements.
Domain registration and nameserver management
Domain registrars manage domain registrations with registry organizations (.com registry: Verisign, .de registry: DENIC). The registrar updates nameserver entries in the TLD zone according to customer instructions. This nameserver delegation allows DNS management to operate independently of the registrar.
Glue records solve circular dependency problems during nameserver delegation. If example.com uses the nameserver ns1.example.com, the .com TLD must know the IP address of ns1.example.com for the delegation to succeed. Glue records in the TLD zone provide these IP addresses together with the nameserver delegation.
Dynamic DNS (DDNS) automatically updates DNS records when IP addresses change. A DDNS client detects new public IP addresses and updates A records accordingly. This automation enables self-hosting despite dynamically assigned IP addresses from residential Internet providers.
Monitoring and troubleshooting DNS infrastructures
dig provides detailed DNS debugging information with various query types and trace options. A dig +trace example.com command displays the complete resolution path from the root servers to the final response. This trace function identifies DNS problems at specific levels of the hierarchy.
DNS monitoring tracks response times, availability, and record consistency from multiple locations. Smokeping or PRTG continuously measure DNS response times and alert on deviations. Geographic DNS monitoring identifies regional outages or performance problems.
Authoritative nameserver logs reveal query patterns, abuse attempts, and performance metrics. BIND logs identify DDoS attacks, incorrect resolver configurations, or unexpected query volumes. This information allows administrators to optimize nameserver performance and security configurations.
DNS load balancing and service discovery
Round-robin DNS distributes traffic across multiple IP addresses by returning them in varying order. An A record containing multiple IP addresses, such as web.example.com IN A 192.168.1.10 and web.example.com IN A 192.168.1.11, statistically distributes requests between both servers. This simple load balancing works without additional infrastructure.
Weighted round-robin DNS enables uneven traffic distribution through TTL manipulation or record frequency. GeoDNS provides geographically optimized IP addresses based on the client’s location. DNS-based load balancing reduces response times and distributes server load, but it also makes debugging DNS-related issues more difficult.
Service discovery through DNS uses SRV records to locate services together with port information. An SRV record such as _matrix._tcp.example.com SRV 10 5 8008 matrix.example.com defines a Matrix service on matrix.example.com port 8008 with priority 10 and weight 5. Lower priority values are preferred, while records with the same priority use the weight to determine traffic distribution. This standardized service discovery mechanism works independently of the underlying protocol.
Integration with self-hosting services
Matrix federation requires specific DNS records for server discovery: either .well-known/matrix/server over HTTPS or SRV records such as _matrix._tcp.example.com. Other Matrix servers automatically discover the local server through these DNS-based discovery mechanisms. Incorrect DNS configuration prevents federation entirely.
Mail services require MX records for mail routing, SPF records for sender authentication, DKIM records for message signing, and DMARC records for policy definition. These DNS records enable trusted email delivery without being classified as spam. Listmonk newsletters depend on correct DNS configuration for reliable deliverability.
SSL certificate validation uses DNS to verify domain ownership. The Let’s Encrypt DNS challenge creates temporary TXT records for automated certificate issuance. This method works without an HTTP server and enables wildcard certificates for multiple subdomains.
Automation and Infrastructure as Code
DNS provider APIs enable programmatic DNS record management for automated deployments. Terraform providers for Cloudflare, Route53, or PowerDNS integrate DNS configuration into Infrastructure-as-Code workflows. Git-based DNS management makes DNS changes version-controlled and traceable.
External-DNS for Kubernetes automatically updates DNS records based on service configurations. A Kubernetes service with the annotation external-dns.alpha.kubernetes.io/hostname: api.example.com automatically creates the corresponding A records. This integration eliminates manual DNS management for container deployments.
DNS validation in CI/CD pipelines verifies DNS configuration before deployment approval. Automated tests validate DNS record existence, response times, and record consistency across multiple resolvers. These quality checks prevent DNS-related service outages caused by configuration changes.
Next Steps:
-
Matrix Server with DNS Federation (planned)
