unbound
unbound copied to clipboard
NLnetLabs
Use with VPNs
Hello, thanks for what you do. I couldn't find much info on the use of VPNs so I'm appealing to you for assistance. My setup on Windows 11 is working OK so far. I've firewalled off the Windows DNS service, but I am unsure whether it is still needed in my case. A certain application I use to link my phone and PC only via LAN uses mDNS, but is aggressive and also bangs its head against my firewall with SSDP , which is the purview of another service I believe so maybe I can get away with no mDNS. Don't like it much anyway.
It would be very nice if I could query through my VPN interface, but I haven't got that to work. I'm unsure whether that is considered an outgoing interface or a forward zone, or both, and whether I need to target the IP of the adapter or that of the VPN's "DNS server." Right now I have no forwarding configured and just the root server file.
The way I thought I understood the configuration, but must not, is that Unbound would receive requests on localhost:53 and query out through the port(s) specified in outgoing-port-permit (I kept the default of 32768). Judging from captures it is not using 32768 at all, but various ports all over the place. It's also listening on TCP port 8953, which I assume has some specific purpose but it not being used currently. I discovered recently that my ISP has a transparent proxy, so it doesn't matter what I set my router to. So, it looks like I'm still sending out plain UDP traffic on port 53, just to root servers instead of a DNS server, which are then intercepted by my ISP and processed?
That's not ideal. I'd like to go the option of using the VPN DNS, if possible. It has some kind of kill switch mechanism though. Barring that I suppose my only other choice is typical forwarding to a regular server with DoH or DoT?
Thanks for taking time to address my newbie questions. Have a nice weekend.
Unbound does not do mDNS. Unbound listens for requests on the port 53, and it queries out through random outgoing ports, for which a range of ports is listed in config. The randomization is important for safety. That is why you see varying port numbers. The port 8953 is the default remote-control port, unbound listens for connections from the unbound-control application, from the localhost on the commandline, where you can set parameters and give a list of commands to the running unbound server.
It depends on how the VPN is configured, I am not sure what your VPN does, eg. what traffic does it pick up and put over the VPN. If you want to have unbound send traffic over the VPN, you could try setting an outgoing-interface if the VPN picks up particular starting IP addresses. Or setting a particular forward-zone to a destination address that the VPN picks up. If the VPN instead ignores UDP, but only picks up TCP traffic, the tcp-upstream option could be used.
Also use of DoH or DoT would encapsulate the DNS traffic in another stream, much like the VPN is doing. So that would be very similar in terms of not sending plain UDP DNS traffic.
It is nice to know that Unbound works on the Windows 11 platform.
@wcawijngaards I have disabled the Windows DNS service and my software still works, so that's good. It seems to be using network broadcast to find the phone (.255) which I guess doesn't need help from DNS, and must be enough because I have SSDP firewalled. Don't know why they can't make it simple and just allow you to input an IP address, instead of spamming the network nonstop with various protocols.
If the ports are randomized by design, shouldn't the config file's outgoing port parameter only accept a range instead of single ports? The example file lists a single port.
So, on a default setup queries go out through a random TCP port, unencrypted, to the destination nameserver's port 53? My traffic may never be getting there. When I test my DNS with only Unbound and my ISP, no VPN/proxy or anything, it shows my ISP's nameserver. My router settings has static routes to the ISP's DNS servers which magically reappear if you delete them. So I have bugged hardware, the way I see it. Unbound still logs everything as if nothing is abnormal, but I think those queries are being hijacked. The technician is coming tomorrow and I'll be able to grill him about it.
I figured out how to make Unbound forward to the VPN adapter's DNS address with WireGuard. Wasn't too hard, but it sometimes throws errors. Furthermore, none of my local zones function when forwarding. It's just relaying everything on, which makes it redundant at that point.
The official Mullvad app won't connect at all after disabling the Windows DNS. It wants to lock down the routes and hijack the system DNS, and if it can't find it, it fails. It's possible to specify a custom DNS, but that's leaking my DNS back out to the ISP, when I'd rather be going into the tunnel (with my local zones working). I'll have to talk to their support, but I'll probably have to use a custom OpenVPN configuration, as they have a couple ports set aside on OpenVPN where the DNS hijacking is disabled.
I will probably end up trying TLS if the VPN DNS won't work well. I have to create some certificates and keys for that, correct? I have heard it said that DoH is actually an abuse of the HTTP protocol. Not sure how much that matters, or whether it is detrimental to performance though. I used Adguard's Do QUIC for a while, which is quite fast, but while it does filter your DNS, the Adguard client is not a reliable proxy or preventer of leaks, so I gave up on it.
Seems like I need to encrypt the queries well and avoid port 53, even on the remote side. Obviously the DNS traffic doesn't have to be on 53 to get hijacked by my ISP, though. They will grab anything they find.
Yes I'm on the latest build of Windows 11 Pro. There's a group policy option you can enable called global DNS that causes the NCSI to ping all adapters instead of just the WAN facing one, which is supposed to make the updates and whatnot work right with local DNS. Turn on global DNS to use local DNS. That definitely sounds like Microsoft.
I like to keep up to date, but in this case it may be more trouble than it is worth.