On 04/10/17 22:45, Nathan Sullivan wrote: > Hi Simon, > > It looks like there was a regression introduced in v2.69, specifically > the commit: > > commit d68c2ca2b7896d6127f9b32d402f299e0b9cf593 > Author: Simon Kelley <si...@thekelleys.org.uk > <mailto:si...@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 :) >
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.
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss