Hello,
are there any plans to publish latest builds (2.0.1) for jessie? The most
current package I can find is knot_2.0.0-1+0~bpo80+1_amd64.deb.
Regards,
PJ
Hello list.
Today, CZ.NIC Labs releases Knot DNS 1.6.5. This patch release contains quite
a lot of non-critical bug fixes and some minor improvements. Everyone is
advised to upgrade.
Let's go through the fixed bugs quickly:
- The server no longer loads expired zones on 'knotc reload' and server
startup.
- We have fixed a rare race-condition in the event scheduling code. The race
caused that events for some zones were significantly delayed. (We were
reported that the server is occasionally ignoring notify messages for random
zones when the server is receiving many notifies. We believe this bug
was the cause and the problem should no longer appear.)
- There was a bug in the NSEC proofs construction. When the zone contained
many delegations, the NSEC proving non-existence of a covering wildcard was
incorrect. The problem is fixed now.
- The TC flag was not set correctly for RRL slipped answers. This problem
is resolved as well.
- We have disabled domain name compression for the root label '.' because it
caused negative compression and some client implementations (like Go DNS)
might have problem decoding these answers.
- The server is now checking whether it is executed in the systemd enviroment
before using journald as a sink for log messages. Also the systemd library
detection at a build time was improved.
- We have also eliminated compilation warnings in endian-conversion functions
on OpenBSD.
And as for the new features:
- The persistent timers are now written to the on-disk database only on server
shutdown. This change was done mainly to improve startup and reload
performance.
- The 'max-conn-idle', 'max-conn-handshake', 'max-conn-reply', and
'notify-timeout' config options now accept time units specification
(e.g., one can use 2m instead of 120).
- We have added 'request-edns-option' config option, which allows inserting
custom EDNS0 options into all queries initiated by the server.
And that's all folks. I would like to thank everyone involved in making this
release, especially bug reporters. We are looking forward to your feedback.
The sources are available as usual.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/1.6/NEWS
Source archives:
https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.gz.asc
Best Regards,
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
Hi,
I'm running Knot 2.0.0 and automatically signing my zone with manual key
management policy. When I manually refreshed the signatures by running
"knotc signzone <zone>", all the signatures were refreshed as expected,
except the DNSKEY RRset, whose signature remained untouched. I thought
this wouldn't be a big deal, as Knot would probably automatically
refresh DNSKEY RRset signature when about 1/10 of its lifetime will be
remaining.
However, when I now look at "knotc zonestatus", it shows that the next
resigning is scheduled far beyond the exipration of the DNSKEY RRset
signature. So, is my DNSKEY RRset signature going to be expired or is
DNSKEY handled in some special way so that it will be eventually
refreshed before expiring?
My current DNSKEY RRSIG will expire at 20150828172101:
nxdomain.fi. 600 IN RRSIG DNSKEY 8 2 600 20150828172101 20150729172101
61894 nxdomain.fi. qQJm.....
But the next resigning is scheduled on 2015-09-14:
nxdomain.fi. type=master | serial=2015081708 | DNSSEC resign in
647h56m43s | automatic DNSSEC, resigning at: 2015-09-14T02:26:59
Thanks,
Antti
Hi,
My system is debian 6.0 (yes I know it's out of date).
When I installed knot from source following the document, I got failed
as below. How can I get continued? thanks.
$ autoreconf -i -f
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:35: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:93: error: possibly undefined macro: AS_IF
configure.ac:102: error: possibly undefined macro: AC_MSG_WARN
configure.ac:122: error: possibly undefined macro: AC_DEFINE
configure.ac:163: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:251: error: possibly undefined macro: AC_SEARCH_LIBS
autoreconf: /usr/bin/autoconf failed with exit status: 1
Network renumbering requires that A and AAAA RRs are directly or
indirectly (DHCP) updated. This in turn requires dynamic DNS updates
(RFC 2136).
Although Knot DNS allows dynamic updates, it is not really prepared to
securely handle this scenario. Knot DNS can either allow an address or
key to update RRs in a zone via ACLs which is not fine-grained enough to
useful for this purpose because it is questionable from a security
perspective (under a certain threat model etc.). Assume that example.com
uses dynamic DNS updates to update A and AAAA RRs to be prepared to
renumber its network. If example.com uses a DHCP server to update the
RRs, it suffices to take over the DHCP server of example.com to update
any RRs in the zone of example.com, including NS, MX, TLSA and SSHFP
RRs. If every host of example.com updates its own A and AAAA RRs
directly and indirectly via a DHCP server, the problem is still the
same, even if you move every hostname in a separate zone, for example it
suffices to take over the webserver that serves example.com to change
the MX RRs of example.com. With more fine-grained ACLs the problem would
not exist.
Currently ACLs consist of a subject (address and key), operation
(transfer, notify, update, control) and object (zone). I think it would
suffice to extend the object of an ACL to a triple (zone, name, type)
similar to dynamic update policies in BIND. Perhaps it would also be
useful to be able to use wildcards and negation. Are there any plans to
extend the ACL mechanism in this way?
Regards,
Matthias-Christian
Hi
Is keymgr broken or what am I doing wrong?
/knot# mkdir kasp
/knot# cd kasp
/knot/kasp# keymgr init
/knot/kasp# keymgr zone add example.com policy none
/knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 2048 ksk
id 36b49807bcdf448c5034cf37688b99616760529c keytag 24400
knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 1024
Cannot retrieve zone from KASP (malformed config value).
Regards,
shadice
Hello
I've built knot 2.0.0 and created a rpm for redhat 7 and have a problem
with the knot.service systemd file.
I've used the rpm SPECS and knot.conf, knot.service file from the src
rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=670057 and
adapted the SPECS file slightly to get it working on redhat 7.
The knot.service file has the following Service section:
[Service]
Type=notify
ExecStart=/usr/sbin/knotd
ExecReload=/usr/sbin/knotc reload
Restart=on-abort
ExecStartPre=/usr/sbin/knotc checkconf
If I use the type "notify" and start the service (systemctl start knot)
the command does not complete but stays in the foreground. After a few
seconds, minutes systemd gets a timeout and terminates the service:
systemd: knot.service operation timed out. Terminating.
knot[32446]: info: stopping server
knot[32446]: info: shutting down
systemd: Failed to start Knot DNS server daemon.
systemd: Unit knot.service entered failed state.
I now changed the knot.service file to use type "simple" [1] and that
works and resolves the problem. However, I believe to have read that
type "notify" should work. Is this a bug?
Daniel
[1] http://www.freedesktop.org/software/systemd/man/systemd.service.html
Hi
I have problems in v2.0.0 with the serial-policy definition as it is not working as expected.
Here is my knot.conf which I am using:
# knot.conf
server:
user: knot:knot
udp-workers: 1
tcp-workers: 1
background-workers: 1
listen: 0.0.0.0@53
listen: ::@53
log:
- target: syslog
any: debug
template:
- id: default
storage: /opt/knot
semantic-checks: on
dnssec-signing: on
kasp-db: kasp
serial-policy: increment
zone:
- domain: example.com
dnssec-signing: off
2015-08-11T18:27:33 info: configuration is valid
Using increment as serial-policy, first the serial gets incremented by 1. After that, it will stay at 1, nevertheless how many changes I make.
info: [example.com] loaded, serial 0 -> 1
info: [example.com] loaded, serial 1 -> 1
info: [example.com] loaded, serial 1 -> 1
info: [example.com] loaded, serial 1 -> 1
Using unixtime as serial-policy, the serial stays always at 0.
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
Am I doing it wrong?
Do you use in anyway a RTC? because I do not have it.
Regards
shadice
Has anyone used the rosedb or dnsproxy modules extensively in production?
I'm concerned about whether it would reliably scale as well as Knot does
without it. I'm evaluating knot in hopes that I can use it to offer part of
my would-be service to potentially millions of websites. I'm planning a
free usage tier would would hopefully be heavily utilized.
Regarding the specific implementation, I want to provide an authoritative
DNS server that returns predefined values based on record types/host
(rosedb). If the host/record combo conditions aren't met, proxy the request
to the original nameserver(s). After reviewing the nightly code it looks
like I'll likely need to invest a lot of time in order to support that
chained query plan.
Thank you for any feedback in advance.
-Anonymous Coward
Hi
Knot DNS v2.0.0 reserves up to 620 MB memory on my Raspberry Pi.
But it actually uses only 0.4 % of the available 512 MB memory.
How can I limit the memory reservation/allocation to 100 MB?
Regards
shadice
