knot-dns-users

knot-dns-users@lists.nic.cz

5 participants
773 discussions

by Alex Massover

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>

12 let, 1 měsíc

Re: [knot-dns-users] Master-slave replication

by Bastien Durel

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>

12 let, 2 měsíce

Master-slave replication

by Bastien Durel

Hello I have some zones in 2 knots in a master-slave relation When I update zones in master, there are replications issues in slave: - sometime changed records are duplicated (old and new value) - sometime removed records persists - sometime the RRSIG records are duplicated (old and new value) I often have to erase slave zones and to restart knot to get correct zone. I update master zone via makefiles that re-create (unsigned) zone files and then reload knot via knotc What is my mistake ? Regards, -- Bastien

12 let, 2 měsíce

Re: [knot-dns-users] Parking page with a large number of zones pointing the the same file.

by Ondřej Surý

Hi Maren, it would never be the 'same' zone file, since you have different full labels (foo.example.net is different from foo.example.com) per zone after loading them into the memory. I would suggest that this use case scenario would be best served by some new query processing dynamic module[1] that you would configure for all those zones and that would always respond with the same data. 1. See the Knot DNS 1.5.0rc1 release notes and documentation 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: Thursday, June 12, 2014 7:50:02 PM > Subject: [knot-dns-users] Parking page with a large number of zones pointing the the same file. > Hello, > I would like to know what the memory allocation/usage > would be like if say I point 1M zones to the same zone file. > > Will it allocate memory for each of the zones or can it just allocate > memory once as it is the same zone file ? > > 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

12 let, 2 měsíce

Parking page with a large number of zones pointing the the same file.

by Maren S. Leizaola

Hello, I would like to know what the memory allocation/usage would be like if say I point 1M zones to the same zone file. Will it allocate memory for each of the zones or can it just allocate memory once as it is the same zone file ? Regards, Maren.

12 let, 2 měsíce

Knot 1.5 - what does state "idle" mean?

by Anand Buddhdev

12 let, 2 měsíce

Fwd: Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

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>: >> 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.

12 let, 2 měsíce

Re: [knot-dns-users] Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

Hi Anand, I see this could be a problem, is the backoff causing the delays for failed zone transfers? There is a configuration option "background-workers" with which you can limit the number of parallel requests, but if you can email me some statistics about failed/passed transfers and transfers/second we can probably work out some more clever queuing. Cheers, Marek On 4 June 2014 12:11, Marek Vavruša <marek(a)vavrusa.com> wrote: > Hi Anand, > > I see this could be a problem, is the backoff causing the delays for > failed zone transfers? > There is a configuration option "background-workers" with which you > can limit the number of parallel requests, > but if you can email me some statistics about failed/passed transfers > and transfers/second we can probably work out > some more clever queuing. > > Cheers, > Marek > > On 4 June 2014 12:06, Anand Buddhdev <anandb(a)ripe.net> wrote: >> On 03/06/2014 20:10, Marek Vavruša 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. >> >> Great stuff Marek! >> >> I've started an instance of 1.5.0-rc1 with a few thousand slave zones >> configured. The bootstrap takes quite a while as Knot has to XFR all the >> zones in. >> >> It looks like Knot is hitting our master very hard, because it seems to >> want to make too many parallel connections. I see this in the logs: >> >> 2014-06-04T09:58:51 [error] AXFR of 'zone' with 'master': Requested >> resource is busy. >> >> Each such error will cause Knot to retry the zone later, and waste time >> and cycles. Is there any way to get Knot to limit the number of parallel >> XFRs it does? Or re-use TCP connections? >> >> The Knot server has been running for over 15 minutes now, and has still >> not finished boot-strapping all the zones. >> >> Regards, >> >> Anand >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

12 let, 2 měsíce

Knot DNS 1.5.0 first release candidate!

by Marek Vavruša

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 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS> Sources: https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.gz https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz.asc>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot- <https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz.asc>1.5.0-rc1 <https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS>.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

12 let, 2 měsíce

Re: [knot-dns-users] knot-dns-users post from fay-mutluluk-hikayeleri@fotoalem.com requires approval

by Jan Včelák

Dne St 28. května 2014 16:19:49, knot-dns-users-owner(a)lists.nic.cz napsal(a): > As list administrator, your authorization is requested for the > following mailing list posting: > > List: knot-dns-users(a)lists.nic.cz > From: fay-mutluluk-hikayeleri(a)fotoalem.com > Subject: You are in the financial matrix. Choose the red pill! > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > https://lists.nic.cz/cgi-bin/mailman/admindb/knot-dns-users > > to approve or deny the request.

12 let, 2 měsíce

← Newer
1
...
61
62
63
64
65
66
67
...
78
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users