3 ms·

That doesn't answer the question I asked. If you issue a DNS query to your resolver and DNSSEC validation fails, then the resolver can't trust the result it re

by danyork 12y ago

That doesn't answer the question I asked. If you issue a DNS query to your resolver and DNSSEC validation fails, then the resolver can't trust the result it received as that info could be bogus. I can't see how there is a "usable result". Am I missing something?

tptacek 12y ago
If TLS had used the same model, it would never have succeeded. You are missing something: 99.9999% of the time, DNSSEC resolver failures will be benign, and the data returned in the query not only useful but required for connectivity. When TLS was implemented, it had the benefit of being entirely new; every piece of software that TLS secured had to be modified to accommodate it, and so almost everything that implements TLS has some kind of policy switch for how to handle verification failures. But part of the pipe dream of DNSSEC is that it's a switch server operators can flip on behalf of all their millions of users. And of course that's not going to work, because different users and different sites are going to have radically different policies for when to "click through" a resolver failure. But because the code for all this stuff was written back in the 1980s, none of it supports any kind of policy lever for this problem. When a TLS certificate fails to validate, you know something went wrong with TLS. When a DNSSEC resolution fails, gethostbyname() just returns NULL, and the host falls off the Internet. You're a programmer, right? What are the implications of this problem for you users? This, incidentally, is something DNSCurve got entirely right. Unlike DNSSEC, where virtually every failure is going to be benign (because DNSSEC is even harder to administrate than TLS, where 99.9999% of failures are also benign), DNSCurve fails when attackers fuck with connections and in basically no other situations.
- danyork 12y ago
  Ah, so you don't like that DNS resolvers just return a regular SERVFAIL when DNSSEC validation fails, without some kind of indication as to why the failure occurred. I agree. I wish a failure of DNSSEC validation returned a different code or set a bit somehow so that resolvers could then know that the failure was because of DNSSEC validation. The resolver could then take action based on that knowledge. A couple of us (who were not involved in the early discussions of DNSSEC) were discussing re-introducing this idea to see what kind of traction it might get now that we've seen a good bit of DNSSEC deployment and have more operational experience.

by danyork 12y ago

tptacek 12y ago

If TLS had used the same model, it would never have succeeded. You are missing something: 99.9999% of the time, DNSSEC resolver failures will be benign, and the data returned in the query not only useful but required for connectivity. When TLS was implemented, it had the benefit of being entirely new; every piece of software that TLS secured had to be modified to accommodate it, and so almost everything that implements TLS has some kind of policy switch for how to handle verification failures. But part of the pipe dream of DNSSEC is that it's a switch server operators can flip on behalf of all their millions of users. And of course that's not going to work, because different users and different sites are going to have radically different policies for when to "click through" a resolver failure. But because the code for all this stuff was written back in the 1980s, none of it supports any kind of policy lever for this problem. When a TLS certificate fails to validate, you know something went wrong with TLS. When a DNSSEC resolution fails, gethostbyname() just returns NULL, and the host falls off the Internet. You're a programmer, right? What are the implications of this problem for you users? This, incidentally, is something DNSCurve got entirely right. Unlike DNSSEC, where virtually every failure is going to be benign (because DNSSEC is even harder to administrate than TLS, where 99.9999% of failures are also benign), DNSCurve fails when attackers fuck with connections and in basically no other situations.

danyork 12y ago
Ah, so you don't like that DNS resolvers just return a regular SERVFAIL when DNSSEC validation fails, without some kind of indication as to why the failure occurred. I agree. I wish a failure of DNSSEC validation returned a different code or set a bit somehow so that resolvers could then know that the failure was because of DNSSEC validation. The resolver could then take action based on that knowledge. A couple of us (who were not involved in the early discussions of DNSSEC) were discussing re-introducing this idea to see what kind of traction it might get now that we've seen a good bit of DNSSEC deployment and have more operational experience.