[Dev][Feedback] Changing DNS behaviour on router

[Vexira]

Know other ISPs still using this?

There are a few in Australia that requires tagging of sorts a vlan tag.

 

[ColinTaylor]

There are a few in Australia that requires tagging of sorts a vlan tag.

We're talking about VPNs not VLANs.

 

[Vexira]

We're talking about VPNs not VLANs.

Sorry half asleep

 

[themiron]

Know other ISPs still using this?

beeline has more 2 million of customers in ru, I think it's more than enough, not counting multiple smaller isps.
as for other countries, heard about some in CIS, Israel, France

 

[RMerlin]

beeline has more 2 million of customers in ru, I think it's more than enough, not counting multiple smaller isps.
as for other countries, heard about some in CIS, Israel, France

2 Millions is a drop in the ocean, therefore I stand by my "not many ISPs" claim.

 

[themiron]

2 Millions is a drop in the ocean, therefore I stand by my "not many ISPs" claim.

two users from this thread are indeed a drop.

let me rephrase, fw has bug with any isp l3 vpn services that needs fqdn server address, official fw has it fixed.
millions users with multiple isps in multiple countries are potentially suffering from this.
one-two (from this thread) users (capable to workaround) will potentially suffer from separate dnsmasq's and system resolver nameserves.
see, millions uncapable to fix that vs two who can setup anything via console.

 

[themiron]

also, with dns probing enabled it checks local dnsmasq for the response, not any real isp /whatever dns.
this could potentially bring issues with some unusual dnsmasq configurations, i.e huge fixed cache ttl or even absence of dns probe target.

what if make special settings alike existing "Wan: Use DNS probes to determine if WAN is up (default: Yes)" with reasonable defaults for the most?
i.e "dns_local=0" /* use local dns for system resolver */.

 

[RMerlin]

let me rephrase, fw has bug with any isp l3 vpn services that needs fqdn server address, official fw has it fixed.

That remains to be proven. Last time it was actually broken, I got users contacting me about it, at which point I fixed it.

I need to setup a test VM to act as a DHCP + PPTP server to confirm whether or not it's broken. I should have more time soon to look into this as I'll be on vacation next week.

I also need to test DNSFilter, which might likely be interfering as well, depending on whether it's up in the intermediary stage, or only at the final stage of the connection establishing.

also, with dns probing enabled it checks local dnsmasq for the response, not any real isp /whatever dns.
this could potentially bring issues with some unusual dnsmasq configurations, i.e huge fixed cache ttl or even absence of dns probe target

Not a problem, dns.msftncsi.com has a TTL of 25 seconds (which is why a Windows PC is still able to determine if it's connected or not even if the PC's DNS is set to point at the router rather than the ISP server.)


I'm not saying that if there is an issue I don't want to fix it. Just that I need first to confirm whether or not there truly is an issue, and determine which would be the best way to fix it. I'm not willing to blindly go for the easiest route, and fix one issue by creating another one. I consider the fact that stock firmware cannot resolve LAN hostnames to be a bug as as well.

 

[themiron]

I need to setup a test VM to act as a DHCP + PPTP server to confirm whether or not it's broken. I should have more time soon to look into this as I'll be on vacation next week.

but why? logic in rc is pretty clear (update_resolvconf) regarding how dns are managed. please look at the code.

Not a problem, dns.msftncsi.com has a TTL of 25 seconds (which is why a Windows PC is still able to determine if it's connected or not even if the PC's DNS is set to point at the router rather than the ISP server.)

unfortunately not so easy. dnsmasq's cache ttl can be changed with options, therefore it's possible that dns_target gets stuck in dnsmasq's cache, which, as we know, had bugs in the past already. 127.0.0.1 nameserver in resolv.conf means dnsmasq is actually checked by wanduck, not WAN connection, therefore it might not trigger demand connection if configured so.

so, see, some things are broken (pptp/l2tp/vpnc + dnsfiler), others are potentially broken with simple (from the first view) change isp dns to local dnsmasq.
hidden dependencies (dnsmasq config/malfunction/etc <> wan down redirection) could bring pain to debug, and I think this is one of reasons why option to disable dns probing was introduced - workaround for workaround, which actually needs another workaround

