5 ms·

I have never heard anyone propose that DoH should be running in front of authoritative resolvers. DoH is strictly a recursive DNS feature where the client conta

by belorn 7y ago

I have never heard anyone propose that DoH should be running in front of authoritative resolvers. DoH is strictly a recursive DNS feature where the client contact the recursive resolver and the recursive resolver on the behalf on the client goes and gather the answers to the query. People can disagree on the terminology here but I call that a proxy. With DoT there is little reasons to not apply the same technology to authoritative resolvers. Conceptually it is almost as simple as supporting both UDP and TCP, and with the low number of root authoritative servers you can even store locally the address and certificates as part of the operating system. Since a lot of TLDs already have signed roots for DNSSEC it is even a pretty simple move forward to imagine a TLS support being enabled by them and the root. I would be amiss to not mention that Bind already store address and root zone keys of root servers as part of the install package. A bit of a tell is that there is an RFC for authoritative servers running DoT. It is called aDoT. There is no RFC for DoH, and no one is talking about aDoH. Authoritative servers running DoH is not on the map, but aDoT is. Again we can disagree on the terminology but this is the reason why I see DoH as primary a security tool for proxying DNS request while DoT can be used for end-to-end.

fanf2 7y ago
I think you are very confused about the maturity of authoritative DoT. Have a look at https://datatracker.ietf.org/wg/dprive/documents/ https://datatracker.ietf.org/wg/dprive/documents/ None of the authoritative DoT drafts have even been adopted by a working group yet, so based on the usual IETF timescales means they are probably years away from an RFC. There are still substantial problems to be worked out wrt working out if an auth server supports DoT without slowing things down horribly, and working out how to authenticate a server without getting mired in EPP and the ICANN/registry/registrar policy swamp. The threat model needs to be clarified: do we need to protect against active attacks (much more difficult and stronger authentication required) or just passive snooping (which allows opportunistic upgrade). Does TOFU make sense? So many questions still to be resolved, as it were
- belorn 7y ago
  That was a bit unnecessary hostile. The idea that communication between resolver and authoritative servers should be encrypted is not a new concept. People have been discussing and talking about it for, I would like to say decades. What it does not have is an opportunity for data collection and there is not multiple companies competing to become the central location for dns query data. There is no default setting which a company might pay a significant sum for. Like DNSSEC there is also very little to be gained by authoritative DNS server providers in return for any added complexity. Since I work in this industry I can with fair confidence say that for most registrars the added risk and complexity is the primary reason why security technology in the DNS space is not moving like it does in other areas. It used to be the same thing for email servers but googles attitude more or less changed that. If you do not support TLS then google is more likely to mark your email as spam. The cost of installing TLS is significant smaller than the cost of users email getting flagged as spam, so within a very short time window most email providers suddenly started to support TLS. Getting people to care about security is often a simple matter between risk and cost, a fact often brought up by Bruce Schneier. > Does TOFU make sense There is many potential schemes but one of the more simpler one would be to use DNSSEC and hardcode the certificates of the root servers (Authoritive server programs already hardcode some information about root servers as they rarely change). About 1398 of 1527 TLDs have signed zone in dnssec and it would cover most lookup. In theory there is nothing to prevent the root server from simply publishing TLS keys next to the NS records, with registries doing the same. Looking at how communication between email servers became TLS protected, they did not resolve all those questions and yet we went from all plaintext to almost all encrypted in a few years. As side note, let me give one example of a business concept. When you buy a domain there is usually a way to get analytics of how the domain get queried. Information like how often and from where which helps the domain owner get a perspective of how their domain get used. Let now say 80% of the traffic get routed through cloudflare. 80% of the logs are now gone. That is sad but you can buy it back If you move your DNS to cloudflare which will happy provide analytic for your domain. All Pro, Business and Enterprise plan customers will even get additional geographical information.
  - fanf2 7y ago
    I don’t mean to be hostile, I just want to make it clear that it is wrong to say “DoT is end-to-end” and wrong to say “there is an RFC for authoritative servers running DoT”. It might possibly happen at some point in the future but there is a lot of work still to do before then.

by belorn 7y ago

fanf2 7y ago

I think you are very confused about the maturity of authoritative DoT. Have a look at https://datatracker.ietf.org/wg/dprive/documents/ https://datatracker.ietf.org/wg/dprive/documents/ None of the authoritative DoT drafts have even been adopted by a working group yet, so based on the usual IETF timescales means they are probably years away from an RFC. There are still substantial problems to be worked out wrt working out if an auth server supports DoT without slowing things down horribly, and working out how to authenticate a server without getting mired in EPP and the ICANN/registry/registrar policy swamp. The threat model needs to be clarified: do we need to protect against active attacks (much more difficult and stronger authentication required) or just passive snooping (which allows opportunistic upgrade). Does TOFU make sense? So many questions still to be resolved, as it were

belorn 7y ago
That was a bit unnecessary hostile. The idea that communication between resolver and authoritative servers should be encrypted is not a new concept. People have been discussing and talking about it for, I would like to say decades. What it does not have is an opportunity for data collection and there is not multiple companies competing to become the central location for dns query data. There is no default setting which a company might pay a significant sum for. Like DNSSEC there is also very little to be gained by authoritative DNS server providers in return for any added complexity. Since I work in this industry I can with fair confidence say that for most registrars the added risk and complexity is the primary reason why security technology in the DNS space is not moving like it does in other areas. It used to be the same thing for email servers but googles attitude more or less changed that. If you do not support TLS then google is more likely to mark your email as spam. The cost of installing TLS is significant smaller than the cost of users email getting flagged as spam, so within a very short time window most email providers suddenly started to support TLS. Getting people to care about security is often a simple matter between risk and cost, a fact often brought up by Bruce Schneier. > Does TOFU make sense There is many potential schemes but one of the more simpler one would be to use DNSSEC and hardcode the certificates of the root servers (Authoritive server programs already hardcode some information about root servers as they rarely change). About 1398 of 1527 TLDs have signed zone in dnssec and it would cover most lookup. In theory there is nothing to prevent the root server from simply publishing TLS keys next to the NS records, with registries doing the same. Looking at how communication between email servers became TLS protected, they did not resolve all those questions and yet we went from all plaintext to almost all encrypted in a few years. As side note, let me give one example of a business concept. When you buy a domain there is usually a way to get analytics of how the domain get queried. Information like how often and from where which helps the domain owner get a perspective of how their domain get used. Let now say 80% of the traffic get routed through cloudflare. 80% of the logs are now gone. That is sad but you can buy it back If you move your DNS to cloudflare which will happy provide analytic for your domain. All Pro, Business and Enterprise plan customers will even get additional geographical information.
- fanf2 7y ago
  I don’t mean to be hostile, I just want to make it clear that it is wrong to say “DoT is end-to-end” and wrong to say “there is an RFC for authoritative servers running DoT”. It might possibly happen at some point in the future but there is a lot of work still to do before then.