[GH-ISSUE #718] Improve TTL handling (in zone files) #279

New issue

Open

opened 2026-03-07 23:14:42 +03:00 by kerem · 0 comments

kerem commented

2026-03-07 23:14:42 +03:00

Owner

Originally created by @makarchuk on GitHub (Mar 25, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/718

In discussion on #712 we touched that there's a chance that TTL is not handled correctly while parsing a zone file.

I'm creating this issue to plan and document changes and reasoning behind it.

RFC states the following:

TTL on SOA field should be applied to negative responses and be used as a default TTL for the records that do not have one set specifically (and if there were no TTL directive earlier in a file).

Relevant RFC part:

The SOA minimum field has been overloaded in the past to have three
   different meanings, the minimum TTL value of all RRs in a zone, the
   default TTL of RRs which did not contain a TTL value and the TTL of
   negative responses.

   Despite being the original defined meaning, the first of these, the
   minimum TTL value of all RRs in a zone, has never in practice been
   used and is hereby deprecated.

   The second, the default TTL of RRs which contain no explicit TTL in
   the master zone file, is relevant only at the primary server.  After
   a zone transfer all RRs have explicit TTLs and it is impossible to
   determine whether the TTL for a record was explicitly set or derived
   from the default after a zone transfer.  Where a server does not
   require RRs to include the TTL value explicitly, it should provide a
   mechanism, not being the value of the MINIMUM field of the SOA
   record, from which the missing TTL values are obtained.  How this is
   done is implementation dependent.

   The Master File format [RFC 1035 Section 5] is extended to include
   the following directive:

                           $TTL <TTL> [comment]

   All resource records appearing after the directive, and which do not
   explicitly include a TTL value, have their TTL set to the TTL given
   in the $TTL directive.  SIG records without a explicit TTL get their
   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].

   The remaining of the current meanings, of being the TTL to be used
   for negative responses, is the new defined meaning of the SOA minimum
   field.

Originally created by @makarchuk on GitHub (Mar 25, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/718 In discussion on #712 we touched that there's a chance that `TTL` is not handled correctly while parsing a zone file. I'm creating this issue to plan and document changes and reasoning behind it. [RFC](https://tools.ietf.org/html/rfc2308#section-4) states the following: `TTL` on `SOA` field should be applied to negative responses and be used as a default `TTL` for the records that do not have one set specifically (and if there were no `TTL` directive earlier in a file). Relevant RFC part: ``` The SOA minimum field has been overloaded in the past to have three different meanings, the minimum TTL value of all RRs in a zone, the default TTL of RRs which did not contain a TTL value and the TTL of negative responses. Despite being the original defined meaning, the first of these, the minimum TTL value of all RRs in a zone, has never in practice been used and is hereby deprecated. The second, the default TTL of RRs which contain no explicit TTL in the master zone file, is relevant only at the primary server. After a zone transfer all RRs have explicit TTLs and it is impossible to determine whether the TTL for a record was explicitly set or derived from the default after a zone transfer. Where a server does not require RRs to include the TTL value explicitly, it should provide a mechanism, not being the value of the MINIMUM field of the SOA record, from which the missing TTL values are obtained. How this is done is implementation dependent. The Master File format [RFC 1035 Section 5] is extended to include the following directive: $TTL <TTL> [comment] All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive. SIG records without a explicit TTL get their TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5]. The remaining of the current meanings, of being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field. ```