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
I thought I'd enable debugging code to try and figure out why the server
goes into a loop. So I added the following to configure:
--enable-debug=server,zones,xfr,packet,dname,rr,ns,hash,compiler,stash
However, Knot doesn't compile now. The compile fails with:
...
...
libknot/packet/packet.c: In function 'knot_packet_parse_question':
libknot/packet/packet.c:311: error: 'bp' undeclared (first use in this
function)
libknot/packet/packet.c:311: error: (Each undeclared identifier is
reported only once
libknot/packet/packet.c:311: error: for each function it appears in.)
If I remove the packet debug option, I can compile Knot again.
Regards,
Anand
Hello Knot developers,
I configured an instance of Knot 1.2.0rc3 with 5174 slave zones, and
started it. I wanted to see how long it would take to transfer all the
zones in. It has been running for about an hour, and it still hasn't
managed to load all the zones from its master. I'll pick just one zone
as an example to show how long it took:
# grep apnic.net /var/log/knot/knot.log
2013-03-09T00:50:19.361489-00:00 Will attempt to bootstrap zone
apnic.net. from AXFR master in 37s.
2013-03-09T01:06:31.330875-00:00 Will attempt to bootstrap zone
apnic.net. from AXFR master in 35s.
2013-03-09T01:16:19.741644-00:00 Incoming AXFR transfer of 'apnic.net.'
with '193.0.0.198@53' key 'ripencc-20110222.': Started.
2013-03-09T01:16:35.282203-00:00 Will attempt to bootstrap zone
apnic.net. from AXFR master in 52s.
2013-03-09T01:52:16.477212-00:00 Will attempt to bootstrap zone
apnic.net. from AXFR master in 37s.
2013-03-09T01:56:02.806828-00:00 Will attempt to bootstrap zone
apnic.net. from AXFR master in 13s.
2013-03-09T01:57:00.901518-00:00 Incoming AXFR transfer of 'apnic.net.'
with '193.0.0.198@53' key 'ripencc-20110222.': Started.
2013-03-09T01:57:01.096493-00:00 Incoming AXFR transfer of 'apnic.net.'
with '193.0.0.198@53' key 'ripencc-20110222.': Finished.
>From the time Knot decided it needed to bootstrap apnic.net, to the time
it actually transferred the zone in, it took 67 minutes! All that while,
it was responsing with SERVFAIL for the zone.
While the zone "apnic.net" has now been loaded, Knot is still busy
loading many of the other zones. I can't tell how far it is. Perhaps
there could be a command for knotc, called "zonestatus" which would
print out a list of all configured zone, and their statuses.
I understand that transferring in lots of zones takes time. However, if
I start an instance of BIND with the same slave zones, it can transfer
them all in within about 15-20 minutes. Knot appears to be much slower
in comparison.
Do you have any suggestions for speeding things up?
Regards,
Anand
Hello Knot developers,
I'm testing the use of multiple instances of Knot on the same server.
For this simple test, I have two configurations, A.conf and B.conf, as
follows. Note that I'm bind the control interface to two different ports.
A.conf:
...
...
interfaces {
a { address A; }
}
remotes {
ctl { address 127.0.0.1; }
}
control {
listen-on { address 127.0.0.1@5553; }
allow ctl;
}
B.conf:
...
...
interfaces {
b { address B; }
}
remotes {
ctl { address 127.0.0.1; }
}
control {
listen-on { address 127.0.0.1@5554; }
allow ctl;
}
I then start both instances:
knotd -c A.conf
knotd -c B.conf
Now, if I run "knotc -c A.conf reload" then the A instance reloads, as I
expect.
However, if I run "knotc -c B.conf reload", then it is still the A
instance that reloads. The only way I can get the B instance to reload
is to run "knotc -p 5554 reload".
This is not what I expected. I expected that if I give knotc a
configuration file, then it will use the address and port numbers in
there, so that it can signal the correct instance of Knot. In
comparison, the upcoming NSD4 *does* do this. It has an "nsd-control"
command, and if I give it a configuration file as a parameter, then it
uses the control port settings from that file to signal the appropriate
instance of NSD, and not just the default one.
Would you consider getting knotc to also behave the way nsd-control
does? After all, knotc *does* read some configuration from the file, so
ideally it should also read the control section and use the appropriate
address and port numbers from there.
Regards,
Anand Buddhdev
RIPE NCC
Dear Knot developers,
I've been playing with Knot version 1.2.0-rc3, and run into a small
issue. Apologies if it has already been reported.
I'm using a configuration like this:
system {
...
...
user knot.knot;
}
log {
file "/var/log/knot/knot.log" { ... }
}
When I start Knot, it starts running as root, and creates the file
/var/log/knot/knot.log, as root. It then switches to the non-privileged
user "knot". Now it can no longer continue writing to the log file.
Could you please add some code (to go before it changes the UID) to
change the ownership of the log file to the user it is about to switch to?
Regards,
Anand
