William Ahern <[email protected]> wrote: > 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.
yes, but you missed a piece: /* Eliminate duplicates */ Duplicates should be eliminated when possible, because libc/asr only uses the first 5 addresses I think. Imagine we have a v4 announcement doing 3 addresses, and a v4 "umb" doing 2 addreses, libc will never get around to using a manual entry at the end if those dynamic dns servers are in fact not responding. I was trying to handle that kind of situation heuristically. Maybe we can avoid the address sort, but still attempt to delete duplicate addresses, to increasae the odds of reaching a manual entry. > 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. Naw.... the qsort() is only sensitive to the address to reduce bigO of the duplicate elimination. I think a slightly more clever sort+eliminate chunk of code would do the job.
