DNS Over TLS: Encrypting DNS End-To-end
code.fb.com
DNS Over TLS: Encrypting DNS End-To-end
1–10 of 28 posts
Re: DNS Over TLS: Encrypting DNS End-To-end
#2FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.
Re: DNS Over TLS: Encrypting DNS End-To-end
#3[deleted]
Re: DNS Over TLS: Encrypting DNS End-To-end
#4FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.
Thank you for this clarification. Its definitely an interesting decision. I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers.
Without a doubt, as far as security goes, DNSSEC would provide the security side - with DoT being a privacy provider. However, FB doesn't implement DNSSEC. I know there is a LOT of opinions on DNSSEC and I completely understand why they do not implement it. This just leaves me in the dark a bit as to why they did this. Anyone have insights?
Re: DNS Over TLS: Encrypting DNS End-To-end
#5FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.
Thank you for this clarification. Its definitely an interesting decision. I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. Without a doubt, as far as security goes, DNSSEC would provide the security side - with DoT being a privacy provider. However, FB doesn't implement DNSSEC. I know there is a LOT of opinions on DNSSEC and I completely understand why they do not implement…
> I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers.
You gain everything by this. Encrypting traffic from your stub resolver to the recursive resolver is meaningless if the recursive is going to send your request unencrypted to the authoritative. Recursive resolvers will send ECS data revealing your subnet and fingerprinting information, and open you up to active and passive mitm attacks.
> Without a doubt, as far as security goes, DNSSEC would provide the security side
You're comparing apple to oranges here, and DNSSEC is a far cry from total security. They are complementary; DoT provides a private and protected path to the authoritative, while DNSSEC proves origin authenticity and response correctness. But you're right in that DNSSEC is controversial and difficult to turn on.
Re: DNS Over TLS: Encrypting DNS End-To-end
#6This is absolutely wonderful. DNS has long been an easy target for attackers, and its design has been nothing but painful to retrofit with better security mechanisms the have led to incredibly low adoption (I'm looking at you DNSSEC) of better protections against forgery.
Worse still, clients that believe themselves secure using HTTPS are essentially voiding their warranty by using UDP DNS. DNSCrypt, DoH, and DoT will hopefully change all of this, and I think it says something about Facebook that they're working with Cloudflare to protect their users from the dangers of DNS. Nicely done CF and FB.
Re: DNS Over TLS: Encrypting DNS End-To-end
#7I'd rather want to see DNS-over-QUIC
Re: DNS Over TLS: Encrypting DNS End-To-end
#8Earlier quoted context omitted.
Thank you for this clarification. Its definitely an interesting decision. I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. Without a doubt, as far as security goes, DNSSEC would provide the security side - with DoT being a privacy provider. However, FB doesn't implement DNSSEC. I know there is a LOT of opinions on DNSSEC and I completely understand why they do not implement…
> I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. You gain everything by this. Encrypting traffic from your stub resolver to the recursive resolver is meaningless if the recursive is going to send your request unencrypted to the authoritative. Recursive resolvers will send ECS data revealing your subnet and fingerprinting information, and open you up to active and passive…
From operational perspective, it may be easier to maintain a certificate (after all, that's what you already do for an HTTPS service) than a DNSSEC signed zone. It is also easier if you have a multiple DNS providers, since you don't have to coordinate zone resigning. On the other hand, DoT doesn't provide the same properties (like client-side revalidation) as record level DNSSEC. It is undoubtedly an imperfect solution, but better than a perfect solution that isn't deployed. I see the two technologies as complementary, a fairly good DNSSEC deployment at the TLD level can provide a safe way for key discovery at SLD level. There are many facets to this, and it is still fairly early in resolver-to-authoritative DoT standardization process, this is just one of the first steps to show that it's feasible in real world.
Re: DNS Over TLS: Encrypting DNS End-To-end
#9FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.
Excuse my ignorance of DNS, but isn't the resolver a software component in most people's computers? For example, in GNU/Linux, I thought it'd be a part of libc and what read /etc/resolv.conf. What do you mean by connection between client and resolver?
Or are name servers like 1.1.1.1 and 8.8.8.8 what you mean by resolvers?
Re: DNS Over TLS: Encrypting DNS End-To-end
#10FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.
Excuse my ignorance of DNS, but isn't the resolver a software component in most people's computers? For example, in GNU/Linux, I thought it'd be a part of libc and what read /etc/resolv.conf. What do you mean by connection between client and resolver? Or are name servers like 1.1.1.1 and 8.8.8.8 what you mean by resolvers?
He means a recursive resolver. A stub resolver is also referred to as a client, so it's clear from context. When you connect to 1.1.1.1 you're using DoT, but not necessarily from the recursive to the authoritative.