The attack fails
Your laptop asked the resolver for www.example.com. The resolver has already followed the referrals, so it asks ns1.example.com directly. It sets the DO (DNSSEC OK) bit, which means: send the signatures too.
An attacker floods the resolver with fake replies, exactly as in the cache-poisoning lesson. They claim www.example.com is at 198.51.100.66. One fake guesses the right query ID and port and arrives before the real reply.
This resolver validates. The fake reply has no signature that example.com's public key can verify, and only the zone's private key can make one. So the reply is marked bogus: the resolver throws it away and caches nothing.
How the seals work
How does the resolver know? Each zone keeps a private key and publishes the public half as a DNSKEY record. Beside every set of records it publishes an RRSIG: a signature anyone can check with that DNSKEY.
But an attacker could publish a key of their own. So each parent zone publishes a DS record, a fingerprint (hash) of its child's key, and signs it. The root vouches for .com; .com vouches for example.com.
The chain has to start somewhere. The resolver trusts exactly one key in advance: the root zone's key, built in as its trust anchor. Every other key is trusted only if a chain of DS links leads back to it.
Checking the real answer
The resolver asks again and the genuine reply arrives: www.example.com is at 203.0.113.10. Next to the record rides its RRSIG, made with example.com's private key.
The RRSIG checks out with example.com's DNSKEY. That key matches the DS that .com signed; .com's key matches the DS the root signed; the root's key matches the trust anchor. Every link holds, so the answer is secure.
The resolver hands your laptop 203.0.113.10 with the AD (authenticated data) flag set. DNSSEC proved nobody changed the answer. It did not hide it: DNSSEC gives integrity, not privacy.
Encrypted DNS
Ordinary DNS travels over UDP port 53 in plain text. Anyone on the path, like a stranger on the same café Wi-Fi, can read every name your laptop looks up. Signatures do not change that.
DNS over TLS (DoT) wraps the queries in an encrypted TLS connection to the resolver on port 853. The eavesdropper can tell that DNS is being used, but not which names you ask for.
DNS over HTTPS (DoH) sends each query as an HTTPS request, usually on port 443, so it blends in with web traffic. Both protect only the trip to the resolver; DNSSEC still proves the answer itself.
The records, field by field
;; step 1/12 · ask-signed · query ;; Validating resolver → example.com query resolver → ns1.example.com (192.0.2.53), UDP/53 id random 16 bits, from a random source port (RFC 5452) flags QR=0 RD=0 EDNS0 DO=1 (DNSSEC OK, RFC 3225) question www.example.com. IN A
A validating resolver that receives a reply that fails validation may ask the same or another server again; if nothing validates it returns SERVFAIL instead of an unverified answer (RFC 4035 §5.5). Encrypted DNS protects only the hop between your device and the resolver. The resolver still sees every name, and its own queries to authoritative servers are usually plain text.