Re: The state of resolv.conf

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

 



On Tue, Sep 16, 2008 at 09:46:08AM -0400, Simo Sorce wrote:
> On Tue, 2008-09-16 at 15:09 +0200, Adam Tkac wrote:
> > On Tue, Sep 16, 2008 at 05:01:29AM -0500, Callum Lerwick 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.
> > 
> > If NM and routes go away I think you don't need DNS at all ;)
> 
> Well if you use NM only to manage your networks that is true, although
> that's not the only way (and I also have VMs with virttual networks on
> my laptop :-)
> 
> > If you are interested only in caching why you cannot use nscd?
> 
> Not all programs use nscd as not all type of queries can be fulfilled by
> the glibc interface. For example SRV/TXT records ...
> Also nscd is not smart enough to understand network condition and adapt
> it's behavior.

Right you are.

> 
> > I have creation of NM support to BIND in TODO
> > (https://bugzilla.redhat.com/show_bug.cgi?id=441057) but I haven't got
> > time for it yet. If vpnc/openvpn will interract with NM then you can ask
> > NM for DNS servers for every interface and then use them as "forwarders"
> > in BIND. Additionaly you can get advantage of DNSSEC aware resolver.
> 
> I am not concerned about the DNS server used to do this. It would be
> nice tho if bind could consult different DNSs based 1) on the DNS name
> to be queried, and B) the reverse IP to be queried.
> 
> IE when I connect to the RedHat VPN in some case I would like to have
> all .redhat.com DNS queries sent to the RH DNS servers and all others
> sent to my normal network DNS. Also for reverse lookups I'd like to send
> to the RH network only the networks RH do manage, and not any other
> networks in the world.
> 
> This will allow me to make efficient use of the VPN, and when I am on
> slow links allows me to send non-RH queries to the local, much faster
> DNS server instead of piping them through the VPN.
> 
> If you have multiple VPNs set up you can see how this becomes important,
> esp. if each site you are connected to has its own DNS with private
> views available only to internal clients.
> 

Yes, it will be nice feature to use the closest nameserver. But it is
very difficult to get this information automatically (if you are
using "static" nameserver configuration you could configure forward
zones and it will work well).

One solution, in theory, might be use information from DHCP:
- get per-device DHCP information and export it (NM)
- get "preferred" domains from search/domain directives from DHCP
- for that domains use servers whose are on same network interface as
  domain

With reverse lookups situation is far more difficult - I can't see
any solution how get potential per-interface candidates from DHCP.

Adam

-- 
Adam Tkac, Red Hat, Inc.

-- 
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