On Sat, 2007-06-23 at 10:47 -0400, C. Scott Ananian wrote: > Rémi and Simon give my responses very eloquently. Although you could > have yet-another-network-daemon redundantly process RA messages, the > kernel is doing it already and it makes sense to just push this > information to userland using /proc and/or netlink. Although parsing > RA messages and processing expiry in userland looks barely-possible > now, SeND support is really necessary for long-term IPv6 security, and > duplicating SeND functionality in userland would be a nightmare. > Futher, the neighbor discover protocol involves Router Solicitation > messages which elicit the Router Advertisement reply, and we really > don't want userland sending redundant Router Solicitation messages > around, just because the kernel doesn't want to tell it what Router > Advertisements it received. I considered storing the *complete* > Router Advertisement messages received and pushing them unparsed to > userland, just to get around the bogus "DNS in the kernel" politics > (hint: it's not a resolver in the kernel, it's just nameserver > addresses being stored). Does anyone really suggest that this would > be a better solution? > > The goal is to push the userland component into glibc, likely through > a NSS resolver plugin. Current glibc doesn't do any processing to > determine when /etc/resolv.conf has changed, which is a problem for
The glibc guys rejected things like periodically stat()-ing resolv.conf. The standard solution to this has been to push the responsibility for noticing resolv.conf changes to _each_ _app_, which must periodically call _res_init() to get glibc to re-read resolv.conf and notice any changes. This is what eg Mozilla/Firefox and other internet-type apps do right now. Or, run a caching nameserver and point resolv.conf to 127.0.0.1, or use nss_lwres, which hopefully is in much better shape than it was a year or two ago (ie, actually respecting TTL and such). Dan > long-running applications. Exporting RDNSS-in-RA via netlink messages > (or by poll() on a /proc file as is done for /proc/<pid>/mounts, which > was suggested in linux-kernel) is an elegant solution that (as Rémi > noted) cleanly handles interface up/down/reconfig, route expiration, > and (eventually) the cryptographic neighbor discovery protocol without > weaving a web of hairs from the kernel to the resolver. > --scott > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
