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
I've configured Knot 1.2.0-rc3 to log to a file with this:
log {
file "/var/log/knot/knot.log" { any debug, info, notice, warning, error; }
}
However, some log messages are appearing in /var/log/messages via
syslog, for example:
Mar 9 11:51:37 ams3 knot[30177]: [error] Incoming AXFR transfer of
'0.0.0.0.a.2.ip6.arpa.' with '193.0.0.198@53' key 'ripencc-20110222.':
Zone transfer refused by the server.
Looks like some parts of Knot are not honouring the file log option.
Regards,
Anand
Hello Knot developers,
I've added some zones to my Knot configuration like this:
zones {
example.com {
file example.com;
xfr-in master;
notify-in master;
}
}
After Knot has started up, I see the following files in the storage
directory:
example.com
example.com.db
example.com.db.crc
example.com.diff.db
I see that Knot keeps a copy of the zone in a compiled form. Why does it
also dump the plain text zone?
This would be okay for a small number of zones, but if I want to load a
few thousand zones, then all those plain text copies of the zone files
will take up unnecessary space on the disk. I tried to turn off the
plain text copy by removing the "file example.com" config line, but then
Knot created a file called "example.com..zone" (yes, with two dots) to
keep a plain text copy of the zone anyway.
Is it possible to turn off this plain text dump of the zone?
Regards,
Anand
Hi everyone,
I'm happy to announce that the 3rd and hopefully final release
candidate of Knot DNS 1.2.0 is out!
This one not only brings a few bugfixes, but also a new feature.
The hot topic of the day - Response Rate Limiting, based on the work
of Vernon Schryver and Paul Vixie
(http://www.redbarn.org/dns/ratelimits).
If you're not familiar with the topic, it is a way to combat DNS
amplification and reflection attacks.
General idea is to identify flows in outgoing responses and block
responses exceeding the rate limit.
To get at least some degree of service for victims a mechanism called
SLIP is used, causing each Nth blocked response to
be sent as truncated, thus enabling legitimate requests to reconnect over TCP.
You can enable rate limiting by setting option "rate-limit" to a value
greater than 0, for example:
system {
rate-limit 100;
}
For more about rate limiting knobs, refer to the documentation or a
sample configuration.
Any feedback is more than welcome before it lands in the final version!
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-rc3.tar.gz
GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc3.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
