Discussion:
About DNS servers and search domains in Router Advertisements
(too old to reply)
Patrik Flykt
2017-09-22 11:07:58 UTC
Permalink
Raw Message
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?

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.


Cheers,

Patrik
Lennart Poettering
2017-09-22 15:07:06 UTC
Permalink
Raw Message
Post by Patrik Flykt
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...
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
--
Lennart Poettering, Red Hat
Patrik Flykt
2017-09-29 10:26:10 UTC
Permalink
Raw Message
Hi,
Post by Lennart Poettering
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
Post by Lennart Poettering
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.
Post by Lennart Poettering
Specifically I figure the most suitable could be the first one we
The trivial case is that RADV is configured, so as first option we
have:

0. DNS data configured specifically for RADV
Post by Lennart Poettering
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.
Post by Lennart Poettering
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

Loading...