DNSSEC is meant to stop attackers from tampering with DNS answers. It signs records so resolvers can verify that data is authentic and unchanged. Many security teams assume that if DNSSEC validation passes, the answer can be trusted. New academic research suggests that assumption deserves closer scrutiny. Researchers from Palo Alto Networks, Purdue University, the University of California Irvine, and the University of Texas at Dallas present an analysis of DNSSEC that goes beyond bug … More → The post Formal proofs expose long standing cracks in DNSSEC appeared first on Help Net Security.
I’ve wondered at times if DNS resolution should be a vote system at the client side; one chooses a set of, say 3 DNS servers, and trusts the majority reply, reporting the dissenting one, if there is one, to some other set of observers who can then evaluate if something hinky is afoot.
Off the top of my head, this will cause client lookups to always be as slow as the slowest server, as well as increasing server loads. You could perhaps request from more than three servers and use the first replies, but then you’re increasing server loads even more and not necessarily even looking at the responses.
Also, if the error/attack is higher in the DNS hierarchy, all the edge servers would report the same incorrect data.
This is excellent work, I’m happy that these maths wizards are using their powers for good.
Is the fix as simple as saying you can’t enable both NSEC and NSEC3? Obviously, this will be problematic for clients using the disabled version.
