[systemd-devel] About DNS servers and search domains in Router Advertisements

[Patrik Flykt]

	Hi,

On Fri, 2017-09-22 at 17:07 +0200, Lennart Poettering wrote:
> So, of course, people might want arbitrary complex schemes there, but
> I'd probably keep it simple at least in the beginning, and try to be
> as automatic as possible...
> 
> maybe we should have a structure DNSConfiguration or so, which
> carries all DNS servers and search domains acquired from a specific
> source, where "source" refers to either the DNS data attached to an
> interface or DNS data attached to networkd's global configuration or
> DNS data read from /etc/resolv.conf.

That should be the goal. Right now most of the below can be implemented
quite easily:

> When EmitDNS=/EmitDomains= is set we'd try to find the most suitable
> such DNSConfiguration structure and propagate that.

Yes. Here we want to have independent but identical handling of DNS and
Domains.

>  Specifically I figure the most suitable could be the first one we
> find by checking the following list:

The trivial case is that RADV is configured, so as first option we
have:

  0. DNS data configured specifically for RADV

> 1. DNS data configured on the interface the RADV server is on itself,
>    if there is any
> 2. global DNS data configured for networkd in networkd.conf or so, if
>    there is any
> 3. global DNS data configured in /etc/resolv.conf, if there is any
> 4. DNS data of the interface the default route goes to (if this isn't
>    unique, then search through all interfaces and pick the one with
>    the lowest metric on the default route and if that still doesn't 
>    help pick the one with the lowest ifindex
> 5. DNS data of any other interface (if there are multiple, use the 
>    with the lowest ifindex)

>From this list (0.,) 1. and 4. seem trivial to implement, especially
since there already is an manager_find_uplink(). I'll focus on those
two first.

> Or something like that. I figure initially this could be implemented
> much simpler than the list above, but I think such an automatic logic
> would be highly desirable in the long run, because it maximizes the
> chance we can automatically do the right thing...

Yep, I played around at home, and noticed that one indeed wants to
reuse already added configuration items, at least using 1. and 4.
above.

Patch incoming soonishly.


Cheers,

	Patrik