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
Hi Maren,
you should turn the explicit notification
both in bind and knot.
For Knot use "notify-out <slave1> <slave2>;" + "xfr-out <slave1> <slave2>;"
See the documentation:
https://www.knot-dns.cz/static/documentation/html/configuration.html#master…
For Bind use "notify explicit;" + "also-notify;", see:
http://www.zytrax.com/books/dns/ch7/xfer.html#notify
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: "Maren S. Leizaola" <leizaola(a)udr.hk.com>
> To: knot-dns-users(a)lists.nic.cz
> Sent: Monday, July 7, 2014 1:32:52 PM
> Subject: [knot-dns-users] Two hidden masters - sending notifications to public slaves.
> Hi,
>
> We are setting up to do zone generations of two separate hidden masters
> which will take turns on the zone generation.
>
> Public/visible DNS servers "should" get notifies from both servers and
> select the one with the with the highest serial number.
>
> I am planning to run bind on one server and knot on the other. On bind i
> have the issue that it would not send notifies to the name servers until
> I turned on "notify-soa yes;". However I realise that his will only
> notify one single DNS server and introduces a single point of failure.
>
> Does Knot have any issues sending the notifies. How do I go about
> getting this done?
>
> Regards,
> Maren
>
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
Hello,
after upgrading to new stable version 1.4.7 we noticed a problem with
zones, which are expiring (i've seen some bugfix -expiration timer). It
happened second time now, and i think its happening every week (7days).
Zones, which expired are selected randomly, count of expired zones is ~8.
expired zones are listed like this:
somezone.net. type=slave | serial=0 | bootstrap idle |
After manually refreshing zone everything works fine.
TTL is 86400 - 1 day
We are using knot as slave dns. Bind9 is master.
Thanks for some advices.
Jakub
Hello everybody,
We're currently testing Knot for a slave server with a BIND master,
and we've noticed that NOTIFY messages from this master are not being
processed by Knot. As I understand, BIND uses a random source port for
NOTIFY messages, as a precaution against attacks. Also, if I
understand correctly, when I add a remote master to a zone in Knot, if
I don't specify a port for it then it defaults to 53-
This leads me to believe that Knot is rejecting NOTIFY messages from
the BIND master, because they come from an unexpected, random port. Is
this correct? Can this situation be rectified to allow NOTIFY messages
from random ports?
Thank you very much in advance.
Gonzalo Muñoz
NIC Chile
Hi,
We are setting up to do zone generations of two separate hidden masters
which will take turns on the zone generation.
Public/visible DNS servers "should" get notifies from both servers and
select the one with the with the highest serial number.
I am planning to run bind on one server and knot on the other. On bind i
have the issue that it would not send notifies to the name servers until
I turned on "notify-soa yes;". However I realise that his will only
notify one single DNS server and introduces a single point of failure.
Does Knot have any issues sending the notifies. How do I go about
getting this done?
Regards,
Maren
Hello,
I'm trying to understand if Knot can solve our performance problem with big scale dynamic DNS deployment. Currently we use BIND and the performance of Dynamic Updates is insufficient for our requirements. Doing some research I understood that BIND processes updates sequentially and can't really benefit from SMP.
I understand how RCU allows parallel reads with updates. But reads is not an issue in our deployment. My question is, does Knot able to process multiple updates in parallel (and not sequentially) and provide a better scale for _updates_?
As far as I understand it depends on data structure hierarchy implemented in Knot.
--
Alex Massover | Telefónica Digital
Architect
M +972-54-2279512
alex(a)jajah.com<mailto:alex@jajah.com>
Hello,
We have Knot 1.4.6 on CentOS installation.
When doing NAPTR ddns update, like this:
nsupdate
> server x.x.x.x
> update add 3.1.1.1.1.1.1.1.1.2.7.9.9.our.domain.com. 172800 NAPTR 1 1 "u" "E2U+sip" "!^.*$!sip:123@freeswitch.org!" .
> send
; Communication with server failed: timed out
It fails with:
knotd: libknot/rrset.c:1703: rrset_serialize: Assertion `size_one == rr_size' failed.
Aborted
No issues with ddns updates with TXT records.
--
Alex Massover | Telefónica Digital
Architect
M +972-54-2279512
alex(a)jajah.com<mailto:alex@jajah.com>
Le samedi 14 juin 2014 à 00:10 +0200, Jan Kadlec a écrit :
> Hello,
> one more thought: Could you please check your master log file for this
> warning message: (log for category: zones and severity: warning has to
> be enabled) "Zone file for '...' changed, but serial didn't - won't
> create changesets."? This happens when you change the zone, but the
> serial remains the same.
> Note that Knot will change the serial when automatic DNSSEC is enabled,
> so before creating the zone file in the script, you have to get the
> current serial from server and increment that serial. Updating your zone
> files using this approach might help you, but it is nevertheless a bug.
Hello,
I had this warning sometimes. I edit my zone files with emacs in zone
mode, so the serial is auto-incrementing, but I have to save it twice to
pass over the dnssec auto-increment.
I put a check in my makefiles to ensure the old serial is lower than the
new one.
Look like it works with that, here was my mistake :)
Thanks a lot !
Regards,
--
Bastien Durel <bastien+knot(a)durel.org>