I'm not saying that if there is an issue I don't want to fix it. Just that I need first to confirm whether or not there truly is an issue, and determine which would be the best way to fix it. I'm not willing to blindly go for the easiest route, and fix one issue by creating another one. I consider the fact that stock firmware cannot resolve LAN hostnames to be a bug as as well.

stock firmware doesn't use hostname resolving of dhcp clients via system resolver, your fw as well.
if, for whatever reasons one need it - it's possible:
1) enter 127.0.0.1 to wan dns via web ui
2) edit /etc/resolv.conf from post-firewall script
3) switch to local resolver via options as I suggested earlier, tbd
all this for ones who understand using dnsmasq as system resolver limitations, of course, and really need it.

 

[sfx2000]

Heya,

I am considering reverting back resolv.conf to match what Asus uses in stock firmware, which is to always use the DNS servers rather than 127.0.0.1 (which means always use dnsmasq). Primary reason would be this might be more robust for weird ISPs who use a DHCP + VPN type of architecture (as after the DHCP lease is obtained, it typically uses a special "temporary" DNS server that can resolve the ISP's PPTP/L2TP hostname).

The primary side effect of this is the router itself will no longer be able to resolve LAN hostnames. The most visible effect for end user is netstat-nat (on the webui) would no longer resolve LAN IPs into LAN hostnames (but it would still work for public hostnames).

Any impact on the existing scripts out there that are run on the router itself? Does any of these require to be able to resolve LAN IPs and hostnames?

I think this is probably ok - and for reasons that I shouldn't probably disclose, other than it makes sense from a security perspective... and as you mention, the whole DHCP+VPN thing would be more robust.

Resolving local devices/hosts can be handled easily with avahi and the dot-local TLD there...

 

[dvohwinkel]

This change would not affect LAN clients resolving hostnames (internal or external). Just when the router itself wants to resolve a hostname (e.g. for firmware update check).

I normally point local machines's dns to the router and secondary dns to 8.8.8.8.. is that bad?

 

[ColinTaylor]

I normally point local machines's dns to the router and secondary dns to 8.8.8.8.. is that bad?

Your question is off-topic, but to answer it anyway... It's probably OK and not "bad". But the exact behaviour is down to the client not the router. For example this is Windows' behaviour. Also consider that if your router's DNS server has stopped responding then there's likely to be a more general problem with the router or your internet connection. In such a case 8.8.8.8 is probably unreachable as well.

 

[NGRhodes]

Could it be made switchable ?

 

[RMerlin]

Could it be made switchable ?

Feature bloat, would confuse users, and I'd end up constantly answering questions about it (see what happened with the QoS overhead parameters...).

 

[RMerlin]

I spent some time configuring a Linux server on my LAN that reproduces how Beeline works (i.e. it issues a DHCP lease, and provides an internal DNS server that allows to resolve a PPTP hostname, used to setup the VPN tunnel that ultimately connects you to the Internet). The good news is, the process is working properly without the need for resolv.conf to point at the ISP-provided DNS. Making that change would only serve in improving robustness (tho I haven't been able to create any particular scenario where this would make a difference), therefore there's no real need to change the default behaviour.

The current tentative plan is to leave the current behaviour as it is by default, but add an option on the "Hacks and Tweaks" section of Tools -> Other Settings that would allow changing behaviour to have resolv.conf point at the ISP's nameservers instead, which would reproduce the behaviour of the stock firmware, at the expense of losing LAN hostname resolution on the router itself. I might possibly add a warning on the WAN page, advising people using DHCP+VPN to look at that setting if they are experiencing any connectivity/stability issues with their ISP.

Since the default behaviour would remain unchanged, then I won't have to deal with a constant stream of support questions regarding this parameter - just like I don't provide any support for any of the other settings available in that Tweaks section.

Setting up that VM was an "interesting" project BTW, spent an entire evening getting it up and running on my Quotom Xen host. Came in handy that this Quotom has four distinct NICs