DNS Security and Domain Governance Guide

Summary

DNS security is the cornerstone of reliable internet infrastructure operation, determining whether domains can be trustfully resolved to correct resources. This article systematically outlines the types of security threats facing DNS, analyzes DNSSEC deployment status and technical challenges, compares the mechanisms and privacy-security tradeoffs of DoH and DoT encrypted DNS protocols, and assesses the domain governance system’s support for security practices. Even with new payment methods such as USDT domain purchases, DNS security infrastructure remains central to the domain system—evolution of the payment medium does not in any way replace or diminish the necessity of DNS security protection.

Research Scope

As the internet’s core naming system, DNS bears the foundational function of mapping human-readable domain names to IP addresses, and its security status directly impacts the availability and trustworthiness of web applications. The primary threats currently facing DNS security include DNS cache poisoning, DNS hijacking, DDoS amplification attacks, and BGP hijacking affecting DNS; the defense system relies on DNSSEC signature verification, encrypted DNS protocols (DoH/DoT), and registrar security locks as primary pillars. Although global DNSSEC deployment rates continue to rise, the complexity of signing chain management and key rollover risks still constrain adoption pace—NIST SP 800-81 Rev.1 provides systematic security deployment guidance for this purpose.

DNS Security Threat Categories

DNS cache poisoning involves injecting forged DNS responses into recursive resolvers, causing them to cache incorrect domain-IP mappings and thereby redirecting user traffic to malicious servers. The classic Kaminsky attack (2008) revealed the severe vulnerability produced by combining UDP’s stateless nature with predictable DNS transaction IDs—although modern resolvers have mitigated this through transaction ID randomization and source port randomization, the fundamental elimination of this attack vector still requires DNSSEC’s cryptographic verification mechanism. DNS hijacking involves compromising registrar accounts or exploiting registrar system vulnerabilities to directly modify a domain’s authoritative DNS records, redirecting the entire domain’s traffic to attacker-controlled servers. Such attacks have broad impact and long duration; the 2019 DNS hijacking incidents targeting multiple country-code TLDs affected numerous government and commercial websites.

DDoS amplification attacks exploit DNS protocol’s connectionless UDP nature and the asymmetry where response packets are much larger than query packets, sending large volumes of DNS queries with spoofed source IPs to open recursive resolvers, causing amplified response traffic to overwhelm the target IP. The amplification factor of such attacks can reach 28 to 70x, making them a common tool for launching large-scale denial-of-service attacks. BGP hijacking, while not a DNS-specific attack, is particularly destructive to DNS infrastructure: attackers broadcast false BGP route prefixes to hijack the IP address space of authoritative DNS servers, directing DNS queries within affected autonomous systems to attacker-controlled pseudo-servers. The 2018 BGP hijacking incident targeting Amazon Route 53 redirected traffic from websites using that DNS service such as MyEtherWallet, highlighting the coupled risk between the BGP and DNS foundational protocol layers.

DNSSEC Deployment Status and Challenges

DNSSEC provides data origin authentication and integrity protection by appending digital signatures to DNS responses, with its trust chain delegating from the root zone’s Key Signing Key (KSK) downward through TLD and second-level domain Zone Signing Keys (ZSK). The root zone KSK is maintained by ICANN through Key Ceremony multi-signature cold storage, TLD operators maintain ZSKs at the registry level with periodic rotation, and second-level domain holders must enable DNSSEC signing at their registrar and upload DS records to the registry to complete trust chain anchoring. NIST SP 800-81 Rev.1 explicitly lists DNSSEC deployment as a core requirement of DNS security best practices, emphasizing the decisive role of correct DS record configuration and key lifecycle management in trust chain integrity.

DNSSEC deployment rates exhibit significant TLD variation. According to ICANN statistics, DNSSEC signing rates for large gTLDs such as .com and .net remain below 5%, while European ccTLDs such as .nl, .cz, and .se have signing rates exceeding 30% to 60%. Reasons for this gap include: massive registration volumes in large gTLDs leading to high signing computation and storage costs, uneven registrar support for DNSSEC management interfaces, and the technical threshold of DS record upload processes making it difficult for small and medium domain holders to complete configuration independently. Key rollover risk is another key challenge: the 2018 root zone KSK rollover (KSK-2017) was delayed by one year due to insufficient technical preparation and communication, and the second KSK rollover in 2024 similarly faces urgent coordination pressure—KSK/ZSK rollover failure will result in trust chain rupture and validation denial of service.

DNS security governance applies globally; non-ICP-filing domains equally need to follow DNSSEC deployment best practices. Regardless of whether a domain is in a jurisdiction requiring ICP filing, the DNSSEC signing and verification mechanism provides equal protection against cache poisoning and response tampering. Domain holders should assess their registrar’s DNSSEC support capabilities, ensure DS records are correctly anchored to the registry, and execute ZSK rollovers on schedule to maintain continuous trust chain validity.

Encrypted DNS Protocols: DoH vs DoT

DNS over HTTPS (DoH) and DNS over TLS (DoT) address the eavesdropping and tampering risks of traditional DNS queries transmitted as plaintext UDP packets by encrypting the transport layer. DoT establishes TLS encrypted tunnels over TCP port 853 for DNS queries, suitable for system-level deployment between network devices and resolvers; DoH encapsulates DNS query packets within HTTPS connections (TCP port 443), making their traffic characteristics indistinguishable from ordinary web traffic, suitable for browser and application-layer deployment. The two are cryptographically equivalent in security; differences lie primarily in deployment scenarios and traffic analysis resistance.

Mainstream browsers’ DoH deployment strategies have sparked privacy vs security tradeoff debates. Both Firefox and Chrome provide DoH support, but Mozilla has adopted a more aggressive “Trusted Recursive Resolver” policy, routing user DNS queries by default to designated resolvers such as Cloudflare or NextDNS, bypassing enterprise DNS policies configured by local network administrators. In enterprise network and parental control scenarios, DoH’s encryption特性 makes DNS-level content filtering and threat detection difficult to implement, creating governance tension between security management and individual privacy. DoT is more commonly deployed on the recursive-to-authoritative path within ISP and enterprise networks—its encrypted transport protects query privacy on intermediate links while preserving network administrators’ control over recursive resolver selection.

Risk Assessment Table

Compliance Boundaries

This article analyzes DNS security threats, defense mechanisms, and governance frameworks for educational research purposes. The content does not constitute investment, legal, or security audit advice. Domain holders should select appropriate security measures based on their business scenarios and comply with laws and regulations regarding DNS operations and data protection in their jurisdiction. This article’s analysis of encrypted DNS protocols does not constitute a recommendation for any specific resolver service provider; users should evaluate privacy policies and compliance credentials when choosing DoH/DoT resolver services.

References

• ICANN DNS Overview: Domain Name System core resolution mechanisms, root zone management, and ICANN governance framework. Source
• ICANN DNSSEC Explanation: DNS Security Extensions cryptographic verification mechanisms, key management, and deployment guide. Source
• NIST SP 800-81 Rev.1: DNS security deployment guide, covering DNSSEC, key management, and system hardening best practices. Source

Related Resources

• DNSSEC Deployment Analysis
• DNS Hijacking Attack Research
• DNS over HTTPS Research
• DNS Security FAQ
• Advanced: DNSSEC Deployment Practices
• DNSSEC Check Guide