Re: The state of resolv.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux