Hello,
I'm new to that list. Using NSD + DNSSEC + key rotation for many years.
Now I like to check if and how KNOT's auto keyrotaton can safe me from my ugly script foo...
https://lists.nic.cz/pipermail/knot-dns-users/2019-November/001721.html
JP Mens mention "I'm rolling the KSK every five minutes for testing"
instead I reinvent the wheel: could one post the relevant settings?
Thanks,
Andreas
After several successful attempts using the exact same configuration and
steps mentioned in early question here
<https://lists.nic.cz/pipermail/knot-dns-users/2020-January/001744.html> or
here <https://gist.github.com/azzamsa/24dca2e201c3bea4f489a09f7a3a8716>
(with better preview)
I get stuck with no usable master
The master side
Jan 12 07:35:12 knot-master-1.novalocal knotd[12007]: info:
[namadomain14.com.] zone file updated, serial 2018070410
Jan 12 07:35:12 knot-master-1.novalocal knotd[12007]: warning:
[namadomain14.com.] notify, outgoing, remote slaveip@53, s...TAUTH'
Jan 12 07:37:18 knot-master-1.novalocal knotd[12007]: info:
[namadomain14.com.] control, received command 'zone-begin'
Jan 12 07:37:32 knot-master-1.novalocal knotd[12007]: info:
[namadomain14.com.] control, received command 'zone-set'
Jan 12 07:37:37 knot-master-1.novalocal knotd[12007]: info:
[namadomain14.com.] control, received command 'zone-commit'
Jan 12 07:37:37 knot-master-1.novalocal knotd[12007]: info:
[namadomain14.com.] zone file updated, serial 2018070410 -> 2018070412
Jan 12 07:37:37 knot-master-1.novalocal knotd[12007]: warning:
[namadomain14.com.] notify, outgoing, remote slaveip@53, s...TAUTH'
Jan 12 07:37:41 knot-master-1.novalocal knotd[12007]: info: control,
received command 'zone-read'
Jan 12 07:38:11 knot-master-1.novalocal knotd[12007]: info:
[namadomain14.com.] control, received command 'zone-notify'
Jan 12 07:38:11 knot-master-1.novalocal knotd[12007]: warning:
[namadomain14.com.] notify, outgoing, remote slaveip@53, s...TAUTH'
The slave side
Jan 12 07:34:54 knot-slave-1 knotd: info: control, received command 'conf-read'
Jan 12 07:35:19 knot-slave-1 systemd-logind: Removed session 2.
Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-begin'
Jan 12 07:35:20 knot-slave-1 knotd: notice: control, persistent
configuration database not available
Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-set'
Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-set'
Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-set'
Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command
'conf-commit'
Jan 12 07:35:20 knot-slave-1 knotd: info: [namadomain14.com.] zone
will be loaded
Jan 12 07:35:20 knot-slave-1 knotd: info: [namadomain14.com.] failed
to parse zone file (not exists)
Jan 12 07:35:21 knot-slave-1 knotd: warning: [namadomain14.com.]
refresh, remote master1 not usable
Jan 12 07:35:21 knot-slave-1 knotd: error: [namadomain14.com.]
refresh, failed (no usable master)
Jan 12 07:35:23 knot-slave-1 knotd: warning: [namadomain14.com.]
refresh, remote master1 not usable
Jan 12 07:35:23 knot-slave-1 knotd: error: [namadomain14.com.]
refresh, failed (no usable master)
Jan 12 07:35:27 knot-slave-1 knotd: info: control, received command 'zone-read'
Jan 12 07:35:29 knot-slave-1 knotd: info: control, received command 'zone-read'
Jan 12 07:35:34 knot-slave-1 knotd: warning: [namadomain14.com.]
refresh, remote master1 not usable
Jan 12 07:35:34 knot-slave-1 knotd: error: [namadomain14.com.]
refresh, failed (no usable master)
Jan 12 07:36:31 knot-slave-1 knotd: warning: [namadomain14.com.]
refresh, remote master1 not usable
Jan 12 07:36:31 knot-slave-1 knotd: error: [namadomain14.com.]
refresh, failed (no usable master)
Jan 12 07:37:14 knot-slave-1 knotd: info: [namadomain14.com.] control,
received command 'zone-begin'
Jan 12 07:37:55 knot-slave-1 knotd: info: [namadomain14.com.] control,
received command 'zone-abort'
Jan 12 07:38:19 knot-slave-1 knotd: info: control, received command 'zone-read'
Jan 12 07:39:12 knot-slave-1 knotd: warning: [namadomain14.com.]
refresh, remote master1 not usable
Jan 12 07:39:12 knot-slave-1 knotd: error: [namadomain14.com.]
refresh, failed (no usable master)
Problems
Previously, even though I have ‘NO AUTH’ in master side. The zone in slave
still crated, because I don’t get no usable master.
But the sudden there is no usable master. I’ve tried:
- sudo service knot restart
- remove everything -> reinstall everything
Both give me no luck.
Thank you in advance.
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
