Hi BIRDies,
I was playing with RA and DNSSL options today. I found the order of DNSSL
options generated unhelpful.
My config looks something like this:
```
protocol radv {
dnssl {
domain "global1.example";
domain "global2.example";
};
interface "enp2s0" {
dnssl {
domain "interface.example";
};
};
}
```
and I see the following RA options being generated (as shown by rdisc6):
DNS search list : global1.example global2.example
DNS search list lifetime: 1800 (0x00000708) seconds
DNS search list : interface.example
DNS search list lifetime: 1800 (0x00000708) seconds
I tested with dhcpcd and rdnssd and saw problems with both: 1) dhcpcd
outright doesn't support multiple DNSSL options so I only got the first one
in /etc/resolv.conf (working on reporting) and 2) rdnssd supports this but
the list in /etc/resolv.conf ends up being:
search global1.example global2.example interface.example
While rdnssd's behaviour seems in-line with RFC 8106 it's not what I wanted
to achive overall.
See section 6.3. "Synchronization between DNS Search List and Resolver
Repository", https://datatracker.ietf.org/doc/html/rfc8106#section-6.3.
> [...] it stores the DNSSL domain names (in order) [...]
My goal was to have interface.example be the LAN domain (i.e the first in
the search list) and the rest of the domains last in the search list.
Admittedly this is a weird use-case and global dnssl was probably just
intended for the simple case of all interfaces having the same search
domain.
If I had multiple LANs and corresponding domains I would not be able to
share the list in the global dnssl option anyway, this really only works
with LAN domains and network-wide search domain in the global list.
I know I can fix this using the `dnssl local` switch (I tried and it works
as expected), but perhaps a new option to give the order I want would be
useful for others?
Thanks,
--Daniel
