feat: primary and secondary zone transfers#538
Conversation
|
Thanks! What's the upstream ticket for this? |
|
Will track release via the PR for now. @brian-toresdahl-datum you good with this being prioritized this month? |
|
Definitely. |
There was a problem hiding this comment.
Something I don't see covered in this doc is how DNS records are created for Zones that are configured as secondaries. Would we reconcile all of the records that are created through the zone transfer and replicate them into Datum's control plane so a user knows all of the records we've received?
Also curious what type of status information we can offer to consumers about zone transfers so they understand the health. Status information may be a good argument to make zone transfers a separate resource so its status isn't conflated with general zone status.
scotwells
left a comment
There was a problem hiding this comment.
API design looks good.
Some things to consider for a follow up PR:
- May be good to expand the user stories section with some examples of what steps a user would need to take to use this functionality. Especially since there's steps users would need to take in their DNS provider to make this work correctly.
- Would be good to have architecture diagrams showing the relationship between various components that are needed for this system
|
For #545 (backreference) |
This enhancement proposes a model for Primary and Secondary DNS Zone transfers. It introduces DNSZone (Primary/Secondary roles) and TSIGKey (with zoneRef ownership) to require TSIG for Secondary imports and enable optional outbound transfers for Primaries. Transfers run on a dedicated xfr1 transfer plane while anycast edges remain serve-only, improving security and multi-tenant safety with a default-deny posture and presence-implies-intent config. The goal is a secure, reliable, and maintainable foundation for DNS at Datum that maps to PowerDNS initially and remains provider-agnostic over time.