Just to clarify the use of DNS over TLS (DOT)

A Former User

I am currently forwarding to quad9, using unbound in forwarding mode and TLS port 853.
The chosen behavior is use local DNS (127.0.0.1), ignore remote DNS server.
Even though I put the 2 quad9 DNS servers in my DNS servers list.
This gives me this list:
DNS server(s)
127.0.0.1
149.112.112.112
9.9.9.9
Doing that, along with these checked options:
-Hide Identity id.server and hostname.bind queries are refused
-Hide Version version.server and version.bind queries are refused
-Query Name Minimization Send minimum amount of QNAME/QTYPE information to upstream servers to enhance privacy

ALL my DNS request are encrypted and no SNI information (the server name I'm asking an address for) is revealed.
Only the name of the quad9 DNS server name is revealed in the packets.
THAT is what I call privacy.

Am I wrong?
Why please?

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

Query Name Minimization Send minimum amount of QNAME/QTYPE information to upstream servers to enhance privacy

That sure isn't going to be optimal if your forwarding - that only makes sense if your resolving.. That if would even work would require multiple queries.. You should not have that set if forwarding.

That only works when you resolve by asking roots for just the ns of the .tld, and then asking the gltd server of that .tld for the domain.tld, then you ask the authoritative ns for that domain.tld for whatever.domain.tld

Those other two options are just for clients talking to unbound, unbound will hide what dns server your running from the client - kind of really pointless to be honest, unless you were serving dns to unknown clients, etc. Why would you care if your clients could find out that your running version X of unbound?

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "unbound 1.17.1"

Oh no - my clients, that I manage and allow on my network can figure out I am running 1.17.1 of unbound..

THAT is what I call privacy.

Until you go to that IP you just looked up and the sni is in the clear in the ssl handshake.. That is what I call a false sense of security if you think your hiding where you are going from your isp ;)

If you are going to do dot, the one thing I would make sure you uncheck is doing dnssec - since it is pointless when you forward. Where you forward is either doing dnssec or its not. And quad9 has clearly stated doing dnssec when you forward to them can cause problems.

https://support.quad9.net/hc/en-us/articles/4433380601229-Setup-pfSense-and-DNS-over-TLS
Disable Enable DNSSEC Support if enabled.
DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures.

A Former User

Thank you for your precious time and knowledge.
I am going to disable the settings you point out, and check the results. Every gain in performance would be welcome. Thank you.
DNSSEC is already disabled.

From my point of vue, I never see the name of the destination server I just looked up. Only the name of the DNS server I am talking to.
Like in your example: you seem to be talking to a DNS server with the address 44.199.138.71 using HTTPS.
Maybe we dont understand each other. I don't care if the name of the DNS server I talk to is in the clear (9.9.9.9 dns.quad9.net for me). Only the server name of the destination given by the DNS server (quad9 in my case). Like seeing amazon.com in the packet if I were to go to that site.

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

with the address 44.199.138.71 using HTTPS.

No that is the server I was making a ssl connection too.. And that is the fqdn I was wanting to talk too.. Sure you can hide that actual dns query from your isp via dot.

But when you actually go to make the connection, the fqdn your wanting to talk to is in the clear inside the ssl handshake.. Your not hiding that you looked up www.amazon.com from your isp, they just need to look in a different place.

Until esni, or now ech (esni died before it went anywhere) and the sni is actually encrypted - your not really hiding anything by using dot.. your just making it a tiny bit harder for them to find the fqdn you are going to..

edit: here is me going to amazon.com - this is part of the ssl handshake, this is the client hello where in the clear its called out what fqdn your wanting to talk too.. Just like your dns query.

until such time that the sni is encrypted - doh and dot are for sure not providing the "privacy" they pretend they are.. But you for sure are doing is handing all your dns over to someone else on a silver platter..

Not saying they don't have uses - but don't kid yourself in thinking that your isp doesn't know where your going, sure hiding where your going in some CDN cloud that hosts 1000's if not 100s of thousands of sites might give you some cover.. But simple sniff of the ssl handshake and they know exactly what fqdn your wanting to talk to..

A Former User

I understand what you are saying.

But again, please understand this: I never can find the fqdn I am wanting to talk to in the clear inside the ssl handshake, using my setup and using the string search function of wireshark. And yes, I capture the whole packets.

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

setup and using the string search function of wireshark

to search for it you would have to do something like this.. Here I filter my capture to just client hello's

then I add a colum to just show that specific info

