Hello,
one more question:
What is the proper way of autostarting Knot Resolver 1.4.0 on systemd (Debian Stretch in my case) to be able to listen on interfaces other from localhost?
As per the Debian README I've set up the socket override.
# systemctl edit kresd.socket:
[Socket]
ListenStream=<my.lan.ip>:53
ListenDatagram=<my.lan.ip>:53
However after reboot the service doesn't autostart.
# systemctl status kresd.service
kresd.socket - Knot DNS Resolver network listeners
Loaded: loaded (/lib/systemd/system/kresd.socket; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kresd.socket.d
└─override.conf
Active: failed (Result: resources)
Docs: man:kresd(8)
Listen: [::1]:53 (Stream)
[::1]:53 (Datagram)
127.0.0.1:53 (Stream)
127.0.0.1:53 (Datagram)
<my.lan.ip>:53 (Stream)
<my.lan.ip>:53 (Datagram)
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to listen on sockets: Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS Resolver network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered failed state.
To get it running I have to type in manually:
# systemctl start kresd.socket
I apologize, I am now to systemd and its socket activation so it's not clear to me whether service or socket or both have to be somehow set up to autostart or not.
Could anyone clarify this?
Also, this is also in the log (again, Debian default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile '/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by knot, or writeable by others?
Thanks!
--
Regards,
Thomas Van Nuit
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Hello all,
I have come across an incompatibility with /usr/lib/knot/get_kaspdb and knot in relation to IPv6. Knot expects unquoted ip addresses however the kaspdb tool uses the python yams library which requires valid yams and therefore needs IPv6 addresses to be quoted strings as the contain ‘:’. This incompatibility causes issues when updating knot as the ubuntu packages from 'http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu’ call get_kaspdb during installation. The below gist shows how to recreate this issue. Please let me know if you need any further information
https://gist.github.com/b4ldr/bd549b4cf63a7d564299497be3ef868d
Thanks John
Dear Knot Resolver users,
Knot Resolver 1.4.0 has been released!
Incompatible changes
--------------------
- lua: query flag-sets are no longer represented as plain integers.
kres.query.* no longer works, and kr_query_t lost trivial methods
'hasflag' and 'resolved'.
You can instead write code like qry.flags.NO_0X20 = true.
Bugfixes
--------
- fix exiting one of multiple forks (#150)
- cache: change the way of using LMDB transactions. That in particular
fixes some cases of using too much space with multiple kresd forks (#240).
Improvements
------------
- policy.suffix: update the aho-corasick code (#200)
- root hints are now loaded from a zonefile; exposed as hints.root_file().
You can override the path by defining ROOTHINTS during compilation.
- policy.FORWARD: work around resolvers adding unsigned NS records (#248)
- reduce unneeded records previously put into authority in wildcarded answers
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.4.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.4.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.4.0.tar.xz.asc
Documentation:
http://knot-resolver.readthedocs.io/en/v1.4.0/
--Vladimir
Hi,
I'm getting an HTTP 500 error from https://gitlab.labs.nic.cz/ that says
"Whoops, something went wrong on our end". Can someone take a look at it
and fix it?
Thanks!
--
Robert Edmonds
edmonds(a)debian.org
Hi,
we have a DNSSEC enabled zone, for which knot serves RRSIGs with expire
date in the past (expired on Sept 13th) and signed by a no longer active
ZSK. The correct RRSIGs (uptodate and signed with the current ZSK) are
served as well, so the zone still works.
Is there a way to purge these outdated RRSIGs from the database?
Regards
André
Hi,
I maybe missed something. I created kasp direcotry, added knot as a
owner.
In the kasp directory (/var/lib/knot/kasp) runned commands:
keymgr init
keymgr zone add domena.cz policy none
keymgr zone key generate domena.cz algorithm rsasha256 size 2048 ksk
Cannot retrieve policy from KASP (not found).
Did I missed something ?
Thanks and best regards
J.Karliak
--
Bc. Josef Karliak
Správa sítě a elektronické pošty
Fakultní nemocnice Hradec Králové
Odbor výpočetních systémů
Sokolská 581, 500 05 Hradec Králové
Tel.: +420 495 833 931, Mob.: +420 724 235 654
e-mail: josef.karliak(a)fnhk.cz, http://www.fnhk.cz
Hello,
this might be a rather stupid question.
I have a fresh install of Debian Stretch with all updates and Knot Resolver 1.4.0. installed from CZ.NIC repositories. I've set up a rather simple configuration allowing our users to use the resolver and everything works fine (systemd socket override for listening on LAN). I have however noticed that kresd logs every single query into /var/log/syslog, generating approx. 1 MB/min worth of logs on our server. I've looked into documentation and haven't found any directive to control the logging behavior. Is there something I might be missing? I would preferrably like to see only warnings in the log.
Here's my config:
# cat /etc/knot-resolver/kresd.conf
net = { '127.0.0.1', '::1', '<my.lan.ip>' }
user('knot-resolver','knot-resolver')
cache.size = 4 * GB
Thanks for the help.
--
Regards,
Thomas Van Nuit
Sent with [ProtonMail](https://protonmail.com) Secure Email.
I've written aknot module, which is functioning well. I've been asked
to add functionality to it that would inhibit any response from knot,
based upon the client's identity. I know the identity; I just need to
figure out how to inhibit a response.
I just noticed the rrl module, and I looked at what it does. I emulated
what I saw and set pkt->size = 0 and returned KNOTD_STATE_DONE.
When I ran host -a, it returned that no servers could be reached. When
I ran dig ANY, I ultimately got the same response, but dig complained
three times about receiving a message that was too short in length.
I really want NO message to be returned. How do I force this?
Hi Volker,
thank you for your question.
Your suggestion is almost correct, just a little correction:
knotc zone-freeze $ZONE
# wait for possibly still running events (check the logs manually or so...)
knotc zone-flush $ZONE # eventually with '-f' if zone synchronization is
disabled in config
$EDITOR $ZONEFILE # you SHALL increase the SOA serial if any changes
made in zonefile
knotc zone-reload $ZONE
knotc zone-thaw $ZONE
Reload before thaw - because after thaw, some events may start
processing, making the modified zonefile reload problematic.
BR,
Libor
Dne 5.9.2017 v 23:17 Volker Janzen napsal(a):
> Hi,
>
> I've setup knot to handle DNSSEC signing for a couple of zones. I like to update zonefiles on disk with an editor and I want to clarify which steps need to be performed to safely edit the zonefile on disk.
>
> I currently try this:
>
> knotc zone-freeze $ZONE
> knotc zone-flush $ZONE
> $EDITOR $ZONE
> knotc zone-thaw $ZONE
> knotc zone-reload $ZONE
>
> As far as I can see knot increases the serial on reload and slaves will be notified.
>
> Is this the correct command sequence?
>
>
> Regards
> Volker
>
>
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
