[Openvpn-devel] man: extend description for "dhcp-option DNS" on Windows

Message ID 20230905211357.581-1-a@unstable.cc
State New
Headers show
Series [Openvpn-devel] man: extend description for "dhcp-option DNS" on Windows | expand

Commit Message

Antonio Quartulli Sept. 5, 2023, 9:13 p.m. UTC
From: Antonio Quartulli <antonio@mandelbit.com>

Add an important detail about the DNS configured via this option
to be an "interface-specific" DNS. This detail is important when
troubleshooting DNS issues since this logic will bypass the
routing table.

Signed-off-by: Antonio Quartulli <antonio@mandelbit.com>
---
 doc/man-sections/vpn-network-options.rst | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Selva Nair Oct. 5, 2023, 7:03 p.m. UTC | #1
Hi,

On Tue, Sep 5, 2023 at 5:41 PM Antonio Quartulli <a@unstable.cc> wrote:

> From: Antonio Quartulli <antonio@mandelbit.com>
>
> Add an important detail about the DNS configured via this option
> to be an "interface-specific" DNS. This detail is important when
> troubleshooting DNS issues since this logic will bypass the
> routing table.
>
> Signed-off-by: Antonio Quartulli <antonio@mandelbit.com>
> ---
>  doc/man-sections/vpn-network-options.rst | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/doc/man-sections/vpn-network-options.rst
> b/doc/man-sections/vpn-network-options.rst
> index b7f33acd..17c7d4a2 100644
> --- a/doc/man-sections/vpn-network-options.rst
> +++ b/doc/man-sections/vpn-network-options.rst
> @@ -158,6 +158,12 @@ routing.
>          Set primary domain name server IPv4 or IPv6 address.
>          Repeat this option to set secondary DNS server addresses.
>
> +        On Windows this option sets an "interface-specific" DNS, meaning
> +        that the system will try to reach it via the VPN interface,


even if the routing table says otherwise.


> If the wanted DNS is not
>

If the desired DNS server is not

+        expected to be reached via VPN, please don't use this option, but
>

please don't --> do not


> +        rather set the DNS manually (or via DHCP).
>

delete "rather"


> +
>          Note: DNS IPv6 servers are currently set using netsh (the existing
>          DHCP code can only do IPv4 DHCP, and that protocol only permits
>          IPv4 addresses anywhere). The option will be put into the
>

That said, I'm not convinced this is the right way to document this. IMO,
using "--dhcp-option DNS n.n.n" to set a DNS server not reachable through
the tunnel is a misuse of that option on any platform.

Even on "non-windows" one shouldn't do that as it's very reasonable for a
script that handles it to set it on the interface, instead of globally, if
the platform permits it. For example, using systemd-resolved on Linux
(though I'm not totally sure how exactly interface-specific DNS works in
this case).

So, if at all, why not state that the DNS server specified here should be
reachable through the tunnel irrespective of the platform?

Regards,

Selva
Antonio Quartulli Oct. 5, 2023, 9:39 p.m. UTC | #2
Hi,

On 05/10/2023 21:03, Selva Nair wrote:
[cut]

Thanks fr the feedback on the context of the patch.

> That said, I'm not convinced this is the right way to document this. 
> IMO, using "--dhcp-option DNS n.n.n" to set a DNS server not reachable 
> through the tunnel is a misuse of that option on any platform.
> 
> Even on "non-windows" one shouldn't do that as it's very reasonable for 
> a script that handles it to set it on the interface, instead of 
> globally, if the platform permits it. For example, using 
> systemd-resolved on Linux (though I'm not totally sure how exactly 
> interface-specific DNS works in this case).
> 
> So, if at all, why not state that the DNS server specified here should 
> be reachable through the tunnel irrespective of the platform?

Well I simply want to document the current behaviour (we spent a few 
hours debugging this situation because the documentation wasn't clear 
enough).

On Linux at the moment you can pass any DNS and, like you said, the user 
script will do something with it. On Windows, this is not the case and I 
simply want to note this down.

If you think we should accept only VPN-reachable IPs (which may make 
sense, although some people do crazy things and may not like it), then 
we should change the code in order to reject anything that cannot be 
routed through the VPN. But so far OpenVPN has always left the 
responsibility to the user/admin to make sure that all pieces will fit 
together.

So instead of forcing any semantic, I think we should simply document 
what the code does.

Cheers,

> 
> Regards,
> 
> Selva

Patch

diff --git a/doc/man-sections/vpn-network-options.rst b/doc/man-sections/vpn-network-options.rst
index b7f33acd..17c7d4a2 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -158,6 +158,12 @@  routing.
         Set primary domain name server IPv4 or IPv6 address.
         Repeat this option to set secondary DNS server addresses.
 
+        On Windows this option sets an "interface-specific" DNS, meaning
+        that the system will try to reach it via the VPN interface, no
+        matter what the routing table says. If the wanted DNS is not
+        expected to be reached via VPN, please don't use this option, but
+        rather set the DNS manually (or via DHCP).
+
         Note: DNS IPv6 servers are currently set using netsh (the existing
         DHCP code can only do IPv4 DHCP, and that protocol only permits
         IPv4 addresses anywhere). The option will be put into the