Op 29/10/2024 om 11:11 schreef Daan Hoogland:
sounds good @Wido den Hollander <w...@widodh.nl> ,
several questions come to mind (most of them in the realm of 'details':
credentials; can these be operator property or must these be user property
(bring your own)? (or can we configure both setups)
My idea is that the Admin adds a DNS provider and the credentials. The
Admin/Owner set it's credentials there, not the ones of the end-user.
In my current idea you would select one driver to be active at the same
time. DNS management usually doesn't require multiple providers to be
active at the same time.
CloudStack keeps track of which DNS zone was created by which users and
allows you to manage that zone.
ttl; is there a maximum configurable as well?
Yes. It should be a range. The minimum is often a restriction you see
much more.
record types; do we make this an allow-list or a set of feature switches?
I would say that the provider/driver has a static list or a
functionality to dynamically provide which types are supported. We could
also add a 'deny-list' where you as an admin can override certain
records. You might not want people to modify the SOA and NS records for
example.
and kicking in an open door, is there a minimum set of record types a
driver must support (a, cname, mx, ...).
I'd say so: A, AAAA, CNAME, TXT and MX are the bare minimum.
The DNS provider will probably pre-set a few records when you create a zone:
- NS
- SOA
Most providers will probably not allow you to modify these records as it
can break the DNS zone.
Hope my overall idea is clear. This obviously needs to go into a
functional spec and then needs development. Both which will be time
consuming.
Wido
great idea!!
On Tue, Oct 29, 2024 at 10:18 AM Wido den Hollander <w...@widodh.nl.invalid>
wrote:
Hello,
I got my inspiration for this proposal from the recently added object
storage [0] plugin in CloudStack.
My idea is as follows:
- A new framework is addedd: Authorative DNS
- This allows for admins and end-users to manage DNS zones
- Different providers implement different APIs, examples:
- PowerDNS through it's API [1]
- Public DNS providers like NS1 [2], rcodezero [3], Gandi [4],
CloudFlare [5], etc
- Your local DNS which applies to your environment
These drivers will support various functionality and advertise their
capabilities or limitations:
- Create and delete zones
- Manage records in these zones
- Advertise which record types are supported
- Limit the amount of records in a zone (if any)
- Set a limitation on how low the TTL can be
Per account and domain we can then set limits:
- Amount of zones to create
- Amount of creates per zone
This would allow for a couple of things:
- End-users can manage their DNS via the same API as they manage their
cloud resources
- End-users can manage DNS via the CloudStack UI
- We can directly create public DNS records for newly created instances
- You assign a DNS zone to a CloudStack zone
- Upon VM creation a record is created
i-xx-yy-vm.myzone.tld A 1.2.3.4
i-xx-yy-vm.myzone.tld AAAA 2001:db8:af31::61
- When the VM is removed the DNS records are removed
- Console Proxy and Secondary Storage VMs can point to a working
hostname instead of IP-address
- We can then also support IPv6 for the CP and SS
Your feedback is welcome!
Wido
[0]:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Object+Store+Framework
[1]: https://doc.powerdns.com/authoritative/http-api/index.html
[2]: https://www.ibm.com/products/ns1-connect/api
[3]: https://my.rcodezero.at/openapi/
[4]: https://api.gandi.net/docs/livedns/
[5]: https://developers.cloudflare.com/api/
