netdev - Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1182737851.16455.3.camel@xo-13-A4-25.localdomain>
Date:	Sun, 24 Jun 2007 22:17:31 -0400
From:	Dan Williams <dcbw@...hat.com>
To:	"C. Scott Ananian" <cscott@...top.org>
Cc:	Rémi Denis-Courmont <rdenis@...phalempin.com>,
	David Stevens <dlstevens@...ibm.com>, netdev@...r.kernel.org
Subject: Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS
	autoconfiguration

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html