Daniel Salzman via knot-dns-users <knot-dns-users@lists.nic.cz> wrote:
> 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.
Just to be clear: my parent zone file includes at the very beginning the file
with the default TTL directive. I might have misunderstood you, though.
> 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."
Oops, I didn't know that :-(
> So I expect the same should apply to the $TTL directive as well.
>
> What do you and the others think?
I do consider the $INCLUDE directive as "include all definitions in that
included file and use the default $TTL directive if not stated otherwise".
example.tld:
-----------------------------------------------------
$ORIGIN example.tld.
$INCLUDE ___TTL_SOA___
$INCLUDE ___A_AAAA___
-----------------------------------------------------
That should be -IMHO- combined to a resulting zone file like:
-----------------------------------------------------
$ORIGIN example.tld.
$TTL 30m ; default expiration time of all resource records without their own
TTL value
@ IN SOA ns1.enfer-du-nord.net. hostmaster.enfer-du-nord.net. (
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)
)
; A and AAAA records
@ IN A 1.2.3.4
IN AAAA dead:beef::1
-----------------------------------------------------
That is what I would expect without knowing RFCs.
And, IIRC, that is the way NSD did it before I migrated to Knot ;-)
Just my 2 cents,
Michael
>> $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)
>> )
>
> 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
>> --
> --
--
