-
Notifications
You must be signed in to change notification settings - Fork 0
feat: primary and secondary zone transfers #538
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.