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 for Android: free password hash cracker in your pocket

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

Message-ID: <OF8A941F0F.60C57774-ON88257303.0064A759-88257303.006782B8@us.ibm.com>
Date:	Sat, 23 Jun 2007 11:51:10 -0700
From:	David Stevens <dlstevens@...ibm.com>
To:	Rémi Denis-Courmont <rdenis@...phalempin.com>
Cc:	cananian@...il.com, "C. Scott Ananian" <cscott@...top.org>,
	netdev@...r.kernel.org
Subject: Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration

Rémi Denis-Courmont <rdenis@...phalempin.com> wrote on 06/23/2007 11:13:01 
AM:

>    An implementation might perform additional validity checks on the
>    ICMPv6 message content and discard malformed packets.  However, a
>    portable application must not assume that such validity checks have
>    been performed.

        This doesn't say that unauthenticated packets must be delivered,
and I don't think the portability of an RDNS daemon is an issue. But
even if you really wanted to run the same code on a non-Linux machine,
it just means that your daemon code would have to do its own 
authentication.
Reading /proc or netlink with packet formats you've defined to get this
information is not more portable to non-Linux machines, right?
        I don't see any issue here. If an application is relying on the
ability to see forged packets for portability reasons, it's probably not
an application you want running on your machine. :-)

> That would encourage people into running open recursive DNS servers 
> which is widely known and documented as a bad practice. Definitely a 
> very bad idea.
        I don't understand your point here. I'm talking about client
behaviour, and if the client fails for a server from a downed interface,
I don't see how that's different from removing the client from the
list, which is what you want to do. Nobody should feel encouraged to
do anything different on the server side-- at least not by me!
 
> > But if you really need it, you can monitor netlink, or poll the
> > interface flags on whatever interval you require for detection.
> 
> >         As for autoconf, that's available from sysctl, I assume from
> > /proc somewhere, too. That usually doesn't change, but if you want to
> > account for runtime configuration changes, you can always monitor
> > netlink and reread when new addresses appear, too.
> 
> There are a bunch of parameters that determine whether an interface 
> accepts RAs or not. I doubt it's wise to try to reimplement that into 
> userspace, particularly if it is subject to change.

        I'm not suggesting re-implementing anything; I'm saying you can
read the current state at application level, if you need it. If you
think it's difficult to get the correct information from existing
API's, then improving those API's is always worthwhile. I don't
believe it's excessively difficult to determine if autoconf is in
use, though.

> My point 
> is raw IPv6 sockets are not usable for the time being, and I do not see 
> anyway to fix without modifying the kernel.

I disagree about raw sockets being usable, but "without modifying the
kernel" isn't a constraint.
"modifying the kernel" != "put DNS server info in the kernel";
if there's a bug, or some minor tweaking that'd help the feature along,
I'd support that. The important point for me is that the basic mechanisms
are already in place, and I think it'd be best to use those rather than
creating a new interface for all of this.

> The userspace DNS configuration daemon might need to be started later 
> than the kernel autoconf - another issue that needs help from the 
> kernel.
        Easily done; the init scripts are what bring the interfaces up
in the first place, so start the daemon before those run. Adding an
entry in inittab so it'll be automatically restarted if it dies is also
a reasonable thing. RA's are resent periodically, and they can be lost
anyway, so not the end of the world if you miss one, either.

                                                                +-DLS

-
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