Hi,
Today I migrated my knot from FreeBSD to Gentoo (because it take too
much time to stay on a supported release of FreeBSD)
I rsynced my knot.conf (and changed the paths) and /var/db/knot to
/var/lib/knot
However, daemon failed to start because it wasn’t able to bind to
/var/run/knot/knot.sock, and the permissions where good. I had to remove
/var/db/knot and rsync only zones and keys.
I don’t get the link from files in /var/lib and a denied permission on
/var/run/knot/knot.sock, so I think that there is a bug here.
Regards,
--
Alarig
Dear all,
I have 2 servers and one of them I installed dnsblast.
I read many time your DNS-benchmarking
<https://gitlab.labs.nic.cz/knot/dns-benchmarking> project and get it from
gitlab but I can't send packet more than 500K.
please help.
Best Regards.
Hello!
after reading and rereading the documentation (release 2.9) section on
automatic KSK management, and rereading it again, I finally understood
the part which says "the user shall propagate [the DS] to the parent".
In particular due to the log entry
info: DS check, outgoing, remote 127.0.0.1@53, KSK submission attempt: negative
and the phrasing of the "submission:" configuration stanza, I thought
Knot would attempt to do so itself via dynamic update. I think I was
injecting too much wishful thinking into the text. :)
Now to my two questions:
Is it envisioned to have Knot launch an executable in order to perform
the submission? I'm thinking along the lines of Knot running at every
`check-interval':
./ds-submitter zone "<cds>" "<cdnskey>"
upon which the ds-submitter program could (e.g. via RFC2136) add DS
RRset to the parent zone. Might be nice to have ... (I did see the bit
about journald and using that to trigger DS submission, but using
journald frightens me a bit.)
I notice that a dynamic update on 2.9 logs
info: [zone.] DDNS, processing 1 updates
is there any way to get more details logged (what the update actually
was)? My configuration contains:
log:
- target: syslog
server: debug
control: debug
zone: debug
any: debug
Thank you.
-JP
Hello,
Is KASP directory sharing possible between different knot instances ?
(I have a "public" instance and a "private" one, with internal
addresses, using different storage: directories, but the same kasp-db:)
The internal one sometimes returns invalid DNSSEC data for non-existant
names until I restart it. Is it to be expected in this setup ?
Thanks,
--
Bastien
Hello.
I found another strange behaviour on my slave : it kept old RRSIG's for
SOA entries.
I fixed it by running zone-purge, then zone-retransfer
; <<>> DiG 9.11.5-P1-1~bpo9+1-Debian <<>> +dnssec @87.98.180.13 caa
www.geekwu.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12546
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 19, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.geekwu.org. IN CAA
;; AUTHORITY SECTION:
geekwu.org. 86400 IN SOA ns.geekwu.org.
hostmaster.geekwu.org. 2019101730 3600 1200 2419200 10000
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054714 20181104041714 54076 geekwu.org.
8b6lzlyI1fZUxwtCt9GHsRu1Ist1CtDFm+NifSTTESoMK3XAnW8gyZzp
UIEmNiIRKdYnze+FsW+oEw4hm9pkW/lwgIls3tBvLKCwRseUwrj5jIbh rPK9fYuWM0RP1HBj
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054719 20181104041719 54076 geekwu.org.
uoRZZ4jV2jaubsH7W3VIpIdu9iVKYnz9q+GpNHSnEDv4Mt5JcVnLChLk
/eeRKSK9U7h8yFSOmxdcTBIyITlbGGBeeVbZFdQYsSshpN1Fa7YME9JU ttr5tISHoPnHlM2y
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054723 20181104041723 54076 geekwu.org.
/2EY2DNqeX0GqK0eDcg3dFIqgH0346fP1XuIHM3oswRMnFMtCEDuD325
jpqByKlOkl4Edlv/GyJlJXohrdlWyTzE2xCM6ad2ordYHu0eCO8npfEi OOPc2HhtBYQUM+TU
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054727 20181104041727 54076 geekwu.org.
OwfeorMdvR3Q4XvkSfNxruYJfcPRPIhsnDrrYk41L1gIYMRwEfapO/Te
tza5M07CGx0rQPvFejXHRr7vzlatxvI9k9Vqrs12CR1q7ak+NVhxcM53 syCJVN/z8iKu5uYV
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054731 20181104041731 54076 geekwu.org.
DpyZ6MCWuEA025ghGRJBISd0Lp7qXWb3R27+R/+FWnIytoLrIIzgRLI5
TEojx/k6hlbwFszH024T5CP5vQ1WXjIVyF9ZwNjseJ+skZgPx5ySzqrI R8WXgdpKYi4+SrYs
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054738 20181104041738 54076 geekwu.org.
nNr2vNwLQSlDE7UXQWxGCiTTKb3wyx5VSzhoB8W8ovkSD9EHbcAr3QuP
cR3ICASDhnWySB4NEB7i+qncT90+JEccuxvT8fBCoMHJtMy0YjNqsTLd tOOSitLogl4h8the
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054741 20181104041741 54076 geekwu.org.
/28OcE9l7MXN9wKl2vpI5fxNpu6Ia1i4ku3V61Pix2JPKKJ4YhYG1BDw
aBnpncgso71CiJyVz1Rsp1X50V6tGdibtP/ckRdqvl9f+W+KeCvcrcaS 8u4a5BjeqDFokrfY
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054743 20181104041743 54076 geekwu.org.
GA4eFm1u4jxa+Jhu4vWa+UoucY7OES/8bKxkaIMte0AsC7bPovWdS8Qx
6zrrS9u1PEXS4dDy+PeCxPQFSefaPfiEY44J8JILTaf4OfiL+ij7RI2m MrN1e428veGFFfrY
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054746 20181104041746 54076 geekwu.org.
MnF6nqK/UV+Q68Lf6mV80E4FcClEARc9gclqH4jP0gaxco/DpqGhWEgG
yKM/E8ePIPOaUyRqdoiRKfWS2xcQExhqbeS+orcUjKx04BxDbp8rpCFG lRhR+QLEO4SpTrKo
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181118054749 20181104041749 54076 geekwu.org.
MygQqAnclUn//WxI3gi04Fjkcim/7C4rusz0pj0RXOwl5yAQZMj5gFl7
v5WtUdxbysOhGiiJeHHpWWepD46E2DIlpAp/vKC8hw/DGNRSk6gT6cWl UqylhEIgKrekqVb4
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181125063021 20181111050021 54076 geekwu.org.
h1vHar/cdzpfTbVPhP6UW11aW6pB+1sfagKMBIPDif8mDjvLOP1KsTvI
LuAUUNHaQgcYaoYwc9MrSQ+/se6CweK80B+O7pk+GFSWfqygyHhEvHZt YOHX183eKtYyjFix
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181125063028 20181111050028 54076 geekwu.org.
hDTZuOOKCCWEYlWApA/g+RdSOKxfEGmttto8/BwUNYGBs/2dHziAIQlD
y4SQh2ST1crUeHOTL7d8o+naqbt2lT7pMNqrUQy6XXYdVZ4gQ6aIjVkG Yi7kRgdG8Nksm31N
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20181213181717 20181129164717 63974 geekwu.org.
6BspV1velFjzJQqmGejOSyV6A9NOg3n486/mAx4llB4d+S1KF3j7dzzX
TmMalQN2QufP7NDCVaV4kmtoOgUwS/XcfAQeDJ/b5/bYNa1ERf/tV6bJ 3Z4by5PlXdqoPte5
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20190113191717 20181230174717 21289 geekwu.org.
2+WLMBHmrc2hygRoGtZbtgxikv6aHRv5xDg07nKldKKk/oR9l2GtjpUt
yaMtgu+x/5Uk02eCwea+Vs41wq7BfzcZlL5SNqud9vFqCWAH3izikfLL mngKO3HHBvzxmqgy
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20190213201717 20190130184717 63065 geekwu.org.
8xL2eX4atI6Z+CxwZaF4cwGmNKXY389Qsnz9qZZkXdGcnmzYct5UVBl1
LM0bR/e3D5ZCAhdFR8NynhUKPwCKaSgivjzKNmLunqDFUJgM/4fZFAP8 pXce50jpYXVMBmhm
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20190316211717 20190302194717 19071 geekwu.org.
FdHJKayUYfLsXu9ct9Mfvo1nVRei8xExluWbOfD9wbe/ZDqFQKyBvWKr
hMrdUvSgCQ52iaTWl88cdPtho8YgGXRC+qse5rzqK+9toKbFryg/jFAX 18xJSYrntilYJm1u
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20190416221717 20190402204717 14519 geekwu.org.
kIBe1/zzEbX09gKk0R6MbAicxfoGjL1ojWvR/8oQBdld1yVtyMtLWKic
NhkellgCaXIb7cluj/SAUQC2lr9tJxZp31oG+DhQBAG2arQAVtphxJ0p yUwD7klvUweJM49Y
geekwu.org. 86400 IN RRSIG SOA 14 2 86400
20191109090028 20191026073028 47945 geekwu.org.
9tmNQt48ZT3aTV/WkcfPpLQ3/3rpKXaDlasT9+EnRyniLrLuuHgQtRfw
uxvJpillbGVn15uy9aoMDADV9K5DfdaNOgskK1v3QYgMpGtao+soydi/ Y9MyfDFUQNmSUIKD
Therefore, let's encrypt checks failed when querying it with
"detail": "DNS problem: SERVFAIL looking up CAA for arrakeen.geekwu.org"
; I guess their validating resolver did not picked the correct RRSIG,
and failed to validate.
If you want to investigate, I have another zone which have the same
problem, and a bit more time before certificate expiration, for which I
can provide details, journal, etc.
Regards,
--
Bastien Durel
Hello,
I am using knot version 2.7 with automated keyrollover for DNSSEC.
I am trying to understand the rollover process so that I can exactly
predict when a rollover is in progress.
So far I have understood this:
KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)-->
KSK (1) [ready]
---(submitted in parent zone)-->
---((KSK-TTL) - (DNSKEY TTL + propagation delay + DS parent TTL + x))->
KSK (2) [created and published]
KSK (2) [ready] ---(submitted in parent zone)-->
KSK (1) [retire-active], KSK (2) [active] ---(propagation delay + DNSKEY
TTL)->
KSK (1) [removed]
My observartions during the rollover:
Knot configuration:
DNSKEY-TTL: 12h
Propagation-delay: 2h
Zone TTL default: 1h
KSK-lifetime: 3d
ZSK lifetime: 0
Parent configuration:
DS-TTL on parent: 1h
KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)-->
KSK (1) [ready]
---(submitted in parent zone)-->
---((3d) - (12h + 2h + 1h + x))->
KSK (2) [created and published]
KSK (2) [ready] ---(submitted in parent zone)-->
KSK (1) [retire-active], KSK (2) [active] ---(2h + 12h)->
KSK (1) [removed]
The new key was created 19 hours before the KSK-lifetime ends. When I
substract DNSKEY TTL, propagation delay and DS parent TTL its still 4
hours too early. Somebody knows why?
References:
https://www.knot-dns.cz/docs/2.7/html/reference.htmlhttps://tools.ietf.org/html/rfc6781.html#section-4.1.2
Thanks and Cheers,
Sakirnth
