> 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.
So maybe the first generation Ted proposes has some problems. And what have YOU DONE recently?? Look, I think some people don't understand the goal. The goal is a privsep layer for the libc resolver, with external communication operating on the other side of a priv boundary. Preventing direct communication to programs, to test their soft underbellies. That is a valuable goal. Maybe YOU trust unbound to do this. Maybe you haven't gotten a grasp of how featuritis is eating it release after release, and the risk of error creeps in constantly. I am also hearing an argument for selective configuration. That's the kind of "remember to compile with the stack protector if you believe in security!" hogwash I heard around 20 years ago. Only make it secure if you need it secure! Get off my computer kidz. We know this program-libc-external-world issue with DNS needs to be solved one day. Requiring deep port 53 invasion into a host or network is patently stupid, yet accepted. As I said, unbound does not solve the problem because the software does 900 other things you don't want. I'm hearing a tone that only people who know how to configure complex situations should be secure. That stands against my principles. For this DNS problem, I think we have a number of new ideas which can fit together to do something great, and we should endeavour to integrate this stuff. That kind of thing does not happen on one round. Such harsh condemnation of the first attempt is seriously contemptable. Take a chill pill, or participate in improving it, or wait your turn. Now to the logic. search won't work in roaming + non-roaming situations. There are solutions being discussed to make that easier, they dovetail into this slightly. For Ted's current proposal I think making this libc:resolver interface communiate via an IP address is the problem. People wish to control policy via their own IP reach policies towards their own nameservers, and 127.0.0.1 is an IP that falls into that catagory of control. For instance, hijacking 127.0.0.1 immediately makes it impossible for rebound to speak to a localhost unbound, I think it is clear this design isn't quite right. If such a twisted configuration can still work, it would indicate we are on the right road. We kind of want a secret direct interface between the resolver library routines and the resolution daemon (or remote one). BTW, it has been done before -- the original Sun ypserv used to do this, and I suppose other systems have done it also. Luckily we already have a mechanism which allows us to know that a DNS lookup is being performed by libc -- the socket has been opened with SOCK_DNS. In some way, those can be directed to a rebound (if it is running) -- which can then do the standard dance of honouring /etc/resolv.conf, just like libc would have. Which would allow all other configurations to work, probably. Yes there are also not-our-resolvers which lack the SOCK_DNS flag. We want to do the right thing there. They would continue to lookup via resolv.conf, and miss out on rebound protection. Eventually when people realize programs-speaking-to-rebound prevent a host from selectively filtering port 53 to only one program (rebound), then maybe they'll want to fix those other programs/libraries. It is a long road. I don't know these ideas creates new problems. We'll just have try them out. But throwing them under the bus with +1's is basically the 'get off my lawn" argument. But at least I'll try to engage in constructive arguments with Ted, because if we can pull this cleanly it will be great.
