The state of resolv.conf

[Paul Howarth]

Nils Philippsen wrote:
> On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote:
>> On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote:
>>> Wouldn't the best way be to have an api that can be used to add and
>>> delete DNS servers and manipulate resolv.conf. Then we could have
>>> deamons call that.
>> No what you really need is more than a simple resolv.conf file.
>>
>> We need a default caching daemon (which by itself will solve a lot of
>> other issues) that tools like NM, vpnc, openvpn can interact with.
>> These tools will tell the caching daemon which IP ranges and which
>> domains their provided forwarders should be consulted for. All dynamic
>> so that as soon as one daemon goes away, the caching DNS will notice and
>> revert queries to the default DNS. And if NM/routes go away it can keep
>> working out of its cache.
> 
> Definitely. The current way of modifying resolv.conf sometimes leaves
> behind the VPN setup (without VPN connection) and is generally
> unflexible. Ideally, it should be something which isn't restricted to
> class A/B/C like reverse DNS (seems to be), but which would route DNS
> requests based on arbitrary domain name or IP-range criteria to the
> desired name servers.

Another problem with modifying resolv.conf is that most processes only 
read it once, usually shortly after starting up, so any changes that 
happen after that don't get picked up by existing processes. So for 
instance you could have a web browser that couldn't resolve names from a 
VPN tunnel that had been brought up after the browser had been started.

Paul.