[sorry for cross-post, please don't cross-post when replying]
Hi,
we are currently implementing DNSSEC in Knot DNS and we would like to gather opinions on this topic. I think we have all have more experience of DNSSEC deployment now and it would be very valuable for us to gather that experience and forge an implementation that would be liked by the users.
Could you please spare a few minutes and fill a little survey of ours on this topic?
https://docs.google.com/forms/d/1gS-Z1NAL78oFOU51HR6jmg-ZkAevU2CrvCHQgrNnXL…
If you don't want to give your answers to NSA :), you can reply to this email (the Reply-To is set to knot-dns-users(a)lists.nic.cz), or just send the feedback back to me.
Thank you very much,
Ondrej
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
Dear knot users/developers,
I'm testing Knot 1.3.0-rc2. One issue I've run into is when knot exits
uncleanly. In this case, it leaves its PID file behind in
/var/lib/knot/knot.pid.
On the following attempt to start knot, it sees the PID file, and
refuses to start, so I have to remove the stale PID file by hand. If I
run knot under a supervisor, such as upstart, then it tries to run knot,
fails, tries again rapidly in succession, and eventually gives up, at
which point knot isn't running.
My first observation is that in cases where knot is running under a
supervisor, the PID file is not necessary. The supervisor knows knot's
PID, and can signal it directly (to reload, or stop). Could you consider
making the PID file optional? As in, if in knot.conf, I have:
pidfile "";
then knot should not attempt to write (or read or delete) a PID file at all.
Alternatively, could you make knot a bit smarter so that if it detects a
PID file at startup, but that PID is either not in use, or the process
using it is not knot, then it should remove the PID file?
Without either of these possibilities, I have to add logic in my startup
scripts or supervisor scripts to remove any stale PID files. If I only
had one instance of knot, I could do that simply with "rm -f
/var/lib/knot/knot.pid", but I'd like to run multiple instances of knot,
and so I would have multiple PID files, whose locations I would have to
extract from the config file first in order to delete them reliably.
This starts to get hairy...
I hope I have made a reasonable case for providing an option to not
record a PID file, or clean up one before starting. My preference is for
the first option, ie. not writing a PID file.
Regards,
Anand Buddhdev
RIPE NCC
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.
--------------------------------------------------------------------------
