|
|
| Line 1: |
Line 1: |
| WORK IN PROGRESS | | WORK IN PROGRESS |
|
| |
| == Introduction ==
| |
|
| |
| The Domain Name System (DNS) is a fundamental component of the Internet, allowing human-readable domain names to be translated into machine-readable IP addresses. While DNS was designed for scalability, speed, and reliability, it was not initially built with a strong focus on security. This lack of security has led to vulnerabilities that are frequently exploited by attackers, necessitating continuous improvements and innovative defensive mechanisms.
| |
|
| |
| == DNS Overview ==
| |
|
| |
| DNS operates as a hierarchical and decentralized naming system that relies on multiple layers of servers—root servers, TLD servers, and authoritative DNS servers. These servers work together to resolve queries and provide the IP addresses associated with domain names. The process of DNS resolution is illustrated in Figure 1 below.
| |
|
| |
| [[File:DNS_Process.png|frameless|center|600px|caption=Figure 1: DNS Name Resolution Process]]
| |
|
| |
| '''How DNS Resolution Works'''
| |
|
| |
| A client initiates a query to its local DNS resolver, asking for the IP address of a specific domain.
| |
| If the local resolver does not have the answer cached, it forwards the query to a root server.
| |
| The root server points to the appropriate top-level domain (TLD) server (e.g., .com).
| |
| The TLD server then refers the query to the authoritative server for the specific domain.
| |
| Finally, the authoritative server provides the IP address of the domain, which is cached by the resolver for future use.
| |
|
| |
|
| |
| == DNS Vulnerabilities ==
| |
|
| |
| === DNS Cache Poisoning ===
| |
| Cache poisoning is a common attack method targeting DNS resolvers. Attackers inject fake DNS responses into the resolver's cache, redirecting users to malicious websites. By exploiting weaknesses such as predictable transaction IDs and static UDP source ports, attackers aim to impersonate legitimate DNS servers.
| |
|
| |
| To successfully execute a DNS cache poisoning attack, the attacker must:
| |
|
| |
| Spoof the source IP address to match the legitimate DNS server.
| |
| Correctly guess the transaction ID and UDP source port used in the original query.
| |
| Inject the forged response before the legitimate server replies.
| |
| The mechanics of a DNS cache poisoning attack are depicted in Figure 2 below.
| |
|
| |
| [[File:CachePoisoning.png |frameless|center|600px|caption=Figure 2: DNS cache poisoning attack process]]
| |
|
| |
| === Real-World Incident: Kaminski Attack ===
| |
| In 2008, Dan Kaminski demonstrated a critical vulnerability in DNS systems, now known as the Kaminski attack. At the time, most DNS resolvers used static source ports, significantly reducing the difficulty of cache poisoning. Kaminski showed that attackers could predict transaction IDs and ports, making it easier to inject forged responses.
| |
|
| |
| Although modern DNS systems employ randomization for both transaction IDs and source ports, attackers must now guess 32 random bits (16 bits each for the transaction ID and source port), resulting in over 4 billion possible combinations.
| |
|
| |
| == Countermeasures ==
| |
|
| |
| To mitigate DNS vulnerabilities, multiple layers of defenses have been implemented. These can be broadly categorized into name server protections and resolver-based solutions:
| |
|
| |
| === Name Server Protections ===
| |
|
| |
| DNSSEC (Domain Name System Security Extensions): Introduced in 1997, DNSSEC ensures the integrity and authenticity of DNS responses through digital signatures. However, DNSSEC adoption has been slow due to challenges such as complex key management and deployment difficulties.
| |
| DNSCurve: A lightweight alternative to DNSSEC, DNSCurve encrypts DNS queries and responses to protect against eavesdropping and manipulation. It offers faster performance but lacks DNSSEC's hierarchical trust model.
| |
|
| |
| === Resolver-Based Protections ===
| |
|
| |
| Randomization of Transaction IDs and Source Ports: Modern resolvers implement randomization to make it harder for attackers to guess query parameters.
| |
| DNSCrypt: Encrypts DNS queries and responses, ensuring confidentiality between clients and resolvers. This is particularly useful for preventing on-path attacks.
| |
| DNS-over-TLS (DoT): Encrypts DNS traffic using TLS, protecting against interception and amplification attacks.
| |
| DNS-over-HTTPS (DoH): Encapsulates DNS queries within HTTPS traffic, making it harder to identify and block DNS queries.
| |
|
| |
| == Conclusion ==
| |
| The DNS system remains a cornerstone of the Internet but continues to face significant security challenges. Vulnerabilities such as cache poisoning underscore the need for robust defenses, including DNSSEC, DoT, and other encryption-based technologies. However, securing DNS is an ongoing process, requiring collaboration between network operators, software developers, and end-users.
| |
|
| |
| == References ==
| |
| <references> <ref name="Schwenk2022Cryptography">Schwenk, J., "Cryptography and Network Security," 2022.</ref> <ref name="DNS_Sec_Survey">Khormali, A. et al., "Domain Name System Security and Privacy: A Contemporary Survey," Computer Networks, 2021.</ref> <ref name="DNS_Security_Challenges">P. Rescorla, "DNS Security Challenges and Solutions," Journal of Network Security, 2020.</ref> <ref name="DanKaminski">Kaminski, D., "The Kaminski DNS Cache Poisoning Vulnerability," Black Hat Conference, 2008.</ref> </references>
| |