Does KnotDNS Resolver support the use of different RPZ's per-view?
Looking to create a DNS setup that allows recursion to two separate
groups, one using one RPZ setup, the other using another.
Is this possible with Knot?
Thanks,
-jake
I'm building my own RPM for Knot 2.2.0 on Centos 7 due to the fact that the
system version is still 1.x. I'm building it with systemd integration, and
I've borrowed the systemd service file from the Fedora RPM. I'm having
issues at startup, though.
I'm wondering if it's related to the use of 'Type=notify', since knot seems
to be running, but then after a delay of 30 seconds systemd decides it has
failed and kills it.
I'm attaching useful bits below. Any thoughts on the cause?
My service file is:
[Unit]
Description=Knot DNS server daemon
[Service]
Type=notify
ExecStart=/usr/sbin/knotd
ExecReload=/usr/sbin/knotc reload
Restart=on-abort
ExecStartPre=/usr/sbin/knotc conf-check
# Breaks daemon reload
#CapabilityBoundingSet=cap_net_bind_service cap_setuid cap_setgid
[Install]
WantedBy=multi-user.target
And this is what knot is reporting at startup:
● knot.service - Knot DNS Server
Loaded: loaded (/etc/systemd/system/knot.service; disabled; vendor
preset: disabled)
Active: failed (Result: timeout) since Thu 2016-05-12 19:52:34 UTC; 3min
19s ago
Process: 5875 ExecStart=/usr/sbin/knotd (code=exited, status=0/SUCCESS)
May 12 19:51:04 master01.test.conundrum.com knotd[5875]:
2016-05-12T19:51:04 info: starting server
May 12 19:51:04 master01.test.conundrum.com knotd[5875]:
2016-05-12T19:51:04 info: server started in the foreground, PID 5875
May 12 19:51:04 master01.test.conundrum.com knotd[5875]:
2016-05-12T19:51:04 info: control, binding to '/var/run/knot/knot.sock'
May 12 19:52:34 master01.test.conundrum.com systemd[1]: knot.service start
operation timed out. Terminating.
May 12 19:52:34 master01.test.conundrum.com knotd[5875]:
2016-05-12T19:52:34 info: stopping server
May 12 19:52:34 master01.test.conundrum.com knotd[5875]:
2016-05-12T19:52:34 info: updating zone timers database
May 12 19:52:34 master01.test.conundrum.com systemd[1]: Failed to start
Knot DNS Server.
May 12 19:52:34 master01.test.conundrum.com systemd[1]: Unit knot.service
entered failed state.
May 12 19:52:34 master01.test.conundrum.com systemd[1]: knot.service failed.
May 12 19:52:34 master01.test.conundrum.com knotd[5875]:
2016-05-12T19:52:34 info: shutting down
And finally, the config report from building the package:
knot 2.2.0
Target: linux-gnu x86_64
Compiler: gcc -std=gnu99
CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -DNDEBUG -Wno-unused -Wall -Werror=format-security
-Werror=implicit -fpredictive-commoning
LIBS: -lcap-ng -ldl -lpthread -lm -Wl,-z,relro
LibURCU: -lurcu
GnuTLS: -lgnutls -lnettle -I/usr/include/p11-kit-1
Jansson: -ljansson
Libedit: -ledit -ltinfo -I/usr/include/editline
LMDB: shared -llmdb
Sanitizer:
LibFuzzer: no
Prefix: /usr
Run dir: /var/run/knot
Storage dir: /var/lib/knot
Config dir: /etc/knot
Configuration DB mapsize: 500 MiB
Timers DB mapsize: 100 MiB
Knot DNS libraries: yes
Knot DNS daemon: yes
Knot DNS utils: yes
Knot DNS documentation: yes
Use SO_REUSEPORT: yes
Fast zone parser: yes
Utilities with IDN: yes
Systemd integration: yes
Dnstap support: yes
Code coverage: no
Bash completions: no
PKCS 11 support: no
I've just upgraded to 2.2.0 and noticed that knot failed to start. Upon
inspection, I found that:
/usr/lib/systemd/system/knot.service had the following line:
ExecStartPre=/usr/sbin/knotc checkconf
I think this is an error. I had to modify it to:
ExecStartPre=/usr/sbin/knotc conf-check
and then reimport the knot.conf file to get knot to start successfully.
Hello everyone!
Knot DNS 2.2.0 by CZ.NIC Labs has been just released! This release
brings only a few new features, but it contains a bunch of important
bugs fixes and many significant changes under the hood.
Let's start with the bug fixes and improvements:
- We have resolved build dependency issues on FreeBSD. And we have fixed
a problem when detecting PKCS #11 support in GnuTLS.
- Some bugs related to Dnstap were resolved as well. The logging module
now correctly sets query/response message type. And kdig properly uses
the remote address when showing the capture.
- The global instances of query modules were not executed for queries
hitting existing zones. This problem is fixed in the new release.
- We have enabled execution of semantic checks after IXFR to unify the
behavior with AXFR. Also the logging of messages related to transfers
was improved a little bit.
- The DNSSEC signing produces correct NSEC/NSEC3 bitmap for delegations
where a glue record has the same name as the delegated zone.
- We have added some fixes hopefully improving compatibility with
PKCS #11 devices. The most significant change is that the generated
keys are marked as sensitive. It makes perfect sense and some devices
(e.g. Luna SA) actually require this attribute to be set.
- The configuration transaction is not aborted when some consistency
check fails. This is particularly useful, if you make a typo when
changing the server configuration with knotc. We have also eliminated
an incorrect error when the last zone was being removed from the
server.
- There are also some bug fixes and improvements in the utilities. The
keymgr utility should provide more sensible error messages, new
consistency checks were added, and some commands were extended
a little bit. The kdig utility now properly handles AXFR responses
containing only the SOA record in the first message. And kdig will
also use a local resolver if the resolv.conf file is empty.
- The zone event scheduler was improved. And we hope that it will speed
up the event lookup if you have many many zones.
And finally the new features:
- We have added RRL white listing. This allows to exempt some clients
from rate limiting, for example your monitoring hosts. See the
rate-limit-whitelist configuration option for details.
- We have added support for URI (RFC 7553) and CAA (RFC 6844) resource
record types.
- The knotc utility now supports interactive mode with command line
editing, tab completion, and history. Just start knotc without any
command and give it a try.
- And the server has a new control interface we will be extending in the
future. The knotc utility already uses this interface. And we also
have a simple Python binding for this interface. We are definitely
looking for some feedback.
That's all folks. Thank you for using Knot DNS.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/2.2/NEWS
Source archive:
https://secure.nic.cz/files/knot-dns/knot-2.2.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.2.0.tar.xz.asc
Cheers,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
Hey,
I was wondering if any work has been done on a statistics module for Knot DNS? I have read the mailing list and saw the conversation between Daniel and Julian, but haven’t seen anything on the list since then and I don’t see anything the documentation.
Best regards,
/rog
Good morning,
it is able to run knot resolver daemon with knot 1.6.x ?
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.
Good morning,
I run knot2 on opensuse, configuration was migrated from 1.6. to 2.1.1,
I run step by step configuration by manual to keymgr and after command :
"keymgr policy add secure keystore hsm"
I get a message:
celer:/var/lib/knot/kasp # keymgr policy add secure keystore hsm
Policy with given name alredy exists.
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])
Previos command was
keymgr keystore add hsm backend pkcs11 config
"pkcs11:token=knot;pin-value=4587 libsofthsm2.so"
and was successfull.
On the testing "server" with knot all works fine, testing server is
opensuse 42.1 x64. Problem is on opensuse 13.2 x64
There is a core dump in the attachment. In the /var/log/messages were
complains to libc:
Apr 11 10:25:49 celer kernel: [7927072.584757] keymgr[13591]: segfault at
7fff18000000 ip 00007f3f59c20ca4 sp 00007fff18064f18 error 4 in
libc-2.19.so[7f3f59ba5000+19e000]
For sure I made upgrade of glib by zypper, but no success.
Any ideas ?
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.
Hi,
we're using knot DNS (2.0.2) on one of our primaries, to balance out
"BIND is used everywhere". So far, we're quite happy, but today I got
a complaint from our hostmaster team - triggered by a warning from DENIC
that "our SOA records are inconsistent".
Turns out they are, if you look at uppercase/lowercase...
$ dig +short @ns.space.net space.net soa
ns.space.net. hostmaster.space.net. 2016040601 28800 3600 864000 1800
$ dig +short @ns3.dns.space.net space.net soa
ns.Space.Net. hostmaster.Space.Net. 2016040601 28800 3600 864000 1800
first one is knot, second is BIND, and the "mixed case" spelling is
what the zone master (hidden primary) is distributing.
(I understand that DNS is not case-significant, but we're using upper
case in DNS labels because we like it that way...)
Looking at labels inside the zone (dig axfr) shows that knot is lowercasing
*everything*, not only the SOA records.
So, I started looking whether there is a switch that can change knot's
behaviour to just leave the labels alone, and do not lowercase everything.
Google did not find anything, neither did "man knotd" or "man knot.conf".
So, is there a hidden switch or compile-time feature to achieve this?
thanks in advance,
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hello to all,
I tried to look a little bit to the codes but can I ask how concurrent
update is avoided? I mean RCU is used to avoid concurrent read and write.
But how concurrent update is avoided?
Thank you!
masoud
Good morning,
I've migrated to knot2, configuration file was migrated by knot1to2
tool. Knot 2 loads, but to not load my DNSSEC signed zone (NSEC, not
NSEC3). Knot2 is installed from suse dns server repo, version
"knot2-2.1.1-1.1.x86_64".
Error message:
Apr 7 08:57:39 celer knotd[21676]: info: reloading configuration file
'/etc/knot/knot.conf'
Apr 7 08:57:39 celer knotd[21676]: info: configuration reloaded
Apr 7 08:57:39 celer knotd[21676]: info: [domain.cz] zone loader,
semantic check, completed
Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] DNSSEC, failed to
initialize (not found)
Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] failed to store
changes into journal (not found)
Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] zone event 'load'
failed (not found)
Part of the configuration file:
...
...
template:
- id: "default"
storage: "/var/lib/knot"
zone:
- domain: "domain.cz."
file: "domain.cz"
notify: "slave"
acl: "acl_slave"
semantic-checks: "on"
ixfr-from-differences: "on"
max-journal-size: "1073741824"
dnssec-signing: "on"
kasp-db: "/var/lib/knot/domain.cz.keys"
...
...
Directory "/var/lib/knot/domain.cz.keys" contains zone private and
public keys.
What did I missed ?
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.