Or directly look in the client hello like I posted.

A Former User

There is an easier method than that called "Find a packet", but there you go:

johnpoz

@marchand-guy that is exactly what I said ;) you just called your colum fqdn dest, vs server name..

that is your packet 443 traffic to yoru dot server.. sniff your other traffic to say amazon.com

Clearly you know how to find the info.. Your just not looking at your other traffic. If your 443 traffic to dot server shows the fqdn, why would you think some other client hello to say amazon.com or google.com or netgate.com would not also show the fqdn in the clear..

Which was my whole point. Where you go is in the clear, until such time that encrypted sni becomes a thing across the internet..

BTW: that is a lot of session setups to your dot server, it should be reusing the same session.. opening that many ssl sessions sure and the hell not very efficient. You have 10 different sessions being setup in 15 seconds?

I know there was an issue with old version of unbound that it didn't reuse the session, but that was a few versions back when they changed that. from my understanding from unbound docs, I believe its suppose to be able to reuse the session for like 60 seconds.. Creating a new session for every query would be horrible performance..

A Former User

Damn! Now I understand what you were saying all along.
Sorry for being dense.
DNS resolution (encrypted or not) is one thing.
Accessing the destination after that, is another. And unless you use a VPN, HTTPS will always show the name of the destination (SNI) in the clear.

And thank you for spotting the communication issues I seem to have.
I will look into it further, because yes, I have some slowdowns...

Thank you, again.

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

HTTPS will always show the name of the destination (SNI) in the clear.

Exactly - until such time that whole of the internet adopts some form of encrypted sni, there was an attempt with esni, that crashed and burned.. now the latest is ech (encrypted client hello).. But for that to work, every site hosting https services would have to enable it ;) So not going to happen anytime soon that is for sure hehehe

edit: the problem with any form of encrypted sni, is the hoster - why should they bother to enable it.. Its more work, it will be more resources their boxes have to expend to serve traffic, just one other thing that could break and take their site offline, which if site is selling something, or even just serving ads could mean lost revenue..

I don't really see it taking off like a rocket ship that is for sure, if adopted - its going to be a slow grind.. Some of the major hosters like cloudflare or something sure could make it so its default or even click a button. Like they do with dnssec on your domains. But for it to reach any sort of major deployment going to be a slow crawl that is for sure..

Shoot how many sites have moved to tls 1.3? even ;) If you want a slow crawl for change just look at ipv6..

dnssec should be on every domain, its % of use is horrible... Changes like this are slow to take hold.. dnssec is another one of those why should I enable it - its just something that could fail, and prevent my users from getting to my site.. So its adoption has been lack luster that is for sure.

A Former User

I like your way of thinking.

I need to rethink my communications stategy. If using DOT with quad9 is causing me delays, and my HTTPS communications are showing my destinations anyway, maybe I should try cloudflare to try isolating the DOT problems to quad9, or drop DOT altogether and get back to resolver without forwarding and ticking the maximum of options available to minimize the infos going out.

edit: I could try going full VPN from my router, but that's opening a can of worms...

RobbieTT

@johnpoz said in Just to clarify the use of DNS over TLS (DOT):

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

Query Name Minimization Send minimum amount of QNAME/QTYPE information to upstream servers to enhance privacy

That sure isn't going to be optimal if your forwarding - that only makes sense if your resolving.. That if would even work would require multiple queries.. You should not have that set if forwarding.

The default setting in unbound is to apply qname-minimisation: yes.

The monsters only bite you if you select the option of qname-minimisation-strict: yes but the unbound default is set to : no.

There is also the option to set tls-use-sni: no. The default setting is a more reasonable : yes.

️

A Former User

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

set tls-use-sni

No such option on my installation (pfsense 2.6 CE) in resolver settings

johnpoz

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

The default setting in unbound is to apply qname-minimisation: yes.

since when? I just looked at clean install of 2.6 and that is not enabled.. Why it could be default, it sure wouldn't make sense if you were forwarding.

That might be the default for unbound, but default settings on pfsense would not to do that.. Unless they changed something recently?

tls-use-sni: no.

That would have zero to do with clients creating a connection to say amazon.com, etc., That would have more to do when forwarding to some sort of specific dot server..

RobbieTT

@marchand-guy You can go pure CLI for unbound configuration but the pfSense GUI gives you a custom options box where you can add configuration settings.

️

RobbieTT

@johnpoz said in Just to clarify the use of DNS over TLS (DOT):

