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
