Issue with vpn client 'Accept DNS Configuration' parameter

[RMerlin]

Re-reading the strict-order man entry for the tenth times or so, I am even more convinced than before that this option is simply useless, as it does not work the way people expect (it will not guarantee that a given server will be used first, since dnsmasq will always go with what was the last known working server). Therefore I intend to remove the Strict option, and relabel the options:

"Ignore", "Accept" and "Exclusive".

 

[john9527]

Re-reading the strict-order man entry for the tenth times or so, I am even more convinced than before that this option is simply useless, as it does not work the way people expect (it will not guarantee that a given server will be used first, since dnsmasq will always go with what was the last known working server). Therefore I intend to remove the Strict option, and relabel the options:

"Ignore", "Accept" and "Exclusive".

Sorry, but I have to disagree with this one. It's always worked in the way I would expect accessing in order as verified by dumping the dnsmasq stats.

 

[RMerlin]

Sorry, but I have to disagree with this one. It's always worked in the way I would expect accessing in order as verified by dumping the dnsmasq stats.

They aren't processed in reverse orders for you (meaning ISP would be used first)?

One problem with this idea as well is since dnsmasq will always go with the last known working DNS, if the tunnel's DNS fails to respond to a request, it might no longer get used by the tunnel until dnsmasq gets restarted, as dnsmasq would have moved to another DNS (typically your ISP's).

 

[john9527]

They aren't processed in reverse orders for you (meaning ISP would be used first)?

One problem with this idea as well is since dnsmasq will always go with the last known working DNS, if the tunnel's DNS fails to respond to a request, it might no longer get used by the tunnel until dnsmasq gets restarted, as dnsmasq would have moved to another DNS (typically your ISP's).

Let me go back through my notes. I seem to vaguely remember there was a quirk (maybe you had to add the serves in reverse order of how you wanted them accessed??). I found it when I added a hidden option for one of my users who wanted a 'reverse strict' so he could use a local DNS server first and fall back to the VPN servers if his failed.

 

[RMerlin]

Let me go back through my notes. I seem to vaguely remember there was a quirk (maybe you had to add the serves in reverse order of how you wanted them accessed??). I found it when I added a hidden option for one of my users who wanted a 'reverse strict' so he could use a local DNS server first and fall back to the VPN servers if his failed.

That could match the findings posted earlier in this thread.

I had a quick look at my code, and it would require a good bit of refactoring to be able to add the VPN servers at the end of the list rather than the top (since the result of the VPN addition determines how the firmware deals with the ISP servers while writing the resolv file). Just unsure if it's really worth it considering Simon's notes on how unreliable strict-order really is. Imagine that for a few secs none of the VPN-supplied DNS works. Dnsmasq would then fall back to your ISP server, and would always stick to them, until dnsmasq itself gets restarted. That kind of unpredictable behaviour is what makes me doubt the real value in keeping the Strict option there.

In an ideal world, if any server is marked as being "down", dnsmasq would periodically (after a few minutes down) re-test them while in strict mode, and if they come back alive, put them back at the top of the priority list. But considering Simon won't even consider fixing the reverse order parsing, I doubt he'd ever go down that route.

 

[john9527]

nsmasq would then fall back to your ISP server, and would always stick to them, until dnsmasq itself gets restarted. That kind of unpredictable behaviour is what makes me doubt the real value in keeping the Strict option there.

I think the 'stickiness' is disabled when in strict mode.

 

[john9527]

@RMerlin
Decided to do a little testing to check again, and found that the VPN resolv file gen was inadvertently broken when you added the the support for pushing server search domains (and I missed it when I remapped your change). Likely the cause of the problems. I'll send you a patch.

 

[RMerlin]

I just pushed a number of fixes around DNS handling for OpenVPN clients.

1) Swapped order of nameservers so while in strict-order mode, VPN servers will get used first
2) Fixed strict-order not getting enabled in various scenarios, such as changing while the client was running, or enabling then starting it

I've now tested about every scenarios and things looked good:

Starting and stopping in strict-order mode
Changing to and from strict-order mode with a running client

 

[Saturnine]

RMerlin - I'm not sure this is related (and it's a minor issue)...

For whatever reason, likely related to the issues raised in this thread, I get DNS leaks when I set 'Strict' mode. Setting 'Exclusive' fixes this, but has one minor side effect.

The hostname of my router is 'rtr' and the domain is set to home.<mydomain>.com. In 'Strict' mode, this resolves to 10.0.0.1 from my internal LAN. I presume the router itself is resolving this. In Exclusive mode, rtr.home.<mydomain>.com resolves to the public IP address set by DDNS. This means that I can't access the router when on the LAN by using its hostname, presumably due to hairpinning.

Is there any scope for a setting which will resolve locally (but not forward) then fall back to the VPN DNS servers?

Running 384.8_2 on an 86U.

 

[RMerlin]

For whatever reason, likely related to the issues raised in this thread, I get DNS leaks when I set 'Strict' mode. Setting 'Exclusive' fixes this, but has one minor side effect.

Yes, as discussed in this firmware, Strict mode does not use the VPN servers in priority. It also won't prevent clients from using hardcoded nameservers.

Exclusive mode forces the router to use the specified remote server, therefore the router's own DNS server is bypassed. There's nothing that can be done about that.