On Wed, May 11, 2022 at 04:54:02PM +0100, james palmer wrote: > i have a local dhcp server running which gives out three nameservers: > > - 192.168.0.2 (resolves some local machine names) > - 9.9.9.9 > - 149.112.112.112 > > on linux, android, and windows the local nameserver takes priority over the > others. > on openbsd thanks to the nameservers being sorted by ip address > 149.112.112.112 is chosen first. > this causes the local machine names to not resolve. > > is there a reason for this behaviour? > i would expect the nameservers to be written in the order they are set as on > the dhcp server.
I have no direct knowledge, but judging from the code in resolvd.c handle_route_message and cmp, the sorting is primarily driven by declared priority of the source--resolvers associated with a higher priority source come first, independent of IP address. However, the relative ordering information among a set of proposed resolvers from a particular routing message seems to be dropped on the floor, no other information is used to sort, and the sort comparator falls back to comparing the address strings (using strcmp) to achieve a stable sort. This could be fixed, assuming the current behavior is broken or undesirable, by adding a new member to struct rdns_proposal recording the relative ordering of proposals within the incoming routing message (i.e. their index in the proposal set), and using that member in the comparator to sort addresses of equal priority before resorting to strcmp on the address string. This presumes the DHCP advertisement order is preserved in the routing message. There other potential nuances, like multiple proposal sets (from different routing messages) with the same priority, in which case a message counter or other mechanism might also be needed to get a more intuitive total ordering.
