3 ms·
We could skip all the issues we have with DNSSEC using just the same technology and security model that TLS+WebPKI has. It is called using DNS over TLS and talk
by belorn 3y ago
We could skip all the issues we have with DNSSEC using just the same technology and security model that TLS+WebPKI has. It is called using DNS over TLS and talking directly with the authoritative server rather than using caching resolver. With no (non-local)caching you don't have any caching invalidation for keys which is one of the major problems in deploying dnssec.
Severs talking to servers do have a bit different handling of errors than browsers. A browser can ask the users if they want to ignore the error, but with a server the answer need to be to close the connection. If the certificate for the DoT server is broken then the domain goes down, just as a TLS+WebPKI SaaS service will break with broken certificates. The impact however will be just as major as with dnssec errors.
I have personally tried to advocate a bit that people should give up public/shared revolvers. The delay in response time in modern machines quite minor, and in term of loading a web page or sending a email, a few milliseconds here and there doesn't really have a large impact. My argument for that has primarily been about privacy and security (no insecure path between stub and resolver), but I have not considered in the past the major benefit of removing caching in terms of stability.
- tptacek 3y agoThis is false! The point isn't that TLS 1.3 is a better protocol that DNSSEC (though: it extremely is). It's that the entire WebPKI ecosystem has features DNSSEC does not have, has no timeline towards having, and probably never will have, because DNSSEC is de jure controlled by sovereign countries who will not agree to a global transparency log.
- belorn 3y agoI think you are missing the whole point of what is being suggested. There is no DNSSEC if clients are talking directly with authoritative services using DNS over TLS. No signatures, no sovereign countries who controls keys, not anything which is defined by the DNSSEC. Once a client is securely connect to an authoritative service using TLS, everything that the server is transmitting is by definition authenticated. The client need to traverse the tree of authoritative servers by itself, but that is the only drawback.