6.2 starts nsd before slaacd binds ipv6 address

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

6.2 starts nsd before slaacd binds ipv6 address

lists+misc
Hello all -

I don't feel this warrants a bug report, but nevertheless feel that this
behavior is inconsistent with the way dhclient works.  I have a vultr
server running nsd/OpenBSD 6.2, and I suspect that the move to slaacd
from kernel code in 6.1 is what has broken my nsd config (it fails to
start on boot now).

Vultr uses dhcp/autoconf for ipv4/ipv6, and nsd worked perfectly on
OpenBSD 6.1.  In my nsd.conf, I specify the outbound ipv4/ipv6
addresses, and the idea is that the interface addresses are assigned
before nsd is started.  This was the case in oBSD 6.1.  However, in 6.2,
it seems that slaacd is assigning the ipv6 address after nsd starts.
This leads to error messages such as:

nsd[15166]: xfrd: could not bind source address:port to socket: Can't assign requested address

I've gotten around this by using the ipv4 address for xfr's, and having
nsd listen on ::1@8053 (unbound has :53) for ipv6 & redirecting with pf.

I *think* the proper behavior should be that daemons wait on slaacd to
attempt to solicit/bind first, similar to dhclient.

I do admit that I've been tinkering with ipv6 a lot lately and twisting
all the knobs, but hopefully this is helpful info as we transition more
ipv6 dominant internet.

Reply | Threaded
Open this post in threaded view
|

Re: 6.2 starts nsd before slaacd binds ipv6 address

Florian Obser-2
On Mon, Oct 09, 2017 at 06:31:06PM +0000, [hidden email] wrote:
> Hello all -
>
> I don't feel this warrants a bug report, but nevertheless feel that this
> behavior is inconsistent with the way dhclient works.  I have a vultr

there is a school of thought that says dhclient should not delay the
boot process until it has a lease (or times out after what? 30
seconds?)

> server running nsd/OpenBSD 6.2, and I suspect that the move to slaacd
> from kernel code in 6.1 is what has broken my nsd config (it fails to
> start on boot now).

sure, you got lucky before, the kernel did the stateless address
auto configuration dance faster and won the race against nsd.
slaacd is losing. But if your router solicitations had been
delayed nsd might have one the race against the kernel...

>
> Vultr uses dhcp/autoconf for ipv4/ipv6, and nsd worked perfectly on

Uhm, no. vultr *supports* dhcp/autoconf. But they assign a static v4
address and a v6 /64 subnet from which you are free to choose any
address(es) you want.
They tell you that you get your gateway from router advertisements in
v6.

> OpenBSD 6.1.  In my nsd.conf, I specify the outbound ipv4/ipv6
> addresses, and the idea is that the interface addresses are assigned
> before nsd is started.  This was the case in oBSD 6.1.  However, in 6.2,
> it seems that slaacd is assigning the ipv6 address after nsd starts.
> This leads to error messages such as:
>
> nsd[15166]: xfrd: could not bind source address:port to socket: Can't assign requested address
>
> I've gotten around this by using the ipv4 address for xfr's, and having
> nsd listen on ::1@8053 (unbound has :53) for ipv6 & redirecting with pf.

I would suggest to use static IPs for servers as a better
work around.

Also note that vultr gives you a full /64 v6 subnet, no
need to dick around with different port numbers.
Of course depends on what you are doing...

>
> I *think* the proper behavior should be that daemons wait on slaacd to
> attempt to solicit/bind first, similar to dhclient.
>

ah, but it's not the daemons that wait, dhclient is delaying.

> I do admit that I've been tinkering with ipv6 a lot lately and twisting
> all the knobs, but hopefully this is helpful info as we transition more
> ipv6 dominant internet.
>

--
I'm not entirely sure you are real.

Reply | Threaded
Open this post in threaded view
|

Re: 6.2 starts nsd before slaacd binds ipv6 address

Christian Weisgerber
In reply to this post by lists+misc
On 2017-10-09, [hidden email] <[hidden email]> wrote:

> I don't feel this warrants a bug report, but nevertheless feel that this
> behavior is inconsistent with the way dhclient works.  I have a vultr
> server running nsd/OpenBSD 6.2, and I suspect that the move to slaacd
> from kernel code in 6.1 is what has broken my nsd config (it fails to
> start on boot now).

There definitely are races in the demon startup sequence.  It's
less clear what to do about them.

At home, I have my own stratum 1 NTP server, so my standard ntpd.conf
is "server ntp".  This seemingly innocuous configuration has revealed
_two_ races.

