3 ms·

Major resolvers do DNSSEC validation. The real problem is the very low number of zones that are actually signed. Which shouldn't be an excuse for not doing DNS

Major resolvers do DNSSEC validation. The real problem is the very low number of zones that are actually signed. Which shouldn't be an excuse for not doing DNSSEC validation if only because your own zones can be signed. You know, the ones you will be constantly ssh'ing to, and blindly accept new ssh server keys from because hey, it's your zone and you trust it.

deleted 8y ago
[deleted]
tptacek 8y ago
A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security. The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC. What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside. DNSSEC is bad, which is why nobody uses it.
pfg 8y ago
Note that I was referring to client/stub resolvers specifically. Last time I checked, it was rather uncommon for them to perform their own DNSSEC validation rather than trusting the AD bit sent by their upstream resolver. In practice that means any MitM between you and your DNS resolver can spoof DNS regardless of DNSSEC status. DoH/DoT, on the other hand, mitigates this.

deleted 8y ago

[deleted]

tptacek 8y ago

A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security. The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC. What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside. DNSSEC is bad, which is why nobody uses it.

pfg 8y ago

Note that I was referring to client/stub resolvers specifically. Last time I checked, it was rather uncommon for them to perform their own DNSSEC validation rather than trusting the AD bit sent by their upstream resolver. In practice that means any MitM between you and your DNS resolver can spoof DNS regardless of DNSSEC status. DoH/DoT, on the other hand, mitigates this.