Post by Patrik Flykt
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
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...
Post by Patrik Flykt
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 Poettering, Red Hat