you can reboot, wait for things to settle, browse to someplace new or do an nslookup, in the router CLI do cat /var/log/dnsmasq, and look at the last part of the output for DNSmasq activity relating to the new lookup, you can see (*) that the old behavior (for me 46816 and earlier) of using the ZZ.ZZ.ZZ.ZZ server first has changed (for me 48141). DNSmasq now uses the XX.XX.XX.XX server first. If you picked a domain to look up that is a bit slow to resolve, so that the request to XX.XX.XX.XX times out, you'll see it query YY.YY.YY.YY, and if that times out, ZZ.ZZ.ZZ.ZZ as well.
Re the logging: the =extra gives you the query numbers to make it possible to associate all the lines that relate to a particular query. And you don't want to leave loq-queries there permanently, as the log file will grow insanely large. Specifying a log file but not log-queries is fine, as the log entries are modest in number. (Smaller routers may or may not have this logging capability. I have no idea.)
Summary: Strict Order is not newly broken. It is newly fixed, as having to put the server= lines in reverse order was always bizarre. That quirk is now gone. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
@eibgrad, I read your comments, I fully agree, that is why we stopped using strict order it is just unreliable I also saw that more than one DNS servers is hit despite strict-order
Yeah, I sort of assumed you'd be on top of it. Once I got done w/ this issue on Merlin, I was going to look into dd-wrt too, just to be sure. Good to know it's NOT an issue w/ dd-wrt.
Joined: 16 Nov 2015 Posts: 6447 Location: UK, London, just across the river..
Posted: Fri Jan 28, 2022 20:21 Post subject:
I'm sorry to jump in this thread, just to add...
Stubby users are not affected by the strict order bug, as Stubby manages DNS queries by 'round robin=1' or its internal strict order way, 'round robin=0'...
So DNSmasq 'strict order' option is not been in use anyway...you can turn it off, as Stubby overlays it with its own queries algorithm as a stub resolver.. _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
FWIW, I use no-resolv and have never seen a leak. My three DNSCrypt DNS providers are all that get used. Re Strict Order or not, some time ago I added iptables rules to count packets to each of my three DNS providers. Checking just now, I see since my last boot earlier this afternoon:
2567 packets to primary DNS via UDP
399 packets to primary via TCP
97 packets to secondary DNS via UDP
0 packets to secondary via TCP or to tertiary, either UDP or TCP
My interpretation is that this is pretty close to strict. I don't find it implausible that 4% of Quad9 (primary) responses are too slow to avoid triggering a query to the secondary DNS provider. I do also use DNSSEC with full checking of unsigned replies, the time and packet-count burdens of which are not crystal clear to me, though I assume they are significant. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
The problem we have w/ ALL the tomato variants (FreshTomato, Merlin, etc.) is they have a long tradition of supporting four (4) different DNS configurations! Exclusive, Strict, Relaxed, and Disabled. And it's confusing to most ppl (even me) to have all these options (even w/ the Exclusive option, the behavior can vary depending on whether or NOT you're using PBR). And in the case of Merlin, it's possible to have up to five (5) concurrent OpenVPN clients, all w/ their own DNS preferences!
I wish it was more like dd-wrt and the router just reconfigured DNSMasq to use the VPN's server's DNS servers and be done with it. IOW, you get what you get. At least then how the router behaves becomes comprehensible and predictable. But right now, I doubt most ppl truly understand the consequences of all these options. Sometimes having too many options defeats the purpose of a GUI.
