Lets say I create a reverse zone-file for 192.0.2.0/24 network in my DNS server and my DNS server will be the authoritative for reverse-zone 2.0.192.in-addr.arpa. In this reverse zone-file I create Start of Authority record with following parameters:
$ dig @localhost -t SOA 2.0.192.in-addr.arpa. +noall +answer
2.0.192.in-addr.arpa. 604800 IN SOA primary-DNS-server secondary-DNS-server 2015010600 28800 7200 1209600 86400
$
Am I correct that the DNS TTL for this reverse-zone is 86400 seconds? And this means that if recursive(caching) name-server asks a PTR record from this zone, then this recursive name-server will cache the result for 86400 seconds?
Back in 1997, that would have been one correct SOA record interpretation of several. :) Things were a little more ambiguous back then.
RFC 2308 reclassified the last field of the SOA record as the negative caching interval, otherwise known as the
NCACHE
field. RFC2308 §4 is the most applicable here. It not only redefines this as theNCACHE
field, but also explains why coding the default TTL into the SOA record would have been misguided to begin with. (emphasis for the latter is in bold)Breaking this down:
NCACHE
) specifies how long remote nameservers should cache a negative response if a query results in NXDOMAIN.$TTL
directive for text based zone files.$TTL
and family are not records, therefore you cannot query for them and they will not survive a zone transfer. (instead, all missing TTLs will be replaced with this value at the time of zone transfer)As Andy says, the default TTL is moot if the individual records specify their own TTLs.
Almost. The soa record itself has a TTL of 86400 seconds, and depending on the server-side software that will be the default ttl for that zone.
Individual records within that zone - such as PTR or NS - can have their TTL overridden. I believe that a recursive query for any individual DNS record will return with its own TTL, though I say that based on observation rather than referenced documentation.