Bryan Steele [bry...@gmail.com] wrote: > On Thu, Sep 15, 2016 at 10:14:51AM -0400, Ted Unangst wrote: > > Florian Obser wrote: > > > Not everything listening on localhost port 53 is a recursive resolver. > > > nsd(8) per defaults listens on 0.0.0.0 and will respond with REFUSED for > > > almost every query. asr stops in that case and does not try the next > > > resolver in the list. > > > > Ah! There's the catch. The good news is I think we can still bind to > > localhost:53 if nsd is on *:53 (right?). This matters if rebound isn't > > listening. > > Perhaps I'm confused, but what happens when rebound is stopped by the > user or it crashes? I think that would mean requests would fallback to > nsd on *:53 which as Florian mentioned, would not try the next > nameserver in resolv.conf. >
This entire discussion is bat-shit crazy to me! Adding secret nameservers to resolv.conf is plain wrong. Hijacking the libc resolver is an approach for systemd, not OpenBSD. I already configure special nameservers on certain machines, that bind to 127.0.0.1, for my own reasons. In a general sense, when I configure the system to do something, and it does something different, I now have to recompile libc. What !??!?! This point that has been reached in this discussion just reinforces the idea that this approach is wrong. The sensible thing to do is add a 'search' parameter to resolv.conf. If programs parse resolv.conf themselves, and they break, we should fix them. It seems like the default should be 'search rebound file bind' and 'search rebound bind file' if no 'lookup' keyword is specified. Most users won't ever have 'search rebound' visible in their resolv.conf. That rebound acts like a nameserver is what prompted the idea to hijack the resolver. But it's really a tool that takes over certain duties from the libc resolver, so the libc resolver should be properly configurable to hand over duties, or not. 'search' is the logical place for this. Chris
