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
Hi everyone,
as an outcome of the discussions on the RRL mailing lists and a
stellar feedback in recent weeks,
we have decided to slip yet another release candidate before the 1.2.0
finally goes out.
The release candidate features a reworked classification in RRL in
respect to the RRL technical memo
and also includes code to resolve hash collisions in the former implementation.
Also a new 'zonestatus' command was introduced to knotc and a several
bugs were fixed, namely logfile ownership problems, faster rate of SOA
queries on refresh and
knotc respecting 'control' section in configuration.
As usual, you can find a full list of changes at
https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0-r…
Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc4.tar.gz
GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc4.tar.gz.asc
Packages available at www.knot-dns.cz will be updated soon as well.
Have a nice weekend,
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
On a server with 16 GB of RAM, my instance of BIND can load my 5174
zones into memory and use around 13 GB.
Knot didn't do so well. At some point while trying to XFR-in these
zones, it hit the memory limit and the Linux out-of-memory killer came
along and killed it.
When I started it up again, it began loading zones in from the disk, but
then appeared to go into some kind of loop, and the CPU usage was 100%.
This is usually a sign that it is stuck in some kind of loop or
deadlock. The only want to stop it is with a KILL signal (TERM doesn't
work). The log didn't output anything.
How can I help debug this?
Do you have any numbers on how much RAM Knot will require given a bunch
of zones? This would allow me to estimate how much RAM I will need in a
server for the zones I have.
Regards,
Anand
Hello,
Is there any existing functionality to log queries? I've enabled all
existing logging for the "answer" category and do not see any. But maybe it
is unsupported in version 1.1.0?
log { syslog { answering all; } }
Thanks,
Jonathan
Hello,
I'd like to mention a few nits about Knot's documentation, if you don't
mind. :)
1. Docs linked to from https://www.knot-dns.cz/documentation.html have
URLs which don't look permanent; this makes it difficult to link to
individual pages. It would be better imo, to have permanent URIs.
2. The usage message for [knotc flush] says "Flush journal and update
zone files.". I understand this to mean zones that have received
updates (RFC2136) will be written out, but this doesn't occur. I note
zones are written out only at the end of a `zonefile-sync' period.
3. ixfr-from-differences, while documented in the manual, points to
'Controlling running daemon', but it doesn't say there, that the
syntax is 'on/off'.
Enabling this in zones {} doesn't seem to do anything here: I was
expecting to see a "*.ixfr" or some such file containing diffs, but I
get none; neither for incoming xfr, nor for DNS updates.
4. Docs specify in 'Controlling running daemon' there is a knotc option
-a, but the code doesn't have that: knotc: invalid option -- 'a'
Same for 'Running Knot DNS' chapter.
Regards,
-JP
Hello,
Yesterday I had Knot 1.1.0 installed and with 4000 test zones on a slave
server configuration, a knotc refresh would hit my master to check SOA on
all zones very quickly (I would see over 600 queries per second). It could
generally complete the task in well under 60 seconds.
Today I have upgraded to 1.2.0-RC3 and with the same 4000 test zones on a
slave server configuration a knotc refresh is extremely slow. It issues SOA
queries to the master at about 10 queries per second.
Why this change? Is there any setting I can implement to speed this up? In a
production environment with 250k+ zones, this obviously won't work.
Thanks!
Jonathan
Hello,
I'm pretty sure I have tomatoes (or other vegetables) on my eyes, but
Knot won't answer UDP queries here, running on Centos 6.3 in an OpenVZ
container. This is the minimal configuration and the results I'm seeing:
$ knotc -V
Knot DNS, version 1.2.0-rc3
$ cat knot.sample.conf
system {
identity "knot 1.2-rc2";
storage "/etc/knot";
}
interfaces {
my-iface { address 127.0.0.1@53; }
}
zones {
example.com {
file "example.com.zone";
}
}
log {
syslog { any info, debug, notice, warning, error; }
}
$ knotc -c knot.sample.conf start
2013-03-11T18:07:44.244202+01:00 Starting server...
2013-03-11T18:07:44.244337+01:00 Zone 'example.com.' is up-to-date.
$ netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 11408/knotd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 486/sshd
tcp 0 0 172.16.153.104:22 172.16.153.1:64881 ESTABLISHED 554/sshd
tcp 0 0 :::22 :::* LISTEN 486/sshd
udp 0 0 127.0.0.1:53 0.0.0.0:* 11408/knotd
unix 2 [ ] DGRAM 8840414 11408/knotd
$ dig @127.0.0.1 example.com any
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> @127.0.0.1 example.com a
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig +tcp @127.0.0.1 example.com a
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> +tcp @127.0.0.1 example.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20248
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;example.com. IN A
;; AUTHORITY SECTION:
example.com. 60 IN SOA localhost. root.localhost. 1997022700 28800 14400 3600000 86400
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Mar 11 18:08:32 2013
;; MSG SIZE rcvd: 79
Mar 11 18:07:44 knot knot[11408]: Binding to interface 127.0.0.1 port 53.
Mar 11 18:07:44 knot knot[11408]: Configured 1 interfaces and 1 zones.
Mar 11 18:07:44 knot knot[11408]:
Mar 11 18:07:44 knot knot[11408]: Loading 1 compiled zones...
Mar 11 18:07:44 knot knot[11408]: Loaded zone 'example.com.' serial 1997022700
Mar 11 18:07:44 knot knot[11408]: Loaded 1 out of 1 zones.
Mar 11 18:07:44 knot knot[11408]: Starting server...
Mar 11 18:07:44 knot knot[11408]: Server started as a daemon, PID = 11408
Mar 11 18:07:44 knot knot[11408]: PID stored in /etc/knot/knot.pid
Can you please help me open my eyes?
Thanks,
-JP
