Hi,
the majority of warning messages does not contain particular domain name
(zone name), so it is impossible to figure which zone file is wrong.
For example:
> 2014-01-23T20:13:07 [warning] encountered identical extra SOA record
> 2014-01-23T20:13:07 [warning] encountered identical extra SOA record
> 2014-01-23T20:13:07 [warning] TTL does not match TTL of its
> RRSet.Changing to 19200
Can you please add zone names into all error and warning messages
related to one zone?
Thanks
Petr Šťastný
Hello,
I want to use Knot for master zones only without any DNS updates, so
journal files are not needed. But they are created for every zone and it
seems impossible to disable them.
But this is bad in my situation when I want to serve 200000+ zones,
because it creates 200000+ journal files in one directory (but they are
never used).
Should be possible to disable journal files or create them only in case
of need or at lease divide them into more subdirectories?
It would be also nice to be able to choose another directory for journal
files in configuration. "storage" option is for both (zone files and
journal files). Or explicitly state journal file path and filename in
"zone" section.
Thanks
Petr Šťastný
Hoj vespolek.
trosku jsem se uz ztratil s dnssecem s knotem. Vygeneroval jsem si
klice, rekl knotu, kde ma klice hledat, knot je podepsal, zadna
stiznost od nej. Klic jsem zadal i do keysetu na web4u, to proslo
taky. Ale pokud si udelam drill my zony, drill oznami, ze mi chybi DS
zaznam nebo trusted key:
drill -TD ajetaci.cz
Warning: No trusted keys were given. Will not be able to verify authenticity!
;; Domain: .
;; Signature ok but no chain to a trusted key or ds record
[S] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: . 172800 IN DNSKEY 256 3 8
AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX195Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6WybBZ6kuqED ;{id = 33655 (zsk), size =
1024b}
[S] cz. 86400 IN DS 54576 10 2
397e50c85ede9cde33f363a9e66fd1b216d788f8dd438a57a423a386869c8f06
;; Domain: cz.
;; Signature ok but no chain to a trusted key or ds record
[S] cz. 18000 IN DNSKEY 256 3 10 ;{id = 40877 (zsk), size = 1024b}
cz. 18000 IN DNSKEY 257 3 10 ;{id = 54576 (ksk), size = 2048b}
cz. 18000 IN DNSKEY 256 3 10 ;{id = 54602 (zsk), size = 1024b}
[S] Existence denied: ajetaci.cz. DS
;; No ds record for delegation
;; Domain: ajetaci.cz.
;; Signature ok but no chain to a trusted key or ds record
[S] ajetaci.cz. 3600 IN DNSKEY 257 3 5 ;{id = 36256 (ksk), size = 2048b}
ajetaci.cz. 3600 IN DNSKEY 256 3 5 ;{id = 11937 (zsk), size = 1024b}
[S] ajetaci.cz. 3600 IN A 77.48.63.10
;;[S] self sig OK; [B] bogus; [T] trusted
--
Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a
DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu,
zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji.
My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP)
policy and check. If you've problem with sending emails to me, start
using email origin methods mentioned above. Thank you.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hi,
I think there is something wrong with logging categories.
Documentation says:
> server - Messages related to general operation of the server.
> zone - Messages related to zones, zone parsing and loading.
I use Knot 1.4.1 with the following configuration:
> log {
> file "/var/log/knot/knot-server.log" {
> server error, warning, notice, info;
> }
>
> file "/var/log/knot/knot-zone.log" {
> zone error, warning, notice, info;
> }
>
> stderr {
> any error, warning;
> }
> }
Everything is logged only into knot-server.log and knot-zone.log is
always empty.
knot-server.log file contains:
> 2014-01-20T21:45:12 Knot DNS 1.4.1 starting.
> 2014-01-20T21:45:12 Rate limiting set to 20 responses/sec.
> 2014-01-20T21:45:12 Binding to interface 0.0.0.0 port 53.
> 2014-01-20T21:45:12 Binding to interface :: port 53.
> 2014-01-20T21:45:12 Configured 2 interfaces and 1 zones.
> 2014-01-20T21:45:12 Changing group id to '1001'.
> 2014-01-20T21:45:12 Changing user id to '1001'.
> 2014-01-20T21:45:12 Server started as a daemon, PID = 25371
> 2014-01-20T21:45:12 PID stored in
> '/usr/local/knot/1.4.1/var/run/knot/knot.pid'
> 2014-01-20T21:45:12 Server changed directory to /.
> 2014-01-20T21:45:12 Zone 'xxxx.eu.' loaded (serial 2013042301)
> 2014-01-20T21:45:12 Loaded 1 out of 1 zones.
> 2014-01-20T21:45:12 Starting server...
> 2014-01-20T21:45:12 Binding remote control interface to
> /usr/local/knot/1.4.1/var/run/knot/knot.sock
> 2014-01-20T21:45:25 Reloading configuration...
> 2014-01-20T21:45:25 Zone 'xxx.eu.' is up-to-date (serial 2013042301)
> 2014-01-20T21:45:25 Loaded 1 out of 1 zones.
> 2014-01-20T21:45:25 Configuration reloaded.
And the question is: why are messages related to zone loading logged in
"server" category and not in "zone" category (which is said in
documentation)?
Thanks
Petr Šťastný
Hi Anand,
Never mind. I understand your situation.
Initially, we had just timestamps in zone dumps. I prefer this, since
it makes smaller dumps and it is faster to process such records.
Afterwards,
we turned it off due to incompatibility with Bind. Because Bind is
unable
to load these dumps if you need it.
Is there still anybody who requires human-readable timestamps in zone
dumps from Knot?
If not, we probably disable this functionality.
Thanks,
Dan
On 2014-01-10 23:08, Anand Buddhdev wrote:
> On 10/01/2014 19:42, daniel.salzman(a)nic.cz wrote:
>
>> We have probably found the problem. The function gmtime, which we use,
>> is not thread safe. So I have replaced it with a better one. Please,
>> try the attached patch.
>
> Hi Daniel,
>
> Thanks for this. However, I prefer not to test this on our current Knot
> servers, as they are running in production. I have applied Marek's
> earlier patch which disabled human-readable timestamps, and that's
> keeping this problem away.
>
> Actually, I even asked Marek why you convert the timestamps to
> human-readable in the zone dumps. After all, the zone files are only
> going to be read back in by Knot, so you'd save some cycles when
> writing
> and reading the zones, by not converting them back and forth between
> human-readable and unix timestamp.
>
> Is it reasonable to ask that you just dispense with human-readable
> timestamps?
>
> Regards,
>
> Anand
Hi Everyone,
about a week ago, CZ.NIC Labs released the 1.4.0 and received some
positive responses, but also discovered a few issues here and there.
I'll try to summarize the important bits.
Since the 1.4.1, OpenSSL >= 1.0.0 is required on configure as we ran
into several issues with the older versions. If that means a problem
for you, please let us know, we can always try to work something out.
That also fixes compile failures on some platforms with OpenSSL <
1.0.0
Moreover, we've ran into a race condition when generating timestamps
in the zone file. This affects both 1.3 & 1.4 users, so if you run
Knot on slave with secured zones and experience a refusal to load a
zone after reload, I advise you to rebootstrap the zones from the
master.
As for the other issues, we've fixed an empty APL record support and
immediate zone file syncing if you use that (it didn't flush the zone
correctly after resign and 'knot zonestatus' didn't handle this
properly). All that plus more code coverage bugfixes and papercuts.
Yet again, many thanks to our dear users for the bug reports, hints
and nudges in the right direction.
Last thing, as you can see, we've dropped the bz2 source packages. I
hope that doesn't affect anyone, two should be more than enough.
Here's a full change log:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.xz.asc
Kind Regards,
Marek, CZ.NIC Labs
--
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
Hello Knot users,
We discovered today that When Knot 1.4.0 dumps zones to disk, it
sometimes writes out the dates in RRSIG expiry and inception fields like
this:
20140230203521
Yes, that's apparently 30 February! If you later restart Knot, or reload
it, it will refuse to load this zone, and begin returning REFUSED
responses for it.
I spoke with the good folk at CZNIC, and Marek quickly provided me with
a patch, attached here. It turns off pretty-printing of the dates, so
that the expiry and inception dates are written in unix time. This fixes
the problem for us, so if you're running Knot in production, you may
want to apply this patch too.
We don't yet know where this bug is, but needless to say Marek and his
colleagues are investigating, and I'm sure a proper fix for it will
appear in due course.
Regards,
Anand Buddhdev
RIPE NCC
Hi Everyone,
I hope you had a terrific Christmas. Now, I know it's all work, but
after some time spent in the release candidate, CZ.NIC Labs are proud
to release Knot DNS 1.4.0 final version.
There have been a several bugfixes, odds and ends since the last
release candidate.
Namely NSEC3/transfer related bugs and case sensitivity of QNAME,
there's a link for an exhaustive list of changes below. But allow me
to reiterate what's new since the 1.3 version. Shall we?
Since the first beta, we have brought a new major feature on the
table. A technology preview of an automatic DNSSEC signing. Now, since
it's not a final product, there are still a few shortcomings; mainly
key management and auxiliary tools missing. However, that shouldn't
stop you from giving it a try! We've written a short "how to" on our
wiki page here:
https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-quickstart
But it's really as simple and creating signing keys and setting
"dnssec-enable on;"
There are few more enhancements like IDN in the utilities, zone serial policies
and fancier zone file printout. Plus a lot of changes under the bonnet. Say
for example the memory consumption, which is significantly lower (~35%
for our large zones). We've also doubled our (continuous) efforts in
producing both
unit and operational test cases, not to mention Knot DNS being kindly
accepted in the Coverity Scan program for open source software.
We've also spent some time on other related projects. Say the
comparison of the authoritative name servers, that you can find here:
https://www.knot-dns.cz/pages/benchmark.html
The whole effort is open source, you can try it yourself or even
create new test cases, any feedback is welcome.
https://gitlab.labs.nic.cz/labs/dns-benchmarking
With all that, the work is far from finished. We're going to further
polish the Knot DNS 1.4 features and prepare a new version at the same
time. By the way, we have a few surprises for you in that department
as well. Last but not least, we and the whole CZ.NIC Labs would like
to thank you, our users and supporters, who poured a lot of time into
helping us shape the Knot DNS the way it is. It's truly appreciated.
Here's a full change log:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.0/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.bz2https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.bz2.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.xz.asc
Kind Regards,
Marek, CZ.NIC Labs
--
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
Hello Knot devs,
The Knot zones directive allows some options at the top-level (such as
"storage", "disable-any", etc). However, the following options can only
be specified per zone:
xfr-in
xfr-out
notify-in
notify-out
update-in
Could you make it so that these options can also be specified at the top
level so that all zones specified after can inherit the same options.
This is useful when I have the same master or set of masters for a whole
bunch of zones, and I don't need to specify them each time for each zone
separately.
Regards,
Anand