* Split DNS for macOS @ 2021-10-28 7:16 Stephen Larew 2021-10-28 7:16 ` [PATCH] Enable "split DNS" configurations for an interface Stephen Larew ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Stephen Larew @ 2021-10-28 7:16 UTC (permalink / raw) To: wireguard 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/T/ [2] https://github.com/slarew/wireguard-apple/commit/6ebc356d9e11ab91443e06de5e89f1af57fcdff8 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] Enable "split DNS" configurations for an interface 2021-10-28 7:16 Split DNS for macOS Stephen Larew @ 2021-10-28 7:16 ` Stephen Larew 2021-10-28 9:58 ` Split DNS for macOS Bruce Ferrell 2022-01-28 5:23 ` Stephen Larew 2 siblings, 0 replies; 17+ messages in thread From: Stephen Larew @ 2021-10-28 7:16 UTC (permalink / raw) To: wireguard; +Cc: Stephen Larew By adding a tilde prefix to a domain name entry in the DNS= line, the domain is interpreted as a "matching domain" for DNS routing instead of a "search domain." This corresponds to setting a non-empty NEDNSSettings.matchDomains property for the network tunnel. Using tilde as a prefix is borrowed from systemd-resolved's equivalent usage. If one or more match domains are specified, then the specified DNS resolvers are only used for those matching domains instead of acting as the first resolver before the system's primary DNS resolvers. Signed-off-by: Stephen Larew <stephen@slarew.net> --- .../Shared/Model/TunnelConfiguration+WgQuickConfig.swift | 5 +++++ .../Tunnel/TunnelConfiguration+UapiConfig.swift | 1 + Sources/WireGuardApp/UI/TunnelViewModel.swift | 7 ++++++- Sources/WireGuardApp/UI/macOS/View/highlighter.c | 9 ++++++++- Sources/WireGuardKit/InterfaceConfiguration.swift | 4 +++- Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift | 7 ++++++- 6 files changed, 29 insertions(+), 4 deletions(-) diff --git a/Sources/Shared/Model/TunnelConfiguration+WgQuickConfig.swift b/Sources/Shared/Model/TunnelConfiguration+WgQuickConfig.swift index 5d5216c..87bc93f 100644 --- a/Sources/Shared/Model/TunnelConfiguration+WgQuickConfig.swift +++ b/Sources/Shared/Model/TunnelConfiguration+WgQuickConfig.swift @@ -136,6 +136,7 @@ extension TunnelConfiguration { if !interface.dns.isEmpty || !interface.dnsSearch.isEmpty { var dnsLine = interface.dns.map { $0.stringRepresentation } dnsLine.append(contentsOf: interface.dnsSearch) + dnsLine.append(contentsOf: interface.dnsMatchDomains.map { "~" + $0 }) let dnsString = dnsLine.joined(separator: ", ") output.append("DNS = \(dnsString)\n") } @@ -191,15 +192,19 @@ extension TunnelConfiguration { if let dnsString = attributes["dns"] { var dnsServers = [DNSServer]() var dnsSearch = [String]() + var dnsMatchDomains = [String]() for dnsServerString in dnsString.splitToArray(trimmingCharacters: .whitespacesAndNewlines) { if let dnsServer = DNSServer(from: dnsServerString) { dnsServers.append(dnsServer) + } else if dnsServerString.first == "~" && !dnsServerString.dropFirst().isEmpty { + dnsMatchDomains.append(String(dnsServerString.dropFirst())) } else { dnsSearch.append(dnsServerString) } } interface.dns = dnsServers interface.dnsSearch = dnsSearch + interface.dnsMatchDomains = dnsMatchDomains } if let mtuString = attributes["mtu"] { guard let mtu = UInt16(mtuString) else { diff --git a/Sources/WireGuardApp/Tunnel/TunnelConfiguration+UapiConfig.swift b/Sources/WireGuardApp/Tunnel/TunnelConfiguration+UapiConfig.swift index cdc81ce..f2ff763 100644 --- a/Sources/WireGuardApp/Tunnel/TunnelConfiguration+UapiConfig.swift +++ b/Sources/WireGuardApp/Tunnel/TunnelConfiguration+UapiConfig.swift @@ -75,6 +75,7 @@ extension TunnelConfiguration { interfaceConfiguration?.addresses = base?.interface.addresses ?? [] interfaceConfiguration?.dns = base?.interface.dns ?? [] interfaceConfiguration?.dnsSearch = base?.interface.dnsSearch ?? [] + interfaceConfiguration?.dnsMatchDomains = base?.interface.dnsMatchDomains ?? [] interfaceConfiguration?.mtu = base?.interface.mtu if let interfaceConfiguration = interfaceConfiguration { diff --git a/Sources/WireGuardApp/UI/TunnelViewModel.swift b/Sources/WireGuardApp/UI/TunnelViewModel.swift index b65c8cc..3b3fcda 100644 --- a/Sources/WireGuardApp/UI/TunnelViewModel.swift +++ b/Sources/WireGuardApp/UI/TunnelViewModel.swift @@ -139,9 +139,10 @@ class TunnelViewModel { if let mtu = config.mtu { scratchpad[.mtu] = String(mtu) } - if !config.dns.isEmpty || !config.dnsSearch.isEmpty { + if !config.dns.isEmpty || !config.dnsSearch.isEmpty || !config.dnsMatchDomains.isEmpty { var dns = config.dns.map { $0.stringRepresentation } dns.append(contentsOf: config.dnsSearch) + dns.append(contentsOf: config.dnsMatchDomains.map { "~" + $0 }) scratchpad[.dns] = dns.joined(separator: ", ") } return scratchpad @@ -197,15 +198,19 @@ class TunnelViewModel { if let dnsString = scratchpad[.dns] { var dnsServers = [DNSServer]() var dnsSearch = [String]() + var dnsMatchDomains = [String]() for dnsServerString in dnsString.splitToArray(trimmingCharacters: .whitespacesAndNewlines) { if let dnsServer = DNSServer(from: dnsServerString) { dnsServers.append(dnsServer) + } else if dnsServerString.first == "~" && !dnsServerString.dropFirst().isEmpty { + dnsMatchDomains.append(String(dnsServerString.dropFirst())) } else { dnsSearch.append(dnsServerString) } } config.dns = dnsServers config.dnsSearch = dnsSearch + config.dnsMatchDomains = dnsMatchDomains } guard errorMessages.isEmpty else { return .error(errorMessages.first!) } diff --git a/Sources/WireGuardApp/UI/macOS/View/highlighter.c b/Sources/WireGuardApp/UI/macOS/View/highlighter.c index d89feda..e005377 100644 --- a/Sources/WireGuardApp/UI/macOS/View/highlighter.c +++ b/Sources/WireGuardApp/UI/macOS/View/highlighter.c @@ -121,6 +121,13 @@ static bool is_valid_hostname(string_span_t s) return num_digit != num_entity; } +static bool is_valid_dns_match_hostname(string_span_t s) +{ + if (!s.len || s.s[0] != '~') + return false; + return is_valid_hostname((string_span_t){ s.s + 1, s.len - 1}); +} + static bool is_valid_ipv4(string_span_t s) { for (size_t j, i = 0, pos = 0; i < 4 && pos < s.len; ++i) { @@ -448,7 +455,7 @@ static void highlight_multivalue_value(struct highlight_span_array *ret, const s case DNS: if (is_valid_ipv4(s) || is_valid_ipv6(s)) append_highlight_span(ret, parent.s, s, HighlightIP); - else if (is_valid_hostname(s)) + else if (is_valid_hostname(s) || is_valid_dns_match_hostname(s)) append_highlight_span(ret, parent.s, s, HighlightHost); else append_highlight_span(ret, parent.s, s, HighlightError); diff --git a/Sources/WireGuardKit/InterfaceConfiguration.swift b/Sources/WireGuardKit/InterfaceConfiguration.swift index 4fb8f1b..521d4b8 100644 --- a/Sources/WireGuardKit/InterfaceConfiguration.swift +++ b/Sources/WireGuardKit/InterfaceConfiguration.swift @@ -11,6 +11,7 @@ public struct InterfaceConfiguration { public var mtu: UInt16? public var dns = [DNSServer]() public var dnsSearch = [String]() + public var dnsMatchDomains = [String]() public init(privateKey: PrivateKey) { self.privateKey = privateKey @@ -27,6 +28,7 @@ extension InterfaceConfiguration: Equatable { lhs.listenPort == rhs.listenPort && lhs.mtu == rhs.mtu && lhs.dns == rhs.dns && - lhs.dnsSearch == rhs.dnsSearch + lhs.dnsSearch == rhs.dnsSearch && + lhs.dnsMatchDomains == rhs.dnsMatchDomains } } diff --git a/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift b/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift index c53a82c..dac7648 100644 --- a/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift +++ b/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift @@ -88,7 +88,12 @@ class PacketTunnelSettingsGenerator { let dnsSettings = NEDNSSettings(servers: dnsServerStrings) dnsSettings.searchDomains = tunnelConfiguration.interface.dnsSearch if !tunnelConfiguration.interface.dns.isEmpty { - dnsSettings.matchDomains = [""] // All DNS queries must first go through the tunnel's DNS + if tunnelConfiguration.interface.dnsMatchDomains.isEmpty { + // All DNS queries must first go through the tunnel's DNS + dnsSettings.matchDomains = [""] + } else { + dnsSettings.matchDomains = tunnelConfiguration.interface.dnsMatchDomains + } } networkSettings.dnsSettings = dnsSettings } -- 2.30.1 (Apple Git-130) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-28 7:16 Split DNS for macOS Stephen Larew 2021-10-28 7:16 ` [PATCH] Enable "split DNS" configurations for an interface Stephen Larew @ 2021-10-28 9:58 ` Bruce Ferrell 2021-10-29 15:33 ` Stephen Larew 2022-01-28 5:23 ` Stephen Larew 2 siblings, 1 reply; 17+ messages in thread From: Bruce Ferrell @ 2021-10-28 9:58 UTC (permalink / raw) To: wireguard 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-28 9:58 ` Split DNS for macOS Bruce Ferrell @ 2021-10-29 15:33 ` Stephen Larew 2021-10-29 17:03 ` Andrew Fried 0 siblings, 1 reply; 17+ messages in thread From: Stephen Larew @ 2021-10-29 15:33 UTC (permalink / raw) To: Bruce Ferrell; +Cc: wireguard > On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 15:33 ` Stephen Larew @ 2021-10-29 17:03 ` Andrew Fried 2021-10-29 21:07 ` Stephen Larew 0 siblings, 1 reply; 17+ messages in thread From: Andrew Fried @ 2021-10-29 17:03 UTC (permalink / raw) To: wireguard 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 On 10/29/21 11:33 AM, Stephen Larew wrote: > > >> On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 > -- Andrew Fried afried@spamteq.com +1.703.667.4050 Office +1.703.362.0067 Mobile ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 17:03 ` Andrew Fried @ 2021-10-29 21:07 ` Stephen Larew 2021-10-30 21:00 ` Dusan Zivadinovic ` (3 more replies) 0 siblings, 4 replies; 17+ messages in thread From: Stephen Larew @ 2021-10-29 21:07 UTC (permalink / raw) To: Andrew Fried; +Cc: wireguard > On Oct 29, 2021, at 10:03, Andrew Fried <afried@spamteq.com> wrote: > >> On Oct 29, 2021, at 08:33, Stephen Larew <stephen@slarew.net> wrote: >> >>> On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 21:07 ` Stephen Larew @ 2021-10-30 21:00 ` Dusan Zivadinovic 2021-11-03 9:15 ` Harald Dunkel ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Dusan Zivadinovic @ 2021-10-30 21:00 UTC (permalink / raw) To: Stephen Larew; +Cc: wireguard Hi list, I would appreciate that, its a usefull feature. Think of connecting to multiple remote VPN peers simultaneously, and use different DNSes for certain domains in each VPN connection. Just as an example, the iOS app DNSCloak also sports a split DNS function. regards, Dusan > Am 29.10.2021 um 23:07 schrieb Stephen Larew <stephen@slarew.net>: > >> On Oct 29, 2021, at 10:03, Andrew Fried <afried@spamteq.com> wrote: >> >>> On Oct 29, 2021, at 08:33, Stephen Larew <stephen@slarew.net> wrote: >>> >>>> On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 21:07 ` Stephen Larew 2021-10-30 21:00 ` Dusan Zivadinovic @ 2021-11-03 9:15 ` Harald Dunkel 2021-11-03 9:42 ` Matty Driessen 2021-11-03 11:54 ` Alex Burke 2021-11-06 4:54 ` David Anderson 3 siblings, 1 reply; 17+ messages in thread From: Harald Dunkel @ 2021-11-03 9:15 UTC (permalink / raw) To: wireguard Hi folks, I really like this patch. Currently DNS on MacOS is unable to resolve both my local DNS names and the domain in the office in parallel, if Wireguard is enabled. I have to use somehost.local to fall back to zeroconf for my LAN as a workaround, which is pretty annoying. My suggestion would be to set SupplementalMatchDomains instead(!) of SearchDomains, using the current config file syntax without '~'. Since SupplementalMatchDomainsNoSearch is disabled by default, setting SupplementalMatchDomains is sufficient to configure both lists. See https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf This has to be verified, of course. Regards Harri On 2021-10-29 23:07:38, Stephen Larew wrote: >> On Oct 29, 2021, at 10:03, Andrew Fried <afried@spamteq.com> wrote: >> >>> On Oct 29, 2021, at 08:33, Stephen Larew <stephen@slarew.net> wrote: >>> >>>> On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-11-03 9:15 ` Harald Dunkel @ 2021-11-03 9:42 ` Matty Driessen 0 siblings, 0 replies; 17+ messages in thread From: Matty Driessen @ 2021-11-03 9:42 UTC (permalink / raw) To: wireguard Hello, 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. Regards, Matty On Wed, Nov 3, 2021 at 10:20 AM Harald Dunkel <harald.dunkel@aixigo.com> wrote: > > Hi folks, > > I really like this patch. Currently DNS on MacOS is unable to resolve > both my local DNS names and the domain in the office in parallel, if > Wireguard is enabled. I have to use somehost.local to fall back to > zeroconf for my LAN as a workaround, which is pretty annoying. > > My suggestion would be to set SupplementalMatchDomains instead(!) of > SearchDomains, using the current config file syntax without '~'. Since > SupplementalMatchDomainsNoSearch is disabled by default, setting > SupplementalMatchDomains is sufficient to configure both lists. See > > https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf > > This has to be verified, of course. > > > Regards > Harri > > > > On 2021-10-29 23:07:38, Stephen Larew wrote: > >> On Oct 29, 2021, at 10:03, Andrew Fried <afried@spamteq.com> wrote: > >> > >>> On Oct 29, 2021, at 08:33, Stephen Larew <stephen@slarew.net> wrote: > >>> > >>>> On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 21:07 ` Stephen Larew 2021-10-30 21:00 ` Dusan Zivadinovic 2021-11-03 9:15 ` Harald Dunkel @ 2021-11-03 11:54 ` Alex Burke 2021-11-06 4:54 ` David Anderson 3 siblings, 0 replies; 17+ messages in thread From: Alex Burke @ 2021-11-03 11:54 UTC (permalink / raw) To: wireguard 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 <stephen@slarew.net> wrote: > > >> >>> On Oct 29, 2021, at 10:03, Andrew Fried <afried@spamteq.com> wrote: >>> >>>> On Oct 29, 2021, at 08:33, Stephen Larew <stephen@slarew.net> wrote: >>> >>>> On Oct 28, 2021, at 02:58, Bruce Ferrell <bferrell@baywinds.org> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 21:07 ` Stephen Larew ` (2 preceding siblings ...) 2021-11-03 11:54 ` Alex Burke @ 2021-11-06 4:54 ` David Anderson 2021-11-06 9:47 ` Matty Driessen 3 siblings, 1 reply; 17+ messages in thread From: David Anderson @ 2021-11-06 4:54 UTC (permalink / raw) To: wireguard On Fri, Oct 29, 2021, at 14:07, Stephen Larew wrote: > 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. Hi, Tailscale person here. Yes, the Tailscale macOS app supports configuring either split DNS. It's situationally popular for things like "direct anything under amazonaws.com to the AWS VPC internal resolver on the other side of my tunnel", which makes your AWS VMs and such magically resolve correctly without shoveling all your unrelated requests through AWS. The semantics of NEDNSSettings I've worked out so far: * `searchDomains` sets interface-scoped search domains only, which appear to not be used at all for single-label DNS query expansion. IOW, it seems to do mostly nothing - or at least, I've not discovered anything it affects. * `matchDomains` specifies what DNS suffixes should be sent to your resolvers (specified in `servers`). Specifying a list of suffixes here implements split-DNS. Specifying "" (the empty suffix, which matches all names) captures all queries. * `matchDomains` _also_ installs any non-empty string you specify in the global search path. * `matchDomainsNoSearch` lets you make `matchDomains` be just match domains, without modifying the global search path. You don't get more granularity than that, either all `matchDomains` are search paths, or none. * If you want to fully capture all DNS traffic but also set some global search domains, you can list both the empty string and non-empty strings in `matchDomains`, and you'll get that behavior. * You only get a single set of resolver IPs. This means you can have many DNS suffixes with `matchDomains`, but all of them will go to the pool of `servers` you provided. You can't route foo.com to 1.2.3.4 and bar.com to 2.3.4.5 without having another intermediate proxy to break things out further. * Apple's DNS management service only installs the "default" resolver into the legacy /etc/resolv.conf, so a bunch of commandline tools inherited from BSD will be completely unaware of split DNS configurations, because they don't use whatever the "correct" resolution API is (I presume mach port something something). * Apple doesn't have a public API for reading back the OS DNS settings, because they don't want other applications poorly reimplementing the OS's algorithm for selecting among contributed configuration. There is presumably an undocumented API that scutil et al. can use to read things out, but I've not dug into that at all. Regarding upstreaming: OS-level DNS capabilities vary wildly across linux, apple and windows, and across versions of same (e.g. Windows 8+ can do split DNS, Windows 7 cannot - but WSL/WSL2 can't on any version to date). I can ramble at length about each OS if desired, but the bottom line is "send all DNS to these servers" is the only configuration that can be implemented reliably on all of them. So, the question would be: do you want upstream WireGuard applications to have consistent behavior on all platforms? If so, you have to either forego split DNS, or do a lot of work to polyfill missing features on each platform (Tailscale's attempt at this is https://github.com/tailscale/tailscale/tree/main/net/dns). Or expose the uneven feature surface to the user, and delegate the pain of non-portability to them. - Dave ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-11-06 4:54 ` David Anderson @ 2021-11-06 9:47 ` Matty Driessen 0 siblings, 0 replies; 17+ messages in thread From: Matty Driessen @ 2021-11-06 9:47 UTC (permalink / raw) To: wireguard Hello Dave, Thank you for this explanation and the challenges that come with split-DNS. The biggest gripe I have with the current implementation in WireGuard is that the search domain is not set as a global search domain when using a split-tunnel. As you said the reason for this is "If you want to fully capture all DNS traffic but also set some global search domains, you can list both the empty string and non-empty strings in `matchDomains`, and you'll get that behavior.". When I use the same configuration file with the wg-quick utility the search domain from the configuration file is set as a global search domain. I think this is the case for all OS'es and should at least be the case when using the WireGuard UI tool as well? Regards, Matty On Sat, Nov 6, 2021 at 5:59 AM David Anderson <dave@natulte.net> wrote: > > On Fri, Oct 29, 2021, at 14:07, Stephen Larew wrote: > > 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. > > Hi, Tailscale person here. > > Yes, the Tailscale macOS app supports configuring either split DNS. It's situationally popular for things like "direct anything under amazonaws.com to the AWS VPC internal resolver on the other side of my tunnel", which makes your AWS VMs and such magically resolve correctly without shoveling all your unrelated requests through AWS. > > The semantics of NEDNSSettings I've worked out so far: > * `searchDomains` sets interface-scoped search domains only, which appear to not be used at all for single-label DNS query expansion. IOW, it seems to do mostly nothing - or at least, I've not discovered anything it affects. > * `matchDomains` specifies what DNS suffixes should be sent to your resolvers (specified in `servers`). Specifying a list of suffixes here implements split-DNS. Specifying "" (the empty suffix, which matches all names) captures all queries. > * `matchDomains` _also_ installs any non-empty string you specify in the global search path. > * `matchDomainsNoSearch` lets you make `matchDomains` be just match domains, without modifying the global search path. You don't get more granularity than that, either all `matchDomains` are search paths, or none. > * If you want to fully capture all DNS traffic but also set some global search domains, you can list both the empty string and non-empty strings in `matchDomains`, and you'll get that behavior. > * You only get a single set of resolver IPs. This means you can have many DNS suffixes with `matchDomains`, but all of them will go to the pool of `servers` you provided. You can't route foo.com to 1.2.3.4 and bar.com to 2.3.4.5 without having another intermediate proxy to break things out further. > * Apple's DNS management service only installs the "default" resolver into the legacy /etc/resolv.conf, so a bunch of commandline tools inherited from BSD will be completely unaware of split DNS configurations, because they don't use whatever the "correct" resolution API is (I presume mach port something something). > * Apple doesn't have a public API for reading back the OS DNS settings, because they don't want other applications poorly reimplementing the OS's algorithm for selecting among contributed configuration. There is presumably an undocumented API that scutil et al. can use to read things out, but I've not dug into that at all. > > Regarding upstreaming: OS-level DNS capabilities vary wildly across linux, apple and windows, and across versions of same (e.g. Windows 8+ can do split DNS, Windows 7 cannot - but WSL/WSL2 can't on any version to date). I can ramble at length about each OS if desired, but the bottom line is "send all DNS to these servers" is the only configuration that can be implemented reliably on all of them. > > So, the question would be: do you want upstream WireGuard applications to have consistent behavior on all platforms? If so, you have to either forego split DNS, or do a lot of work to polyfill missing features on each platform (Tailscale's attempt at this is https://github.com/tailscale/tailscale/tree/main/net/dns). Or expose the uneven feature surface to the user, and delegate the pain of non-portability to them. > > - Dave ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-28 7:16 Split DNS for macOS Stephen Larew 2021-10-28 7:16 ` [PATCH] Enable "split DNS" configurations for an interface Stephen Larew 2021-10-28 9:58 ` Split DNS for macOS Bruce Ferrell @ 2022-01-28 5:23 ` Stephen Larew 2022-01-28 9:02 ` Harald Dunkel 2 siblings, 1 reply; 17+ messages in thread From: Stephen Larew @ 2022-01-28 5:23 UTC (permalink / raw) To: wireguard > On Oct 28, 2021, at 00:16, Stephen Larew <stephen@slarew.net> 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/20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local/T/ > [2] https://github.com/slarew/wireguard-apple/commit/6ebc356d9e11ab91443e06de5e89f1af57fcdff8 Thanks everyone for your opinions and feedback. Here’s my summary: - DNS configuration is nuanced, fragmented, and platform dependent. - Split DNS can be accomplished in several ways: - Via the native macOS DNS resolution machinery (NEDNSSettings.matchDomains in my patch) - Via a local or upstream non-platform-native DNS resolver - Demand for split DNS exists. Other VPN apps (e.g. Tailscale and DNSCloak) allow setting split DNS. -- I would appreciate some feedback from the WireGuard maintainers on next steps. Thanks ahead. I’ll address some feedback below. > On Nov 3, 2021, at 02:15, Harald Dunkel <harald.dunkel@aixigo.com> wrote: > > Hi folks, > > I really like this patch. Currently DNS on MacOS is unable to resolve > both my local DNS names and the domain in the office in parallel, if > Wireguard is enabled. I have to use somehost.local to fall back to > zeroconf for my LAN as a workaround, which is pretty annoying. > > My suggestion would be to set SupplementalMatchDomains instead(!) of > SearchDomains, using the current config file syntax without '~'. Since > SupplementalMatchDomainsNoSearch is disabled by default, setting > SupplementalMatchDomains is sufficient to configure both lists. See > > https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf > > This has to be verified, of course. > > Regards > Harri Harri, it sounds to me like SupplementalMatchDomains is functionally the same as NEDNSSettings.matchDomains. The difference is that SupplementalMatchDomains is specified in Apple’s configuration profiles instead of thru the NEDNSSettings.matchDomains API (by way of a wg-quick syntax extension in my patch). If the WireGuard macOS app supported Apple’s configuration profiles (I don’t believe it does but I may be mistaken), then a configuration profile would conveniently avoid the extended wg-quick syntax in my patch. However, I think configuration profiles are less accessible to the average user. > On Nov 3, 2021, at 14:34, Andrew Fried <afried@spamteq.com> wrote: > > Basically, what I'm suggesting is that DNS servers handle DNS and wireguard handle routing/transport. Adding VPN functionality to a nameserver or dns capabilities to Wireguard adds complexities that can be better handled elsewhere. > > What makes Wireguard so good is that it does one thing and does it really, really well. > > Andrew Andrew, to your point, alternative DNS solutions exist and can be deployed in many ways. WireGuard itself is not a DNS solution. That said, wg-quick style configuration (used by the WireGuard macOS app) already does basic DNS configuration. My patch adds a small extension to wg-quick syntax (tilde prefixed domains) to make certain split DNS scenarios possible. Crucially, my patch actually integrates directly into macOS’s DNS machinery. No third party software or external network DNS servers need apply. > On Nov 5, 2021, at 21:54, David Anderson <dave@natulte.net> wrote: > > Hi, Tailscale person here. Dave, your technical details sound right based on what I remember from my own experimentation. -Stephen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2022-01-28 5:23 ` Stephen Larew @ 2022-01-28 9:02 ` Harald Dunkel 0 siblings, 0 replies; 17+ messages in thread From: Harald Dunkel @ 2022-01-28 9:02 UTC (permalink / raw) To: wireguard On 2022-01-28 06:23:29, Stephen Larew wrote: > > I would appreciate some feedback from the WireGuard maintainers on next steps. Thanks ahead. > Metoo. Testers wanted? Regards Harri ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS @ 2021-10-29 21:06 Matty Driessen 2021-11-03 21:34 ` Andrew Fried 0 siblings, 1 reply; 17+ messages in thread From: Matty Driessen @ 2021-10-29 21:06 UTC (permalink / raw) To: wireguard 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-10-29 21:06 Matty Driessen @ 2021-11-03 21:34 ` Andrew Fried 2021-11-03 21:46 ` Alex Burke 0 siblings, 1 reply; 17+ messages in thread From: Andrew Fried @ 2021-11-03 21:34 UTC (permalink / raw) To: wireguard Hi Matty, I understand exactly what you're trying to accomplish and agree that split dns can be challenging, especially with multiple VPN gateways. My point is that what you're describing is a DNS issue, not a firewall/vpn/routing issue. As such, I think there's more eloquent way to solve DNS related issues. The old fashioned way is to add exceptions to the equivalent of the /etc/host file. Not ideal, doesn't scale well and pretty static, but if you're relying on just a few private host mappings it works pretty well. The second and more palatable solution is to have the internal nameservers running software that supports views - such that queries for xxxx.example.com that originate from private address space return different answers than if the query originated from public space. A third option would be set the internal recursives up as forwarders that only respond authoritatively for your private "mydomain.internet" and forward all other requests to nameservers capable of public recursion. There's the dnsdist solution, which is an advanced dns proxy server capable of routing requests to different recursives based on the domain name. DNSDIST does a lot of other stuff as well, but the heart of is intelligent proxying. In our racks we use DNSDIST to distribute around a million DNS queries per minute and it works flawlessly. Basically, what I'm suggesting is that DNS servers handle DNS and wireguard handle routing/transport. Adding VPN functionality to a nameserver or dns capabilities to Wireguard adds complexities that can be better handled elsewhere. What makes Wireguard so good is that it does one thing and does it really, really well. Andrew On 10/29/21 5:06 PM, Matty Driessen wrote: > 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 > -- Andrew Fried afried@spamteq.com +1.703.667.4050 Office +1.703.362.0067 Mobile ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Split DNS for macOS 2021-11-03 21:34 ` Andrew Fried @ 2021-11-03 21:46 ` Alex Burke 0 siblings, 0 replies; 17+ messages in thread From: Alex Burke @ 2021-11-03 21:46 UTC (permalink / raw) To: wireguard Hi Andrew, > What makes Wireguard so good is that it does one thing and does it really, really well. I am in complete agreement on this, but Wireguard wouldn't really be "doing" (implementing) what Stephen and Matty are trying to accomplish, but rather simply integrating with the mechanism the Apple platform has implemented for doing precisely that. While I'm not in a position to weigh in on how much development work it would entail for Jason et al to implement to the high standard Wireguard is known for, or how much bloat it would add, it's undoubtedly a killer feature, and it's my professional opinion that a significant proportion of the Wireguard user base would benefit from supporting it — especially for corporate use. > On 3 Nov 2021 at 21:34, Andrew Fried <afried@spamteq.com> wrote: > Hi Matty, > > I understand exactly what you're trying to accomplish and agree that split dns can be challenging, especially with multiple VPN gateways. > > My point is that what you're describing is a DNS issue, not a firewall/vpn/routing issue. As such, I think there's more eloquent way to solve DNS related issues. > > The old fashioned way is to add exceptions to the equivalent of the /etc/host file. Not ideal, doesn't scale well and pretty static, but if you're relying on just a few private host mappings it works pretty well. > > The second and more palatable solution is to have the internal nameservers running software that supports views - such that queries for xxxx.example.com that originate from private address space return different answers than if the query originated from public space. > > A third option would be set the internal recursives up as forwarders that only respond authoritatively for your private "mydomain.internet" and forward all other requests to nameservers capable of public recursion. > > There's the dnsdist solution, which is an advanced dns proxy server capable of routing requests to different recursives based on the domain name. DNSDIST does a lot of other stuff as well, but the heart of is intelligent proxying. In our racks we use DNSDIST to distribute around a million DNS queries per minute and it works flawlessly. > > Basically, what I'm suggesting is that DNS servers handle DNS and wireguard handle routing/transport. Adding VPN functionality to a nameserver or dns capabilities to Wireguard adds complexities that can be better handled elsewhere. > > What makes Wireguard so good is that it does one thing and does it really, really well. > > Andrew > > > On 10/29/21 5:06 PM, Matty Driessen wrote: >> 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 > > -- > Andrew Fried > afried@spamteq.com > +1.703.667.4050 Office > +1.703.362.0067 Mobile ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-01-28 9:02 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-28 7:16 Split DNS for macOS Stephen Larew 2021-10-28 7:16 ` [PATCH] Enable "split DNS" configurations for an interface Stephen Larew 2021-10-28 9:58 ` Split DNS for macOS Bruce Ferrell 2021-10-29 15:33 ` Stephen Larew 2021-10-29 17:03 ` Andrew Fried 2021-10-29 21:07 ` Stephen Larew 2021-10-30 21:00 ` Dusan Zivadinovic 2021-11-03 9:15 ` Harald Dunkel 2021-11-03 9:42 ` Matty Driessen 2021-11-03 11:54 ` Alex Burke 2021-11-06 4:54 ` David Anderson 2021-11-06 9:47 ` Matty Driessen 2022-01-28 5:23 ` Stephen Larew 2022-01-28 9:02 ` Harald Dunkel 2021-10-29 21:06 Matty Driessen 2021-11-03 21:34 ` Andrew Fried 2021-11-03 21:46 ` Alex Burke
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).