external dns servers don't authoritatively serve the delegated domain well

[davepacheco]

The external DNS servers do not:

• serve an SOA record at $delegated_domain
• serve NS records for $delegated_domain
• serve A records for the NS records for $delegated_domain
• set the "authoritative" flag on responses

I am not sure if we should also be serving some combination of SOA, NS, and A records for sys.$delegated_domain and $silo.sys.$delegated_domain.

At the very least, this has (understandably) confused customers and hindered debugging (because it seems that dig +trace couldn't follow the chain to the silo-specific domain -- I have not tested this). Several customers have reported no problems with external DNS so it seems this doesn't necessarily break things.

[twinfees]

More details below (from a customer):

1. On returning an SOA record, the main fields below (at a minimum) need to be set correctly:

• SERIAL (needs to be correct in order for zone transfers to work).
• If DNS NOTIFY is not provided, TTL and REFRESH values need to be set appropriately to ensure regular zone transfers on the secondaries (for a workaround).
• MINIMUM (60 second or less).
• RNAME (email addr of the admin responsibile for the zone).

2. On returning an NS record:

• Allow zone transfers with DNS NOTIFY (uses a list of IP address - secondaries - that are immediately notified if the zone has changed, allowing the secondaries to update their copy of the zone.

3. Return "aa" bit on answers. While this can be worked around, setting this helps the DNS admin know that it's authoritative for the zone (e.g. this is not a recursively resolved or cache record being returned). Would help further with DNS troubleshooting in general.

4. Honor the DNS TYPE (SOA, NS, A, AAAA, ...).

[iximeow]

I am not sure if we should also be serving some combination of SOA, NS, and A records for sys.$delegated_domain and $silo.sys.$delegated_domain.

AFAICT the answer here is "only if there might be different DNS servers managing those domains and their subdomains" - for example, if we one day wanted to allow zone transfers for individual silos, then we'd want an SOA record for $silo.sys.$delegated_domain.

[iximeow]

@twinfees going through the list you'd shared above:

1. On returning an SOA record, the main fields below (at a minimum) need to be set correctly:

• SERIAL (needs to be correct in order for zone transfers to work).
• If DNS NOTIFY is not provided, TTL and REFRESH values need to be set appropriately to ensure regular zone transfers on the secondaries (for a workaround).
• MINIMUM (60 second or less).
• RNAME (email addr of the admin responsibile for the zone).

with #8047 we'll return SOA records for queries to the rack's delegated domain, and its serial will increment when the external DNS zone's contents change. the other fields are currently hardcoded, with REFRESH at 3600 seconds, RETRY at 600 seconds, EXPIRE at 1800 seconds, and MINIMUM at 600 seconds. the RNAME is hardcoded at admin@$delegated_domain. these all ought to be configurable in the future, much like the rack's delegated domain in the first place. we still don't support NOTIFY or zone transfers, so the SOA fields.. are not moot, but are probably not as helpful as anyone would like at this moment.

2. On returning an NS record:

• Allow zone transfers with DNS NOTIFY (uses a list of IP address - secondaries - that are immediately notified if the zone has changed, allowing the secondaries to update their copy of the zone.

#8047 also has us returning NS records now, but no plumbing for changes resulting in NOTIFY or being exportable via AXFR.

3. Return "aa" bit on answers. While this can be worked around, setting this helps the DNS admin know that it's authoritative for the zone (e.g. this is not a recursively resolved or cache record being returned). Would help further with DNS troubleshooting in general.

#8120 ! we're set here.

5. Honor the DNS TYPE (SOA, NS, A, AAAA, ...).

this one was a while ago, #6308

we've got the other issue about what the appropriate method is to replicate external DNS records, i'll open another issue against omicron for configuring the external DNS domain and SOA record. with that, i think we can call this done!