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

[Lennart Poettering]

On Fr, 22.09.17 14:07, Patrik Flykt (patrik.flykt at linux.intel.com) wrote:

> 
> 
> 	Hi,
> 
> Now that we have Router Advertisements and are able to also send
> statically configured DNS servers and DNS search domains, I wonder
> which set of DNS servers makes most sense to automatically add in
> Router Advertisements.
> 
> The current status quo is DHCPv4, where one can configure the use of
> the uplink DNS servers by setting EmitDNS=true and leaving DNS= server
> list empty in the DHCPServer section. The easy way out is to define the
> same variable and behavior for Router Advertisements, but what about
> the other DNS servers that may be specified in other interfaces'
> .network files or received via DHCP over these interfaces?
> 
> For example, there might be an interface that is neither the default
> uplink, nor the current interface that is sending Router
> Advertisements, but it nevertheless has DNS servers configured. Such
> DNS servers are not considered by the DHCPv4 server at the moment,
> might there have been a sinister plan behind this behavior?

Not really, I figure this is just an oversight...

> One thing that cannot be added automatically to networkd are of course
> the DNS servers configured directly to resolved.conf or any fallback
> DNS servers. In addition, since search domains can also be sent, the
> same policy is applicable to them - or is it? If we figure out what the
> policy for DNS search domains is, the search domains should of course
> also be sent out in DHCPv4 server messages.

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. When EmitDNS=/EmitDomains= is set we'd try
to find the most suitable such DNSConfiguration structure and
propagate that. Specifically I figure the most suitable could be
the first one we find by checking the following list:

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 one
   with the lowest ifindex)

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...

Lennart

-- 
Lennart Poettering, Red Hat