Hi,
What is your version of Knot?
Could you please:
- Purge the timers `knotc -f zone-purge example.org. +timers`
- Re-sign the zone `knotc zone-sign example.org`
- Repeat your test
?
Thanks,
Daniel
On 2018-10-17 23:25, Maximilian Engelhardt wrote:
Hi,
I'm using a zone with DNSSEC signing
Hi Daniel,
The test was done using version 2.7.2. Tonight it got updated to 2.7.3, but I
don't see any difference with the new version
$ knotc -f zone-purge example.org. +timers
OK
$ knotc zone-sign example.org
OK
log output:
Okt 18 12:02:15 backroad knotd[15628]: info: [example.org.]
Hi Libor,
I don't know why the message appears three times. I was also wondering about
this. I had a quick look at a tcpdump and nsupdate does indeed send three
requests:
12:27:57.973741 IP6 (flowlabel 0x5e7e8, hlim 64, next-header UDP (17) payload
length: 37) ::1.5835 > ::1.53: [bad udp
Hi Libor,
Thanks a lot for your help.
On Wed, 17 Oct 2018 14:06:00 +0200
"libor.peltan" wrote:
> by default, all changes to the zone, including DNSSEC signing, are
> immediately flushed into zonefile. Thus, if you simply set
> dnssec-signing to off, Knot stops signing the zone, but the
>
Hi Oliver,
Ah, the mistake was that changing the dnssec-policy *and* dnssec-signing
in one go does not insert the delete-CDS/CDNSKEY records since knot
immediately stops all dnssec related actions. Thanks!
You at least want to have the special CDNSKEY record -signed- anyway ;)
Am I right
Hi Maxi,
thank you for the information provided. There really seem to be a bug in
re-planning DNSSEC re-sign. I will take a look on it.
Btw, try using knsupdate instead of nsupdate ;)
Regarding the not-responding Knot, the only idea I have is it could have
been possibly Knot unable to bind
Hi Libor,
Thanks for you help.
In fact I tried to use knsupdate at some time in the the past and it didn't
work, which later turned out to mainly be a configuration issue on my side.
Maybe I will try switching again some time in the future.
I don't know if this was clear in my last messages,
