Hello Andrew, I just want to chime in here and say that I think the current implementation of search domains is simply not working the way it should on the MacOS client.
My use case is pretty common, an internal DNS server that has entries for internal servers. I defined a search domain in the WireGuard configuration; DNS = 10.13.13.1 mydomain.internal. The search domain is for convenience, so I can just use the servername instead of servername.mydomain.internal. Now this works fine when I route all the traffic through the VPN (AllowedIPs = 0.0.0.0/0) but the search domain is completely ignored when I only route the traffic I need to (AllowedIPs = 10.13.13.0/24 192.168.0.0/24). I don't think this is a configuration error on my side. The DNS responds fine when using servername.mydomain.internal. This problem is even mentioned in the "WireGuard macOS & iOS TODO List" 9. matchDomains=[“”] doesn’t do what the documentation says. Specifically, DNS servers are not used if allowed IPs isn’t 0.0.0.0/0. The description isn't 100% accurate (or outdated), the DNS server is used but the search domain isn't being set on the primary resolver. Some have solved this issue by adding the search domains to the list of matchDomains; dnsSettings.matchDomains = [""] + dnsSettings.searchDomains. But that way the DNS server specified in WireGuard is still the primary resolver for all DNS queries. Here is a link on how OpenVPN handles this and I think it's how it should work when not using AllowedIPs 0.0.0.0/0. https://openvpn.net/faq/how-does-ios-interpret-pushed-dns-servers-and-search-domains/ On a split-tunnel, where redirect-gateway is not pushed by the server, and at least one pushed DNS server is present: - route all DNS requests through pushed DNS server(s) if no added search domains. - route DNS requests for added search domains only, if at least one added search domain. Yours sincerely, Matty -- Hi Stephen, A better solution to your problem would be to deploy DNSDIST: https://dnsdist.org/ I for one would hope that esoteric requests that address a solution for less than 1% of the users would be rejected with the overall goal of preventing feature creep and bloat. Andrew
