Hi,
Please see inline
From: marek(a)vavrusa.com [mailto:marek@vavrusa.com] On Behalf Of Marek Vavruša
Sent: 04 June 2014 11:13
To: Alex Massover
Cc: knot-dns-users(a)lists.nic.cz
Subject: Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate!
Hi Alex, the "xfr-in" statement always allowed a list of remotes as masters.
However, only the first one was always used. With the 1.5.0, other remotes are used for
failover should the first master be inaccessible or returning lame answers. There
isn't any advanced functionality like load balancing or anything, do you need
something like that?
Also, the update forwarding to primary master is not reimplemented in the rc1 (but will be
in final, see KNOWN_ISSUES). In that case, the things get tricky - in past, we used the
first remote in the list
as a primary. With the list now, we should probably take the primary NS as is in the SOA
of the zone. Thoughts?
[Alex] Will this guarantee data consistency, providing there are a number of slave servers
with update forwarding?
Also, I’m not sure I understand how the second master gets the updated zone, when the
first fails.
Best,
Marek
On 4 June 2014 09:35, Alex Massover <alex@jajah.com<mailto:alex@jajah.com>>
wrote:
Hello,
I’m not able to find any information about how multi-master works.
Can someone point me to the info, please? Does it work with dynamic updates?
BR, Alex.
From:
knot-dns-users-bounces@lists.nic.cz<mailto:knot-dns-users-bounces@lists.nic.cz>
[mailto:knot-dns-users-bounces@lists.nic.cz<mailto:knot-dns-users-bounces@lists.nic.cz>]
On Behalf Of Marek Vavruša
Sent: 03 June 2014 21:31
To: knot-dns-users@lists.nic.cz<mailto:knot-dns-users@lists.nic.cz>
Subject: Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate!
Here are the correct links for those baffled by my (admittedly) poor mail formatting
skills.
Changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz.asc
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz.asc
Marek
--
Marek Vavrusa, Knot DNS
CZ.NIC Labs
http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW:
http://labs.nic.cz http://www.nic.cz
On 3 June 2014 20:10, Marek Vavruša
<marek.vavrusa@nic.cz<mailto:marek.vavrusa@nic.cz>> wrote:
Hi Everyone,
with the 1.5.0 mostly feature-complete, us jolly folks at the CZ.NIC Labs thought
that the time has come to share it with you in form of a first release candidate.
I'd like to tell you a story first - I was browsing through the NEWS file, looking
back
at the things we've done since the 1.0.0 two years ago. Oddly enough, one of the
new
features was an "optimized memory consumption", and I've seen this repeat a
few times.
I would have thought that the Knot DNS consumes zero memory by now, but it appears it
doesn't
work that way. The law of diminishing return still applies, and the changes in between
the versions
seem almost insignificant. Sometimes at least (recently, I've added a benchmark of 1M
small zones to our benchmark [1], which showed how much memory did we need per each
zone).
We addressed that. And despite the new preallocated packet buffers and other features, we
still managed to cut down the resource requirements for TLD use cases for about 20%.
My point is, while the 20% does not seem that impressive alone, but the steep
release-over-release tendency of smaller memory footprint and faster startup/answer
performance just shows the unrelenting attention to the seemingly insignificant stuff,
like structure alignment or packet distribution. That's what we're commited to.
Now, what's actually new in the 1.5.0? I've touted the major changes under the
bonnet earlier this
year and boy, we've been busy. One of the major changes is the new query processing,
which allowed us to do several cool things. The query processing is broken down to the set
of step,
that are built like a LEGO, and each of the steps can be altered by the modules.
We have two modules now - a module capable of synthesizing forward/reverse records
according to the configuration template. This for example solves the IPv6 reverse records
problem (SLAAC as well), as we don't have to generate massive zones, but rather create
the records on the fly.
The second module is a dnstap query/response log. Heard about the dnstap [2]? It's a
pretty ingenious solution to the fine-grained capture of the DNS traffic without
compromising the performance.
By the way, the utilities (kdig) support it too and you can either capture or replay
queries now.
The good thing about modules is that it allows us to streamline (about 12K LOC less) the
core functionality and extend the server at the some time. Think RRL, load balancing,
geo-aware answers.
What about other things? As for the visible changes, for instance a multi-master
failover, improved logs, asynchronously loaded zones, much more accurate "knotc
memstats" and "zonestatus" tools, new user manual ...
I could probably bore you to death with the nitty gritty stuff, so check out the
changelog to know more. That being said, I'd like to ask your help. The new stuff,
like the asynchronous zone loading or logging, change the usability a little. Did we break
your scripts or use case? Compliment, cheeky remark or angry rant? Please let us know,
we'd like to get most of the kinks ironed out till the final release. Thank you.
Changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.gz.asc
https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc1.tar.xz.asc
[1]
http://knot-dns.labs.nic.cz/pages/benchmark.html#tab-resource-usage
[2]
http://dnstap.info/
Kind Regards,
Marek
--
Marek Vavrusa, Knot DNS
CZ.NIC Labs
http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW:
http://labs.nic.cz http://www.nic.cz