On 7/9/21 11:57 PM, Simon Kelley wrote: > On 09/07/2021 11:26, Petr Menšík wrote: >> Hi, >> >> just personal opinion. I think all described variants should end with >> configuration error. Desired behavior conflicts for all types. I see no >> reason to have both at the same time when only one can be active. If we >> care much about specific use case, it should print at least warning >> visible in dnsmasq --test output. I would exit with fatal and require >> user to specify clearly what is desired. Leaving only one variant >> without caring about their order. Just comment out the line you do not >> want active. >> >> As a minimum, it should warn there are conflicting orders for a single >> domain. > > Order doesn't matter. As a general rule, and with very few exceptions, > order of configuration _never_ matters in dnsmasq. > > The conflict is defined by priority; > > --server=/example.com/1.2.3.4 > > always has higher priority than > > --address=/example.com/ > > I think that's pretty reasonable.
Is it? Administrator requested both forwarding example.com to 1.2.3.4 and sending NXDOMAIN for the name. Whatever priority it takes, one of them would be ignored and behaves like only one of these lines were specified. Administrator should know that just by checking dnsmasq.conf. Citing man page: --address=/example.com/ is equivalent to --server=/example.com/ Why would have forwarder IP higher priority than authoritative NXDOMAIN response? It would be opposite way on common server with authoritative zone such as bind9. Authoritative zone answers have higher priorities than forwarders. I think conflicting instructions should not be silently ignored to avoid confusion, especially those provided explicitly by the user. I think it is not well specified in manual page. Instead of describing arbitrary priorities, I would request user to specify only non-conflicting configuration. > > > Cheers, > > Simon. > > > >> Cheers, >> >> Petr >> >> On 7/6/21 1:14 PM, Kevin Darbyshire-Bryant wrote: >>> Hi Simon, >>> >>> An eager OpenWrt tester of current dnsmasq master has noticed the following >>> change in behaviour: >>> >>> Openwrt uses a conf file containing a list of RFC6761 domains that are >>> considered undesirable to forward, reducing load on upstream servers etc. >>> This conf file contains lines such as "server=/onion/“. Said user >>> overrides this with a line in main config file >>> ’server=/onion/127.0.0.1#2053’. Unfortunately current dnsmasq looks >>> through its servers and returns ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, >>> I’ll forward that to 127.0.0.1#2053’ >>> >>> The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 >>> config file - 2) Take advantage of new syntax and use >>> ’server=/*.onion/127.0.0.1#2053’ >>> >>> I’m flagging this as a change in behaviour and I’m not sure how >>> syntactically it can or even should be fixed, or just documented as a >>> change in behaviour. eg. >>> >>> Should there be a difference (& what should it be) between >>> >>> --server=/onion/ >>> --server=/onion/127.0.0.1#2053 >>> >>> (forward to 127.0.0.1#2053) >>> >>> and >>> >>> --server=/onion/127.0.0.1#2053 >>> --server=/onion/ >>> >>> (not sure!) >>> >>> or even worse >>> >>> --server=/onion/127.0.0.1#2053 >>> --server=/onion/ >>> --server=/onion/127.0.0.1#2153 >>> >>> (use both #2053 & #2153?) >>> >>> Cheers, >>> >>> Kevin D-B >>> >>> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >>> >>> -- >>> Petr Menšík >>> Software Engineer >>> Red Hat, http://www.redhat.com/ >>> email: pemen...@redhat.com >>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
