DNS Security Basics

# CHAPTER 11

DNS Security Basics #

1. Introduction #

When Paul Mockapetris invented DNS in 1983, the internet was a small network of trusted academics and government researchers. Security was not a design priority; the protocol inherently trusts whatever answers it receives. Today, this implicit trust is a massive vulnerability. If a hacker can successfully lie to a DNS Resolver, they can stealthily redirect millions of users away from legitimate websites and into malicious traps. In this chapter, we will explore the critical vulnerabilities of the Domain Name System, understand the mechanics of Cache Poisoning and DNS Hijacking, and introduce DNSSEC, the cryptographic upgrade designed to save the internet's phonebook.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Understand why the original DNS protocol is inherently vulnerable.

• Explain the mechanics of a DNS Spoofing / Cache Poisoning attack.

• Differentiate Cache Poisoning from DNS Hijacking.

• Define the purpose and mechanism of DNSSEC.

• Recognize the severe impact of DNS-based cyberattacks.

3. Beginner-friendly Explanations #

The Fake Phonebook (DNS Spoofing): Imagine you are walking down the street looking for your bank. You ask a police officer for directions. A criminal disguised as a police officer gives you directions to a fake building painted to look exactly like your bank. You walk inside and hand your money to the robbers.

This is exactly how DNS Spoofing works. Your computer asks the network: *"Where is bank.com?"* The hacker's computer replies faster than the real DNS server, saying: *"I am the DNS server! bank.com is at IP 192.168.99.1."* Your browser goes to the hacker's IP address, which hosts a fake website that looks exactly like your bank. You type in your password, and the hacker steals it.

4. Cache Poisoning #

Spoofing one person on a coffee shop Wi-Fi is dangerous, but hackers think bigger. They target the Recursive Resolver (the massive server that does the looking up for an entire city).

1. 1. A user asks the Resolver for bank.com.

1. 2. The Resolver asks the global Authoritative Server.

1. 3. The hacker intercepts the traffic and blasts the Resolver with a fake reply: *"bank.com is at Hacker's IP!"*

1. 4. The Resolver believes the fake reply.

1. 5. The Poison: The Resolver saves this fake IP address in its Cache with a TTL of 24 hours. For the next 24 hours, *every single person in the city* who asks the Resolver for the bank will be sent to the hacker's server. The cache has been successfully poisoned.

5. DNS Hijacking #

While Cache Poisoning exploits the communication between servers, DNS Hijacking exploits the administration level. A hacker steals the password to a company's GoDaddy account. They log in and manually change the Authoritative A Record to point to the hacker's IP. The DNS protocol is working perfectly, but the truth itself has been altered at the source. The only defense against this is multi-factor authentication (MFA) on registrar accounts.

6. The Solution: DNSSEC #

To stop Cache Poisoning, the internet engineering community invented DNSSEC (Domain Name System Security Extensions).

DNSSEC does not encrypt the DNS request. Instead, it adds a Cryptographic Signature to the DNS records. It is a digital wax seal.

1. 1. The website owner uses a Private Key to stamp their A Records.

1. 2. When the Resolver receives the A Record, it uses a Public Key to verify the stamp.

1. 3. If a hacker tries to send a fake A Record, they cannot forge the mathematical stamp.

1. 4. The Resolver realizes the stamp is missing or broken, drops the fake record, and protects the user.

7. Security Awareness Examples #

The MyEtherWallet Attack (2018): Hackers successfully poisoned the DNS servers of Amazon Route 53. Users who typed myetherwallet.com into their browsers were silently redirected to a Russian server. The fake server looked identical to the real site. Users typed their credentials, and the hackers stole over $150,000 in cryptocurrency in just two hours before the cache poisoning was resolved.

8. Best Practices #

• Enable DNSSEC: If you own a domain name, you should log into your registrar (e.g., Namecheap, Cloudflare) and click the button to enable DNSSEC. It is usually free. Once enabled, cryptographic signatures will automatically be appended to your zone file, protecting your customers from MITM cache poisoning attacks.

9. Common Mistakes #

• Assuming HTTPS Solves DNS Attacks: A common misconception is that HTTPS (SSL) protects you from DNS Spoofing. It does not. HTTPS encrypts the data *after* you connect to the IP address. If DNS sends you to the wrong IP address first, you are already trapped. (However, a vigilant user will notice that the fake website's SSL certificate throws a massive red warning in the browser).

10. Mini Project: Verify DNSSEC Configuration #

You can check if a website is protected by DNSSEC using the terminal.

1. 1. Open your terminal.

1. 2. We will use the +dnssec flag with the dig command.

1. 3. Run: dig +dnssec cloudflare.com

1. 4. Look in the "ANSWER SECTION". You will see an A Record, but directly beneath it, you will see an RRSIG record. This is the cryptographic signature! Cloudflare is protected.

1. 5. Try it on a smaller, personal website. You likely will not see the RRSIG record, indicating they have not enabled DNSSEC.

11. Practice Exercises #

1. 1. Explain the mechanical difference between a local DNS Spoofing attack on a coffee shop Wi-Fi and a large-scale DNS Cache Poisoning attack on an ISP's Resolver.

1. 2. How does the implementation of DNSSEC prevent a hacker from successfully injecting a fake IP address into a Resolver's cache?

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain the vulnerability inherent in the original DNS protocol that allows Cache Poisoning to occur.

• Q: Walk me through the implementation of DNSSEC. Does DNSSEC provide privacy (encryption) for the user's query?

• Q: Differentiate between DNS Cache Poisoning and DNS Hijacking at the registrar level. How would you defend against both?

14. FAQs #

Q: If DNSSEC is so secure, why doesn't every website use it? A: DNSSEC is computationally heavy and notoriously difficult to configure correctly. If a network engineer makes a mistake updating the cryptographic keys, the entire internet will see the website as "invalid" and drop the connection, knocking the business offline entirely. Many companies view the risk of misconfiguration as higher than the risk of being spoofed.

15. Summary #

In Chapter 11, we confronted the historical trust vulnerabilities embedded in the foundation of the internet. We detailed how malicious actors exploit the unverified nature of DNS queries to execute local Spoofing and devastating, wide-scale Cache Poisoning attacks. We distinguished these architectural exploits from administrative DNS Hijacking. Crucially, we explored DNSSEC, the cryptographic upgrade acting as a digital wax seal, ensuring data integrity across the resolution chain. By understanding these threats, network engineers can architect robust defenses and recognize the critical importance of secure zone management.

16. Next Chapter Recommendation #

DNSSEC proves the data hasn't been tampered with, but it doesn't hide the data. Anyone can still read what websites you are visiting. How do we encrypt the actual question? Proceed to Chapter 12: DNS Over HTTPS (DoH) and DNS Over TLS (DoT).