Hello list!
The second release candidate of Knot DNS 1.6.0 by CZ.NIC Labs is here!
The update contains just a few changes, which improve the new persistent slave
zones timers feature.
The database for the zone timers was being opened before the privileges were
dropped and UID/GID changed. As a result, the database could not be reopened
after invoking the "knotc reload" command and updated timers could not be
written into the database. This problem is resolved now. If you are updating
from -rc1, you will need to fix the database ownership to match your knotd
user.
We also increased the maximal size of the database from 10 MB to 100 MB. This
should be enough for thousands of slave zones.
And finally, we improved a logging of errors related to database operations.
If you have a time to try the new release candidate, please, do so. The final
release will probably slip a few days, but it is still scheduled for the next
week.
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.xz
Have a nice weekend!
Best regards,
Jan, CZ.NIC Labs
Hello everyone!
Today, CZ.NIC Labs presents the first release candidate of Knot DNS 1.6.0.
This comes quite soon after the release of the 1.5.3, which took place about a
month ago. For this time, we were really conservative about inclusion of new
features. We want to maintain Knot DNS 1.6.0 as a stable version and we intend
to provide bug fixes for this release for a longer period of time.
The 1.6.0 brings just one new feature - persistent timers for slave zones:
The server stores zone expire, refresh, and flush timers in the file-backed
database. The timers are written whenever they change and are recovered when
the server is started. As a result, the timers will survive a full server
restart.
The persistent timers feature is an optional feature and depends on the LMDB
library. Please, make sure the library is available at the build time and
check the output of the 'configure' script, if you want to use this feature.
We also modified domain names letter-case handling in RDATA. Previously, we
preserved letter case of domain names in RDATA fields. With the 1.6.0, the
domain names are converted to lower-case letters, unless the RR type is "new"
and should be handled case-sensitively for compatibility with old servers. We
believe that this approach is RFC-compliant.
The letter case handling modification allowed us to simplify the DNSSEC
signing code a little bit and also resolved problems with invalid signatures
issued by Knot DNS for some mixed-case RR sets.
All the other changes are various small bug fixes.
Please, give Knot DNS 1.6.0-rc1 a try and report any troubles you encounter.
We are looking forward to your feedback. If everything goes well, we plan to
release the final version at the beginning of the next week.
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.xz
Best regards,
Jan, CZ.NIC Labs
Hey everyone,
I have a production Knot DNS setup; there are two features that I believe would make it even better than what it is now.
* Under the zones section a way to just "push" all master zones to slaves; the slaves should just accept any zone from a verified master in the slaves knot.conf.
* The ability to just load zones from disk without explicitly stating the zone in knot.conf. For example in /var/lib/knot/example.com.zone; Knot DNS automatically loads the example.com.zone without it being identified in the knot.conf under the zone section. Of course it should do checks (like it does now) before loading the zone, and then gracefully fail and log to the logging mechanism.
Other than that; awesome DNS server!
protobuf-c 1.0.0 added a new 'allocator' field to ProtobufCBufferSimple
that controls memory allocation, which must be NULL in order to request
the default system allocator. Allocating ProtobufCBufferSimple objects
on the stack without zeroing the entire object can result in
protobuf-c's memory allocation functions dereferencing a garbage
pointer.
Note that the use of the zero initializer in this instance generates a
warning on some gcc versions:
dnstap.c: In function 'dt_pack':
dnstap.c:26:2: warning: missing braces around initializer [-Wmissing-braces]
ProtobufCBufferSimple sbuf = {0};
^
dnstap.c:26:2: warning: (near initialization for 'sbuf.base') [-Wmissing-braces]
This warning is spurious and was fixed recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=211289
---
src/dnstap/dnstap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dnstap/dnstap.c b/src/dnstap/dnstap.c
index 41d42e7..cf3770c 100644
--- a/src/dnstap/dnstap.c
+++ b/src/dnstap/dnstap.c
@@ -23,7 +23,7 @@
uint8_t* dt_pack(const Dnstap__Dnstap *d, uint8_t **buf, size_t *sz)
{
- ProtobufCBufferSimple sbuf;
+ ProtobufCBufferSimple sbuf = {0};
sbuf.base.append = protobuf_c_buffer_simple_append;
sbuf.len = 0;
--
2.0.0
Good afternoon,
I made a change in our zone, changed serial of the zone and reload
the zone. When I check the syslog, I saw some complains, that the
signatures was out of date. For example:
Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in
node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: A.
Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in
node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: AAAA.
Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in
node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: NSEC.
This happens for all records in the zone.
Last change was 11.8.2014, knot signed it and planned resign to 7.9.2014:
Aug 11 13:39:10 slimak knot[22992]: Semantic checks completed for
zone=fnhk.cz.
Aug 11 13:39:10 slimak knot[22992]: Zone 'fnhk.cz.' reloaded (serial
2014081101)
Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing started...
Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is
valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public
Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is
valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public
Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. -
Successfully signed.
Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next
signing planned on 2014-09-07T11:39:10.
Aug 11 13:39:10 slimak knot[22992]: Loaded 5 out of 5 zones.
Aug 11 13:39:10 slimak knot[22992]: Applied differences of 'fnhk.cz.'
to zonefile.
Aug 11 13:39:10 slimak knot[22992]: Configuration reloaded.
Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to
'195.113.115.171@53': Query issued (serial 2014081102).
Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to
'195.113.123.91@53': Query issued (serial 2014081102).
Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to
'89.248.244.34@53': Query issued (serial 2014081102).
on 7.9.2014 the zone was resigned automatically:
Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing zone...
Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is
valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public
Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is
valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public
Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. -
Successfully signed.
Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to
'195.113.115.171@53': Query issued (serial 2014081103).
Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to
'195.113.123.91@53': Query issued (serial 2014081103).
Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to
'89.248.244.34@53': Query issued (serial 2014081103).
Sep 7 13:39:11 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next
signing planned on 2014-10-04T11:39:10.
Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to
'195.113.115.171@47363': Started (serial 2014081102 -> 2014081103).
Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to
'195.113.115.171@47363': Serial 2014081102 -> 2014081103.
Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to
'195.113.115.171@47363': Finished in 0.01s.
And after today's changes knot told me that the signatures was out of date.
I've this similar version of knot on my own server, there is no problem
Any ideas ?
Thanks and best regards
J.Karliak
--
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 am currently testing knot and I have found a problem when CNAME
are in uppercase.
My primary server is running with BIND.
I have these two declarations :
myserver IN A 10.1.1.1
myserver-alias IN CNAME MYSERVER
On the knot secondary server, after zone transfer, all seems ok :
myserver.mydomain.fr. 900 A 10.1.1.1
myserver-alias.mydomain.fr. 900 CNAME MYSERVER.mydomain.fr.
But when I ask knot for myserver-alias, I have a NXDOMAIN response
(tcpdump output below) :
17:00:29.718834 IP dns-client.38146 > knot-server.domain: 4787+ A?
myserver-alias.mydomain.fr. (43)
17:00:29.719011 IP knot-server.domain > dns-client.38146:
4787 NXDomain*- 1/1/0 CNAME MYSERVER.mydomain.fr. (123)
17:00:29.719555 IP dns-client.54520 > knot-server.domain: 2945+ A?
myserver-alias.mydomain.fr.mydomain.fr. (54)
17:00:29.719637 IP knot-server.domain > dns-client.54520: 2945
NXDomain*- 0/1/0 (111)
Tested with knot 1.5.1 and 1.5.2
Best regards,
--
Didier ALBENQUE
SG/SDSI/BSE
Architecte technique
Le café est un breuvage qui fait dormir,
quand on n'en prend pas. Alphonse Allais
----------------------------------------------------------------------
Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.
Greetings
Regarding the gpg key used to sign http://deb.knot-dns.cz/debian/.
Any chance that that key could be available for downloaded by way of
https://, or perhaps just have its fingerprinted listed on
https://www.knot-dns.cz/pages/download.html?
While the https:// CA model is far from perfect it'd still like to think
it being a step up compared to regular http://, and at the same time a
lot easier to document than the process of following the signatures in a
gpg web of trust.
// Andreas
JFTR I did push the 1.5.2 to wheezy-backports directly
since 1.5.2 contains a remote vulnerability, so it's
available there - see https://tracker.debian.org/knot
Cheers,
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
-------------------------------------------
----- Original Message -----
> From: "Leoš Bitto" <leos.bitto(a)gmail.com>
> To: knot-dns-users(a)lists.nic.cz
> Sent: Tuesday, September 9, 2014 12:06:45 PM
> Subject: Re: [knot-dns-users] problem with debian repository
> On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote:
>> Dne 22.8.2014 09:52, Peter Hudec napsal(a):
>>> Hi,
>>>
>>> this mail is directed for debian repository maintainers.
>>>
>>> The debian repository is not working properly, the Packages(.gz) and
>>> Sources(.gz) files are empty.
>>>
>>
>> I'm observing same problem. However, I've noticed that latest version of
>> Knot is available in official wheezy-backports tree.
>>
>
> http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too.
> However I do not agree with the availability in the official
> wheezy-backports
> (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) -
> the previous version 1.5.1 was not there until the last week, and the
> current version 1.5.2 is not there at all (which might actually be a
> good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294).
>
>
> Leoš Bitto
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
Could you please flush your DNS cache (deb.knot-dns.cz
should point to sophie.nic.cz now) and try again?
The debarchive got broken and I couldn't fix it, so
it has been replaced by reprepro.
In case you can't flush your caches, please just temporarily
change deb.knot-dns.cz to sophie.nic.cz.
Also the repository is now signed:
# wget -O - http://deb.knot-dns.cz/debian/apt.key | apt-key add -
Full instructions can be found here:
http://deb.knot-dns.cz/debian/README.txt
Ondrej
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
-------------------------------------------
----- Original Message -----
> From: "Leoš Bitto" <leos.bitto(a)gmail.com>
> To: knot-dns-users(a)lists.nic.cz
> Sent: Tuesday, September 9, 2014 12:06:45 PM
> Subject: Re: [knot-dns-users] problem with debian repository
> On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote:
>> Dne 22.8.2014 09:52, Peter Hudec napsal(a):
>>> Hi,
>>>
>>> this mail is directed for debian repository maintainers.
>>>
>>> The debian repository is not working properly, the Packages(.gz) and
>>> Sources(.gz) files are empty.
>>>
>>
>> I'm observing same problem. However, I've noticed that latest version of
>> Knot is available in official wheezy-backports tree.
>>
>
> http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too.
> However I do not agree with the availability in the official
> wheezy-backports
> (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) -
> the previous version 1.5.1 was not there until the last week, and the
> current version 1.5.2 is not there at all (which might actually be a
> good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294).
>
>
> Leoš Bitto
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users