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
I just successfully migrated a several zones from NSD to Knot DNS. The
migration was straightforward and quick, but I limiting the number of
addresses per interface and remote server to one doesn't make sense to
me especially with dual stack hosts. This is more intuitive to me in
NSD. What is the rationale behind the current syntax?
Regards,
Matthias-Christian
Hi Everyone,
we're proud to announce, that release candidate for the next major
release 1.2 is out!
Apart from a couple bugfixes, it features full DDNS support (including
update forwarding).
There are a few limitations related to DNSSEC-signed zones, please
refer to user manual for more information.
Access control for dynamic updates could be configured in a similar
fashion to transfers, using the 'update-in' keyword.
Next major thing is an updated remote control tool.
Basic commands for start/stop/restart/compile and checks are the same
as they were,
but the command for refresh/flush/status could be executed remotely
given the right configuration.
You can enable remote control interface with a new config section
'control', f.e.:
control {
listen-on { address 127.0.0.1@5553; }
allow remote0;
}
You can also specify a remote with associated TSIG key for security reasons.
Knot control tool then accepts host, port and TSIG key as a parameter, f.e.:
$ knotc -s 127.0.0.1 -p 5553 status
Key could be also specified in a file instead of a command line parameter.
But that is just a tip of the iceberg. For more smaller features, like
configurable TCP timeouts or LOC support,
refer to RELNOTES and a user documentation.
RELNOTES: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.2-rc1/…
Sources: https://secure.nic.cz/files/knot-dns/knot-1.2-rc1.tar.gz
GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2-rc1.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
