Opened 6 months ago

Last modified 4 months ago

#1209 new Feature Wish

full and consistent support of dhcp-option DOMAIN and DOMAIN-SEARCH

Reported by: gvde Owned by:
Priority: minor Milestone: release 2.5
Component: Networking Version: OpenVPN 2.4.7 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


It would be good if there was a consistent use of the dhcp-option to set the domain name suffix for the connection as well as the domain search list. Currently, it's a mix of using DOMAIN only, using it as connection suffix if it's a single one or using it as search list if there are multiple. Some clients use DOMAIN-SEARCH for search list. However, that's not even in the official documentation. It's really not easy to set this up properly for all kinds of clients if it's not clear from the configuration/server side to start with.

The connection suffix and the search list are two separate things, two separate dhcp options and should be handled separately.

In my opinion, DOMAIN should be the connection suffix as it is described in the documentation, the equivalent of DHCP option 15 Domain Name.

The dns domain search list, i.e. the equivalent of DHCP option 119 Domain Search should be a separate configuration option, e.g. DOMAIN-SEARCH as it is already used by some.

On client side, this should obviously be handled the same way it would be handled if options were not pushed by openvpn but instead the client would actually use DHCP with a DHCP server delivering exactly those two options as described.

Change History (2)

comment:1 Changed 6 months ago by selvanair

I do not think there is any inconsistency in the way --dhcp-option DOMAIN foo is handled within OpenVPN. On OS-es where dhcp-option is internally handled (e.g., Windows) its passed on as option 15. On other systems its in the environment as foreign_option_{n} set to dhcp-option DOMAIN foo.

Possibly scripts like update-resolv-conf handles it differently depending on foo is a single word or multiple words and may need fixing. Contributed scripts like pull-resolv-conf/xxx may also be doing this. But OpenVPN core doesn't make any such distinction. Though, technically, option 15 should be a single word (domain).

As for DOMAIN_SEARCH (option 119), we don't currently support it. AFAIK, until a recent update to Windows 10, this option wasn't correctly handled on Windows which is is relevant as Windows is one of the main platforms where we can internally process dhcp options.

That said, we could add DOMAIN-SEARCH as a new dhcp-option. Users will have to take care to specify DOMAIN (option 15) as a single suffix as systems/scripts may continue to interpret it differently based on single or multiple words.

comment:2 Changed 4 months ago by Gert Döring

Milestone: release 2.5
Type: Bug / DefectFeature Wish

Interesting coincidence. I got the question about "can OpenVPN set the searchlist on Windows?" just a few weeks ago by a local user/admin...

Adding DOMAIN-SEARCH (or however we call it) is not overly hard - it needs clear documentation on the interpretation somewhere, a bit of windows hacking to get the necessary new data type into the DHCP "set up server response" code (it's DNS label compressed...), and update pull-resolv-conf/client.up.

Then, talk to Tunnelblick and the Connect guys :-)

It won't likely happen in the 2.4 scope as it's a new feature and not a bugfix - setting milestone to 2.5

Note: See TracTickets for help on using tickets.