On Sun, 2005-10-09 at 14:08 -0400, Christopher Aillon wrote: > Have we looked at using dnscache[1] for our caching nameserver? It > seems more lightweight than using bind (without its track record even!) > and seems like exactly what we would want. I haven't looked too much in > detail at it (or bind for that matter), but I think its worth > considering. I wonder if we would get more widespread adoption for it. > > [1] http://cr.yp.to/djbdns/
IIRC, there is some sort of funny licensing issue with that. Debian does not ship binaries, but instead a source package that creates binaries you can install. What about 'dnsmasq' or 'pdnsd', perhaps in combination with 'resolvconf'? Was 'resovconf' thoroughly reviewed, or rejected with prejudice an not even a cursory code view? I really think it's a mistake not to go with 'resolvconf'. I believe the issue had to do with wanting to make it possible for the vpn support to say that lookups within the vpn should only be asked to certain name servers. It would probably not be difficult to make resolvconf able to do that, since each time you send information to it, you also specify the interface that information is to be associated with. There is an "interface-order" file that lists the order in which interfaces DNS information is to be used, so the VPN (perhaps on a tun* interface) can take precedence, perhaps. The lookup can go there first, be turned down for non-VPN names, and go next to the eth* DNS in the normal recursive DNS lookup fashion. That happens once when the dns cache is empty. Oh, I see. That takes only slightly longer, in the human time-frame, as having the name server decide where to ask the lookup, unless the VPN nameserver is down and we have to wait for the full time-out period. At that point, the lookup would cross untrusted networks attempting to locate the name in global DNS. So here, for some high-security applications, you want the name server to make that decision intelligently. (IIRC, dnsmasq may have support for this; it's probably not difficult to implement.) It's the scripts in /etc/resolvconf/update.d etc that determine what is done with that information. The thing is that the nameserver installs a script there that uses that information to build it's forwarders list, and the actual resolv.conf file then contains only 127.0.0.1. It already does this now. If the script for the particular name server or DNS cache can write the right configuration for a name server that has the capability for it, then all's well. It's really not as complicated and lawless as you might think, since to write a script for that, one must review what the scripts that other packages install do. Simply find all packages depending on 'resolvconf', get the source, and read them. It's not difficult to play well with others in that fashion. In my opinion, the more modular "unix style" componentization that resolvconf provides is better than having NetworkManager do all the work in it's own selfish way. Why re-invent the wheel? I can see using other software on my laptop that also needs to update the resolv.conf file. PPPD, is one, dnsmasq is another (I use it's DHCP server on occasion, for user-mode-linux and network booted Debian installer, and love the way it uses /etc/hosts in such a simple way plus has dynamic DNS for DHCP clients). % apt-cache rdepends resolvconf resolvconf Reverse Depends: whereami vpnc udhcpc sendmail-base pump pdnsd netscript-2.4 laptop-net gnome-ppp dnsmasq dnsmasq avahi-dnsconfd squid postfix fetchmail dhcp3-client Q: What if ifupdown had explicit support for working co-operatively with NM, or was rolled into it's own backend style with appropriate extensions and modifications? It really is a very powerful system, and such a nice program design. I like the way he wrote a little language for the various network setup methods. It's really worth a week's study. I will certainly be revisiting it as I study languages and compilers in the future. Extensible software is where it's at. Q: What if 'wpasupplicant' became a .so library that it's daemon uses and that NM can also incorporate, perhaps as a dynamically loadable plug-in? NIH? Don't accuse me of it! Yes, there are only 24 hours in a day. -- Karl Hegbloom <[EMAIL PROTECTED]> _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
