3 ms·

Unless I’m misunderstanding something, what you’re talking about is already possible. You can delegate subdomains using NS records (glue records optional, depe

Unless I’m misunderstanding something, what you’re talking about is already possible. You can delegate subdomains using NS records (glue records optional, depending). Then you can create a record at the apex, effectively making it a single record zone. The only real exception being that you can’t create a CNAME at the apex. And you can delegate a subdomain of the subdomain in the same way. The delegations can be to completely separate DNS services/servers managed by completely different teams. This hierarchy and ability to delegate not just resolution but also control is pretty fundamental to the protocol. In practice creating a zone per record would be messy and unnecessary if you didn’t need to delegate control but you could do it if you wanted to.

derefr 8y ago
My point was precisely that the fact that this process is “messy” is purely a UX problem; and the fact that it’s seen as “unnecessary” (rather than “desirable”) is purely down to the fact that it is more “messy” to do. This could all be handled internal to the registrar, such that you just see a tree of managed zones, with the ability to create new directories (zones) in the tree with a single click. All that is is a different UX for the capability that already exists. But if you can make a CNAME record with one click; or make a new child zone with an apex A record with one click; then why not the latter? The reason I was saying that you shouldn’t be able to delegate such child zones—not all child zones, just the ones created through this one-click process—is precisely that being able to do so would make the process of creating them in the first place not one-click, because then they’d have to have SOA records that are independently managed (and so, probably, created with a form you fill out on zone creation, like regular zones), rather than being automatic derivatives of their parent zone’s SOA information. Sure, you could have a control-panel option to turn one of these automatically-managed child zones into a fully-separate top-level zone with the ability to edit its SOA information, delegate it, etc. But that’s just a two-click process to get what we already have, whereas what I care about is the one-click process that gets you something we don’t have: child zones that are required to be bound to the same authority, and therefore are managed with the simplicity of team-based ACLs [like e.g. the AWS resources in a project] rather than with separate top-level accounts in different registrars. It’d be a one-click operation for the domain administrator of “example.com” to break off “foo.example.com”, and then one more click (of an ACL assignment drop-down) for the domain admin to assign the foo team the use of the child zone “foo.example.com” as a namespace to use however they please (including creating further child zones off of.) But all of that would live under what would currently be considered one account with a DNS registrar or DNS management service. IMHO, this paradigm would be “the obvious thing” for services like AWS Route53 to offer—it fits in much better with the rest of the “enterprise-wide policy-controlled access on pooled resources” philosophy that these IaaS clouds have, than the current approach (every domain and all its sub domains being managed as single resources with single IAM owners) does.

derefr 8y ago

My point was precisely that the fact that this process is “messy” is purely a UX problem; and the fact that it’s seen as “unnecessary” (rather than “desirable”) is purely down to the fact that it is more “messy” to do. This could all be handled internal to the registrar, such that you just see a tree of managed zones, with the ability to create new directories (zones) in the tree with a single click. All that is is a different UX for the capability that already exists. But if you can make a CNAME record with one click; or make a new child zone with an apex A record with one click; then why not the latter? The reason I was saying that you shouldn’t be able to delegate such child zones—not all child zones, just the ones created through this one-click process—is precisely that being able to do so would make the process of creating them in the first place not one-click, because then they’d have to have SOA records that are independently managed (and so, probably, created with a form you fill out on zone creation, like regular zones), rather than being automatic derivatives of their parent zone’s SOA information. Sure, you could have a control-panel option to turn one of these automatically-managed child zones into a fully-separate top-level zone with the ability to edit its SOA information, delegate it, etc. But that’s just a two-click process to get what we already have, whereas what I care about is the one-click process that gets you something we don’t have: child zones that are required to be bound to the same authority, and therefore are managed with the simplicity of team-based ACLs [like e.g. the AWS resources in a project] rather than with separate top-level accounts in different registrars. It’d be a one-click operation for the domain administrator of “example.com” to break off “foo.example.com”, and then one more click (of an ACL assignment drop-down) for the domain admin to assign the foo team the use of the child zone “foo.example.com” as a namespace to use however they please (including creating further child zones off of.) But all of that would live under what would currently be considered one account with a DNS registrar or DNS management service. IMHO, this paradigm would be “the obvious thing” for services like AWS Route53 to offer—it fits in much better with the rest of the “enterprise-wide policy-controlled access on pooled resources” philosophy that these IaaS clouds have, than the current approach (every domain and all its sub domains being managed as single resources with single IAM owners) does.