On Mon, Jun 10, 2013 at 09:45:35PM +0200, Helmut Grohne wrote: > [...] > > A. resolv.conf is a static file which changes only very rarely. > > Implications: > > 1. Existing DNS client applications do not need to change. > > 2. DNS service should always be provided at a fixed address > > 3. Therefore in the default installation this address should > > refer to localhost. Otherwise it cannot be redirected later > > as the network environment or installed package set changes. > > 4. Therefore in most installations there should be a local > > proxy or cache. It should use DHCP-provided, PPP-provided or > > similar, as a forwarder. The local DNS provider address > > should be owned by whatever proxy or cache is installed. > > So here we would likely introduce a virtual package, local-dns-resolver. > Likely resolvconf would depend on it. It would be provided by name > servers, that bind to localhost by default. > > 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. > 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. This setup should only be used for administrators who want to completely forbid their users from querying other DNS servers (short of starting a tunnel somewhere else). > [...] -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: Digital signature