> But if things are done your way then because myhome.example.com needs to have a TTL of 15 mins now all of example.com must have a 15 min TTL instead of two days.

Er, why? I was proposing precisely the opposite of that: that if you made myhome.example.com a separate zone from its parent, it'd have a separate TTL.

Honestly, there's no reason (other than the awful UX of current DNS servers and registrars) that any/all subdomains that have reason to change independently, aren't made into independent zones that are simply "managed under" their parent zone.

In software, you decouple components that have different rates of change (e.g. policy and implementation layers), so that teams corresponding to those rates of change can deal with the components using engineering strategies suited to their lifecycles. (E.g. a policy DSL can be quickly modified and pushed by the ops team; while modifying the implementation requires code review and a successful CI build.) Because this is pretty much an unalloyed good, we do it more than we need: we modularize everything, even things with the same needs, because "keep everything modular" is a lot easier of a principle to follow, and it allows us to group things into different change-flow-rate layers after the fact.

So why, oh why, do we not obey this principle with our DNS subdomains? The same team who owns the "microsoft.com" zone is responsible for any changes required to the "technet.microsoft.com" zone, and the "zune.microsoft.com" zone? How crazy is that, as the best-supported, idiomatic-UX default to have in DNS systems?

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.

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.

> I was proposing precisely the opposite of that: that if you made myhome.example.com a separate zone from its parent, it'd have a separate TTL

Sorry, I misunderstood your comment then.