On 2023/04/12 13:20, Theo de Raadt wrote: > Stuart Henderson <stu.li...@spacehopper.org> wrote: > > > On 2023-04-11, Theo de Raadt <dera...@openbsd.org> wrote: > > > Kaya Saman <kayasa...@gmail.com> wrote: > > > > > >> This somehow is overriding my resolv.conf file; another words the > > >> information is *not* being used from resolv.conf and is instead being > > >> used from the ipcp negotiation as part of the pppoe kernel module. > > > > > > then the pppoe code should submit a RTM_PROPOSAL route message ... > > > > it does. > > > > i still don't see how this information can *override* resolv.conf > > But I do not understand what "override" means. resolvd intentionally > has NO MECHANISM to allow choice, the list of addresses is chosen by a > fixed internal heuristic, INTENTIONALLY without configuration knobs. > There is one knob: If one doesn't want resolvd semantics, stop the > daemon. So easy. But by default, the system runs with it, because > that means 99% of users get the semantics which satisfy 99% of > users without having to handle a configuration file. > > What I don't understand from the complaint is why that ppooe dynamic > address doesn't rise to the top of the file, because dynamic requests > of that kind always rise to the top. Therefore they get used. > > So if it isn't in the file, then something else has been broken, probably > by the user, right? > > But it is probably best to ignore this entire discussion because some > piece of configuration has been done to BREAK the default behaviour, > and then the user owns all the pieces. > >
There is a complication in Kaya's case because if my handle on the config is correct, there are likely to be nameservers learned from both DHCP (in one rdomain) and PPPOE (in another), but they won't work on the opposite connection. In this situation I would disable resolvd (and for the sake of an easy life, probably use some public resolver accessible from both ISPs).