(1) slaacd, ntpd
I also have "family inet6 inet4" in resolv.conf, and ntp(.mips.inka.de)
has both an A and an AAAA record.  ntpd should thus talk to the
server at the v6 address.  However, on faster machines it ends up
talking to the server's v4 address, because slaacd hasn't successfully
configured the local v6 address yet when ntpd starts.

(2) nsd, unbound, ntpd
On my home gateway I run unbound as caching name server. My private
mips.inka.de namespace is configured as a stub-zone supplied by nsd
running on the same machine on port 5353.  I was quite surprised
to find that ntpd on the gateway wasn't talking to ntp.mips.inka.de
but instead to ntp.inka.de--a very different machine.  Apparently,
at the time ntpd starts and queries unbound, nsd isn't ready yet
and unbound can't resolve ntp.mips.inka.de, leading to another
attempt to resolve "ntp" as ntp.inka.de.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 6.2 starts nsd before slaacd binds ipv6 address

Theo de Raadt-2
> > I don't feel this warrants a bug report, but nevertheless feel that this
> > behavior is inconsistent with the way dhclient works.  I have a vultr
> > server running nsd/OpenBSD 6.2, and I suspect that the move to slaacd
> > from kernel code in 6.1 is what has broken my nsd config (it fails to
> > start on boot now).
>
> There definitely are races in the demon startup sequence.  It's
> less clear what to do about them.

This is an irrelevant race.

The transit paths are equivalent.  IPV6 was sold on the premise that
we change the software to support a second transit, which performs
exactly the same function so that either can be used, equivalently.

If the applications support both methods, then why would we wait
until we can qualify that both are working?  Either works -- and
that is Good Enough.

The DNS lookup picks a method that works because returning an answer
ASAP is the mission of the DNS lookup code.  There are no valid inet6
routes, so inet6 is bot operating at that point and it returns the
answer.

Since these are UDP applications, they could contain logic to speak
the other protocol if they discover later that it works.  Such logic
could be complicated and fragile.

But I don't use "family inet6 inet4" in resolv.conf or any other such
logic, so I don't want my machines booting slower to satisfy the
problem... and I doubt anyone else does either.  That is likely the
only circumstance where this problem happens --

Because I understand people have made DNS servers return different
results if the request comes in over IPV6.  That is obviously an
agenda-driven campaign which breaks the original promise that the
data over transport would produce identical results.  It breaks
things in subtle ways, no surprise.


> At home, I have my own stratum 1 NTP server, so my standard ntpd.conf
> is "server ntp".  This seemingly innocuous configuration has revealed
> _two_ races.
>
> (1) slaacd, ntpd
> I also have "family inet6 inet4" in resolv.conf, and ntp(.mips.inka.de)
> has both an A and an AAAA record.  ntpd should thus talk to the
> server at the v6 address.  However, on faster machines it ends up
> talking to the server's v4 address, because slaacd hasn't successfully
> configured the local v6 address yet when ntpd starts.
>
> (2) nsd, unbound, ntpd
> On my home gateway I run unbound as caching name server. My private
> mips.inka.de namespace is configured as a stub-zone supplied by nsd
> running on the same machine on port 5353.  I was quite surprised
> to find that ntpd on the gateway wasn't talking to ntp.mips.inka.de
> but instead to ntp.inka.de--a very different machine.  Apparently,
> at the time ntpd starts and queries unbound, nsd isn't ready yet
> and unbound can't resolve ntp.mips.inka.de, leading to another
> attempt to resolve "ntp" as ntp.inka.de.
>
> --
> Christian "naddy" Weisgerber                          [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: 6.2 starts nsd before slaacd binds ipv6 address

Fernando Gont-2
On 10/11/2017 01:32 PM, Theo de Raadt wrote:

> But I don't use "family inet6 inet4" in resolv.conf or any other such
> logic, so I don't want my machines booting slower to satisfy the
> problem... and I doubt anyone else does either.  That is likely the
> only circumstance where this problem happens --
>
> Because I understand people have made DNS servers return different
> results if the request comes in over IPV6.  That is obviously an
> agenda-driven campaign which breaks the original promise that the
> data over transport would produce identical results.  It breaks
> things in subtle ways, no surprise.

The combination of larger responses because of AAAA records and DNSsec,
plus the fact that IPv6 Extension Headers (including fragmentation)
works so bad (RFC7872) on the public Internet, makes me (and a bunch of
other people) wonder to what extent we'll be able to rely on IPv6 for
DNS transport.


--
Fernando Gont
e-mail: [hidden email] || [hidden email]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1