Hi Peter,
On 4 June 2014 12:08, Peter Andreev <andreev.peter(a)gmail.com> wrote:
Just a few thoughts to start from:
1. Masters have to have possibility to exchange their states to each
other, including zones, journals. This means that "multi-master"
should be a "per-zone" feature;
It is, the multi-master is enabled like:
example.com {
xfr-in master1, master2;
}
and the "master2" is then used for failover if the zone transfer with
"master1" fails for example.
Usually, you don't need multiple masters until you have a specific use
case for that.
2. Each master in case of dynamic update has to
forward this update to
other masters. This means that server should look to its configuration
rather than to mname field;
That is true, but this may also cause problems with some specific
setups. Like for example hidden master
that can only sign the zone, but can't forward dynamic updates and
such. That is not to say relying on mname
is always the best. Truth is, I don't like the idea of
authoritative servers forwarding messages, but it seems there are
legitimate use cases for that.
Maybe we could let the zone operator override the mname with the
configuration and put a warning in there,
or is there a complete error-proof solution I'm not aware of?
3. In case of first start there should be option for
operator to tell
server if it starts as slave and has to sync from other masters, or it
should consider itself as master and provide data to others.
As of now, the zone is treated as master unless it has at least one
remote in the "xfr-in" option.
Maybe it's not very intuitive, but we have a new configuration (to
allow remote configuration as well) in planning,
so this could be something to consider.
There is a lot to discuss actually, for example, what
to do with
DNSSec? How to handle requests from slaves on first start?
As for me, such master should be specialized software with main focus
not on performance, but on management and inter-server communication.
I tend to agree, I originally wanted to support multiple masters only
to provide failover for zone transfers.
2014-06-04 13:35 GMT+04:00 Alex Massover
<alex(a)jajah.com>om>:
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(a)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(a)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(a)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(a)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
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
--
Is there any problem Exterminatus cannot solve? I have not found one yet.