Record-level TTLs are useful in practice. Let me give an example. Let's say I am about to make a significant change to the operation of a system. I'm going to f

Record-level TTLs are useful in practice. Let me give an example. Let's say I am about to make a significant change to the operation of a system. I'm going to flip service.example.com from pointing one place, to pointing somewhere else. If something goes wrong during this deployment, then I want to be able to roll back quickly. In preparation for this deployment, I might lower the TTL on service.example.com considerably. This way I can roll out my change quickly and observe the effect across all clients, and I can also roll it back quickly. Once the deployment is done, and I don't expect to make further changes to service.example.com, then I can raise the TTL again. More generally, you might want the ability to propagate changes to the definition of some names much faster than others, and record-level TTLs let you do this. I might be planning to change service.example.com shortly while not planning to change www.example.com any time soon. The downside of low TTLs is a higher volume of queries and thus higher costs, with some implications for availability. Record TTLs are something that I think about, and consider changing, whenever I'm about to make a significant change to a name. (Yes, if TTLs only existed for zones, then you could still break out service.example.com into its own zone, and define the TTL there. But if you frequently want different TTLs for different records, then having to do this would be inconvenience without benefit. Service.example.com would be part of its parent zone initially, then you'd have to separate it out into its own zone just for the sake of a different TTL, and then merge it back in later. Under this use-case, zone-wide TTLs only will add complexity.)