since when? I just looked at clean install of 2.6 and that is not enabled.. Why it could be default, it sure wouldn't make sense if you were forwarding.

That might be the default for unbound, but default settings on pfsense would not to do that.. Unless they changed something recently?

As far as I tell, pfSense picks up the default unbound settings, unless there is a variance to them - this is why the pfSense unbound config list is so small. If the config option is not explicitly set in pfSense then the unbound defaults rule.

 qname-minimisation: <yes or no>
              Send  minimum  amount  of information to upstream servers to en-
              hance privacy.  Only send minimum required labels of  the  QNAME
              and  set  QTYPE  to  A when possible. Best effort approach; full
              QNAME and original QTYPE will be sent when upstream replies with
              a  RCODE other than NOERROR, except when receiving NXDOMAIN from
              a DNSSEC signed zone. Default is yes.

As ever, I'm willing to be corrected.

️

johnpoz

@RobbieTT look at the setting in the gui - its not set, so your saying in the gui being not checked to enable it - would actually mean its doing it.. That would be a bug that should be corrected then, because when not set it just doesn't put in the setting if unbound defaults to yes then there would be no way to turn it off.

Now if there is no gui option for, ok then it would make sense to use the unbound default.. But there is a clear gui setting for qname - and it defaults to not being enabled. If unbound was actually doing it, then it would be BUG that should be fixed..

So looking at my 2.6 config, it doesn't have it.. And it defaults to yes, then it would be on.. But how would I turn it off? Since just clicking enabled, and then disabled just removes the setting..

There is no setting in /var/unbound/unbound.conf for qname.. I have it enabled on my 23.05 and it places this in the conf

qname-minimisation: yes

If unbound now defaults that to yes.. Then yeah there needs to be a redmine put in - because there would be no way to disable from the gui... I just enabled and see the yes in the conf.. Then unchecked it and the whole qqname-minimisation line is gone. So if it is now defaulting to qname -- that is problem..

I will validate that default is now yes in unbound on version that is on 2.6, which is Version 1.13.2, then should prob look on 23.05 and 2.7 snap shots.. if unbound is now defaulting to yes on qname then the logic in the gui needs to be adjusted so you can actually turn it off..

 qname-minimisation: <yes or no>
              Send  minimum  amount  of information to upstream servers to en-
              hance privacy.  Only send minimum required labels of  the  QNAME
              and  set  QTYPE  to  A when possible. Best effort approach; full
              QNAME and original QTYPE will be sent when upstream replies with
              a  RCODE other than NOERROR, except when receiving NXDOMAIN from
              a DNSSEC signed zone. Default is yes.

Yeah its doing it by default.. If I put in in the options box then it doesn't do it..

server:
qname-minimisation: no

redmine created
https://redmine.pfsense.org/issues/14479

edit: ok just tested on 23.05, yeah its doing it even when you uncheck to do it in the gui, it just remove the line to do it in the conf.. which it then does it by default..

RobbieTT

@johnpoz Thanks, I hadn't noticed that at all; it does seem a bit odd.

Other settings via the Resolver GUI do populate faithfully across to the /var/unbound/unbound.conf file.

Learning as we go. No doubt there is more to be uncovered.

️

RobbieTT

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

Accessing the destination after that, is another. And unless you use a VPN, HTTPS will always show the name of the destination (SNI) in the clear.

Things are improving with HTTP/3 as there is very little outside of the encryption, so the actual name has gone from clear text. Of course, you still need an address to route to and that will always be there. In IPv6 land the source and destination probably has a privacy address in place but the prefix may still paint a picture:

2023-06-16 at 18.36.05.png

️

johnpoz

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

Other settings via the Resolver GUI do populate faithfully across to the /var/unbound/unbound.conf file.

To be honest this qname thing is kind of a issue to be sure, hey if your resolving its not really a change in the number of queries.. But if your forwarding and you do qname min its going to cost many queries when there should only be 1..

If I want to look up say host.domain.tld.. and I want to ask quad9 for that - asking it just for .tld or just for domain.tld are wasted queries that only take time to not work, and then finally ask for host.domain.tld

qname min should never be enabled if your forwarding..

And if there is some other thing going on and your creating multiple tls sessions vs just 1 and using it for multiple queries.. It can add up to poor performance..

edit:
To your http3 or quic point.. While the first connection might be encrypted - pretty sure those keys are visible, so you can decode and still get the sni if you wanted to..