[Dnsmasq-discuss] Change in behaviour of --server

[Petr Menšík]

Hi Simon,

would you please tag another test version after fixing build of dbus
builds? I tried building a test package for Fedora [1], but I would have
to backport dbus fixes. No recent test release works with dbus enabled,
which is required on Fedora.

Thanks!

Cheers,

Petr

1. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/build/2312608/

On 7/6/21 10:23 PM, Simon Kelley wrote:
> On 06/07/2021 12:14, Kevin Darbyshire-Bryant wrote:
>> Hi Simon,
>>
>> An eager OpenWrt tester of current dnsmasq master has noticed the following change in behaviour:
> I have to say, I am very much liking the amount of testing that the new
> code is getting. It's great to find these regressions _before_ release.
>
>> 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/
>>
> The order is irrelevant. What matters is the type of configuration. This
> is defined so that, for instance,
>
> --address=/example.com/1.2.3.4
> --server=/example.com/8.8.8.8
>
> will return 1.2.3.4 to an A query, but forward any other queries to 8.8.8.8
>
> The priority order is
>
> IPv6 address
> IPv4 address,
> all zeros address (--address=/example.com/#)
> NXDOMAIN address (--address=/example.com/#/ or --local or --address)
> send to an upstream server.
>
> The order of the last two was arbitrary: I hadn't considered a situation
> in which
>
> --server=/example.com/#/
> --server=/example.com/8.8.8.8
>
> would both exist, and that order is what came out of the implementation
> most easily.
>
> Since doing that is a regression for earlier releases, and you've
> demonstrated how the previous behaviour _can_ be useful, I'm happy to
> swap the priority of the last two items in my list.
>
>
> 719f79a8fdb7cc72a061b2492ea98f7486b6f90e
>
> does the deed.
>
>
>> (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?)
> After 719f79a8fdb7cc72a061b2492ea98f7486b6f90e, that's exactly what will
> happen.
>
> In general the new code makes servers for particular domains first-class
> citizens, so you can specify more than one and dnsmasq will load-balance
> across them in the same way it does for the general upstream servers.
>
>
>
> Cheers,
>
> Simon.
>
>> 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: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB