13 Čec
2024
13 Čec
'24
16:25
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
13 Čec
13 Čec
19:33
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
--
19:57
Daniel Salzman via knot-dns-users <knot-dns-users(a)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
>> --
> --
20:47
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."
i kinda understand this; pola
the reason i would use $INCLUDE is to pull stuff into multiple zones,
and changing origin is very zone specific.
So I expect the same should apply to the $TTL
directive as well.
this would seem to rather limit the usefulness of $INCLUDE
will there be a guessing game of which RRs and directives are effective
outside the scope of the $INCLUDEd file?
randy
15 Čec
15 Čec
22:32
Daniel Salzman via knot-dns-users <knot-dns-users(a)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.
I am still trying to understand where that "default TTL in the parent zone file"
is defined?
I expected 1800s in all of my RRs, but ended up in mainly 3600s.
So, where is 3600s defined?
Is there a knob in knot.conf I might have overlooked?
Any feedback is highly appreciated and regards,
Michael
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
--
--
22:58
Hi,
It's a hardcoded default of 3600 seconds.
We could simply change the parser to keep the default TTL set within an included zone
file. However, it seems that Bind
parses the zone in the same way as Knot. So it's a tough decision :-)
Daniel
On 15. 07. 24 22:32, Michael Grimm wrote:
Daniel Salzman via knot-dns-users
<knot-dns-users(a)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.
I am still trying to understand where that "default TTL in the parent zone
file" is defined?
I expected 1800s in all of my RRs, but ended up in mainly 3600s.
So, where is 3600s defined?
Is there a knob in knot.conf I might have overlooked?
Any feedback is highly appreciated and regards,
Michael
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
--
--
23:07
Daniel Salzman via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
It's a hardcoded default of 3600 seconds.
Ah, now I understand.
We could simply change the parser to keep the default
TTL set within an included zone file. However, it seems that Bind
parses the zone in the same way as Knot. So it's a tough decision :-)
:-)
Or make that hardcoded 3600s a configurable option in knot.conf …
Regards,
Michael
23:21
I don't understand why it's that important if you can add one TTL
directive to the zone?
Daniel
Dne 2024-07-15 23:07, Michael Grimm napsal:
Daniel Salzman via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
It's a hardcoded default of 3600 seconds.
Ah, now I understand.
We could simply change the parser to keep the
default TTL set within
an included zone file. However, it seems that Bind
parses the zone in the same way as Knot. So it's a tough decision :-)
:-)
Or make that hardcoded 3600s a configurable option in knot.conf …
Regards,
Michael
23:43
Daniel Salzman via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
I don't understand why it's that important if
you can add one TTL directive to the zone?
Example:
1) if one does has X zones to configure.
2) now, one needs to modify TTL for all zones to whatever reason.
3) given that one uses a $INCLUDE ___TTL___ directive in all those X zone files …
4) one would need to modifying *one* file only instead of X!
I did expect knot's parser to follow *my* intended directive to follow that (POLA).
But that is not the case, as I found out and why I started this thread.
It is not of utmost importance, though.
*But* it would make my setup much easier to administer.
A configurable default RR limit instead of hardcoded 3600 seconds would help as well.
Regards,
Michael
Daniel
Dne 2024-07-15 23:07, Michael Grimm napsal:
Daniel Salzman via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
-- It's a hardcoded default of 3600 seconds.
Ah, now I understand.
We could simply change the parser to keep the
default TTL set within an included zone file. However, it seems that Bind
parses the zone in the same way as Knot. So it's a tough decision :-)
:-)
Or make that hardcoded 3600s a configurable option in knot.conf …
Regards,
Michael
18 Čec
18 Čec
19:41
Michael,
FYI https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1689
I hope this solves your issue.
Daniel
On 7/15/24 23:43, Michael Grimm wrote:
Daniel Salzman via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
I don't understand why it's that
important if you can add one TTL directive to the zone?
Example:
1) if one does has X zones to configure.
2) now, one needs to modify TTL for all zones to whatever reason.
3) given that one uses a $INCLUDE ___TTL___ directive in all those X zone files …
4) one would need to modifying *one* file only instead of X!
I did expect knot's parser to follow *my* intended directive to follow that (POLA).
But that is not the case, as I found out and why I started this thread.
It is not of utmost importance, though.
*But* it would make my setup much easier to administer.
A configurable default RR limit instead of hardcoded 3600 seconds would help as well.
Regards,
Michael
Daniel
Dne 2024-07-15 23:07, Michael Grimm napsal:
Daniel Salzman via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
-- It's a hardcoded default of 3600 seconds.
Ah, now I understand.
We could simply change the parser to keep the
default TTL set within an included zone file. However, it seems that Bind
parses the zone in the same way as Knot. So it's a tough decision :-)
:-)
Or make that hardcoded 3600s a configurable option in knot.conf …
Regards,
Michael
20:41
Hi Daniel
Wow! I haven't expected that a configurable default RR limit will be implemented, not
that fast, let alone at all ;-)
I am happy with such an option, because it will allow me to omit any $TTL directive in the
future, except that I would like to set NS RRs to an TTL of 1 day as an example in
'$INCLUE ___NAMESERVERS___'
I will wait for the next release (FreeBSD port) and report back, although I am pretty sure
that you have tested it already.
Kudos, thanks and regards,
Michael
On 18. Jul 2024, at 19:41, Daniel Salzman via
knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
Michael,
FYI https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1689
I hope this solves your issue.
Daniel
On 7/15/24 23:43, Michael Grimm wrote:
Daniel Salzman via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
-- I don't understand why it's that
important if you can add one TTL directive to the zone?
Example:
1) if one does has X zones to configure.
2) now, one needs to modify TTL for all zones to whatever reason.
3) given that one uses a $INCLUDE ___TTL___ directive in all those X zone files …
4) one would need to modifying *one* file only instead of X!
I did expect knot's parser to follow *my* intended directive to follow that (POLA).
But that is not the case, as I found out and why I started this thread.
It is not of utmost importance, though.
*But* it would make my setup much easier to administer.
A configurable default RR limit instead of hardcoded 3600 seconds would help as well.
Regards,
Michael
>
> Daniel
>
> Dne 2024-07-15 23:07, Michael Grimm napsal:
>> Daniel Salzman via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
>>> It's a hardcoded default of 3600 seconds.
>> Ah, now I understand.
>>> We could simply change the parser to keep the default TTL set within an
included zone file. However, it seems that Bind
>>> parses the zone in the same way as Knot. So it's a tough decision :-)
>> :-)
>> Or make that hardcoded 3600s a configurable option in knot.conf …
>> Regards,
>> Michael
> -- 
20:44
On 7/18/24 20:41, Michael Grimm via knot-dns-users wrote:
Wow! I haven't expected that a configurable
default RR limit will be implemented, not that fast, let alone at all ;-)
Something like this has happened to me, too, after asking how to do a certain thing ...
and within a few days,
https://www.knot-dns.cz/docs/3.3/html/reference.html#clearing-configuration… was
implemented.
Kudos to the Daniel & his team!
Cheers,
Peter
22 Čec
22 Čec
17:22
Michael Grimm via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
Hi Daniel
Wow! I haven't expected that a configurable default RR limit will be implemented, not
that fast, let alone at all ;-)
I am happy with such an option, because it will allow me to omit any $TTL directive in
the future, except that I would like to set NS RRs to an TTL of 1 day as an example in
'$INCLUE ___NAMESERVERS___'
I will wait for the next release (FreeBSD port) and report back, although I am pretty
sure that you have tested it already.
As expected, this new option fulfils all my expectations.
Thanks again and regards,
Michael
18:32
Thanks for the feedback :-)
Daniel
On 7/22/24 17:22, Michael Grimm wrote:
Michael Grimm via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
Hi Daniel
Wow! I haven't expected that a configurable default RR limit will be implemented, not
that fast, let alone at all ;-)
I am happy with such an option, because it will allow me to omit any $TTL directive in
the future, except that I would like to set NS RRs to an TTL of 1 day as an example in
'$INCLUE ___NAMESERVERS___'
I will wait for the next release (FreeBSD port) and report back, although I am pretty
sure that you have tested it already.
As expected, this new option fulfils all my expectations.
Thanks again and regards,
Michael
48
days inactive
57
days old
13 comments
5 participants
participants (5)
-
Daniel Salzman -
daniel.salzman＠nic.cz
-
Michael Grimm -
Peter Thomassen -
Randy Bush