A countdown, not a fixed number
Every DNS record carries a TTL, set by whoever runs the domain's zone. RFC 1035 defines it as the time in seconds a record may be cached before it should be thrown away. When a resolver fetches the record, it starts counting down from that number and hands out its cached copy until the count runs out.
So the TTL you see in a lookup is usually lower than the one in the zone. A resolver reports the time its copy has left, not the original value. Ask two resolvers and they rarely agree, since each fetched the record at a different moment. A TTL of 0 means the answer is only good for the lookup that asked for it and shouldn't be cached at all.
Why a change waits on the old TTL
A new TTL only applies from the next fetch. When you change a record, resolvers that cached it keep the old answer until their copy expires, so the old TTL decides how long the switch takes. That's what people call DNS propagation. Nothing gets pushed out. Caches just expire one by one.
So lower the TTL before a planned change, wait for the old one to run out, then make the change. Once it has settled, raise the TTL again. Short TTLs aren't free. Each expired copy means another round trip to your name servers, which adds delay for the next visitor and load on your DNS host.
A missing name gets cached too
Resolvers also cache the answer that a name doesn't exist (NXDOMAIN), or that it has no records of the type asked for. RFC 2308 sets how long: the smaller of the SOA record's own TTL and the minimum field inside it. If someone looked up a name before you created it, they can keep getting NXDOMAIN for that long.
The SOA record holds both numbers. The DNS Lookup's More records section reads the SOA record and says how long resolvers keep a "doesn't exist" answer, in plain time.