dhcpcd-discuss

On 26/09/2018 00:11, Stuart Henderson wrote:
> On 2018/09/24 19:14, Roy Marples wrote:
> > On 24/09/2018 16:39, Klemens Nanni wrote:
> > > On Mon, Sep 24, 2018 at 02:20:30PM +0100, Roy Marples wrote:
> > > > I also find it rather odd that you even need to run dhcpcd for DNS as the
> > > > slaacd man page states it supports RFC 8106 which is all about DNS in the RA
> > > > and nothing else.
> > > While slaacd parses RDNSS and DNSSL, it does not touch /etc/resolv.conf to avoid
> > > inteference with dhclient as of now.
> >
> > Then it's man page should at least be updated to reflect this.
>
> Perhaps something more is needed but the manual doesn't usually list what
> something _doesn't_ do - currently it's "slaacd derives IPv6 addresses and
> default routes from received router advertisements and installs them in
> the kernel" so I don't see anything suggesting that it handles resolv.conf.

In STANDARDS it says:
J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, IPv6 Router 
Advertisement Options for DNS Configuration, RFC 8106, March 2017.

It does not mention resolv.conf specifically but it does mention it 
supports DNS. A casual reader might find that somewhat misleading as it 
implies it will configure DNS somehow.
> I think I may propose something like 'It also stores information about
> DNS resolvers and domain search list for retrieval with slaacctl(8)'
> though I don't know if it will be accepted.

In NetBSD we sometimes have a BUGS section:

slaacd does not configure DNS in resolv.conf

slaacctl(8) also makes no mention of it outputting any DNS information.

> > And maybe prod OpenBSD into solving it - a solution to this would be to
> > implement resolvconf. NetBSD and FreeBSD use openresolv for this
> > (disclaimer, I maintain it alongside dhcpcd so there is some bias).
> > https://roy.marples.name/projects/openresolv
> >
> > CCing Stuart as he might know who to prod for this.
>
> This problem has been discussed internally a bit but we don't have
> anything usable. It would need to take input from dhclient [either
> resolv.conf or a lease file], umb(4) [USB MBIM mobile broadband devices,
> which are handled in-kernel and have their own mechanism to fetch ns
> addresses], slaac, and maybe others [vpn etc]. Most of these do not have
> a way to write a resolv.conf file at all - and for some like umb(4),
> doing so would be quite a stretch.
>
> I think the general direction we were looking at was some kind of route
> socket message to send a DNS server advertisement and some kind of
> daemon to select from these and update resolv.conf. This is the sort of
> thing that usually gets whiteboarded at hackathons and I haven't been
> to all that many recently so am probably a bit behind what's happening
> there.

However the internals work, I strongly recommend a resolvconf front end 
to it. A lot of 3rd party software supports it.

I find this daemon idea interesting, but it sounds like over-engineering 
for what it fundamentally does. How you might want to extend it will be 
interesting also - for example, resolvconf can configure a more powerful 
forwarder such as unbound to setup forward zones for specific requests 
from say a VPN config.

> > > > Is there a compelling reason why you need to run both? Either dhcpcd or
> > > > slaacd should be fine.
> > > Because slaacd comes with base, is enabled by default and runs with privilege
> > > separation.
> > >
> > > dhcpcd running as root should only do what's necessary.
>
> I don't understand why someone would run both for two parts of the same
> thing (i.e. handling router advertisements on the same interface).
> If you're going to trust dhcpcd to parse rdnss fields and write files,
> why not let it configure addresses too.

I agree with this.

> > There was also a discussion about doing priv-sep in dhcpcd here:
> > https://roy.marples.name/archives/dhcpcd-discuss/0002137.html
> >
> > But it come to nothing as no-one said if my idea was good or bad. One
> > commentor offered to at least do a small related patch, but that didn't
> > materialise, thus it has stalled as I personally have little interest in the
> > feature.
>
> My last attempt at implementing privsep (porting the privsep code from
> OpenBSD's old version of BIND to a newer one) didn't exactly go well
> so I don't feel too qualified to comment on whether an approach is good
> or not ;)

Well, that explains the silence on the matter. But then at least you've 
seen code and stuff, I am merely theorizing at this stage.

