Hi,
I've got a staging environment running, with two signers signing a
staging version of the .is zone (~115k records).
The staging servers are configured with 2 GB RAM and 4 CPU cores,
running on FreeBSD 12.2.
We've experienced that knot crashes because the server runs out of
memory. The zone is configured with:
zonefile-sync: -1
zonefile-load: difference-no-serial
journal-content: all
One of the signers, after an hour of running is showing 215 MB resident
memory used.
The other signer, that's been running for a whole day is showing 1582 MB
resident memory.
I attached a screenshot showing the amount of memory used over a period
of time, and the graph shows that the amount of memory used very
suddenly increases.
I assume the servers are using a lot of memory for the journals, but I'd
like to understand why the sudden increase in used memory, and what to
expect about needed memory?
.einar
Hi,
i have knot dns setup with dns cookie module enabled but if i check with
dnsviz.net i always get:
The server appears to support DNS cookies but did not return a COOKIE
option.
Relevant parts of my knot.conf:
template:
- id: default storage: "/var/lib/knot"
dnssec-signing: on
dnssec-policy: rsa2048
global-module: [ "mod-cookies", "mod-rrl/default" ]
mod-rrl:
- id: default
rate-limit: 200
slip: 2
- domain: mydomain.de
file: "/etc/knot/zones/mydomain.de.zone"
notify: secondary
acl: acl_secondary
zonefile-load: difference
I thought about maybe it's the slip: 2, but that didn't change anything
if set to 1
Do you guys see anything obvious causing this "issue"?
Thanks for your time
Juergen
Hi,
For many months now, we've been preparing new signers for our internal
zones and eventually .is.
We've got the first of our test zones live on the production signers,
but some things are troubling us.
This is the config we're using for zones:
template:
- id: default
semantic-checks: on
storage: "/usr/local/etc/knot"
file: "zones/unsigned/%s/%s-soa"
serial-policy: dateserial
zonefile-sync: -1
zonefile-load: difference-no-serial
journal-content: all
notify: hidden_primary
acl: hidden_primary_acl
policy:
- id: isnic
algorithm: RSASHA256
ksk-size: 4096
zsk-size: 2048
ksk-lifetime: 365d
zsk-lifetime: 30d
propagation-delay: 1h
rrsig-lifetime: 14d
rrsig-refresh: 7d
rrsig-pre-refresh: 1h
---
zones/unsigned is stored in a git repo and changes are deployed by an
ansible playbook that checks out the latest revision and reloads the zones.
Someone pointed out that zonefile-load: difference-no-serial was risky
for something as important as a TLD, but what is the alternative when
doing automatic DNSSEC signing on zone data from git? Also, we turned
off zonefile-sync, since our current deployment script overwrites the
zonefile. Is there a way to load initial zone data from one file, but do
zonefile-sync to another?
We're seeing this in our logs:
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] zone file
parsed, serial corrected 1970010100 -> 2022012000
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] loaded, serial
2022011900 -> 2022012000 -> 2022011900, 3830 bytes
Any idea what's happening on the second line? It's like knot wants to
increment the serial, but then changes it's mind :)
.einar
OK I recently decided to change the algorithm on all our domains
from RSASHA1 to RSASHA256. Before making the change globally; I
experimented with one domain. I did so by adding a new policy:
CURRENT
policy:
- id: rsa1
algorithm: RSASHA1
ksk-size: 2048
zsk-size: 1024
dnskey-ttl: 43200
zsk-lifetime: 30d
ksk-lifetime: 365d
NEW (PROPOSED)
policy:
- id: rsa2
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 2048
dnskey-ttl: 43200
zsk-lifetime: 30d
ksk-lifetime: 365d
DOMAIN TESTED ON
# a-domain
- domain: a-domain
file: "masters/a-domain"
zonefile-load: difference
dnssec-signing: on
# dnssec-policy: rsa1
dnssec-policy: rsa2
semantic-checks: on
serial-policy: dateserial
acl: [locals, remotes01, remotes03, remotes04]
To preform the intended change. I first set the the current keys on the
test domain to: retire=+1hr
I then added the new policy and assigned it to the testing domain. Then
restarted the knot service. After the hour and some had passed. I performed a
keymgr a-domain del-all-old which removed the old algorithm (RSASHA1) keys.
But I think this was a mistake.
How would I best make this change? Is it enough to simply change algorithm:
and knot will just do the right thing?
Thanks!
-- Chris
Hi,
We're preparing to migrate our zones from OpenDNSSEC 1.4 to Knot DNS 3.1
(and eventually the .is zone).
We've already migrated one unsigned zone to the new signers, but next on
the list is first currently signed zone.
We're going to migrate the zone by doing a key rollover, so we'll add
DNSKEY records for the new keys to the zone on the old signer and vice
versa. While we're migrating the zone we have to stop automatic key
rollovers, and I planned to create a new policy 'dnssec_freeze' with
`manual: on` and apply it to zones during migration.
Am I correct that this will stop all automatic key rolloveres, but keep
the signatures updated?
The the migration is complete, DS records and delegations have been
updated etc., I'll change the policy to an automatic policy. Will knot
seamlessly start automatically rolling over keys according to the new
policy?
.einar
I am trying to import a public key generated by BIND into Knot, when using
the SoftHSM2 key store. I have the following pieces of information:
In my knot.conf file:
policy:
- id: SoftHSMRSAPolicy
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 2048
ksk-lifetime: 7h
zsk-lifetime: 6h
dnskey-ttl: 12s
zone-max-ttl: 15s
keystore: SoftHSM
zone:
- domain: 00.mydomain.com
storage: /srv/knot
file: db.mydomain00
dnssec-signing: on
dnssec-policy: SoftHSMRSAPolicy
The public key is in a file named pubkey, and has the following contents:
; This is a zone-signing key, keyid 14694, for 00.mydomain.com.
; Created: 20211109192137 (Tue Nov 9 12:21:37 2021)
; Publish: 20211109192137 (Tue Nov 9 12:21:37 2021)
; Activate: 20211109192137 (Tue Nov 9 12:21:37 2021)
00.mydomain.com. IN DNSKEY 256 3 8 AwEAAd1XmDMiF4/WWW+lneSg2hScxQl
TJHU/cIyBnDJDnW3MFkuyR7e+y3UqZScTXz5tfcGkDYGpqFqZ3+RgyN7A3ZAC3RsayivUuE9lec25IT97
jPZaTsHUjalDQjXkBhCIHBb79vVsz0SMZOeez78qzhRtpdkFYVNRcAW4EZVgdQAdiuJGeDEuxsaTkRnLwujnaqURyAzevqfQfjz319CPsYr4tN4K9nu2Fc0Sh+b5pdM6ejRieLnUUgZpuefRfgsSHJQErNe
FevdtihLpq93r
E5OARwmK0c4vyzgpmREloMJlwV+lrZdlKqZnnIZIXgkD+59Tjh0XZ72exdvonun4uG8=
(The DNSKEY record is in a single line.)
The command I am using to import this key is
# ./keymgr 00.mydomain.com. import-pub ./pubkey
This spins for a few seconds and then prints out:
Error: file error
Any ideas as to what it is that I am doing wrong?
The command that I am invoking to import this public key is the following:
I have been trying to get a better understanding concerning the information
Knot stores in its KASP. Knot adds new key information into the KASP by
means of the kasp_db_add_key function. One of the arguments to this
function is a pointer to a key_params_t structure, one of whose members is
called is_pub_only. This would seem to imply that the KASP may contain
information about key pairs such that only the public component of the key
pair is available to Knot.
Under what set of circumstances would such a key be stored in the KASP?
Since they are used for signing RRs, any KSKs and ZSKs in the KASP have to
be complete, in that both the private and the public components are
available to Knot (I know that the private component itself is not present
in the KASP, but that's OK). A KASP key for which the private component is
not available could be used for verifying signatures - but that's not
something that Knot does, right?
So, under what set circumstances would Knot add a key to the KASP such that
the is_pub_only member is set to true?
