understood, again, great idea On Tue, Oct 29, 2024 at 11:50 AM Wido den Hollander <w...@widodh.nl> wrote:
> > > 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/ > >> > > > > > -- Daan
