Understanding TTL field of PTR record returned by dig client

Question

I have some doubts about working of DNS in general - even given the fact I have theoretical base. let's consider a following output:

[user@host ~]$ dig google.com
[...]
;; ANSWER SECTION:
google.com.     102 IN  A   172.217.3.174

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 17514 IN    PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 17514 IN    PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 298 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 298 IN  PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 297 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 297 IN  PTR sea15s11-in-f174.1e100.net.

What does it mean TTL field exactly?
In the first answer it is: 17514, further 299, 298...
I know definition, it is something like: How long client should keeps answer in cache (limit queries to DNS)

However,
1. Does it relate only to application clients? After all, linux doesn't cache DNS answers so this field doesn't matter.
2. Does it relate also secondary DNS servers (in other words how long to keep information from master DNS for this specific record?)? What about Refresh SOA field in master?
3. How does it work that it is smaller and smaller? Who is responsible for that? My client (dig on RHat) or DNS server? Authorative or slave? /etc/resolv.conf?

BTW: I consider master and Authorative are the same as well as slave=secondary=non-Authorative

Answer 1

1. Most clients do cache DNS responses, most Linux distributions doesn't by default, but can install software to do this as well.
2. Yes, most DNS servers cache responses for domains they are not authoritative for. This is done per record basis. The Start Of Authority (SOA) refresh interval is on the other hand meant for DNS clusters, where a master server keeps the master copy of the zone, and the SOA record refresh interval sets how often slave servers should request a copy of the whole zone from the master server.
3. Usually it's the client that keeps a cache of records it's already received, and clears them out as records expire. All non-authoritative servers in the chain does the same for cached responses. Linux doesn't do this per default, so the answers you're seeing are from some upstream non-authoritative DNS server.

Authoritative/Non-Authoritative doesn't mean the same thing as Master/Slave in DNS. An authoritative DNS server is a server that is the one publishing a specific zone to the rest of the global DNS. A non-authoritative DNS server is a server that's not responsible for a particular zone, but happens to have a copy of records from that zone. A DNS server can be authoritative for one zone, call it abc.com, but also non-authoritative for another zone, for example bcd.com.

Master and Slave DNS servers are related to clusters. In a cluster of DNS servers, one server is the master and keeps the master copy of all zones that this cluster is authoritative for. Slave servers then poll the master for a copy of the zones, and then responds as authoritative DNS servers for that zone. This is so that all changes are done just to the master and replicated to the slave servers. Usually the slave servers are the only ones responding to external DNS queries, and the master just talks to the slave servers.