DoT vs. DoH

[Authority]

I understand why RMerlin doens't like DoH as a network admin. I also understand why Google and Firefox use DoH, not because it's better, but simply because a browser can't use DoT.

What I didn't realize that DoT was lower latency, making me rethink using DoH. I wonder why NextDNS chose DoH for their CLI client?

This was very informative. https://www.dnsfilter.com/blog/dns-over-tls/

 

[bbunge]

You also need to consider that DoH still uses DNS port 53 to find the DoH resolvers. Not too secure me thinks.

 

[SomeWhereOverTheRainBow]

NextDNS chose DoH because of how they designed their infrastructure. Their infrastructure poorly favors DoT, while highly favoring DoH connections. (It is because of bias implementation).

 

[Smokey613]

I need some clarification, does the NextDNS Merlin client use DoH only or does it also use DoT?

 

[Smokey613]

NM, found my answer.

NextDNS Installer

^^^ "Even the dry-run involves up to 10 requests per client which can be very significant when the entire release population updates." :( That certainly could be part of the RCA on the churn and instability I've seen on what was a very reliable NextDNS setup. I still especially do not like...

www.snbforums.com

 

[SomeWhereOverTheRainBow]

I need some clarification, does the NextDNS Merlin client use DoH only or does it also use DoT?

DoH is their primary platform that they use with their client. They do have DoT capable connections that offer poor performance with stubby.

 

[Smokey613]

Would the NDNS client bypass an ISP’s attempt to intercept and redirect DNS queries?

 

[SomeWhereOverTheRainBow]

Would the NDNS client bypass an ISP’s attempt to intercept and redirect DNS queries?

Most likely because the isp will not be able to manipulate or know where the dns traffic is mixed up in all that https muck. The risk comes from who sees your traffic on the inside of that https muck. Your isp still knows what you are doing though.

 

[Smokey613]

Most likely because the isp will not be able to manipulate or know where the dns traffic is mixed up in all that https muck. The risk comes from who sees your traffic on the inside of that https muck. Your isp is still knows what you are doing though.

I am thinking of installing it on a neighbors ac86u to solve the aforementioned isp dns issue. I already installed Merlin on it.

 

[Authority]

Your isp still knows what you are doing though.

How exactly?

 

[SomeWhereOverTheRainBow]

How exactly?

Through the SNI ; under regular SNI the host name is sent in plain text during the initial TLS handshake before key negotiation ever takes place so the ISP is still able to see what is going on.

 

[SomeWhereOverTheRainBow]

If you encrypt your SNI, you would be looking at different circumstances because it would become hard for the isp to know what is going on, but they have their ways still such as reverse lookups on the ip addresses of sites you visit.

 

[RMerlin]

Encrypted SNI is a fairly new technology that isn't really widespread yet.

 

[Authority]

Encrypted SNI is a fairly new technology that isn't really widespread yet.

Hasn’t Cloudflare been encrypting SNI since 2018?

 

[SomeWhereOverTheRainBow]

Encrypted SNI is a fairly new technology that isn't really widespread yet.

Hasn’t Cloudflare been encrypting SNI since 2018?

An experimental implementation of using Firefox+Dnscrypt-proxy2 built in DoH server features uses ESNI which takes advantage of an obsolete version of ECH (Encrypted ClientHello), a TLS extension to hide the server name in TLS (including HTTPS) connections.
Instructions on setting it up are on their wiki as follows.

Local DoH

dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols. - DNSCrypt/dnscrypt-proxy

github.com

This is not a full encryption though since only limited sites support it (i.e. sites running on cloudflare servers.)

 

[oOMrYairOo]

I'm using nexdns whit ax88u the latest merlin and it's working great.

 

[RMerlin]

Hasn’t Cloudflare been encrypting SNI since 2018?

You need it supported at both ends, both the server and the browser. On the server side it's almost never supported because it's not supported yet by the most commonly used TLS stack (OpenSSL).

Client-wise, I believe Firefox is the only one that supports it, and again at a beta stage.

I believe the protocol is still at a draft stage.

 

[heysoundude]

as an unbound user, I'd like to know if the auth DNS servers it goes to when an URL isn't found in the cache are DoT capable. And how to verify that, or point my rDNS to those that are in preference to those that aren't; the setup at my DNS shouldn't be insurmountable, and it would be likely the best of both worlds - anything that goes out is encrypted, just as anything that comes in should be. (these security/privacy issues are fascinating)...I'm going to pop over to the unbound thread and ask the big brains there...