[Dnsmasq-discuss] Regression of server= order (2.69)

[Nathan Sullivan]

Hi Simon,

It looks like there was a regression introduced in v2.69, specifically the
commit:

commit d68c2ca2b7896d6127f9b32d402f299e0b9cf593
Author: Simon Kelley <***@thekelleys.org.uk>
Date: Tue Feb 18 22:30:30 2014 +0000

Cleanup of server reading code, preparation, for dynamic reading from
files.

Where if you use a list of explicit server= lines with strict-order (and
no-resolv), they were previously selected in a top-down manner.

These are now selected in a bottom-up manner, which is the reverse of what
you would want (basically selecting the least preferred server first).

See the gist here for steps to reproduce:
https://gist.github.com/DanielRussell/57ea022c95f56255fb7fc336a367b265

This was identified by my colleague Dan Russell + myself after finding
issues with recursive query performance following a dnsmasq upgrade. We
then noticed in our debug log stats that all queries were hitting the last
server configured.

If you can spot the culprit and apply a fix it would be appreciated :)

Regards,

Nathan Sullivan.

[Simon Kelley]

Post by Nathan Sullivan
Hi Simon,
It looks like there was a regression introduced in v2.69, specifically
commit d68c2ca2b7896d6127f9b32d402f299e0b9cf593
Date:   Tue Feb 18 22:30:30 2014 +0000
    Cleanup of server reading code, preparation, for dynamic reading
from files.
Where if you use a list of explicit server= lines with strict-order (and
no-resolv), they were previously selected in a top-down manner.
These are now selected in a bottom-up manner, which is the reverse of
what you would want (basically selecting the least preferred server first).
See the gist here for steps to
reproduce: https://gist.github.com/DanielRussell/57ea022c95f56255fb7fc336a367b265
This was identified by my colleague Dan Russell + myself after finding
issues with recursive query performance following a dnsmasq upgrade. We
then noticed in our debug log stats that all queries were hitting the
last server configured.
If you can spot the culprit and apply a fix it would be appreciated :)

This is arguably not a bug, since dnsmasq doesn't make any promises
about what order it uses server= lines, just the servers it reads from
/etc/resolv.conf


-o, --strict-order
By default, dnsmasq will send queries to any of the upstream servers it
knows about and tries to favour servers that are known to be up. Setting
this flag forces dnsmasq to try each query with each server strictly in
the order they appear in /etc/resolv.conf

Which makes a certain amount of sense, since he order of the servers in
/etc/resolv.conf does matter to the libc resolver, so strict-order
replicates that. Dnsmasq configuration files don't in general have any
dependencies on the order of items, or at least there are no promises
based on that order. Since the equivalent of server=.... can also be
dynamically installed via the DBus, it's not even obvious that there is
a defined order for all the server lines, let alone that there's a
semantics to that order.

It's simple to change the order for the simple case, but not so obvious
what can be promised as the semantics of this, especially in the more
complex case involving DBUS, and included config files.

Cheers,

Simon.