> > Anyway, my OpenBSD vm is currently down so I can't test the attached diff,
> > but it should fix your problem. Please test it and let me know.
> >
> > Roy
>
> > diff --git a/src/if-bsd.c b/src/if-bsd.c
> > index cdd959a6..c1a6be86 100644
> > --- a/src/if-bsd.c
> > +++ b/src/if-bsd.c
> > @@ -1393,8 +1393,20 @@ set_ifxflags(int s, const struct interface *ifp)
> >   	/*
> >   	 * If not doing autoconf, don't disable the kernel from doing it.
> >   	 * If we need to, we should have another option actively disable it.
> > +	 *
> > +	 * OpenBSD moved from kernel based SLAAC to userland via slaacd(8).
> > +	 * It has a similar featureset to dhcpcd such as stable private
> > +	 * addresses, but lacks the ability to handle DNS inside the RA
> > +	 * which is a serious shortfall in this day and age.
>
> (fwiw, the kernel-based one didn't support rdnss either..)

The kernel didn't support stable private addresses either to the best of 
my knowledge, but I don't think anyone expects the kernel to write to a 
userland file ..... they would expect userland to, hence the comment.

> > +	 * Appease their user base by working alongside slaacd(8) if
> > +	 * dhcpcd is instructed not to do auto configuration of addresses.
> >   	 */
> > -	if (ifp->options->options & DHCPCD_IPV6RS)
> > +#if defined(ND6_IFF_ACCEPT_RTADV)
> > +#define	BSD_AUTOCONF	DHCPCD_IPV6RS
> > +#else
> > +#define	BSD_AUTOCONF	DHCPCD_IPV6RA_AUTOCONF
> > +#endif
> > +	if (ifp->options->options & BSD_AUTOCONF)
> >   		flags &= ~IFXF_AUTOCONF6;
> >   	if (ifr.ifr_flags == flags)
> >   		return 0;
>
> What option would you suggest for "allow dhcpcd to do DHCPv6-PD and leave
> RA handling entirely to the OS"? I'm currently using noipv6rs for that
> which works with the current code, but is broken with that diff. I'm
> happy to change my config (which is also in the port's "pkg-readme") if
> there's something better.

That's a fair point.
New diff attached which disables autoconf and reqdns on the safe side.
Should work now, let me know.

Roy

diff --git a/src/dhcpcd.c b/src/dhcpcd.c
index 2985ed35..55558c3c 100644
--- a/src/dhcpcd.c
+++ b/src/dhcpcd.c
@@ -451,6 +451,10 @@ configure_interface1(struct interface *ifp)
 		ifo->options &=
 		    ~(DHCPCD_IPV6RS | DHCPCD_DHCP6 | DHCPCD_WAITIP6);
 
+	if (!(ifo->options & DHCPCD_IPV6RS))
+		ifo->options &=
+		    ~(DHCPCD_IPV6RA_AUTOCONF | DHCPCD_IPV6RA_REQRDNSS);
+
 	/* We want to setup INET6 on the interface as soon as possible. */
 	if (ifp->active == IF_ACTIVE_USER &&
 	    ifo->options & DHCPCD_IPV6 &&
diff --git a/src/if-bsd.c b/src/if-bsd.c
index cdd959a6..c1a6be86 100644
--- a/src/if-bsd.c
+++ b/src/if-bsd.c
@@ -1393,8 +1393,20 @@ set_ifxflags(int s, const struct interface *ifp)
 	/*
 	 * If not doing autoconf, don't disable the kernel from doing it.
 	 * If we need to, we should have another option actively disable it.
+	 *
+	 * OpenBSD moved from kernel based SLAAC to userland via slaacd(8).
+	 * It has a similar featureset to dhcpcd such as stable private
+	 * addresses, but lacks the ability to handle DNS inside the RA
+	 * which is a serious shortfall in this day and age.
+	 * Appease their user base by working alongside slaacd(8) if
+	 * dhcpcd is instructed not to do auto configuration of addresses.
 	 */
-	if (ifp->options->options & DHCPCD_IPV6RS)
+#if defined(ND6_IFF_ACCEPT_RTADV)
+#define	BSD_AUTOCONF	DHCPCD_IPV6RS
+#else
+#define	BSD_AUTOCONF	DHCPCD_IPV6RA_AUTOCONF
+#endif
+	if (ifp->options->options & BSD_AUTOCONF)
 		flags &= ~IFXF_AUTOCONF6;
 	if (ifr.ifr_flags == flags)
 		return 0;