Good day,
is there some tool to migrate configuration from 1.6.5 to actual
version ? Keys, configuration, ...
Thanks and best regards
J.Karliak
--
Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a
DomainKeys/DKIM (s ADSP) a implementaci DMARC. Pokud mate problemy s
dorucenim emailu, zacnete pouzivat metody overeni puvody emailu
zminene vyse. Dekuji.
My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP)
policy and implementation of the DMARC. If you've problem with sending
emails to me, start using email origin methods mentioned above. Thank
you.
Setting up slave zone (slave DNS server)
I’ve asked the previous question Setting up slave zone (slave DNS server)
<https://gitlab.labs.nic.cz/knot/knot-dns/issues/667>.
And I’ve followed Libor Peltan’s advice to also configure the zone in the
slave
side. But It still didn’t work for me.
Config
knot.conf in *master* server
# This is a sample of a minimal configuration file for Knot DNS.
# See knot.conf(5) or refer to the server documentation.
server:
rundir: "/run/knot"
user: knot:knot
listen: [ 127.0.0.1@53, ::1@53 ]
log:
- target: syslog
any: info
database:
storage: "/var/lib/knot"
remote:
- id: slave1
address: 111.11.11.111@53
acl:
- id: slave1_acl
address: 111.11.11.111
action: transfer
template:
- id: default
storage: "/var/lib/knot"
file: "%s.zone"
zone:
# # Master zone
# - domain: example.com
# notify: slave
# acl: acl_slave
# # Slave zone
# - domain: example.net
# master: master
# acl: acl_master
knot.conf in my *slave* server
# This is a sample of a minimal configuration file for Knot DNS.
# See knot.conf(5) or refer to the server documentation.
server:
rundir: "/run/knot"
user: knot:knot
listen: [ 127.0.0.1@53, ::1@53 ]
log:
- target: syslog
any: info
database:
storage: "/var/lib/knot"
remote:
- id: master1
address: 222.22.22.222@53
acl:
- id: master1_acl
address: 222.22.22.2222
action: notify
template:
- id: default
storage: "/var/lib/knot"
file: "%s.zone"
zone:
# # Master zone
# - domain: example.com
# notify: slave
# acl: acl_slave
# # Slave zone
# - domain: example.net
# master: master
# acl: acl_master
conf-read result
conf-read in *master* server
[root@knot-master-1 centos]# knotc conf-read
server.rundir = /run/knot
server.user = knot:knot
server.listen = 127.0.0.1@53 ::1@53
log.target = syslog
log[syslog].any = info
database.storage = /var/lib/knotacl.id = slave1_acl
acl[slave1_acl].address = 222.22.22.222
acl[slave1_acl].action = transferremote.id = slave1
remote[slave1].address = 222.22.22.222(a)53template.id = default
template[default].storage = /var/lib/knot
template[default].file = %s.zone
zone.domain = namadomain.com.
zone[namadomain.com.].file = namadomain.com.zone
zone[namadomain.com.].notify = slave1
zone[namadomain.com.].acl = slave1_acl
conf-read in *slave* server
[root@knot-slave-1 centos]# knotc conf-read
server.rundir = /run/knot
server.user = knot:knot
server.listen = 127.0.0.1@53 ::1@53
log.target = syslog
log[syslog].any = info
database.storage = /var/lib/knotacl.id = master1_acl
acl[master1_acl].address = 111.11.11.111
acl[master1_acl].action = notifyremote.id = master1
remote[master1].address = 111.11.11.111(a)53template.id = default
template[default].storage = /var/lib/knot
template[default].file = %s.zone
zone.domain = namadomain.com.
zone[namadomain.com.].master = master1
zone[namadomain.com.].acl = master1_acl
Zone Read
zone-read in *master* server
[root@knot-master-1 centos]# knotc zone-read --
[namadomain.com.] namadomain.com. 86400 TXT "hello"
[namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id.
hostmaster.biz.net.id. 2018070411 3600 3600 604800 38400
zone-read in *slave* server
[root@knot-slave-1 centos]# knotc zone-read --
[namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id.
hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400
Steps I use to create a zone
in *master* server
knotc conf-begin
knotc conf-set 'zone[namadomain.com]'
knotc conf-set 'zone[namadomain.com].file' 'namadomain.com.zone'
knotc conf-set 'zone[namadomain.com].notify' 'slave1'
knotc conf-set 'zone[namadomain.com].acl' 'slave1_acl'
knotc conf-commit
knotc zone-begin namadomain.com
knotc zone-set namadomain.com. @ 86400 SOA ns1.biz.net.id.
hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400
knotc zone-set namadomain.com. @ 86400 TXT "hello"
knotc zone-commit namadomain.com
in *slave* server
knotc conf-begin
knotc conf-set 'zone[namadomain.com]'
knotc conf-set 'zone[namadomain.com].master' 'master1'
knotc conf-set 'zone[namadomain.com].acl' 'master1_acl'
knotc conf-commit
knotc zone-begin namadomain.com
knotc zone-set namadomain.com. @ 86400 SOA ns1.biz.net.id.
hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400
knotc zone-commit namadomain.com
Problems
If we look closely. I’ve crated the configuration of namadomain.com in
*both* master and slave servers. Also I’ve created the SOA record of of
namadomain.com in *both* master and slave servers. But I only create file
config in *master* server and TXT record in *master* server (to test if
AXFR zone transfer worked).
Unfortunately, the file config and the TXT record is not created by slave,
even though I’ve waited for more than hour (1 day actually). Am I missing
something here? (I never put the zone directly in zone: section of
knot.conf,
I always use knotc since I will use libknot control.py to manage zones with
our
app <https://github.com/BiznetGIO/RESTKnot>)
Also am I able to see if the knot in master emit the transfer ‘signal’ and
check
if knot in slave receive that signal? So It will make me easier to debug.
I’ve tried to trigger knotc zone-notify namadomain.com in *master* side,
and knotc zone-retransfer namadomain.com in *slave* side. But nothing
changed.
[root@knot-master-1 centos]# knotc zone-notify namadomain.com
OK
[root@knot-master-1 centos]# knotc zone-read --
[namadomain.com.] namadomain.com. 86400 TXT "hello"
[namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id.
hostmaster.biz.net.id. 2018070411 3600 3600 604800 38400
[root@knot-slave-1 centos]# knotc zone-retransfer namadomain.com
OK
[root@knot-slave-1 centos]# knotc zone-read --
[namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id.
hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400
Machine
# knotc --version
knotc (Knot DNS), version 2.9.1
OS: CentOS 7.5
Thank you in advance.
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
