In discussion today we decided this is unlikely to affect sleds' bootstrap or underlay IPs (because we don't ever change those today) but could affect internal DNS IPs. Still, it would require a sequence where we decide to advertise a prefix, that fails, then we decide not to advertise it any more. For example, if we:

• add an internal DNS zone on a sled
• we fail to advertise that prefix
• then we expunge that internal DNS zone
• then we add an internal DNS zone with the same IP to a different sled

I think that's the sequence that would be required to create a problem (and if that happened, you'd see a similar impact to #7377).

I think it's possible this happens even if we don't fail to advertise the prefix, but we are just slow to schedule the new spawned tokio task.

However, I admit, the timing is still tight for this to be possible

You're right -- the sequence is more like:

• we start booting an internal DNS zone on a sled for the first time since sled boot (either because it was added or because the sled just rebooted)
• before we successfully advertise the prefix, we receive a request to expunge the zone and, assuming we've fixed [sled agent] Zone initialization causes maghemite advertisement, but nothing stops this on zone teardown #7377, we've gone and deleted the prefix
• then this tokio task runs again and re-creates the prefix
• meanwhile, an internal DNS zone with the same IP is placed elsewhere, comes up, and clients try to talk to it, but reach this one and potentially get a wrong answer

If we do #7377 with a reconciler loop, then I think this problem should correct itself, but it remains a problem and could cause weird transient behavior.