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
I have following issue with Knot: when I try to stop it by command
/etc/init.d/knot stop then the daemon is still running. If i run command
knotc stop then it's stopped but immediately run again. If I kill it by
command kill, it's the same...
As I found the /etc/init.d/knot is not working at all and Knot is
probably run during boot by /etc/init/knot.conf and I'm not able to
control it. The "unkillable" proccess is named /usr/sbin/knotd -c
/etc/knot/knot.conf
My environment: Debian 7 AMD64, OpenVZ container, kernel
2.6.32-openvz-042stab092.2-amd64, Knot 1.5.0-1
I tried to install Knot on another older machine where is Debian 7 too
but upgraded from 6 and it's KVM virtual machine. There it works
correctly via init.d script and the proccess is named /usr/sbin/knotd
*-d* -c /etc/knot/knot.conf
Do you have an idea why it's working on older machine correctly and on
the second with OpenVZ not?
Thanks for any help.
Zdenek Z.
Hello Knot folk,
I'm building Knot RPM packages for use on CentOS 7, and I have to write
systemd unit files. Before I write anything, I'd love to hear from
others who may already have done such work, to learn from it. Let me
describe my ideas.
On my existing Knot servers running on CentOS 6 with upstart, I have 2
upstart scripts, viz. knot.conf, and knot-instance.conf. The knot.conf
upstart script looks in /etc/knot for .conf files, and for each one,
runs knot-instance with the config file as a parameter. This way, a
simple "start knot" will start all instances.
In systemd, there is better support for instances, so I want to create a
knot@.service template unit, and a knot.target target unit. Then, I can
create new instances with "systemctl enable knot(a)conf1.conf" and
"systemctl enable knot(a)conf2.conf". Finally, running "systemctl start
knot.target" should start all configured instances. Does this sound
reasonable?
I would also like to know about Knot's built-in support for systemd. I
can't find any documentation about it. Could one of the devs please
describe what Knot actually does if it's compiled with systemd support?
Would you mind adding this information to the online documentation?
Regards,
Anand
Hello list!
Today, CZ.NIC Labs are releasing Knot DNS version 1.5.1!
Let's discuss bugfixes first. Most notably, we've fixed a bug in
automatic DNSSEC signing: domain names in RDATA were not lowercased
before signing, resulting in bogus signatures. Other interesting
bugfixes include proper handling of DDNS prerequisites and some TSIG and
EDNS corner cases.
As for the new features, we've added a basic support for logging using
systemd journal. At the moment, log messages related to zone have the
ZONE field set, which means that you can easily filter log messages
based on zone name criteria. We plan to add more fields in the future to
allow more fine-grained filtering. We're looking forward to your
suggestions in this area.
Moreover, we've improved DDNS performance for large zones by grouping
incoming updates together and executing them as a bulk. This partially
mitigates problems with RCU and copying the zone structure, but dynamic
updates' running time is still proportional to size of the zone and not
to the size of the actual updates. Improving this is one of our top
priorities, and code in this release will help us to do so.
Finally, we've improved and unified format of logging messages. Most
notable, each logging message concerning a zone is now prepended with
[zone name]. If you parse the output of log files, be sure to update
your scripts.
Further, we now enforce a more strict policy for DNSSEC signing keys:
at least one active pair of KSK and ZSK keys of the same algorithm must
be present at all times, or Knot will refuse to sign the zone.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz.asc
Be sure to let us know if you run into any problems. Have a nice day and
thanks for using Knot DNS!
Jan
--
Jan Kadlec, 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,
i'm operating a small hidden master server (four zones spread out to two
external NS servers), and want to introduce dnssec.
so far, i have kept my zone files in /etc under version control, but now
knot starts overwriting them, which is kind of important because of the
serial number increments, but also removes file structure, and comments
and generally messes with the changelog.
i could not quite infer from the documentation what the recommended work
flow is in this situation:
* will things work if i just make the zone files read-only for bind?
* should i keep the original files separate and copy them over to the
knot-writable destinations for each refresh? if yes, can that be
automated from within knot?
in either case, i have to take care of the serial numbers. my current
numbering scheme (YYYYMMDDXX with year, month, day and per-day number)
produces sufficiently few automated changes that incrementing by 10 each
time i edit the unsigned file on one deay would work, but what is best
practice there?
best regards
chrysn
ps. please keep me in cc when replying, as i'm not subscribed to the
list.
--
There's always a bigger fish.
-- Qui-Gon Jinn
Hello Knot DNS users!
After two release candidates, CZ.NIC Labs proudly release Knot DNS 1.5.0
final. This new version differs greatly from the old 1.4 branch - we've
rewritten quite a big portion of our code, and we've built a foundation
for next cool features to come.
But you've probably read about the changes in 1.5.0 in the previous
release messages, so here's just a brief list of improvements that are
visible to users: Optional query modules (currently we have dnstap and
response synthesization modules implemented), lower memory footprint and
improved zone events handling (for those of you with problems with zone
expiring, 1.5.0 should not have this problem). We've also done a lot of
under-the-hood changes, with lots of refactoring and massive code
reductions. Apart from all this, we've been very busy writing tests -
our current test code coverage is around 75 percent.
Here are the changes we've made from 1.5.0-rc2:
Features:
- DDNS forwarding reimplemented
Improvements:
- Transfer sizes logged in bytes if needed
- Logging outgoing NOTIFY messages
- Logging unauthorized incoming NOTIFYs
Bugfixes:
- Zone flush planning after bootstrap
- Incorrect incoming AXFR message sizes
- DDNS signing changes were freed too soon, with possibility of stale data
- knotc remote control key handling
Changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz.asc
We've done all we could to test Knot DNS 1.5.0 on our end, now it's time
you gave it a try! We hope you'll be as happy with it as we are.
Today's thanks for bug reports go to Anand Buddhdev and Motomu Utsumi.
Have a nice day and thanks for using Knot DNS!
Jan
--
Jan Kadlec, 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
