2

I just watched a video on DNS that explained that if there is a man-in-the-middle or if someone has taken over your resolver, DNSSEC can prevent the responses from being tampered with because the client can verify that the owner of the zone has signed the resource records. I think I have a grasp of the basics of how DNSSEC works.

There is one thing I don't understand though, the optional nature of DNSSEC.

Because DNS-sec is optional, is there anything that prevents the main-in-the-middle from crafting a malicious response and claiming that DNSSEC isn't supported in that zone?

schroeder
  • 129,372
  • 55
  • 299
  • 340
Nasso
  • 23
  • 2
  • No, this attack won't succeed, because of the hierarchical nature of DNSSEC. For example, if an attacker tried to poison a local DNS resolver with fake records for stackexchange.com, and cover their tracks by removing the DNSSEC records, the client would detect this anomaly when it requests the DS record for stackexchange.com from the next zone up in the trust chain (in this case, the .com TLD), and finds that there is in fact a valid DS record for stackexchange.com, and therefore, the DNSSEC should be enabled for stackexchange.com. – mti2935 Jan 26 '24 at 14:38
  • 1
    @mti2935: An on-path attacker can muck with the results of queries against the TLD too. – Ben Voigt Jan 26 '24 at 18:11
  • @BenVoigt True, but then the client would detect an anomaly when it requests the DS record for the TLD from the next level up from the TLD - unless that was mucked with too. This chain would continue, all the way up to the root zone, which is the anchor of trust for the entire DNSSEC system. To safeguard against an attack of this nature, the client should have authenticated the root zone's public key, and should verify the entire signature chain up to this key. – mti2935 Jan 26 '24 at 18:42
  • 2
    @mti2935: The important consideration, then, would be whether a DNSSEC-capable client accepts an ordinary (plain DNS, no signature or other DNSSEC features) response for a query to the root zone. If it accepts it, it creates a possibility for a downgrade attack. If it rejects it, it won't be backward-compatible with older existing forwarding/caching DNS servers. – Ben Voigt Jan 26 '24 at 19:44
  • @BenVoigt That's a good point (+1). I think the solution is for DNSSEC-capable clients to 1) not accept an ordinary (plain DNS, no signature or other DNSSEC features) response for a query to the root zone; and 2) use a DNS resolver that complies with RFC4035. – mti2935 Jan 26 '24 at 19:58
  • @Nass0 the answer you accepted was entirely AI-generated. I was just purging the user's answers. Please let the community weigh in to determine if the answer is true at all. – schroeder Jan 27 '24 at 22:53
  • Yeah, the answer you accepted doesn't actually answer what you asked. – schroeder Jan 27 '24 at 22:56
  • @schroeder I think it did. It made it clear that the optional nature of DNCSEC doesn't prevent this problem. I was happy with the answer. – Nasso Jan 30 '24 at 08:22

0 Answers0