On Tue, Jun 11, 2013 at 09:39:40AM +0800, Chow Loong Jin wrote: > > Shuffled the quotes: > > > The difficulty with plan A is probably B4. Do we have a suitable > > > minimal proxy we can install, a way to reconfigure it based on dhcp > > > etc., and a means to displace it when something more substantial like > > > unbound is installed ? > > I think that unbound actually might be that minimal proxy. When you > > install it along with resolvconf, it will currently place itself in > > /etc/resolv.conf (via resolvconf) as the sole nameserver and it will use > > the name servers that were reported to resolvconf from dhcp or ppp as > > upstream name servers. Another cache with similar capabilities in terms > > of resolvconf integration is pdnsd. (Note that pdnsd doesn't do DNSSEC.) > > For chroots we would likely need a i-know-that-there-is-a-cache package. > If it helps any, NetworkManager in Ubuntu currently sets the hostname in > /etc/resolv.conf to 127.0.0.1 and runs dnsmasq locally. This /etc/resolv.conf is > copied into new schroots, allowing for approach A while allowing for dynamic > manipulation of where the DNS queries go to. Yes. I think the experience with dnsmasq (specifically, NM + dnsmasq-base) in Ubuntu shows that this approach is a good one. Note that this is explicitly *NOT* a caching proxy. Using a local caching proxy without a per-user cache is a security issue. > > Strange thought: Would it be possible (on Linux) to add an iptables rule > > to DNAT the local dns port? That would avoid the need for a proxy > > altogether. > Yes. A significant number of Linux-based consumer routers do this already, but > I'd rather we avoid this route if possible. This makes it rather hard to do > stuff like `dig @$other_server $hostname` for debugging purposes -- you'd need > root access to disengage the DNAT rule first. Not for what he's described. dig @$other_server would still work just fine, you would merely have /etc/resolv.conf pointing at 127.0.0.1 and have the *kernel* handle the DNS forwarding instead of using dnsmasq or another proxy. It does have the advantage of simplicity, but there are some important cases (such as split-DNS over a VPN) that couldn't be handled in the kernel. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature