[OpenWrt-Devel] [LEDE-DEV] RFC netifd: UCI parameter to sort name servers in resolv.conf.auto

[Hans Dedecker]

On Mon, Sep 5, 2016 at 3:23 PM, Kevin Darbyshire-Bryant
<kevin at darbyshire-bryant.me.uk> wrote:
>
>
> On 05/09/16 13:49, Hans Dedecker wrote:
>
> On Mon, Sep 5, 2016 at 1:49 PM, Jo-Philipp Wich <jo at mein.io> wrote:
>
> Hi Hans,
>
> imho it would also make sense to take any existing metric setting into
> account as well. At least I'd expect that if I have a wan1 with metric
> 10 and a wan2 with metric 20 that the DNS server entries "inherit" the
> same weight/order.
>
> So priority wise I'd first order by dns metric, then by interface
> metric, then by name - does that make sense to you?
>
> OK I see your point; if the dns metric is equal for the name servers
> the interface metric
> is used as extra sorting criteria.
> I would definitely like to define a dns metric parameter as you don't
> need to define an
> interface metric if you make use of seperate routing tables.
> On existing configs using interface metrics this could to a change in
> behavior as the DNS
> server order can be changed when upgrading; this is acceptable ?
>
> Hans
>
> The dnsmasq manpage has this to say about resolution order:
>
> -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 --all-servers
> By default, when dnsmasq has more than one upstream server available, it
> will send queries to just one server. Setting this flag forces dnsmasq to
> send all queries to all available servers. The reply from the server which
> answers first will be returned to the original requester. So unless you use
> '--strict-order' the order in resolv.conf.auto isn't going to make any/much
> difference.
>
And that's the case you excactly want to solve when you have a main
and backup interface in use or give prio to an IPv4/IPv6 DNS server.
In such a scenario you won't configure dnsmasq in forward-all but in
strict order mode as you don't want to use the name servers of the
backup interface. Operators typically don't like DNS servers being
polled in parallel for performance reasons ....

Also man page about resolv.conf mentions if there're multiple servers
the resolver library queries them in the order listed.
Now Lede uses dnsmasq but what holds the future ?
imo it's more safe to have a mechanism in place in netifd which allows
you tweak the order of the dns nameservers in the resolv.conf file but
I agree you still need to configure dnsmasq in strict-order.

Hans
> Kevin
>
>
> Regards,
> Jo
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel