Securing DNS
Sign the answers, encrypt the queries, and watch the traffic you cannot stop.
What you will learn
- -Explain what DNSSEC proves and what it deliberately does not
- -Choose between DoH and DoT and know the operational trade-off
- -Use sinkholing and query logging to blunt and detect DNS abuse
The attacks in the last lesson all the same two gaps: you cannot tell if a answer is authentic, and you cannot tell if it was tampered with in transit. Three families of defense close those gaps from different angles. None of them does everything, and pretending one does is how people build a false sense of safety.
DNSSEC signs the answers
DNSSEC adds cryptographic to DNS records. The zone owner signs each record set with a , publishes the in the zone, and a validating resolver checks the signature before trusting the answer. A chain of trust runs from the down through the TLD to the zone, so a resolver can verify the whole path.
What that buys you is integrity and authenticity. A poisoned or forged record fails signature validation and gets thrown out. Kaminsky-style poisoning simply stops working against a validating resolver on a signed zone.
Be precise about what DNSSEC does not do. It does not encrypt anything. Every query and answer is still on the wire, so anyone watching sees exactly what you looked up. DNSSEC proves the answer is real; it does not keep it private.
$dig example.com +dnssecDoH and DoT encrypt the queries
is the other half, and it is a separate mechanism. DoT, DNS over , wraps DNS in a TLS tunnel on 853. DoH, DNS over , tunnels it inside ordinary HTTPS on port 443. Both hide your queries from anyone sniffing the local .
The difference is operational, not cryptographic. DoT rides its own port, so a network admin can see DNS-shaped traffic and manage it. DoH hides inside the same 443 as all your web traffic, which is great for user privacy against a hostile network and a genuine headache for a defender trying to enforce DNS or spot tunneling. Neither one authenticates the record the way DNSSEC does; they protect the channel, not the contents' truth.
DoH is a privacy win for users and a monitoring gap for defenders. increasingly uses DoH to hide its lookups inside normal HTTPS, right past the DNS logging a relies on. When you deploy encrypted DNS on a network you defend, pin to a resolver you run or trust, so you keep the instead of blinding yourself.
Sinkholing and monitoring
Signing and encryption are prevention. You still need to see what is happening and be able to break a connection when it goes wrong.
Sinkholing answers a known-bad with an address you , usually a dead-end or a monitoring . A device asking for a malware C2 domain gets your sinkhole instead of the real , so the callback fails and you an with the source IP. Response Policy Zones (RPZ) on BIND, or a Pi-hole in a small setup, both do this by overriding answers for a blocklist.
Logging is the piece people skip and regret. Query logs are the single richest record of what every host on a network is trying to reach.
$grep 'query:' named.log | awk '{print $NF}' | sort | uniq -c | sort -rn$awk '{print length($6), $6}' queries.log | sort -rn | headwhat your network normally resolves. Then a domain registered yesterday, or a burst of long random subdomains, stands out against the noise instead of hiding in it.
A client uses a validating resolver on a DNSSEC-signed zone, over plain UDP. What protection does it have, and what does it lack?
You sinkhole a known malware C2 domain to an internal monitoring host. Beyond blocking the callback, what does that give your response team?
The failed connection is only half the value. Think about who you learn is compromised the moment they ask.