On Fr, 22.09.17 14:07, Patrik Flykt ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
