On Sun, Aug 21, 2016 at 08:36:51PM -0600, Theo de Raadt wrote: > It has been discussed a few times, but no complete plan has formed. > > It is a mix of problems. If rebound is running you want libc to use > rebound's data. If rebound is not running it should work as before > (at least until we come up with a firm plan). rebound needs to be > pointed at the right sources which requires colating the information > from the various input sources (dhcp, umb(4), rtsol, etc) and then > hook them up. And detect when results become wrong, and deal with a > variety of startup or failure conditions. > > We've observed others building overly complicated solutions for this, > and not been satisfied by those solutions. > > Something interesting happened in the last year which could play an > interesting part. The introduction of pledge(2) led to cooperation > between our resolver (libc/asr) and the kernel -- DNS sockets are > tagged with SOCK_DNS. We could play some sort of redirection game in > the kernel, and leave resolv.conf as the file that libc observes. > That could be a piece of the puzzle.
Ah - thanks! I look forward to finding out what the future implementation will end up being. The whole concept of rebound seems like a neat idea. The last couple years have been really exciting to follow :) The progress made with tame/pledge has completely blown me away.
