> > 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 na...@mips.inka.de >
