Dear Knot developers,
I'm testing Knot 1.3.0-rc1 now. One of the things I'd like to be able to
do is to estimate Knot's memory usage without actually loading all my
zones into it (because if it runs out of memory it will be killed).
One very crude way was to load a single zone from a plain text zone
file, and comparing the memory used by knot with the size of the zone on
disk. For a zone of size 229MB, knot is using about 1.3GB of RAM. So I
could say that knot wants about 6x as much RAM for each zone. Is this a
reasonable asumption?
Alternatively, since you know how knot uses memory for a zone, are you
able to provide a small program which can read zones one at a time,
calculate the RAM required for each zone, and then print a summary of
the total RAM required to load all those zones into knot?
We frequently get questions from our users along the lines of "I'd like
you to slave this new zone" or "we are going to sign this zone; will
your server be able to load it?" It would help an operator immensely if
he can get an estimate of the additional RAM required.
Regards,
Anand Buddhdev
RIPE NCC
Our BIND server slaves a zone which has the following record (I have
replaced the actual TLD with placeholders):
*.XX. 60 IN CNAME SERVER.SLD.XX.
BIND loads this zone without complaining.
However, knot 1.3.0-rc1 refuses to load this zone with the following error:
2013-06-07T13:53:50 [warning] Semantic warning in node: *.XX.: CNAME:
CNAME cycle!
2013-06-07T13:53:50 [error] Semantic check found fatal error on line=10
2013-06-07T13:53:54 [error] Zone could not be loaded
(-9992).2013-06-07T13:53:54 [error] Zone XX. could not be loaded.
As a side note, it looks like there's a newline missing somewhere,
because two log lines have appeared on a single line. And what's the
-9992 in brackets?
Regards,
Anand
Testing knot 1.3.0-rc1, I'm seeing a strange message in the log if I
start it without defining any zones:
2013-06-07T10:44:13 Binding to interface 127.0.0.1 port 5353.
2013-06-07T10:44:13 Configured 1 interfaces and 0 zones.
2013-06-07T10:44:13
2013-06-07T10:44:13 Changing group id to '10073'.
2013-06-07T10:44:13 Changing user id to '10073'.
2013-06-07T10:44:13 Loading 0 zones...
2013-06-07T10:44:13 Loaded -12 out of 0 zones.
2013-06-07T10:44:13 [warning] Not all the zones were loaded.
2013-06-07T10:44:13 Starting server...
2013-06-07T10:44:13 Server started in foreground, PID = 10514
2013-06-07T10:44:13 PID stored in /var/lib/knot/knot.pid
2013-06-07T10:44:13 [warning] Server started, but no zones served.
Notice the "-12 out of 0 zones.". Bug?
Anand
Hi everyone,
we've been very busy for the last couple months, and I'm glad to let you
know,
that the Knot DNS v1.3.0 first release candidate is finally out!
This is a feature-full release, packing a lot of new stuff and improvements.
The major change since 1.2.0 is the zone compilation, which is now
deprecated and
zone files are parsed directly on startup. This was made possible with the
new zone file parser,
which is neck to neck in terms of speed with whole parsing to loading a
precompiled zone.
So no more 'compile' steps.
Configuration file is also improved with the handy 'group' keyword, that
allows you to
make groups of remotes and also a support to include another part of config
file.
This is useful for example if you want to store keys elsewhere.
We also now support queries to pseudo CH zone (RFC4892 style), so that is
configurable
as well (we support identity, version and hostname).
On the backend part, we have overhauled several internal structures to
lower memory
consumption and improved speed and scheduling of zone transfers. Log
messages for
those are improved as well, giving a more verbose overview of what was
transferred,
which serial and how long. Apart from that, there are a lot of smaller
performance
improvements, revamped build system and a lot of small details.
For example zone files written out on slave contain a source address, time
and other
useful information. See NEWS or gitlog for more details.
Last new (sort of) feature is, that we included our own DNS tools.
Namely kdig, khost and knsupdate. They are quite compatible with BIND9
tools,
but they also bring several improvements in logging, prettified output and
checks.
Be sure to check them out.
We also had a terrific user feedback, thanks to Erwin Lansing, Anand
Buddhdev, Jan-Piet Mens
and everyone for the reports.
So that's mostly it! For a full overview of changes see:
https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.bz2https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.bz2.aschttps://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.xz.asc
Packages available at www.knot-dns.cz will be updated soon as well.
Kind regards,
Marek
--
Marek Vavruša Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
Hey guys,
i am currently playing around with some dns solutions, currently its knot :-)
Is there any solution for recursion. I would like to add an powerdns server to any node which could do lookups for new zones while the configfile isnt written. As you may know registrys like denic are using realtime checks while ordering a domain.
Regards
Joerg
Thanks for the 1.2.0, some really nice features in there. I especially like the zonestatus command.
I have one problem though. It seems that knot drops its root privileges too early, before trying to bind to the interface.
Configured with:
system { user bind.bind };
Results in:
Apr 23 12:26:26 l knot[25585]: [error] Could not bind to UDP interface 127.0.0.1 port 53.
Apr 23 12:26:26 l knot[25585]: [error] Could not bind to UDP interface ::1 port 53.
Changing to root.bind, makes it work, hence my guess it's related to dropping privileges. This is on FreeBSD 9.0.
Any hints appreciated.
Best,
Erwin
--
Med venlig hilsen/Best Regards
Erwin Lansing
Network and System Administrator
DK Hostmaster A/S
Kalvebod Brygge 45, 3. sal
1560 København V
Tlf. 33 64 60 60
Fax.: 33 64 60 66
Email: erwin(a)dk-hostmaster.dk
Homepage: http://www.dk-hostmaster.dk
.dk Danmarks plads på Internettet
-------------------------------------------------------------------------
Dette er en e-mail fra DK Hostmaster A/S. Denne e-mail kan indeholde
fortrolig information, som kun er til brug for den tiltænkte modtager.
Hvis du ved en fejl har modtaget denne e-mail, bedes du venligst straks
give afsenderen besked om dette og slette e-mailen fra dit system uden
at offentliggøre, videresende eller tage kopi af meddelelsen.
This is an email from DK Hostmaster A/S. This message may contain
confidential information and is intended solely for the use of the
intended addressee. If you are not the intended addressee please notify
the sender immediately and delete this e-mail from your system. You are
not permitted to disclose, distribute or copy the information in this
e-mail.
--------------------------------------------------------------------------
Hi,
We're using the latest version 1.2.0 after updating from 1.1.0. It seems
that when we run a dnsperf against it, we now get many query timeouts. It
isn't that we're overloading the server, because we can run a 2nd server
with dnsperf and get similar throughput (22k qps) but it too has query
timeouts of about just under 1%.
This seemed like maybe it was the response rate limiting, but it says it is
off by default. To be sure, I set the parameter in the config to be off.
Am I missing something? Is there something else I need to turn off?
Thanks for any guidance anyone can provide!
Jonathan
Hello everyone,
we're happy to announce that the Knot DNS 1.2.0 final is out after the
fourth release candidate.
Just to reiterate what's new and fixed in the 1.2.0, we brought 3 new
features in the 1.2.0.
First is a support for dynamic updates (DDNS) including forwarding to the
primary master,
which received a couple of bugfixes in the early release candidates.
Since the third release candidate there is a Response Rate Limiting as a
new way to combat increasing amplification/reflection attacks.
It's been slightly reworked since the release candidate and disabled by
default. You can enable it by setting 'rate-limit' config option to a
sensible value.
Last feature is a reworked control utility which is now able to control the
daemon remotely and even introduced a few new commands, namely 'zonestatus'
to
fetch the status of served zones. Aside from the new features, it also
fixes a few bugs. Namely missing RRSIGs in the response to the ANY type,
processing of some malicious domain names and a detection of broken
implementation of recvmmsg() on some Linux distributions.
As usual, you can find a full list of changes at
https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0/e…
Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0.tar.gz
GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0.tar.gz.asc
Packages available at www.knot-dns.cz will be updated soon as well.
Cheers,
Marek
--
Marek Vavruša Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
