4 ms·
That was a bit unnecessary hostile. The idea that communication between resolver and authoritative servers should be encrypted is not a new concept. People hav
by 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 agoI 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.
- belorn 7y agoThe reason aDoT exist is that DoT was written under a specific charter. To quote the RFC 7858: It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. There is nothing inherent of the DoT protocol that forces a model of client->recursive->authoritative. The RFC is pretty light on even mentioning recursive. It mention a technical aspect of recursive client in exactly one place, which is when discussing connection reuse for multiple requests by saying it should (not must) reuse TCP connection if possible. The RFC really just boils down to the concept of applying TLS to a tcp and udp based protocol. The DoH RFC 8484 is very different and as mentioned above there is no one who is suggesting to apply it in any form beyond as a technology between stub resolver and a recursive server. The dns-privacy IETF is quite relevant in context. If we want to be technically correct here, there is a draft RFC for authoritative servers running DoT called aDoT, with DANE as authentication. Lets imagine a DoH protocol for email where Google or Microsoft suggest that email client should ignore smtp setting and send all email to them by default, and compare that to current model that we use today where client talk securely to servers and server talk security between each other. When viewed like that, is it unfair to describe DoH as being a proxy and the model of just adding TLS as being end-to-end?