External DNS should be configurable

[iximeow]

in #6944 and #8047 we got external DNS to serving an SOA record, but the fields of that SOA record are basically hardcoded. i mentioned the current hardcoded values in this comment. we really ought to have a few things here:

• the SOA RNAME should be configurable to the email address a rack's operator can receive email at. the rack has no reason to send email to this address, but operators deserve to have reasonable DNS records.
• TTL/REFRESH/RETRY/EXPIRE/MINIMUM for the external zone's SOA record should be configurable. this is presumably more immediately observable: these are fields that DNS caching/replication systems might operate in terms of.
• the delegated domain ought to be configurable. it's currently set at RSS time, we have no mechanism to change it at the moment.

i think SOA fields are just a question of storage and API plumbing. wherever those fields live, it's probably worth asking if it should be with the delegated domain.

the SOA fields we have are definitely not ideal, and i expect it's likely someone will want to configure them sooner than later.

i'm not aware of anyone wanting to change the delegated domain today, but it seems pretty reasonable to want. changing the delegated domain is probably a more complicated separate operation - at the very least one would want to track down what, if any, names get derived from it and would need to be updated.

[jgallagher]

• the delegated domain ought to be configurable. it's currently set at RSS time, we have no mechanism to change it at the moment.

#3732 is loosely related (other "currently set at RSS time, no mechanism to change later" configuration). Just wanted to note in case there is overlapping implementation work (some kind of "operator-specified rack-level config" crdb table maybe?).

[davepacheco]

TTL/REFRESH/RETRY/EXPIRE/MINIMUM for the external zone's SOA record should be configurable. this is presumably more immediately observable: these are fields that DNS caching/replication systems might operate in terms of.

Caveat: I don't have a lot of operational experience deploying traditional DNS (outside of a closed system) or DNS caches. So I wonder if this is in the bucket of configuration that the system should really be responsible for (and that allowing operators to configure would invite misconfiguration), or if it's actually environment-specific in a way that the system can't know?

the delegated domain ought to be configurable. it's currently set at RSS time, we have no mechanism to change it at the moment.

This seems probably the most important one to support (it does feel like an ongoing risk that someone might need to change this suddenly). But it's also kind of thorny if customers expect to be able to do this without DNS downtime. It would be easy to support a mechanism where the DNS servers flip suddenly (and at slightly different times) from one domain to another. But that seems very disruptive to anything that uses the console or API and even worse if we've already added support for instance DNS names. Some of the underlying mechanism was built to support serving multiple external DNS domains simultaneously in order to have a transition to avoid this disruption. But I'm sure not all code paths support that and a bunch more work and testing would be required. On the other hand, having something here, even if it's sudden and disruptive, would be much better than not having the ability at all!