On 2023-05-09 16:26, Per Jessen wrote:
Carlos E. R. wrote:
/etc/resolv.conf must point only to the local dnsmasq service.
I disagree. This works perfectly fine for me:
It works, but it is not optimal. IMO.
You could try to explain _why_ it isn't optimal. For me, it it 100% optimal:
The resolver tries the following -
* nscd * forwarders per resolv.conf (in order).
The first one is 127.0.0.1, i.e. dnsmasq. Job done.
Only if dnsmasq fails to deliver will the resolver try the remaining forwarders. (which dnsmasq already tried).
I fail to see what is sub-optimal about that.
I want it to fail and report. If dnsmasq is not answering, it is not optimal.
search local.net z.local.net i.local.net nameserver 127.0.0.1 nameserver 192.168.2.254 nameserver 2001:db8:4c68:1::1000
It must not be allowed to point to external servers, because that means that programs (say firefox) may bypass dnsmasq and waste time waiting for the remote server to answer.
I suggest that is plainly wrong. Most applications do not "bypass" dnsmasq, they are not even aware. Applications use the glibc resolver, which works in a well-defined way. For instance, nameservers are tried in the order they are listed. (unless you have specified "options rotate").
Precisely.
Huh? I have just explained why you are wrong and you agree ?? I'll have to make a note in my calendar :-)
The details of how it works are mostly irrelevant, I just want dnsmasq to process and answer all queries, not a backup or external resolver.
Actually, unless "strict-order" is configured, dnsmasq will prefer servers it knows are up. It's not so important though.
Well, as you are excluding the router, I guess it is something specific to your machine, so we can close with "unable to reproduce". I have 25-30 machines with wicked, one with NM. Hmm, I might have a Raspi with NM, not sure.
No, all my machines using wicked show the same behaviour.
Yet you conclude the machines are all wrong ... it can't be some common factor.
"The behaviour" is about the resolv.conf rotating fast. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)