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 that, unlike the signing process (KSK submission attempts),
> there is no built-in functionality in knot, that takes care about the
> right time to remove the key material from the zone?
Yes. We didn't care much for this usecase, sorry. I guess it's not so
difficult to achieve this manually. We need to have automated just those
processes, that start automatically (e.g. KSK rollover).
> So, basically I should wait
> [propagation-delay] + [max TTL seen in zone/knot_soa_minimum]
> seconds until I manually remove the material.
No, you first need to check when your parent zone removed the DS record.
Afterwards wait for its TTL + propagation_delay.
BR,
Libor
Hi,
I am experimenting with latest knot and its wonderful dnssec autosigner
functionality. It works pretty nice but I am a bit lost in the unsign
process, my zone looks basically like this:
zone:
- domain: "domain.tld."
storage: "/home/oliver/knot/zones"
file: "sign.local"
zonefile-load: "difference"
dnssec-signing: "on"
dnssec-policy: "dnssec-policy"
serial-policy: "unixtime"
policy:
- id: "dnssec-policy"
zsk-lifetime: "2592000"
ksk-lifetime: "31536000"
propagation-delay: "0"
nsec3: "off"
ksk-submission: "local"
cds-cdnskey-publish: "always"
What is the safe way to turn off dnssec once the DS has been seen by
the resolver/knot?
I tried to do dnssec-signing: "off" but that did not change anything;
I also created a second policy called "unsign-policy" where I switched
cds-cdnskey-publish to "cds-cdnskey-publish".
I expected the CDNSKEY/CDS immediately turn into "0 3 0 AA==" and so on
since my propagation-delay is 0 (for faster test results...)
Thanks for any hints!
--
Oliver PETER oliver(a)gfuzz.de 0x456D688F
Hello,
Is there a way how to force AXFR for certain masters in the
configuration? I have a situation with one of master serveres where IXFR
fails - received response is "Format error". Knot does not fall back to
AFXR in this case and the zone is going to expire. Using zone-retransfer
can fix it. Transferring this zone using kdig is also ok.
I can see this with Knot 2.7.2 and Knot 2.7.3 as well.
BR
Ales
Hi,
Is it possible to restrict DNS64 module only for specific IPv6 subnets
in Knot Resolver? The reasoning behind this is that this would make it
possible to run DNS64 resolver on the same instance with the "normal"
resolver in a way that fake AAAA records are returned only to IPv6-only
clients whereas normal dual-stack or IPv4-only clients are served with
unmodified A records.
I found an issue [1] that seems to be related to the very same thing,
but I was left a little bit uncertain what the current situation is and
how this should/could be configured.
[1] https://gitlab.labs.nic.cz/knot/knot-resolver/issues/368
Cheers,
Antti
Hi folks,
sorry for the spam.. now with the right subject..
Maybe anybody can help me..
Is there any possibility to sign with more than one core ? The
"background-workers" parameter didn't help...
KnotDNS is using only one core for signing..
thanks a lot
best regards
--
Christian Petrasch
Senior System Engineer
DNS/Infrastructure
IT-Services
DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY
E-Mail: petrasch(a)denic.de
Fon: +49 69 27235-429
Fax: +49 69 27235-239
http://www.denic.de
PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841
549B E0AE
Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg
Schweiger
Vorsitzender des Aufsichtsrats: Thomas Keller
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht
Frankfurt am Main
Hi,
Every time we switch DNSSEC on for a single zone, it iterates over all
zones (and logs something trivial about each). This appears to us as
not very efficient. Is there a reason for it? Following the
documentation we had not expected this behaviour,
https://www.knot-dns.cz/docs/2.6/html/configuration.html#zone-signing
We are running Knot DNS with ~3500 zones, so you can imagine this has a
bit of an impact.
Thanks,
-Rick
Hi,
Roland and I ran into a crashing condition for knotd 2.6.[689],
presumably caused by a race condition in the threaded use of PKCS #11
sessions. We use a commercial, replicated, networked HSM and not SoftHSM2.
WORKAROUND:
We do have a work-around with "conf-set server.background-workers 1" so
this is not a blocking condition for us, but handling our ~1700 zones
concurrency would be add back later.
PROBLEM DESCRIPTION:
Without this work-around, we see crashes quite reliably, on a load that
does a number of zone-set/-unset commands, fired by sequentialised knotc
processes to a knotd that continues to fire zone signing concurrently.
The commands are generated with the knot-aware option -k from ldns-zonediff,
https://github.com/SURFnet/ldns-zonediff
ANALYSIS:
Our HSM reports errors that look like a session handle is reused and
then repeatedly logged into, but not always, so it looks like a race
condition on a session variable,
27.08.2018 11:48:59 | [00006AE9:00006AEE] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
27.08.2018 11:48:59 | [00006AE9:00006AEE] C_GetAttributeValue
| E: Error CKR_USER_NOT_LOGGED_IN occurred.
27.08.2018 11:48:59 | [00006AE9:00006AED] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
27.08.2018 11:48:59 | [00006AE9:00006AED] C_GetAttributeValue
| E: Error CKR_USER_NOT_LOGGED_IN occurred.
27.08.2018 11:49:01 | [00006AE9:00006AED] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
27.08.2018 11:49:01 | [00006AE9:00006AED] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
27.08.2018 11:49:01 | [00006AE9:00006AED] C_GetAttributeValue
| E: Error CKR_USER_NOT_LOGGED_IN occurred.
27.08.2018 11:49:02 | [00006AE9:00006AEE] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
27.08.2018 11:49:03 | [00006AE9:00006AEE] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
27.08.2018 11:55:50 | [0000744C:0000744E] C_Login
| E: Error CKR_USER_ALREADY_LOGGED_IN occurred.
These errors stopped being reported with the work-around configured.
Until that time, we have crashes, of which the following dumps one:
Thread 4 "knotd" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffcd1bd700 (LWP 27375)]
0x00007ffff6967428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff6967428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff696902a in __GI_abort () at abort.c:89
#2 0x00007ffff69a97ea in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ffff6ac2ed8 "*** Error in `%s': %s: 0x%s ***\n") at
../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff69b237a in malloc_printerr (ar_ptr=,
ptr=,
str=0x7ffff6ac2fe8 "double free or corruption (out)", action=3) at
malloc.c:5006
#4 _int_free (av=, p=, have_lock=0) at
malloc.c:3867
#5 0x00007ffff69b653c in __GI___libc_free (mem=) at
malloc.c:2968
#6 0x0000555555597ed3 in ?? ()
#7 0x00005555555987c2 in ?? ()
#8 0x000055555559ba01 in ?? ()
#9 0x00007ffff7120338 in ?? () from /usr/lib/x86_64-linux-gnu/liburcu.so.4
#10 0x00007ffff6d036ba in start_thread (arg=0x7fffcd1bd700) at
pthread_create.c:333
#11 0x00007ffff6a3941d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
DEBUGGING HINTS:
Our suspicion is that you may not have set the mutex callbacks when
invoking C_Initialize() on PKCS #11, possibly due to the intermediate
layers of abstraction hiding this from view. This happens more often.
Then again, the double free might pose another hint.
This is on our soon-to-go-live platform, so I'm afraid it'll be very
difficult to do much more testing, I hope this suffices for your debugging!
I hope this helps Knot DNS to move forward!
-Rick
Hi folks,
maybe anybody can help me..
Is there any possibility to sign with more than one core ? The
"background-workers" parameter didn't help...
KnotDNS is using only one core for signing..
thanks a lot
best regards
--
Christian Petrasch
Senior System Engineer
DNS/Infrastructure
IT-Services
DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY
E-Mail: petrasch(a)denic.de
http://www.denic.de
PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841
549B E0AE
Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg
Schweiger
Vorsitzender des Aufsichtsrats: Thomas Keller
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht
Frankfurt am Main
