MacOS: search domains are not applied (redirect_dns is false)

[rhuitl]

This is similar to or even the same as #242, but redirect_dns is false in my case.

The server pushes search domains. Probably for compatibility reasons with some clients, it pushes it as both DOMAIN and DOMAIN-SEARCH:

[dhcp-option] [DOMAIN] [int.example.com]
[dhcp-option] [DOMAIN-SEARCH] [int.example.com]

On MacOS, split-DNS is enabled, so

openvpn3/openvpn/client/dns.hpp

Line 267 in 3e3cd51

server.domains.push_back({domain});

adds the search domains to server.domains (and not server.search_domains).

openvpn3/openvpn/tun/mac/macdns.hpp

Line 223 in 3e3cd51

CF::dict_set_obj(info->ovpn.mod, "SupplementalMatchDomains", config.resolve_domains());

sets these as SupplementalMatchDomains but the next line excludes them from being search domains via SupplementalMatchDomainsNoSearch=1.

openvpn3/openvpn/tun/mac/macdns.hpp

Line 229 in 3e3cd51

if (CF::array_len(config.search_domains))

finds an empty list, so no domain is added as a search domain.

When I comment out the code that sets SupplementalMatchDomainsNoSearch, the search domain is added as expected, and I can resolve names without having to type the FQDN. Alternatively, moving

openvpn3/openvpn/client/dns.hpp

Line 271 in 3e3cd51

search_domains.push_back({domain});

out of the else block, so it always adds the domain to the search list, achieves the desired effect.

Could you please review if the current behavior is expected? It means that MacOS users will not have the search domains set up, at all. There are many threads on various forums on the web where people face this problem. Tunnelblick, on the other hand, supports this.

[d12fk]

Yes, the behavior is expected as it is. Pushed --dhcp-option DOMAIN{-SEARCH} were (ab)used as split DNS domains on macOS historically. If you wanted actual search domains that could be achieved (for one domain only) by pushing a --dhcp-option ADAPTER_DOMAIN_SUFFIX. With the changes in v3.11 you can now control if you want the old behavior or not by setting the client config dhcpSearchDomainsAsSplitDomains as you wish. See client/ovpncli.hpp for a short description. If you want both, multiple split domains and search domains, you might want to take a look at pushing the new --dns option instead. Hope that answers all you questions.

[rhuitl]

Thank you very much! I also found that dns search-domains seems to do the trick. We'll test to push this option from the server in the next days. It doesn't look like I can set it in the local ovpn config file.

[d12fk]

You should be able to set it in the local config file as well, but it's only effective together with a valid --dns server. Thinking behind this is that search domains without an accompanying server make no sense and should not compete with potential --dhcp-options DOMAIN then.

[rhuitl]

That makes sense. We push them via dhcp-options, too:

[dhcp-option] [DNS] [1.2.3.4]
[dhcp-option] [DNS] [5.6.7.8]

So if I understand you correctly, we also (or alternatively) have to push

dns server n address addr[:port] [addr[:port] ...]

so it can take effect.

Maybe we should just do away with dhcp-option and try to use dns exclusively?

[d12fk]

If all of your clients are new enough, that is certainly an option. --dns is fairly new, so it might not be the case. Also there are still discussions going on in the openvpn2 project, whether or not --dns should override
DNS related --dhcp-option settings when both are pushed at the same time. For now it does in openvpn3, but depending on the outcome of the discussion it might not in the future, so pushing both at the same time may produce different results then. A saver approach would be to check the IV_PROTO flags for IV_PROTO_DNS_OPTION_V2 on the server side and pushing the option based on what the client claims to support.