dnsmasq setting clarification - IPv4 address and strict-order
1. On the Setup tab for my account, under Linked IP it lists these DNS servers:
But under Setup Guide, if you select Linux (or Routers), for dnsmasq (and stubby, knot, etc.) it lists these DNS servers:
I went with the .0 servers and it seems to be working okay. But I was wondering, maybe I should be using .64, was I given .64 for load-balancing purposes and the guide for dnsmasq just didn't update?
2. In the Setup Guide for dnsmasq it asks for strict-order and lists 188.8.131.52 before 184.108.40.206 (I don't have IPv6 so I left that out). Is the intent to mainly use 220.127.116.11, and only use 18.104.22.168 if it doesn't respond? dnsmasq unfortunately seems to ignore the order, here is the order they appear in my dnsmasq.conf:
but here is what the log shows on startup
Dec 9 14:00:51 dnsmasq: using nameserver 22.214.171.124#53
Dec 9 14:00:51 dnsmasq: using nameserver 126.96.36.199#53
and here are the statistics
Dec 9 21:10:16 dnsmasq: server 188.8.131.52#53: queries sent 20537, retried or failed 2668
Dec 9 21:10:16 dnsmasq: server 184.108.40.206#53: queries sent 2854, retried or failed 6
So it's definitely preferring 220.127.116.11. I think I would probably get better performance if it would prefer 18.104.22.168 since my ping there is about half what it is to 22.214.171.124
vultr-sea 27 ms
■ anexia-yto 31 ms (secondary)
vultr-yto 32 ms
vultr-chi 55 ms
zepto-ymq 59 ms
■ zepto-xrs 65 ms (primary)
vultr-sjc 69 ms
do-sfo 71 ms
vultr-lax 72 ms
anexia-lax 73 ms
zepto-lax 80 ms
Not that the performance is bad or anything. But again I was wondering if I should try to prefer 126.96.36.199 for load-balancing purposes or something.
I guess for issue #2 there is probably no fix other than to report it to dnsmasq, or use something else.
The non .0 IPs are only useful for the Link IP feature. If you are using DoH or DoT (or even EDNS0 CPE ID with dnsmasq), the .0 IPs should be used. Note that the last byte of the IPv4 does not change anything to the routing or server selection.
The 3rd byte (28 or 30) defines the primary and secondary server pool. We designed them so they use different providers, different network routes etc. One might give slightly better performance than the other depending on your origin network and location, but in your case, the latency difference is not big, it won't make much difference. The goal is to offer two really different redundant destinations, so if one route would break, the other would likely not.
If you want to prefer 30, try put it last with strict-order.