Internal NTP zones need to know about the boundary NTP zones. Today, the internal NTP zone config (that RSS constructs and passes into sled agent's PUT /omicron-zones) includes a list of DNS names for the boundary NTP zones that RSS also provisioned. But this means that if we ever wanted to add or remove a boundary NTP zone (e.g., as part of replacing a sled that has a boundary NTP zone or to update the zone to a new image) then we'd need to also update the configs for every internal NTP zone and re-deploy them all.

Could we instead provide an internal DNS name that expands to all the boundary NTP zones? Then on startup (and ideally periodically) the internal NTP zone would re-resolve that name and update itself to point to the right set of servers? That way the only thing that needs to be propagated is DNS, which happens anyway.

Aside: this problem also applies to boundary NTP zones (which reference external servers) but would only matter if/when we allow operators to change the upstream NTP servers. We could solve this the same way (publish an internal DNS name that refers to the same values as the upstream does, and keep it up to date) but that seems goofier for this case since we'd be publishing an internal name for an external IP and we'd also need to keep it up to date. An alternative would be to have the start method ask Nexus what should go there, but that's out because this functionality needs to work even when Nexus isn't up yet. So the zone either needs to cache the last-known value persistently (which is essentially what it does today) or else get it from internal DNS. Maybe we just keep boundary NTP zones the same accept that we would have to redeploy them if this value ever changed.