Client DNS doesn't resolve when using VIP in place of interface IP

jimp

Unfortunately that appears to break DNS over TLS service. With it set to yes, unbound does not bind to port 853.

So for now we may just have to chalk this up to a limitation of unbound. Might need to add a warning in the GUI and docs at least.

ttmcmurry

@jimp said in Client DNS doesn't resolve when using VIP in place of interface IP:

Did you try TLS-enabled queries or just regular ones? Or both?

I tested regular over 53. I'm switching to ubuntu to test dns over tls via DIG or kdig/knot.

jimp

I tested with kdig but that wasn't necessary, really. Checking sockstat | grep unbound on the firewall showed it wasn't bound to 853. When I reverted the change and let it stay on no, it bound to 853 and a kdig query worked.

There is already a warning in the GUI about this under the Enable SSL/TLS Service option but perhaps it could be stronger or better worded.

The DNS Resolver docs haven't been updated yet with any of these settings, but when I get to that point I can add stronger warnings as well.

ttmcmurry

@jimp

Confirmed your results 100% the same with 53/853 with ssl yes/no via the patch.

When I revert the patch, then manually specify the DNS Resolver Network Interfaces with SSL/TLS enabled, both 53 & 853 requests resolve on a VIP; 853 binds to unbound.

Thank you for your time on this, I understand what's happening and how to address it. At least I took time to RTFM before posting in the forum .

jimp

If nothing else it was worth checking again if unbound solved that limitation in the last 3 years

johnpoz

@ttmcmurry said in Client DNS doesn't resolve when using VIP in place of interface IP:

853 binds to unbound.

While this is a off topic question.. I am curious.. In what scenario would you be using dot locally? I don't get the use case..

Why would you want client or even downstream dns in your own network to use dot? Who on your own network would be intercepting or interfering with your dns. I really for the life of me see no valid use case for doing this on a local network.. Is it to remove some stupid warning on a device that your local network is not secure - because its not using dot or doh?

I could see the functionality for unbound, if it was used as an upstream dns where the clients of said dns transit to it over over a public or hostile network. But I don't get it why this is something you would want to do over you own local network to your own local dns.

I guess it should work - if so desired ;) But I don't see use case, other than lab or play..

ttmcmurry

@johnpoz

For DoT - In my case, it's pure lab work. Networks behind networks, behind application delivery appliances & virtual routers. I'm also testing Win10's native DoT capability for plans down the road - not just browser-based DoT that's present in Chrome and Edge, which works a bit differently than at the OS level.

I completely understand why using DoT inside a private network may be viewed as unnecessary. Generally speaking, I see more apps in the wild attempting to use DoT opportunistically - particularly in mobile device apps. The thought here is have it working anyway in case a device starts using it.

For upstream DoT - and I'm calling out AT&T right now - their Gateways intercept and rewrite DNS queries to go through their DNS servers - purely for the purpose of data gathering on customers. The gateways also prohibit changing DNS servers, The only way around it is to use DoT from pfSense or PiHole .. something that sits between the internal network and the gateway itself.

I feel I must mention I work in the financial sector, so it pays to be as forward thinking as possible with security and follow zero trust models in every scenario. At this point, almost all the work I do with networking assumes nothing is trustworthy and never will be - so it is necessary to integrate technologies that look for bad actors at all possible network node locations; utilize SIEM and analysis tools; layer2-7 inspection, etc.

jimp

Usually the cases are:

Situations where you may not trust the security of the local network (e.g. guest network wireless which is unencrypted, or cases where a network is forced to use wireless protocols which may not be fully secure against decrypting traffic from other associated clients)
You want to intercept local client DNS over TLS queries (and hope they don't validate the hostname...)
General paranoia and/or "cool factor" of it

I'm sure there are more, but it isn't something most people will probably need to have enabled.

johnpoz

@jimp said in Client DNS doesn't resolve when using VIP in place of interface IP:

ou want to intercept local client DNS over TLS queries (and hope they don't validate the hostname...)

That one makes the most sense to me ;) I could see wanting to do that for sure - for all of these devices that might be trying to sneak dns over dot or doh..

Thanks Jim - those 3 are all valid.. First one I don't see, unless you were wanting to offer your guest clients a way to use your dns, and don't provide other protection from other clients on your wifi, ie your wifi is completely unencrypted..

jimp

@johnpoz said in Client DNS doesn't resolve when using VIP in place of interface IP:

First one I don't see, unless you were wanting to offer your guest clients a way to use your dns, and don't provide other protection from other clients on your wifi, ie your wifi is completely unencrypted..

It's more about business cases here (hospitality like hotels, coffee shops, etc) which have to cater to the lowest common denominator clients.