I noticed that sometimes DNS64 detection is not working correctly on
boot. Eventually I tracked it down to this:
Feb 6 08:56:22 x1 unwind[7139]: check_dns64_done: bad packet: too short: -1
The problem is that we are checking for dns64 while we might not yet
have a route to the nameserver provided by the router advertisement or
our IPv6 addresses are all tentative. Since we only re-schedule the
check when the network changes we are stuck. Instead we can check for
the presence of DNS64 when we know that DNS works, which is being
rescheduled correctly.
OK?
diff --git resolver.c resolver.c
index 302f381a0dd..95c32369830 100644
--- resolver.c
+++ resolver.c
@@ -1142,6 +1142,8 @@ new_resolver(enum uw_resolver_type type, enum
uw_resolver_state state)
/* FALLTHROUGH */
case RESOLVING:
resolvers[type]->state = state;
+ if (type == UW_RES_ASR)
+ check_dns64();
break;
}
}
@@ -2053,7 +2055,6 @@ replace_autoconf_forwarders(struct imsg_rdns_proposal
*rdns_proposal)
new_resolver(UW_RES_ASR, UNKNOWN);
new_resolver(UW_RES_DHCP, UNKNOWN);
new_resolver(UW_RES_ODOT_DHCP, UNKNOWN);
- check_dns64();
} else {
while ((tmp = TAILQ_FIRST(&new_forwarder_list)) != NULL) {
TAILQ_REMOVE(&new_forwarder_list, tmp, entry);
--
I'm not entirely sure you are real.
