Understanding DNS: Architecture, Configuration, and Security

DNS (Domain Name System) is an essential Internet service that maps domain names to IP addresses using a distributed database, allowing users to access resources via human‑readable names.

Key characteristics include its distributed nature, support for both TCP and UDP (default port 53), and label length limits of 63 characters per level and 253 characters overall.

UDP is used for most queries, but when a response exceeds the original 512‑byte limit, DNS falls back to TCP; modern implementations can request larger UDP packets to avoid the TCP fallback.

The DNS hierarchy resembles an inverted tree similar to a Linux file system. For example, the domain www.tool.chinaz.com. is resolved from the root (.) to the top‑level com , then to chinaz , and finally to the host name.

Top‑level domains (TLDs) are delegated to specific name servers. Organizations may build their own internal name servers for intra‑company name resolution or when public provider name servers do not meet performance or reliability requirements.

Resolution on a client follows the order defined in /etc/nsswitch.conf (e.g., hosts: files dns myhostname ), typically checking the local /etc/hosts file first, then querying a DNS server. The standard recursive resolution flow involves the client contacting a local recursive server, which queries root servers, TLD servers, and authoritative servers step‑by‑step until the final IP address is obtained and cached.

Recursive resolvers differ from authoritative servers: recursive servers perform the full lookup chain, while authoritative servers store the definitive records for their zones.

Caching at each recursive server improves performance and robustness; the global DNS infrastructure relies on 13 root servers whose addresses are hard‑coded into resolvers.

Smart resolution (EDNS) allows a DNS server to return the IP address nearest to the client, improving latency. In China, DNSPod is a popular provider that supports EDNS and offers intelligent routing.

Domain registrars manage the delegation of second‑level domains (e.g., hello.com ) and typically provide authoritative name servers. Registrants can switch to other authoritative servers (e.g., DNSPod) for better performance or features.

Setting up a DNS server with BIND involves editing /etc/named.conf to define zones and logging, and creating zone files that contain SOA, A, CNAME, and other records. Example commands to validate configuration are named-checkconf and named-checkzone . The service is started with service named start and verified via netstat -ntlp .

DNS can provide simple load balancing by adding multiple A records for a host; responses are returned in round‑robin order, though this lacks health checks compared to dedicated load balancers like LVS.

Sub‑domain delegation is performed by configuring an NS record in the parent zone and setting up the child zone’s SOA record, allowing departments to manage their own sub‑domains independently.

Common DNS debugging tools include host , nslookup , and dig . The dig output shows query details, answer sections, and additional information useful for troubleshooting.

DNS amplification attacks exploit the fact that a small query can trigger a large response, overwhelming a target with traffic. Attackers spoof source IPs to direct massive DNS responses at victims. Mitigations involve rate limiting, response size restrictions, and filtering malformed queries.