Hi Chris,
first of all, you seem to be talking about Knot DNS, so it's proper to
switch to correct mailing list, instead of Knot Resolver's one.
I assume you have read all the single-version migration guides below
https://www.knot-dns.cz/docs/3.0/singlehtml/index.html#upgrade-2-6-x-to-2-7…
. It's clear that when migrating over multiple versions, you need to
take care about all the notes at once.
What databases exactly are you talking about? Knot DNS uses multiple
databases for different purposes, e.g. journal or KASP DB. The good news
is, their format does not change much, and when it does, it's usually
backwards-compatible, with some exceptions.
I would strongly recommend that you clone your environment, perform the
migration in some "playground" setup first, and observe if everything
went well; all before migration your production setup ;) Should you
encounter any issues, please contact us on our mailing-list.
Anyway, you might consider a multi-step migration, so that you would
migrate by just one (major) version at once, like this: 2.6.5 -> 2.7.8
-> 2.8.5 -> 2.9.9 -> 3.0.5.
Thanks!
Libor
Dne 09. 04. 21 v 8:13 Daniel Salzman napsal(a):
>
>
> -------- Forwarded Message --------
> Subject: [knot-resolver-users] Any "gothcas" going from 2.65 to 3.04 I should know about?
> Date: Thu, 08 Apr 2021 23:03:54 -0700
> From: Chris <knot(a)tacomawireless.net>
> Reply-To: Knot Resolver Users List <knot-resolver-users(a)lists.nic.cz>
> To: knot-resolver-users <knot-resolver-users(a)lists.nic.cz>
>
> Hi. Moving a couple of our servers to new hardware, and
> taking that opportunity to upgrade some of the services
> at the same time. The main one being knot. Moving from
> a 2.65 context to 3.04. I've read the upgrade doc, and
> while there isn't a 2.65 --> 3.04. It appears for our
> environment that the changed/removed stanzas won't
> have much of an impact *except* as they relate to the
> database. That is; it appears that it isn't going to
> be a smooth transition, as they appear to be incompatible.
> Is that right? Do I need to rewrite all the keys &&
> serials, and start from scratch? If so, as we have
> a huge number of domains, this will be an enormous task.
> Is this avoidable?
>
> Thank you for any and all insight into this transition.
>
> --Chris
Is there a way to configure Knot to avoid overwriting a zone file when
it's doing automatic signing?
I was hoping some combination of zonefile-load and journal-content
would tell Knot to store its internally managed data in the journal
instead of in the zone file, but I haven't found that combination. I
don't see any other likely candidates in the config options, but
hoping I've missed something...
Good afternoon,
in preparation for Knot 3.1, I wanted to update our template that uses
zonefile-load: difference-no-serial from journal-content: changes to
journal-content: all.
However, it seems that we somehow have to update the existing journal.
Otherwise it seems the first change to a zone after that change, will
lead to the following error (running knot 3.0.4):
error: [example.net.] zone event 'load' failed (semantic check)
Subsequent changes seem to be applied just fine.
What is the proposed strategy to change this setting?
Regards
André
Hi,
we performed successfully an algorithm rollover. After changing the
algorithm in the configuration file everything worked as expected. All
zones have been updated to the new algorithm.
When I now sign a new zone the zone is being signed with the old
algorithm's key and an algorithm rollover is being triggered immediately.
Is this an expected behavior? How can I avoid this? Do I have to delete
the old key?
Thanks a lot,
Thomas
Hi!
I have two Debian 10 Buster systems, both patched up current, and both
running Knot 3.0.4-1~cz.nic~buster1 from the apt repository at
https://deb.knot-dns.cz/knot-latest/.
Both Knot installations have virtually identical configs .. really
only different in the related hosts and zone lists. Their logging
configs are both:
log:
- target: syslog
any: info
One of these Knot instances logs to syslog, and the other logs to
systemd-journald. I'm trying to figure out why the difference, and
I've come up empty. The Knot docs simply say that if Knot is compiled
against systemd, then a 'syslog' setting will use systemd-journald.
Mostly I want to know so that I can convince the one using journald to
stop doing that. :) What other things might trigger Knot to use
syslog on a systemd-managed host?
Hi,
is it possible to have two different DNSSEC policies in place? For
example having one domain singed with Alg 8 and another one with Alg 13?
Thanks a lot,
Thomas
Hi!
Today we tried to do a dynamic update to the dnskey set.
What we want to do is to import the ZSK from another signer.
Didn’t work so well.
Feb 16 17:15:28 ip-172-31-38-41 knotd[24222]: warning: DDNS, refusing to update DNSSEC-related record
I guess knot doesn’t like dynamic DNSSEC updates.
I even tried with policy manual:on.
What does one have to do to be allowed to add (or delete) DNSKEY records?
/Ulrich