Possibility of a DNSSEC attack

Question

I start learning about DNS and DNSSEC. I discovered DNSSEC work similar to a PGP signature. A piece of data signed by a key and the key signed by another key. So, I have an attack might work with some assumption, but I want some validation will this work.

Assuming an attacker had intercepted a network, and able to manipulate the packet. A client request a DNS record from Google's public DNS. DNS responses with legit answer. Now the attacker intercept the response packet, modify the answer and remove any DNSSEC related information. Client directed to attacker's site.

The attack basically remove the DNSSEC related information. Since client doesn't have any info to verify the data, it only can trust and connect the IP address within the DNS answer. And the attacker don't need to spoof the target domain and its parent because it is just a simple subtraction.

Is this attack possible or DNSSEC have some kind of mechanism to prevent this happen?

Answer 1

There's a chain of trust that stops this:

The DNS root itself is signed with DNSSEC. This is well-known to clients that support DNSSEC at all. When the DNS root provides records about (e.g.,) the .com domain, its response will include a DS record to indicate that that domain should be signed as well. This works again at subsequent levels: the .com domain will provide a DS record to indicate that example.com is supposed to be signed with DNSSEC.

Because of this, an attacker who removes any DNSSEC record will break the validity of the previous level's DNSSEC, and removing DNSSEC from the root is a clear signal that tampering has occurred.

Caveat: the above only works if every piece of the domain is signed. If example.com isn't signed but secure.example.com is, the attack you're describing does become possible unless the resolver knows of the trust anchor for secure.example.com.

Sources:

• https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#The_lookup_procedure
• https://technet.microsoft.com/en-us/library/dn593672(v=ws.11).aspx