[384.12_Alpha - builds] Testing all variants.

[Marin]

@L&LD, under Tools, Other Settings:

 

[Marin]

When checked as "Yes":

@RT-AX88U-29F0:/tmp/home/root# nslookup x3mtek.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      x3mtek.com
Address 1: 104.27.173.243
Address 2: 104.27.172.243

vs. "No":

@RT-AX88U-29F0:/tmp/home/root# nslookup x3mtek.com
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      x3mtek.com
Address 1: 104.27.172.243
Address 2: 104.27.173.243

 

[L&LD]

When checked as "Yes":

@RT-AX88U-29F0:/tmp/home/root# nslookup x3mtek.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      x3mtek.com
Address 1: 104.27.173.243
Address 2: 104.27.172.243

vs. "No":

@RT-AX88U-29F0:/tmp/home/root# nslookup x3mtek.com
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      x3mtek.com
Address 1: 104.27.172.243
Address 2: 104.27.173.243

Would one or the other be preferred?

I am liking when it is set to 'Yes'. Very responsive!

 

[Marin]

I used to have same issue from the Stubby days:

https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-73#post-478781

 

[Gar]

More responsive for me too with local cache. I also see some buffering without it enabled.

 

[Butterfly Bones]

Would one or the other be preferred?

I am liking when it is set to 'Yes'. Very responsive!

Does your /etc/resolve.conf change?

/tmp/home/root# cat /etc/resolv.conf 
nameserver 127.0.0.1

 

[L&LD]

Does your /etc/resolve.conf change?

/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1

Yes, it does. The internet feels supercharged now, even with 1Gbps up/down ISP speeds here.

 

[owine]

Keep in mind I believe the reason for the change was that it was reported by some users that changing the setting fixed false negatives from the Network Monitoring features (i.e. WAN showing as Disconnected). Something to keep an eye on. A cached response would make some sense as a culprit.

 

[dave14305]

Would one or the other be preferred?

I am liking when it is set to 'Yes'. Very responsive!

I imagine it will be just as responsive set to No if you manually set a fast reliable DNS server in WAN DNS 1 and 2. Your ISP DNS servers appear slow, or one of them is down and timing out.

There shouldn’t be any performance change for devices behind your router for either setting.

 

[Butterfly Bones]

I imagine it will be just as responsive set to No if you manually set a fast reliable DNS server in WAN DNS 1 and 2. Your ISP DNS servers appear slow, or one of them is down and timing out.

There shouldn’t be any performance change for devices behind your router for either setting.

That is what I see, no real difference either way using Cloudflare DNS.

 

[Xentrk]

I can confirm that setting Connect to DNS Server automatically to No solves the nslookup issue. I always had it set this way with the Stubby installer but left it to the default value of Yes when DoT was implemented in 384.11. Now, when I do an nslookup, 1.1.1.1 is being used and not the DNS of the ISP:

 nslookup x3mtek.com
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      x3mtek.com
Address 1: 104.27.173.243
Address 2: 104.27.172.243

When I go to Tools -> Other Settings and set the local caching to Yes...

nslookup now uses the router loop back address:

 nslookup x3mtek.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      x3mtek.com
Address 1: 104.27.172.243
Address 2: 104.27.173.243

There appears to be the best combination for security and performance.

 

[Gar]

I imagine it will be just as responsive set to No if you manually set a fast reliable DNS server in WAN DNS 1 and 2. Your ISP DNS servers appear slow, or one of them is down and timing out.

There shouldn’t be any performance change for devices behind your router for either setting.

If I use Quad9 I see some buffering without local caching, using CF things are fine but I lose the filtering. Hmm...

 

[L&LD]

I imagine it will be just as responsive set to No if you manually set a fast reliable DNS server in WAN DNS 1 and 2. Your ISP DNS servers appear slow, or one of them is down and timing out.

There shouldn’t be any performance change for devices behind your router for either setting.

That is what I see, no real difference either way using Cloudflare DNS.

Right now, I am using the Cloudflare DNS settings with the 'No' setting and also using the Use local caching DNS Server setting too.

I will change the setting to Connect to DNS Server Automatically to Yes in a few hours (possibly tomorrow sometime) and leave the Use local caching DNS Server set to Yes too and then see if I see a difference.

 

[dave14305]

If I use Quad9 I see some buffering without local caching, using CF things are fine but I lose the filtering. Hmm...

Sounds coincidental but unrelated to the local caching setting. A client that is streaming video isn’t influenced by the setting. Only requests from the router, for the router (not a client) are impacted by the setting (such as nslookup in an ssh session, or in the router GUI Network tools).

 

[Xentrk]

I found the setting

Wan: Use local caching DNS server as system resolver (default: No)

has other consequences. I use the ipset feature inside of dnsmasq to automatically populate IPSET lists when domain names are looked up. This morning, I was helping a user and noticed an issue where the IPSET list was not getting populated when doing an nslookup on the domain name. This had always worked in the past. When I changed the setting above to Yes, the populating of the IP address in the IPSET list for the domain name now occurs when running the nslookup command. I need to find the nvram name for this setting and set it to Yes to during the installation of the x3mRouting project to avoid issues.

 

[dave14305]

I need to find the nvram name for this setting and set it to Yes to avoid issues with the x3mRouting project.

In 384.12 it is dns_local_cache. In .11 and earlier it was dns_local. So you may need to account for both.

 

[Xentrk]

In 384.12 it is dns_local_cache. In .11 and earlier it was dns_local. So you may need to account for both.

Thank you @dave14305

I'll update the install script later today. I am glad you told me about the nvram name difference. I'll have to add a check for the firmware version and set the value accordingly. I was stumped this morning as to why the nslookup on a domain name was not populating the IPSET list and glad to find the reason why. Grateful for all of the help and support!

 

[thelonelycoder]

In 384.12 it is dns_local_cache. In .11 and earlier it was dns_local. So you may need to account for both.

I have both with 384.12_alpha1-g4a8cd4ead5:

user@RT-AC86U:/tmp/home/root# nvram get dns_local_cache
0
user@RT-AC86U:/tmp/home/root# nvram get dns_local
1

Which one is it now?

 

[Adamm]

I have both with 384.12_alpha1-g4a8cd4ead5:

user@RT-AC86U:/tmp/home/root# nvram get dns_local_cache
0
user@RT-AC86U:/tmp/home/root# nvram get dns_local
1

Which one is it now?

https://github.com/RMerl/asuswrt-merlin.ng/commit/de8806990462b8c3dbd4182b4991e31cd082f7fe

As of 384.12 its now dns_local_cache, the old setting still exists in your nvram as Merlin renamed the value to force the new defaults.

 

[thelonelycoder]

https://github.com/RMerl/asuswrt-merlin.ng/commit/de8806990462b8c3dbd4182b4991e31cd082f7fe

As of 384.12 its now dns_local_cache, the old setting still exists in your nvram as Merlin renamed the value to force the new defaults.

That means if dns_local_cache is present, the dns_local can be ignored. No need to check firmware version. Or would one have to check for @john9527 s fork that may have a differing nvram parameter?