Indeed, the DOMAIN option and DOMAIN-SEARCH options both define the search domains on the host. These are passed as-is to the OS on Windows, but on Linux and Mac the client needs to handle them. Pritunl does this and treats DOMAIN and DOMAIN-SEARCH the same way.
However other VPN clients on Mac apply DOMAIN and DOMAIN-SEARCH differently. I agree that they’re wrong in their interpretation of the DHCP options. However what they do has merit and could serve as inspiration for adding split DNS to the Pritunl client on Mac.
All the clients I have tried, including the Pritunl client, when they connect to the Pritunl server and receive dhcp-option DOMAIN mycompany.com, configure DNS on the host using scutil. But the dictionaries they create are different and the result is different.
Pritunl createsmultiple:
$ scutil
> open
> show Setup:/Network/Service/1692E22E-ADBB-4FB7-8349-72BE1809C202/DNS
<dictionary> {
Pritunl : true
SearchDomains : <array> {
0 : mycompany.com
}
ServerAddresses : <array> {
0 : 10.254.0.7
1 : 10.254.1.9
2 : 10.254.2.12
3 : 8.8.8.8
}
}
> show State:/Network/Pritunl/Connection/a9b405e50abd8715e93a071ef017ce78
<dictionary> {
Pritunl : true
SearchDomains : <array> {
0 : mycompany.com
}
ServerAddresses : <array> {
0 : 10.254.0.7
1 : 10.254.1.9
2 : 10.254.2.12
3 : 8.8.8.8
}
}
> show State:/Network/Pritunl/Restore/1692E22E-ADBB-4FB7-8349-72BE1809C202
<dictionary> {
DomainName : home
ServerAddresses : <array> {
0 : 192.168.1.1
}
}
It also updates one existing object:
$ scutil
> open
> show State:/Network/Service/1692E22E-ADBB-4FB7-8349-72BE1809C202/DNS
<dictionary> {
Pritunl : true
SearchDomains : <array> {
0 : pigment.app
}
ServerAddresses : <array> {
0 : 10.254.0.7
1 : 10.254.1.9
2 : 10.254.2.12
3 : 8.8.8.8
}
}
The first three are state the Pritunl client uses to reset the last one when disconnecting. The last one is what actually changes the host’s DNS settings. Its content is first propagated to this object:
> show State:/Network/Global/DNS
<dictionary> {
SearchDomains : <array> {
0 : mycompany.com
}
ServerAddresses : <array> {
0 : 10.254.0.7
1 : 10.254.1.9
2 : 10.254.2.12
3 : 8.8.8.8
}
__CONFIGURATION_ID__ : Default: 0
__FLAGS__ : 2
__ORDER__ : 0
}
This is reflected in /etc/resolv.conf as:
search mycompany.com
nameserver 10.254.0.7
nameserver 10.254.1.9
nameserver 10.254.2.12
nameserver 8.8.8.8
This is different from OpenVPN Connect. When connecting to the same Pritunl server with the same profile, OpenVPN Connect creates a single key and does not update any other keys:
$ scutil
> open
> State:/Network/Service/OpenVPNConnect/DNS
<dictionary> {
ServerAddresses : <array> {
0 : 10.254.0.7
1 : 10.254.1.9
2 : 10.254.2.12
3 : 8.8.8.8
}
SupplementalMatchDomains : <array> {
0 : mycompany.com
}
SupplementalMatchDomainsNoSearch : 1
}
Unlike Pritunl’s objects, this sets up a split DNS configuration, where only DNS queries for company.com and its subdomains go to the nameservers pushed by the Pritunl server. The SupplementalMatchDomainsNoSearch is supposed to disable domain search but the fact is that it doesn’t. Setting it to a different value or removing it changes nothing to domain resolution in my experience, so we might as well remove it.
This could be a quick and simple way for the Pritunl client to set up split DNS on Mac.
Orthogonal to the split DNS feature, the way OpenVPN Connect configures DNS can help improve Pritunl. Using shared objects like State:/Network/Service/xxx/DNS leads to race conditions when the host changes network, the host shuts down, etc. This is because this object is actively maintained by the OS, not just Pritunl. Having a single object that only Pritunl manages would be a good way to get rid of these race conditions.
To do that, we could replace the objects Pritunl currently creates with one like OpenVPN Connect’s. We can avoid the “split DNS” effect by including the empty string in SupplementalMatchDomains. That will have the same effect that Pritunl’s approach currently does: update State:/Network/Global/DNS and /etc/resolv.conf and route all the host’s DNS queries to the nameservers pushed by the Pritunl server, but with no shared state and no race conditions.
What do you think?
I would be more than happy to help with such improvements. Currently these DNS issues on Mac are preventing many users in my organisation from using the Pritunl client. Instead they use OpenVPN Connect or the OpenVPN CLI for now, but the Pritunl client has exclusive features that we are interested in. If we could fix these DNS issues that would be great!
