DNSSEC is a great concept with a rather convoluted design that's based on limitations of computers in the 90s. It's obviously better to have DNSSEC than not to, but I wouldn't call it a "great solution".
Case in point: the DNS client never actually validates the DNSSEC signatures, the DNS server the client uses is supposed to do that, and then simply sets a flag that says "I validated this". Perfect for recursive DNS resolvers running on localhost, but terrible for security when applied as designed.
Another example: Firefox currently has encrypted client hello enables to encrypt the SNI information and help combat traffic analysis, but only if you enable DoH to ensure that the necessary DNS records are correct. Once again, Mozilla didn't trust DNSSEC to work right and opted to trust DoH servers on their word.
In truth, DNSSEC isn't widely used, at least not internationally. Some TLDs have high DNSSEC usages, often because their registrar advocates for securing DNS, but with companies like Amazon failing to produce DNSSEC software that doesn't cause massive outages and TLDs like .nz going down for a day because of bad policies and management, many people don't bother.
It's a shame, really, because DANE would've fixed so many problems. I attribute its failure mostly to the design decisions the people behind DNSSEC made when they released the protocol.
> It's a shame, really, because DANE would've fixed so many problems.
It would basically make services like Let's Encrypt unnecessary and would move us close to a world where email encryption and validation works by default.
It would take us to a world where the only CA you can and have to trust is the TLD operators and their nation. Where transparency is mostly an afterthought and violators can't be forced to do anything.
Case in point: the DNS client never actually validates the DNSSEC signatures, the DNS server the client uses is supposed to do that, and then simply sets a flag that says "I validated this". Perfect for recursive DNS resolvers running on localhost, but terrible for security when applied as designed.
Another example: Firefox currently has encrypted client hello enables to encrypt the SNI information and help combat traffic analysis, but only if you enable DoH to ensure that the necessary DNS records are correct. Once again, Mozilla didn't trust DNSSEC to work right and opted to trust DoH servers on their word.
In truth, DNSSEC isn't widely used, at least not internationally. Some TLDs have high DNSSEC usages, often because their registrar advocates for securing DNS, but with companies like Amazon failing to produce DNSSEC software that doesn't cause massive outages and TLDs like .nz going down for a day because of bad policies and management, many people don't bother.
It's a shame, really, because DANE would've fixed so many problems. I attribute its failure mostly to the design decisions the people behind DNSSEC made when they released the protocol.