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
