I can't find anyone talking about this, but isn't it correct to say that if my authoritative DNS server sets the TTL of a record to 1 min and a client is trying to resolve that record on a home computer, going through a local recursive DNS server, that a change to this DNS record may take up to 2 minutes to propagate, due to the fact that caches of the local DNS server and the operating system are being added up?
If client A tries to resolve mysite.com going through local DNS D, right before a DNS record update, then local DNS D will have a fresh record on its local cash with a TTL of 1min, pointing to the wrong record. Now if client B tries to resolve mysite.com 59 seconds later using DNS D, then client's B operating system will cache this record for another minute, effectively taking 2 minutes, at least, for client B to be able to get the correct value.
Is my assumption correct? And if so, what are other possible caches along the way and how can I safely track all of the caches that a specific machine is behind for a specific hostname resolution?
Your assumption is not correct. When sending response to the client, caching DNS server will send only time left until cache expiry as TTL value. The client will not even be aware (and does not really care) what is the "original" TTL value.
Here is an example: I have created
dsmoraes.bajic.nl A 127.0.0.254
with TTL=60. It is a new record so it is safe to assume that it is not cached anywhere. When I query Google DNS for the first time, I will get TTL of 60 (or 59) seconds:
$ dig dsmoraes.bajic.nl @8.8.8.8
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> dsmoraes.bajic.nl @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7656
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dsmoraes.bajic.nl. IN A
;; ANSWER SECTION:
dsmoraes.bajic.nl. 59 IN A 127.0.0.254
;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 02 09:49:49 CEST 2019
;; MSG SIZE rcvd: 62
But with every subsequent request, TTL sent to the client will get lower (only the remaining time):
$ dig +noall +answer dsmoraes.bajic.nl @8.8.8.8
dsmoraes.bajic.nl. 49 IN A 127.0.0.254
$ dig +noall +answer dsmoraes.bajic.nl @8.8.8.8
dsmoraes.bajic.nl. 43 IN A 127.0.0.254
(Google DNS is distributed, so you might hit different caching server in subsequent requests) This way, if caching servers are well behaved, there is no chance of stale record being served (in exceptional cases one might deliberately configure their own DNS server to behave differently, but that is another story).
Further reading: https://www.rfc-editor.org/rfc/rfc1034#section-6