Hello,
My knot 3.4.3 gives me following notice :
notice: config, policy 'rail_policy' depends on default nsec3-salt-length=8, since version 3.5 the default becomes 0
In order to avoid problems when .5 will arrive, I see 2 possibilities:
* add an explicit nsec3-salt-length=8 to my policy
* add an explicit nsec3-salt-length=0 to my policy and resign the
zone.
From https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec3-guidance-10.html#nam…
I understand that 0 should be the new configuration, but what are the
risks (considering eg. DNS caches) if I change the policy of the zone?
I only have small zones, with very few dynamic changes, which I can
delay for the time of the TTL if needed.
--
Erwan David
Hi,
I'm running an instance of knotd for testing. It is installed with the
official ubuntu debian package from kont-dns.cz. When I start the knot
service, using systemctl, it takes a very long time to start up
(sometimes 30 min). This seems to be related to the systemd unit which
is set to type 'notify', and the fact that knot after starting up
wants to re-sign all the zones which needs that before notifying. If I
change the type to 'simple' or 'forked' (together with the knotd -d
option), the start command returns more immediately. My test system
has about 800 zonefiles in it. A large number of them want to be
re-signed after each startup.
My question is, what is the recommended way to start, stop and restart
the server? Also, after starting I cannot find the /run/knot/knot.sock
file, which is needed when stopping the service with 'knotc stop'.
Knot version: 3.4.1-cznic.1~focal (debian package from knot-dns.cz)
OS: Linux 5.4.0/Ubuntu 20.04 Focal amd64.
Kind regards,
Erik Østlyngen
Norid
Hello Daniel,
Are the EPEL packages no longer available (?), I'm stuck at 3.3.9. There have
been no updates since then. Or can you download the .rpm from somewhere else
now?
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
Hi all,
we are using dynamic updates for solving ACME challenges. My goal is to
restrict the key used for this as much as possible. However, I find it a
bit difficult to do so while keeping the required flexibility. Maybe
someone has some good recommendations for this?
The key is already restricted to TXT records, so that's good.
In a nutshell, I'd like to allow only "_acme-challenge.example.com" and
"_acme-challenge.*.example.com". However, the latter cannot be expressed
in the current config format.
I would be fine allowing "*.example.com", if I could just deny a select
few names (SPF, DKIM). But AFAICT, the "deny" option only works on
action, key, and address, now owner matching. Is there any other way to
achieve something like this?
Thanks a lot,
Conrad
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
