Hi,
The Knot's parser behaviour is as you described. However, the default TTL in
the parent zone file isn't affected
by the default TTL in the included zone file.
RFC 1035 says:
"Note that a $INCLUDE entry never changes the relative
origin of the parent file, regardless of changes to the relative origin
made within the included file."
So I expect the same should apply to the $TTL directive as well.
What do you and the others think?
Daniel
On 7/13/24 16:25, Michael Grimm via knot-dns-users wrote:
Hi,
I do have the following example zone files definitions:
$ORIGIN example.tld.
$INCLUDE ___TTL_SOA___
and so on
My ___TTL_SOA___ looks as follows:
$TTL 30m ; default expiration time of all resource records without
their own TTL value
;
@ IN SOA ns1.example.tld. hostmaster.example.tld. (
2024042100 ; serial (increase after each change)
4h ; refresh (recommended >= 4h)
1h ; retry (recommended >= 1h)
14d ; expire (recommended between 7d and 14d)
600 ; negative caching (former minimum, recommended between 5m
and 1d)
)
Note: All of my subsequent $INCLUDDE files do *not* have TTL values set
explicitly!
But: I do end up in a mix of TTL values of 1800 and 3600 for my resource
records. You can check that using my domain in my email address.
I found the following thread about this issue at
https://gitlab.nic.cz/knot/knot-dns/-/issues/751 and
https://datatracker.ietf.org/doc/html/rfc2308#section-4 cited therein:
"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."
In my understanding Knot's behaviour has been set to follow this standard
track. Thus, I do expect that all of my resource records should have a TTL set
to my $TTL directive of 1800 seconds.
I might have well overlooked something, though.
Any feedback is highly appreciated,
Michael
--
--
