Just to clarify some semantics of the config format.
Is each individual 'remote' ID considered to be a single server,
regardless of the number of addresses it has?
For the notify case, it looks like knot will send to each address in a
remote ID in serial, and stop as soon as one replies. That suggests
the above semantics, but I wanted to make sure I'm interpreting this
behaviour correctly before I complicate my config by adding a lot more
remotes. I am currently treating each remote as an organisation,
lumping all of that organisation's servers together under a single ID.
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
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
