This diff doesn't set rtm_index (to identify the interface the dns proposal is associated with)
I guess that means rtm_index is 0. Inside resolvd, the proposal rtm_index is used to track proposals in the learned[] array. resolvd uses if_indextoname() to annotate the interface name on these dynamic lines with "# resolvd: em0". Using 0 means if_indextoname() will fail, and it will write "# resolvd: ", I guess? If multiple agents start offering proposals with the same rtm_index + family, things get a little weird. What would isakmpd or some other vpn layer do if they want to start doing the same as this iked diff -- would they also submit rtm_index 0? The code cannot disambiguate/sort/select from the proposals with the same id#, so all such offers will act as a single proposal, and I think whoever submits the latest will win the fight. That might behave weirdly. So, does the route message need an extension to indicate "who" is making the offer, or should iked (ando other vpns) have unique RTP_PROPOSAL_* identifiers, and then we can have resolvd mix that into the sort also?
