Open mlen opened 4 years ago
concept: approved! finer details: may need more careful selection ability, see #131 where control of the advertising address is desirable.
As an alternate solution, on my own networks, In addition to the ::
, I explicitly advertise a /64 ULA from fc00::/7 and use that network for DNS & some local-only traffic. The DNS server process binds to (ULA)::53
, which is advertised from RDNSS, so it's easy to spot traffic when I tcpdump
as well
I would very much like this feature on my home network, and for what's it worth would consider contributing a reasonable moderate bounty in any shape of form appreciated, to get this FR implemented :wink:
On Fri, Jan 07, 2022 at 05:53:17AM -0800, Nicolas Dumazet wrote:
... would consider contributing ...
Just do it
@nicdumz: Have you progressed on your request?
@nicdumz does PR above implements feature you are requesting?
@bl00mber above PR is for CoreRAD. (Arguably one could migrate from radvd to CoreRAD to get those features, true, but outside of the scope of this FR ;-) )
I'd be willing to give this a try. Is this still open?
That said, my review of this suggests that any solution needs a selection method that will know how to select the DNS address being advertised at runtime versus a static one specified in the configuration. My thinking is it could be the first address on the given interface that matches the chosen network address. And then a method to detect changes so the address can be updated as it changes over time.
Hi @braewoods, if you are still available for this task, I'd like to provide suggestions regarding what you mentioned.
First, the change notification part should already exist as we currently have the "prefix ::/64 {}", "AdvSourceLLAddress on", and "AdvRouterAddr on" features, which also need this information. For the address selection, if multiple addresses are present, a sane default would probably be to use all of them (or whatever logic the formerly mentioned three features currently use). And just a note, even using a schema like the one suggested by @robbat2 probably wouldn't be flexible enough for every case (as multiple ULA and GUA can be present, like in multi-homing cases or when one address gets deprecated). Still, it could be a good starting point. This should cover 80-90% of this problem.
But for "the best" solution, we probably need some runtime flexibility in the long term, like when a SIGUSR1 is received to re-read the config file, a UNIX socket that allows dynamic reconfiguration at runtime, and/or dbus, but that's probably only to cover a small number of use cases. That runtime flexibility would allow writing hooks, e.g., dhcpcd or even things like netbox.
Since the use case here is a dynamic prefix, it might be simplest to allow specifying a static address suffix to be combined with the announced prefix to form the RDNSS address.
The DNS resolver doesn't necessarily run on the same host as radvd. Even if it did, it's simple enough to configure the host's static suffix.
radvd supports selecting the prefix automatically when
::/64
is used as a special value, however only static IPs are supported in RDNSS messages.I think it would be a useful feature to support a special value like
::
for RDNSS to pick one non-link-local IP assigned to the interface and use it as the actual value.This would allow to run the DNS server on the same machine without having to hardcode the IP (that could change any time).