The functionality in [mac,i,iPad]OS that enables zone-based split DNS is quite powerful, and Stephen's contribution would fit my use case as well.
I use a specific DNS resolver of my choice, but having Wireguard able to automagically resolve "host.corp.internal"-style FQDNs when the relevant Wireguard connection is up would be a huge win, not only for me but for corporations with split-horizon DNS which want to implement Wireguard without having to route irrelevant traffic into that tunnel. > On 29 October 2021 at 22:07, Stephen Larew <[email protected]> wrote: > > >> >>> On Oct 29, 2021, at 10:03, Andrew Fried <[email protected]> wrote: >>> >>>> On Oct 29, 2021, at 08:33, Stephen Larew <[email protected]> wrote: >>> >>>> On Oct 28, 2021, at 02:58, Bruce Ferrell <[email protected]> wrote: >>>> >>>> On 10/28/21 12:16 AM, Stephen Larew wrote: >>>>> For many months now, I have been running a patched WireGuard macOS app >>>>> that enables a split DNS configuration. I would like to try to upstream >>>>> my patches for split DNS. >>>>> >>>>> There has been some interest in this patch: >>>>> - "Mac APP DNS Search Domain" thread from July and August 2021 [1] >>>>> - A commenter on my GitHub fork of wireguard-apple. >>>>> >>>>> What is split DNS? It allows sending DNS queries to a specific server >>>>> based on the domain name. Systemd-resolved calls it a routing domain. >>>>> Apple's Network Extension framework calls it a match domain. Split DNS >>>>> is especially useful for internal DNS servers. >>>>> >>>>> For example, if corp.example.com is a routing domain for the DNS server >>>>> at 192.0.2.1 (only accessible over WireGuard), then >>>>> server.corp.example.com is resolved using 192.0.2.1 while >>>>> www.example.com is resolved using some other DNS resolver (depending on >>>>> the other network settings in macOS). >>>>> >>>>> The proposed patch adds new syntax to the wg-quick DNS= line. >>>>> Specifically, a tilde prefixed domain is treated as a routing domain. >>>>> Multiple routing domains can be added. >>>>> >>>>> Limitations: >>>>> - Needs modifications to iOS UI to work on iOS. >>>>> - Only matching routing domains are sent to the DNS servers specified in >>>>> the DNS= config line. No separate fallback catch-all DNS server can >>>>> be set. >>>>> - Routing/match domains are also included in the list of search domains. >>>>> This could be changed with the matchDomainsNoSearch API, but lacking >>>>> more UI or config file changes to expose this option to the user, I >>>>> went with the default. >>>>> >>>>> [1] >>>>> https://lore.kernel.org/wireguard/[email protected]/T/ >>>>> [2] >>>>> https://github.com/slarew/wireguard-apple/commit/6ebc356d9e11ab91443e06de5e89f1af57fcdff8 >>>> >>>> That seems to be a redefinition of the existing definition of split DNS. >>>> >>>> Most usually, split DNS is done at the DNS server and different zones are >>>> served to the resolver based on various criteria... Usually the >>>> origination IP of the query; If the query comes from a client on your >>>> LAN, or a particular subnet, the contents of a particular, private, zone >>>> are returned. If the query comes from, say the internet, a public zone >>>> is returned. >>>> >>>> YOUR description, is how DNS works in general... Except your patch also >>>> seems to either bypass the resolver libraries or wedge itself in front of >>>> them The system resolver libraries well tested and understood and they >>>> handle the following very nicely. >>>> >>>> There is the issue of what happens with large DNS responses. Any DNS >>>> response over 512 bytes UDP fails and is required to be retried as a TCP >>>> query, which can handle the large response. It's late and I'm too tired >>>> to look it up, but there IS an RFC for this. >>>> >>>> It's a little known issue, but I've seen it when working with other VPN >>>> products that ignored/didn't understand the behavior. The results weren't >>>> pretty and really embarrassing. >>>> >>>> Systemd has a bad habit of re-inventing the wheel... Badly. Eventually it >>>> get's sorted, but is that really progress? In the long haul, "move fast >>>> and break things" is a MAJOR pita for the vast majority of us. But some >>>> like it. >>>> >>>> For some real fun, look into DHCPCD. It faithfully implements a >>>> particular RFC. In some networking environments using VPNs, it breaks >>>> routing horribly.... But it meets the RFC. You'll find it in Raspbian by >>>> default, and most other Debian derived distros. I automatically rip it >>>> out and replace it with the also available ISC DHCP client. That one is >>>> fully compatible with Windows, OS X, iOS, and every android and smart >>>> device I could test it with. A DHCP server configured to be compatible >>>> with DHCPCD broke all of the previously named. >>>> >>>> I'm giving this opinion away for free, so it's worth what you paid for it. >>> >>> Regardless of naming or definitions, I think the ability for a *local >>> device* to route DNS queries to different DNS servers based on domain >>> matching criteria is certainly useful. It’s not always possible or >>> desirable to control and configure an upstream DNS server. Hence, this >>> patch enables the local device to do split DNS. >>> >>> To be clear, this patch does not bypass or wedge around anything. In fact, >>> it configures the native macOS DNS settings in the appropriate manner to >>> effect a split DNS configuration. >>> >>> As a result of controlling the native macOS DNS resolution logic, any >>> feature, absent or present, in the macOS DNS resolver libraries should be >>> unaffected. This includes the large DNS response and TCP behavior. I do not >>> expect the small/large UDP/TCP DNS features to change behavior when using a >>> split DNS configuration as proposed in this patch. >>> >>> -Stephen >> >> 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 > > DNSDIST may allow (I have not tried) one to create a split DNS scenario, but > it is an extra piece of software that would need to be discovered, installed, > configured, and maintained by a user or system administrator. I do not > believe it would properly integrate with the macOS DNS resolution machinery. > I do not believe it is a better solution to the problem. > > As I understand it, under some circumstances, the Tailscale macOS app also > implements split DNS in roughly the same manner as done in my patch. Namely, > the tailscale app appears to use the Network Extension APIs to directly > integrate with the macOS DNS resolution machinery. Perhaps the relevant > difference is that tailscale approaches configuration differently (not based > on wg-quick) than the WireGuard macOS app. > > I do not have statistics or polling on who desires this split DNS feature. I > have received private and public requests to upstream the feature. Tailscale > also implements split DNS; presumable customers demand it. I suspect if the > feature was available to users of the WireGuard app, then it would be used > with precision to great effect. Users who do not need this split DNS feature > do not lose any previous functionality in the macOS WireGuard app. > > Personally, my one hesitation with this patch is that, as currently > implemented, a new syntax is added to the wg-quick config file (tilde > prefixed route/match domains). My patch does not address compatibility issues > nor does it add documentation to wg-quick for the new syntax. > > -Stephen
