Currently, the DNS propagation stuff uses the services table to enumerate the list of DNS servers that it's responsible for keeping up to date. It could instead use one of these:

• DNS itself. I realize this sounds absurd. But internal DNS servers operate at known addresses -- by design -- so that they can always be discovered. And they have to be up and discoverable for Nexus to even come up and find CockroachDB. So I can't see a plausible scenario where this approach would fail but one of the other approaches here would work. To use this, we'd need to be sure we correctly create DNS records for internal and external DNS servers.
• Once blueprints are available, this could use the current target blueprint instead. That should be about the same as using DNS. One difference is that systems today won't necessarily have a target blueprint yet so we'd need another code path for those (or else block this task until the target blueprint is established).
• As a fallback, we could use a recent inventory collection. I think this is probably never the best option, but it might be an okay fallback if we decide to use the target blueprint but there isn't one yet. But I think this is a reason to prefer using DNS instead.

Importantly, all of these will stay up-to-date as either internal or external DNS servers are added or removed.