On 2017-10-09, lists+m...@ggp2.com <lists+m...@ggp2.com> 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 na...@mips.inka.de
