5 ms·

A self hosted dyn dns requires a short TTL. eg most of a zone could be 2 days, but myhome.example.com can be set to 15 minutes.

derefr 8y ago
In that use-case, there's no reason that myhome.example.com couldn't be broken out onto its own apex, yet still hosted by the same authoritative DNS servers. (I'm continually surprised that there's no easy way in any DNS registrar's UX to say "I want this DNS name to be an NS record pointing back to your own servers, with you automatically updating that association; and then I want you to expose a new top-level zone for me to edit with that new apex FQDN, just as if it was another asset I had purchased from you. The new zone should have an automatically-managed SOA record derived from its parent zone's SOA record, which prohibits transfers; and the parent zone's SOA should be locked down such that it cannot be transfer-enabled either, as long as the child zone exists [just because no other registrar likely supports receiving this mess.]" Totally possible, but no registrar does it. Maybe because it'd make reselling too easy?)
- codetrotter 8y ago
  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. Now imagine that www.example.com has A LOT of visitors, and myhome.example.com has only OP and his family using it. So now millions of clients need to make up to 96 times more DNS queries each (one day divided by 15 minutes, because 24 hours seems to be the actual maximum amount of time that for example Windows caches positive DNS query replies) because if they are visiting www.example.com and the way too low TTL has expired, all because a handful of people needs a low TTL for myhome.example.com. Per-record TTL is great and I see no reason to do it the way you are suggesting instead.
  - derefr 8y ago
    > 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?
    - codetrotter 8y ago
      > 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.
    - brazzledazzle 8y ago
      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

In that use-case, there's no reason that myhome.example.com couldn't be broken out onto its own apex, yet still hosted by the same authoritative DNS servers. (I'm continually surprised that there's no easy way in any DNS registrar's UX to say "I want this DNS name to be an NS record pointing back to your own servers, with you automatically updating that association; and then I want you to expose a new top-level zone for me to edit with that new apex FQDN, just as if it was another asset I had purchased from you. The new zone should have an automatically-managed SOA record derived from its parent zone's SOA record, which prohibits transfers; and the parent zone's SOA should be locked down such that it cannot be transfer-enabled either, as long as the child zone exists [just because no other registrar likely supports receiving this mess.]" Totally possible, but no registrar does it. Maybe because it'd make reselling too easy?)

codetrotter 8y ago
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. Now imagine that www.example.com has A LOT of visitors, and myhome.example.com has only OP and his family using it. So now millions of clients need to make up to 96 times more DNS queries each (one day divided by 15 minutes, because 24 hours seems to be the actual maximum amount of time that for example Windows caches positive DNS query replies) because if they are visiting www.example.com and the way too low TTL has expired, all because a handful of people needs a low TTL for myhome.example.com. Per-record TTL is great and I see no reason to do it the way you are suggesting instead.
- derefr 8y ago
  > 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?
  - codetrotter 8y ago
    > 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.
  - brazzledazzle 8y ago
    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.