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