What's new

[384.12_Alpha - builds] Testing all variants.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
If the router uses WAN DNS directly, no more dependency on Dnsmasq and potential conflicts with NTP (e.g. all those custom configs to resolve pool.ntp.org with 1.1.1.1). No more worries about Stubby or DNSSEC working if NTP isn’t synced yet. The router will do DNS monitoring directly to the internet instead of through dnsmasq, although that 127.0.1.1 in resolv.conf is counter to this idea.

The downside is the inability for the router to resolve local client names if that’s important to you or your scripts.
Wouldnt a simple fix be to simply add 127.0.0.1 as a name server aswell since stubby is already a part of the mix too?
 
If the router uses WAN DNS directly, no more dependency on Dnsmasq and potential conflicts with NTP (e.g. all those custom configs to resolve pool.ntp.org with 1.1.1.1). No more worries about Stubby or DNSSEC working if NTP isn’t synced yet. The router will do DNS monitoring directly to the internet instead of through dnsmasq, although that 127.0.1.1 in resolv.conf is counter to this idea.

The downside is the inability for the router to resolve local client names if that’s important to you or your scripts.
Thanks, Dave. I’ll set it to “No” for now. Don’t notice any difference, so will just keep it at the new default for now. My setup is just DoT, with DNSFilter set to Router—so pretty much a vanilla setup here.
 
Last edited:
  • Like
Reactions: Gar
If the router uses WAN DNS directly, no more dependency on Dnsmasq and potential conflicts with NTP (e.g. all those custom configs to resolve pool.ntp.org with 1.1.1.1). No more worries about Stubby or DNSSEC working if NTP isn’t synced yet. The router will do DNS monitoring directly to the internet instead of through dnsmasq, although that 127.0.1.1 in resolv.conf is counter to this idea.

The downside is the inability for the router to resolve local client names if that’s important to you or your scripts.
so how would you be able to test if your router is able to resolve local client names?
 
so how would you be able to test if your router is able to resolve local client names?
Host name resolution is rarely used on a small network. If you had a need for host name resolution you could use a wins server.
 
Host name resolution is rarely used on a small network. If you had a need for host name resolution you could use a wins server.
or from my understanding you could just define in dnsmasq what you want to use to do local hostname lookups.
server=/yourlocaldomain/#
local=/yourlocaldomain/
 
or from my understanding you could just define in dnsmasq what you want to use to do local hostname lookups.
server=/yourlocaldomain/#
local=/yourlocaldomain/
It's easier to just set the option to Yes. :D
 
but with it defined under dnsmasq.conf you can have whatever you want in resolv.conf for dns resolvers , using these extra lines in dnsmasq.conf it tells it to use the local cache for local clients
 
but with it defined under dnsmasq.conf you can have whatever you want in resolv.conf for dns resolvers , using these extra lines in dnsmasq.conf it tells it to use the local cache for local clients
Gotcha!
 
i imagine it would be something like
server=/router.asus.com/127.0.0.1
local=/router.asus.com/

but i have no real way to test.
 
i imagine it would be something like
server=/router.asus.com/127.0.0.1
local=/router.asus.com/

but i have no real way to test.
Me either as I have no scripts dependent on host name resolution.
 
I’ve haven’t changed this setting since running Merlin and always had it on “Yes”. I run DoT now. Guess I will stay were I’m at. Being a novice to networking and since I’m running DoT, the comment in the commit would have swayed me to set it to “No”.



Lot’s of great people here with networking experience. I read and appreciate all of your great posts. Thank you all.
Me too. No dcd crashes with Diversion+pixelserv-tls.
I'm still getting the dcd crashes. Diversion, scknet, jrfresh scripts running. No VPN.
 
so how would you be able to test if your router is able to resolve local client names?
Since router.asus.com is in the hosts file, it wouldn't be a valid test, but pick a client name and run nslookup on the router with both options set and compare the results:

nslookup myhomepc.home.lan
Wouldnt a simple fix be to simply add 127.0.0.1 as a name server aswell since stubby is already a part of the mix too?
Then you're back to using dnsmasq for DNS, negating the change in the setting.
 
Since router.asus.com is in the hosts file, it wouldn't be a valid test, but pick a client name and run nslookup on the router with both options set and compare the results:

nslookup myhomepc.home.lan

Then you're back to using dnsmasq for DNS, negating the change in the setting.
I see your point as far as name servers go, from my understanding it will use what ever gets listed first and the others would be fall back , correct me if i am wrong. @dave14305

for example when you select No as an option
resolv.conf

becomes
Name server Wan1 DNS
Name server Wan2 DNS
Name server 127.0.1.1

wouldn't these be used in order.--- so Wan1DNS would be the primary, and the rest would be fallback?

kind of like
Name server Wan1DNS Wan2DNS 127.0.1.1

I did do the test. nothing i've been able to do has made it use nothing but the primary name server for resolver, probably have to do more as far as defining addresses and host inside dnsmasq to really get it to work correctly, so i will stick with the easy "Yes" option.
 
Last edited:
I see your point as far as name servers go, from my understanding it will use what ever gets listed first and the others would be fall back , correct me if i am wrong. @dave14305

for example when you select No as an option
resolv.conf

becomes
Name server Wan1 DNS
Name server Wan2 DNS
Name server 127.0.1.1

wouldn't these be used in order.--- so Wan1DNS would be the primary, and the rest would be fallback?

kind of like
Name server Wan1DNS Wan2DNS 127.0.1.1

I did do the test. nothing i've been able to do has made it use nothing but the primary name server for resolver, probably have to do more as far as defining addresses and host inside dnsmasq to really get it to work correctly, so i will stick with the easy "Yes" option.
Yes, barring a timeout on the first entry, it will rarely use the other entries, if at all. No round robin like Stubby.

I like the idea of the router having dns independent of the dns clients use, so the router will continue to resolve if dnsmasq and/or stubby fails. This is a case where it may be better for the router not to eat its own dog food.
 
Yes, barring a timeout on the first entry, it will rarely use the other entries, if at all. No round robin like Stubby.

I like the idea of the router having dns independent of the dns clients use, so the router will continue to resolve if dnsmasq and/or stubby fails. This is a case where it may be better for the router not to eat its own dog food.
i see the name server 127.0.1.1 as redundant, because i cannot see it falling back to that and resolving properly if it had to, but in theory i don't see this happening unless you don't have an internet connection.
 
i see the name server 127.0.1.1 as redundant, because i cannot see it falling back to that and resolving properly if it had to, but in theory i don't see this happening unless you don't have an internet connection.
I wonder if @themiron can explain the design decision to include it in /tmp/resolv.conf.
 
i see the name server 127.0.1.1 as redundant, because i cannot see it falling back to that and resolving properly if it had to, but in theory i don't see this happening unless you don't have an internet connection.
If you reboot with DoT active, do WAN DNS entries disappear from the file? I’m Away from home for the week so I can’t test it myself. I seem to remember that the contents might change after a reboot.
 
it stays because the router relies on the WAN DNS for the local look ups( network monitoring, things like that ). If you choose to automatically get dns then it uses ISP DNS
 
just curious...

Anyone know where this rules come from?
This rules are generated when router reboot or manually execute service restart_wan.
And with service restart_firewall, this rules disappear.
I don't enable any iptv related option.
Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    32 ACCEPT     igmp --  eth0   any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth0   any     anywhere             base-address.mcast.net/4

Chain PREROUTING (policy ACCEPT 229 packets, 15898 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth0   any     anywhere             base-address.mcast.net/4

from mcpd
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top