Just to clarify the use of DNS over TLS (DOT)
-
@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.. -
@johnpoz
I use forwarding and it only sends a single* query with the default setting.
️*Well, there is an unrelated problem with unbound that may cause 2 sequential queries to be forwarded...
-
@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):
I use forwarding and it only sends a single* query with the default setting.
So your saying in forwarding mode - it disables that qname-min is default to yes? I don't forward so would have to test that.. But yeah that would for sure make sense not to enable qname-min when forwarding.
As to you quic thing though - yeah its still there in the clear.. If I recall they exchange keys when they first talk, but those keys are in the open so anyone that wants to decode can, and wireshark does this on its own, etc...
The qname thing is still a problem though - because there is no "gui" way to disable it, and user just looking at the settings would think its off, when its not.. The only way to turn it off when resolving is to use the custom option box and actually set it to no.
-
@johnpoz said in Just to clarify the use of DNS over TLS (DOT):
The only way to turn it off when resolving
Don't you mean the only way to turn it off when forwarding?
Won't you turn it on when resolving? -
@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):
Won't you turn it on when resolving?
maybe people don't want to do it.. It can cause some issues with cnames, especially if strict.. and now allow for fall back, etc.
When resolving I would have it on sure, but you should be able to disable it if you wanted it too.
As to forwarding seems like you can't enable it? Which would make sense I can not see a reason why anyone that forwards would ever want to use qname, its makes zero sense to do that if forwarding - so maybe when you enable forwardering qname because disabled completely?
I don't forward so would have to do a specific test for it to find out for sure.. But RobbieTT mentioned it doesn't do it, not sure what other issue he is talking about where 2 sequential queries?
-
@johnpoz said in Just to clarify the use of DNS over TLS (DOT):
...not sure what other issue he is talking about where 2 sequential queries?
As said, it is an unrelated issue but at the moment when you have a mix of IPv4 & IPv6 servers in your forwarding list unbound treats the differing address types as 2 distinct query requests and (as an additional irritant) it completes both tasks in sequentially before providing any answer to the client.
Clearly the name servers are equally capable of delivering IPv4 & IPv6 addresses but using both together provides clients different pathways, which can be advantageous. Whilst unbound has consistently fought against a Dnsmasq-like
all-serversoption to avoid the additional loading (harumph!), they have ended-up sending double the queries, despite professing the need for a single query only. Add in the 400ms rules and the 900 (90% fast, 10% slow) rules and query times can become rather odd. Again, a bit off topic here.Regarding HTTP/3 and encryption of the SNI - encrypted means just that, it is no longer sent in the clear. Of course, as a sender/observer or the target address it remains eminently visible on Wireshark.
It is also correct to say that the key exchange can be captured by an external entity (say for censorship) and worked on by software - but it is a difficult task to do at scale. Russian and Chinese censors have taken to blocking HTTP/3. A simple parry but I guess it proves some worth in HTTP/3.
Source/destination address, as I mentioned earlier, remains a vulnerability but it is not always as easy as people make out. A static IPv4 address to a static IPv4 tied to a single server is easy meat and is often the example people highlight. In reality things are often not that easy at all.
For example, many differing services routinely operate behind either a single or a brace of IPs. CDNs, reverse proxies or shared platforms complicate matters. Add in IPv6, privacy extensions and the general complications of BGP et al we quickly get to a more complicated point as to where the modern internet sits before we even contemplate node distribution, dark fibre or VPNs.
As ever, you cannot point at a single aspect of protocols, privacy and security and claim either their robustness or their fallibility. They all add layers and those layers, taken together, do add considerable value. I use what I can, when I can, whilst reaping the benefits of others paying little or no attention to such matters. Fodder for the cannon.
️ -
@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):
but it is a difficult task to do at scale
Says who?? And depends on what your wanting to do with it. While I agree might be a bit harder to scale if what your looking to do is filter/censor..
But what if that is not what after, and what after is just a list of where they are going so can sell this info, etc. Ie what the dot and doh champions have been saying your isp is doing..
I don't need to in real time decode and then make a decision of if you can go there or not.. All that needs to be done is log the traffic and decode it (since the keys are in the clear) as some later time and provide a db that user xyz (ip address) when here and here and here at these times..
Just saying - don't let smoke and mirrors about can not be scaled think your hiding anything..
-
Can unbound be set to resolve DoH ? The DoH packets should be the same except what the server it's handing that request right?
It's a DoH packet, leading to can Squid Proxy handle them and know what to look for, so it could just auto send it to unbound resolver when it sees a DoH request hit?
Right now I block a massive DoH lost.
Side thoughts: I think QBIC/HTTPS3 does the DoH over also just over UDP. That would be some epic code to write to make proxies work better.
Edited:
Unbound can resolve Dot and DoH per custom options
https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/dns-over-https.html
-
@JonathanLee said in Just to clarify the use of DNS over TLS (DOT):
https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/dns-over-https.html
How do we implement this in pfSense.? I would like to experiment with it using my NextDNS
-
@MagikMark I am just learning about this unbound feature also. It looks like it's the same as the proxy SSL intercept.
-
Epic thread here, excellent info and breakdown on Unbound. Especially interesting to see Unbound sending two queries if configured with ipv4 and ipv6 forwarding addresses, and it waits on both queries to complete before returning a response to the client. Definitely going to "fix" that one by dropping back to ipv4 forwarders on my network for now.
-
NextDNS uses this sybtax in forwarding DoT
server:
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 45.90.28.0#clientid.dns.nextdns.io
forward-addr: 2a07:a8c0::#clientid.dns.nextdns.io
forward-addr: 45.90.30.0#clientid.dns.nextdns.io
forward-addr: 2a07:a8c1::#clientid.dns.nextdns.ioMaybe DoH is something similar
However, this syntax does not forwatd device name
-
@MagikMark unbound isn't going to forward to a doh server from what I read per the link, it can act as a doh server. It would then either resolve or forward or forward with dot to what you have setup.
The only reason I can see doing such a thing, if if you want to get rid of the stupid warning that say ios devices give about local network not being private or some such nonsense. I could not for the life of me see why I would want to run doh on my private network.. Who would be intercepting the traffic - me? heheh
-
@johnpoz but did you read unbound DoH uses a library and needs certificates. The link uses interface: 127.0.0.1@443 as an example. I am thinking what is that library for? is it a list of DoH servers and when it sees one in squid it will forward it to unbound maybe? Kind of like SSL intercept, all the client wants is the address, thus with SSL intercept it should already have what it needs to reply if it's sniffed out already. Maybe I don't know I am researching this still.
-
@JonathanLee said in Just to clarify the use of DNS over TLS (DOT):
uses a library and needs certificates
Well yeah if its going to serve up dns over "https" its going to need certs.. To use for the https.
"Unbound uses the nghttp2 library to handle the HTTP/2 framing layer"
Not sure where you got the idea that unbound would talk to a doh server - this is downstream only..
"By adding downstream DoH support"
Unbound can act as a doh server..
