Re: The state of resolv.conf

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

 



On Tue, 2008-09-16 at 16:15 +0200, Adam Tkac wrote:
> 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

Yes, this was the idea.

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

Ys you do not get this one from DHCP, but in most cases DHCP serves your
primary interface and so that is the default (if not then we could think
to add per-connection metadata to tell which are the "local networks"
for this connection).
With VPN, in most cases you *have* the remote networks, because you need
them to be able to route anything. It can be just a number of subnets,
or in some case, it can be that the VPN wants to reroute all.
In either case you know what to do. (If the VPN forces to route all
traffic then you have to use the VPN provided DNS for everything).

I believe NM should keep this information around and we should you it to
make the best choice we can.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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