Hello all,
we want to migrate to a state of the art nameserver software.
Our startingpoint is djbdns/tinydns.
Our first step should be to to use zone transfer from tinydns to knot-dns
(2.7.6).
I configure the knot-dns a slave:
# knotc conf-read
…
acl.id = master
acl[master].address = 5.28.40.220
acl[master].action = notify
remote.id = master
remote[master].address = 5.28.40.220
…
zone.domain = vtnx.net.
zone[vtnx.net.].master = master
zone[vtnx.net.].acl = master
and add a initial soa rr for that domain:
vtnx.net. 0 SOA ns1.vtnx.net. hostmaster.vtnx.net. 1 16384 2048 1048576 2560
This the exact soa of the running vtnx.net domain, but a diffrent serial.
After triggering the notification from the master, i got this logging:
Jan 24 07:53:19 ns1-neu knotd[26299]: info: [vtnx.net.] notify, incoming, 5.28.40.220@38668: received, serial none
Jan 24 07:53:19 ns1-neu knotd[26299]: info: [vtnx.net.] refresh, outgoing, 5.28.40.220@53: remote serial 1548307450, zone is outdated
Jan 24 07:53:19 ns1-neu knotd[26299]: warning: [vtnx.net.] IXFR, incoming, 5.28.40.220@53: malformed response SOA
Jan 24 07:53:19 ns1-neu knotd[26299]: warning: [vtnx.net.] refresh, remote master not usable
Jan 24 07:53:19 ns1-neu knotd[26299]: error: [vtnx.net.] refresh, failed (no usable master)
What about "malformed response SOA"?
Why is this an IXFR and no AXFR?
- Frank
--
Frank Matthieß Mail: frank.matthiess(a)virtion.de
GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1
virtion GmbH Stapenhorster Straße 42b, DE 33615 Bielefeld
Geschäftsführer: Michael Kutzner
Handelsregister HRB 40374, Amtsgericht Bielefeld, USt-IdNr.: DE278312983
Hi,
I want to use Ansible to deploy zone files to my Knot signer (hidden
master). The zone files should be generated from the Ansible playbook
data and will not contain any DNSSEC related information, just SOA, NS,
A, AAAA, TXT and MX records. I'd like to use Knot DNSSEC auto-signing. I
can stop the Knot process before deploying new zone files. I use
zonefile-load: difference in this case, as of the DNSKEY / CDNSKEY / CDS
data should not be replaced with something new. Should this work for me,
or is there anything I miss or is there even a better option?
Kind regards,
Volker
Hi,
I'm working on a registry for +31 ENUM, using Knot DNS 2.6.8. The
intention is to trigger the Python API from PostgreSQL database views.
The postgres user, though added to the knot group and granted rw- on all
of /var/db/knot/* and the knotd socket, cannot do thinkgs like conf-read
through the Python API or knotc.
This is where root and the postgres user diverge:
84630 knotc CALL
open(0x7fffffffe100,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>)
84630 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)"
84630 knotc RET open 6
84630 knotc CALL fstat(0x6,0x7fffffffe068)
84630 knotc STRU struct stat {dev=4261341516, ino=125942,
mode=0100660, nlink=1, uid=0, gid=0, rdev=4294967295,
atime=1545172776.416579000, mtime=1545182138.348328000,
ctime=1545182138.348328000, birthtime=1545172776.416478000, size=16,
blksize=4096, blocks=2, flags=0x800 }
That's root. uid=0 and gid=0 for the /tmp/SENDMDB... file. But now:
84649 knotc CALL
open(0x7fffffffe0f0,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>)
84649 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)"
84649 knotc RET open -1 errno 13 Permission denied
That's user postgres, even though it is in the knot group. It seems to
see the file but have no access, probably due to uid=0, gid=0.
Note that matching name.
--> What is this file it is trying to open, and is it always mapped to
uid=0,gid=0, even if the user running "knotc conf-read" is not root?
Could this be a FreeBSD things, or a jail thing?
Any advise is welcome!
Thanks!
-Rick