- knot-dns-users - lists.nic.cz

by Jan Kadlec

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.gz https://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.asc https://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.cz http://www.nic.cz

11 let, 5 měsíců

1
0
0 0

workflow for zone signing on master

by chrysn

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

11 let, 6 měsíců

4
4
0 0

Knot DNS 1.5.0 final release

by Jan Kadlec

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.gz https://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.asc https://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.cz http://www.nic.cz

11 let, 6 měsíců

1
0
0 0

Re: [knot-dns-users] Two hidden masters - sending notifications to public slaves.

by Ondřej Surý

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

11 let, 6 měsíců

4
5
0 0

Problem with expiring zones - new stable version

by Jakub Stollmann

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

11 let, 6 měsíců

2
1
0 0

Random source port for incoming NOTIFY

by Gonzalo Muñoz

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

11 let, 6 měsíců

3
4
0 0

Two hidden masters - sending notifications to public slaves.

by Maren S. Leizaola

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

11 let, 6 měsíců

1
0
0 0

Knot DNS 1.4.7 patch & 1.5.0-rc2 releases

by Jan Kadlec

Hello list! Today we release two new versions of Knot DNS: 1.4.7 patch release and a second release candidate of 1.5.0: 1.4.7 patch release fixes few minor issues and one major one, here they are in the order of their importance: - Assertion failure when serializing NAPTR records - this error can pop up with DDNS and transfers, regular queries are safe. - Knot could send mismatched IXFRs with automatic DNSSEC enabled. - Some DDNS corner cases were not handled properly. - Slave zone EXPIRE timer could be improperly set. - Zone semantic checks gave some false positive warnings. The NAPTR assertion failure is quite serious, so we recommend all users to update. We sincerely apologize for this. Hopefully all the code reduction and refactoring we did will pay off and versions 1.5 and beyond will see fewer patch releases. Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.7/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz.asc 1.5.0 second release candidate contains two new features: - edns-client-subnet support for kdig, see https://gitlab.labs.nic.cz/labs/knot/issues/252 for more info - Asynchronous startup is now configurable (config option "asynchronous-start"). Two minor improvements: - Faster zone reload. - Text zone files are no longer written to disk right after bootstrap, but are flushed in accordance with the "zonefile-sync" config option. And the following bugfixes: - Knot did not close connection with remote during transfer when the remote replied with SERVFAIL. - Knot was giving wrong log message during IXFR -> AXFR fallbacks. - Some zone events were not handled properly during reloads. We encourage everyone to give the second release candidate a try and send us as much feedback as possible :) Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz.asc We'd like to thank Anand Buddhdev, Alex Massover and Bastien Durel for feedback and bug reports. 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.cz http://www.nic.cz

11 let, 7 měsíců

1
0
0 0

Parallel dynamic DNS updates

by Alex Massover

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>

11 let, 7 měsíců

3
7
0 0

Knot 1.4.6 Aborted on NAPTR ddns update

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>

11 let, 7 měsíců

2
2
0 0

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>

11 let, 7 měsíců

1
0
0 0

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

11 let, 7 měsíců

2
3
0 0

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

11 let, 7 měsíců

2
1
0 0

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.

11 let, 7 měsíců

1
0
0 0

Knot 1.5 - what does state "idle" mean?

by Anand Buddhdev

11 let, 7 měsíců

1
0
0 0

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.

11 let, 7 měsíců

2
1
0 0

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

11 let, 7 měsíců

1
0
0 0

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

11 let, 7 měsíců

4
8
0 0

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.

11 let, 8 měsíců

1
0
0 0

Knot DNS 1.4.6 patch release

by Jan Kadlec

Hello List! Today, we release Knot DNS 1.4.6 with two minor fixes. First issue we've fixed would only occur when doing DNSSEC key rollover using the key metadata (via the dnssec-settime tool, for example) - there was a possibility that the server would try to sign the zone continuously for a limited amount of time. DNSSEC data would stay valid all the time though. The other fix concerns mainly RRL users with recvmmsg enabled - when using SLIP other than 1, responses that should have been dropped were actually sent as empty UDP datagrams. Such responses would not be helpful to the attacker, as they are actually smaller than the queries, but they could confuse legitimate clients. This applies for the responses to malformed query messages as well, even if the RRL is disabled. All in all, if you do not use the automatic DNSSEC or RRL, there's probably no need to update. Hopefully, this is the last release before the 1.5RC1 comes out, so stay tuned. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.6/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.6.tar.xz.asc Updated packages will be available shortly. Thank you for using Knot DNS. Regards, 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.cz http://www.nic.cz

11 let, 8 měsíců

1
0
0 0

knot as a recursive server too - it is planned ?

by Josef Karliak

Hi there, do you plan to enable/run Knot as a recursive server too ? We used our master dns server as a recursive server too (only for our servers), but after migrating from Bind to Knot it is not possible. For now I had to change asking secondary dns server with bind, but ... :) Thanks and best regards J.Karliak.

11 let, 9 měsíců

7
9
0 0

knot 1.4.x and enabling debug.

by Josef Karliak

Hi, I've some problems with my domains, I was unreacheable because of knot wasn't responding. I want to run debug, I've this in my knot.conf: ... ... log { syslog { any all; zone all; } file "/var/log/knotd.debug" { server debug; zone debug; } ... ... but the "/var/log/knotd.debug" file is empty. Did I missed something ? :) About knot : he was running, SOA querried to master server that my knot makes slave, but didn't answered for my domains that he manage. After restart knot all's fine... Anyway I made a few minutes ago update of the knot, maybe some "old" bug fixed in the new version, now running "knot-1.4.4-49.1.x86_64". Thanks and best regards J.Karliak.

11 let, 9 měsíců

2
1
0 0

[PATCH] Turn off TTL display when printing a question section

by Robert S. Edmonds

Question resource records do not include a TTL field (per RFC 1035 §4.1.2), so it seems strange to display a zero TTL when printing the question section. This makes kdig match the question section dump style of drill and dig. --- src/utils/common/exec.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/utils/common/exec.c b/src/utils/common/exec.c index 92af2df..aa5485d 100644 --- a/src/utils/common/exec.c +++ b/src/utils/common/exec.c @@ -200,9 +200,10 @@ static void print_section_question(const knot_dname_t *owner, size_t buflen = 8192; char *buf = calloc(buflen, 1); knot_rrset_t *question = knot_rrset_new(owner, qtype, qclass, NULL); + knot_dump_style_t qstyle = style->style; + qstyle.show_ttl = 0; - if (knot_rrset_txt_dump_header(question, 0, buf, buflen, - &(style->style)) < 0) { + if (knot_rrset_txt_dump_header(question, 0, buf, buflen, &qstyle) < 0) { WARN("can't print whole question section\n"); } -- 1.9.1

11 let, 9 měsíců

2
1
0 0

Knot DNS 1.4.5

by Jan Včelák

Hello Everyone! Today, we announce the Knot DNS 1.4.5, which includes one security fix. We found out, that the TSIG validation code contains a possible weakness. The received TSIG digest was compared using string comparison functions, instead of functions intended for binary data. As a result, under certain conditions, the TSIG digest was compared only partially. We believe that this has no huge security impact, but it is worth fixing as soon as possible. Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.5.tar.xz.asc Corresponding patch (applicable to older releases): https://gitlab.labs.nic.cz/labs/knot/commit/e796477dd60020031610b156fdca07a… We are sorry for the complications. Best Regards, Jan -- Jan Včelák, 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

11 let, 9 měsíců

1
0
0 0

Knot NSEC3 with opt-out

by Klaus Darilion

Hi! I use knot 1.4.4 and sign my zones with NSEC3. Is NSEC3 with opt-out supported? If yes, how can I activate opt-out? I tried setting the flag in the NSEC3PARAM record but apparently this does not activate opt-out. Thanks Klaus

11 let, 9 měsíců

2
4
0 0

Knot DNS 1.5 technology preview

by Marek Vavruša

Hi Everyone, we're getting closer to the 1.5 release and because we're mostly feature complete now, I think today might be a good opportunity to share some of the new stuff we've created and hear out your opinions. There's a ton of improvements that I can't cover in a few paragraphs, but I've picked 3 of those that I think are the pillars for the bigger plan for this year. Just so you know, there is no tarball this time, but if you're brave enough, you can actually try everything covered here. You can find the code in our git repository under a tag "v1.5.0-alpha": $ git clone -b v1.5.0-alpha https://gitlab.labs.nic.cz/labs/knot.git 1. Query processing and code base We've known for a while that there were parts of the code that we weren't happy with. It's not just that it was getting hard to patch and read, but with we had a ton of ideas that we couldn't get implemented because of the limitations (in fact, this effort bears fruits as soon as of this release, but more on that later). One of those places was query processing and dealing with queries in general. Naturally, we've sat down and reworked this from scratch. Now, from the user perspective it's not so exciting - yes we made it RFC compliant in several cases and it's faster than ever (I'm running benchmarks as we speak, so you might want to check out our webpage later). It's still a preview and we're ironing things out, so don't take the numbers as final. For those who are interested in the details (thank you!), it's much much more important because the code lays a solid foundation for the cool stuff to come while being lightweight. How much? Around 10+k LOC which is roughly 10-15% of our code base gone and we offset that by adding almost 5k LOC worth of test cases. To put it in another words, it means it does more with less and we're not done here. 2. Separating Knot DNS library We also improved the Knot DNS build process overall. The code providing basic building blocks for the server and utilities is now held in the libknot library, which is by default linked dynamically to these components. You will also notice the libzscanner library, our high-performance zone scanner written in Ragel (with no dependencies on Knot DNS). We plan to build some other projects on top of that and provide public headers in the future (which is more likely to happen for the libzscanner - if someone is interested). But currently, you may benefit from a smaller size of the binaries. 3. Pluggable query processing modules + auto forward/reverse records New features are always a compromise - usually between ease of use, complexity and resource usage. But what if we could make the core as lightweight as possible and let the user choose? The new processing API is built like a Lego (don't step on it though), it breaks down the processing into independent parts that together form a plan for query processing. So what we did was, we've created an interface for loadable modules and let it add/remove or change the query processing plan as the module sees fit. This allows to keep complexity at bay (for those who don't want extra stuff) and provide a playground for new ideas. We actually have a first module - it can synthesize per-answer forward/reverse records for IPv4/IPv6 addresses from a template in configuration file (see 4.11 in the documentation on further information). For the impatient, an example speaks the best: We have an IPv6 reverse zone we need to take care of, but the problem is the address space is too big to generate a zone file. So we create an empty zone, put in static records we want and let the module to synthesize other records per-answer (if they fit in the template and aren't present in the zone): # Configuration: 1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa { query_module { synth_record "reverse dynamic- example. 400 2620:0:b61::/52"; } Now if we load Knot DNS, and kdig for a reverse record, we get a following reply: $ kdig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. ;; QUESTION SECTION: ;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. 0 IN PTR ;; ANSWER SECTION: ..snip.. 400 IN PTR dynamic-2620-0000-0b61-0000-0000-0000-0000-0001.example. Forward records can be dealt with in a similar fashion, see the manual 4.11 for more examples and information. To sum it up, modules could be a way to accommodate for the "should this be a in a nameserver?" sort of things. If you don't like it, just don't put it in the configuration and you're good. As of now the module API is open (no "how to" though), and so are we for ideas. Phew, this was longer than I expected and I barely scratched the surface. As you see, this version is going to be a lot about tidying up and opening up the possibilities. So what's your take on this? Best, 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

11 let, 9 měsíců

1
0
0 0

Knot DNS 1.4.4

by Marek Vavruša

Hi Everyone, while we in the CZ.NIC Labs are all focused on the next big thing, I thought now it might be a good time to get out another of our (admittedly highly irregular) monthly patch releases. Bug fixes aside, there are a couple improvements that we hope will make your life easier. Here's the breakdown: - 'knotc reload' does not immediately refresh/notify unchanged zones. This fixes the flurry of refresh messages after each reload and makes it lightweight enough to be used frequently. Note that new/changed zones are still added and old zones are removed. However, if you want to refresh zones explicitly, you need to call 'knotc refresh' after reload now. - 'knotc -f refresh' now truly forces a zone refresh. To put it in another words, it's akin to the 'retransfer' command that you missed in the Knot DNS and instead of checking for new zone, it starts a full transfer of the zone right away. - 'knotc' remote commands are now logged in the daemon logfile Now, there are several bugfixes as well. See the NEWS for a complete list, but here's a selection of the most notable - in several cases notify messages weren't sent after a zone resign, progressive bootstrap retry regression was fixed, few issues with journal and maximum entry size. There is also a slight behaviour change in the zone file parser and the daemon itself. First - zone file parser now accepts asterisk in the domain name labels (wildcards aside). As for the daemon, if a zone is in a slave mode and fails to load for some reason, it immediately tries to reboostrap from the master server instead of just reporting an error. I'd also like to thank to Robert S. Edmonds for amending various spelling errors and typos in manpages and documentation, thanks! So that's it, I hope the improvements make this update a little worthwhile before new stuff comes out later this spring. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz.asc 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

11 let, 10 měsíců

1
0
0 0

Some issues with dnssec signed domain.

by Josef Karliak

Hi there, I migrated our primary DNS from Bind to Knot. I runned some tests by nic.cz's dnscheck, but there is an error: DNSSEC signature RRSIG(fnhk.cz/IN/SOA/64431) fails to validate the RR set: key 1: keytag does not match key 2:RSA Verification failed Link to test: http://dnscheck.labs.nic.cz/?time=1395821962&id=102810&view=advanced&test=s… Knot doesn't complains to anything in the system log, fnhk.cz zone is succefully signed. What did I missed ? Thanks and best regards J.Karliak.

11 let, 10 měsíců

2
3
0 0

[PATCH] various spelling and typo fixes

by Robert S. Edmonds

--- Doxy.page.h | 2 +- doc/introduction.texi | 2 +- man/kdig.1.in | 2 +- man/khost.1.in | 2 +- src/utils/common/params.h | 2 +- src/utils/dig/dig_exec.c | 4 ++-- src/utils/dig/dig_params.h | 4 ++-- src/utils/nsupdate/nsupdate_params.h | 2 +- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Doxy.page.h b/Doxy.page.h index 03e43e5..e1b91f2 100644 --- a/Doxy.page.h +++ b/Doxy.page.h @@ -33,7 +33,7 @@ Knot DNS supports the following DNS features: - AXFR - master, slave - IXFR - master (primary master experimental), slave - TSIG -- ENDS0 +- EDNS0 - DNSSEC, including NSEC3 - NSID - Unknown RR types diff --git a/doc/introduction.texi b/doc/introduction.texi index fccb2f1..96e53cb 100644 --- a/doc/introduction.texi +++ b/doc/introduction.texi @@ -31,7 +31,7 @@ Knot DNS supports the following DNS features: @item TCP/UDP protocols @item AXFR, IXFR - master, slave @item TSIG -@item ENDS0 +@item EDNS0 @item DNSSEC, including NSEC3 @item NSID @item Unknown RR types diff --git a/man/kdig.1.in b/man/kdig.1.in index 69a19e8..c313411 100644 --- a/man/kdig.1.in +++ b/man/kdig.1.in @@ -151,7 +151,7 @@ Show TTL value. Use TCP protocol (default is UDP for standard query and TCP for AXFR/IXFR). .TP .BR + [ no ] fail -Stop quering next nameserver if SERVFAIL response is received. +Stop querying next nameserver if SERVFAIL response is received. .TP .BR + [ no ] ignore Don't use TCP automatically if truncated reply is received. diff --git a/man/khost.1.in b/man/khost.1.in index e25ba35..1bf677b 100644 --- a/man/khost.1.in +++ b/man/khost.1.in @@ -41,7 +41,7 @@ Print help. Disable recursion. .TP .B \-s -Stop quering next nameserver if SERVFAIL response is received. +Stop querying next nameserver if SERVFAIL response is received. .TP .B \-T Use TCP protocol. diff --git a/src/utils/common/params.h b/src/utils/common/params.h index 78dd70a..d7c34c6 100644 --- a/src/utils/common/params.h +++ b/src/utils/common/params.h @@ -98,7 +98,7 @@ typedef struct { bool hide_cname; } style_t; -/*! \brief Parametr handler. */ +/*! \brief Parameter handler. */ typedef int (*param_handle_f)(const char *arg, void *params); /*! \brief Parameter argument type. */ diff --git a/src/utils/dig/dig_exec.c b/src/utils/dig/dig_exec.c index aaab062..e10b7a8 100644 --- a/src/utils/dig/dig_exec.c +++ b/src/utils/dig/dig_exec.c @@ -409,7 +409,7 @@ static void process_query(const query_t *query) WALK_LIST(server, query->servers) { srv_info_t *remote = (srv_info_t *)server; - DBG("Quering for owner(%s), class(%u), type(%u), server(%s), " + DBG("Querying for owner(%s), class(%u), type(%u), server(%s), " "port(%s), protocol(%s)\n", query->owner, query->class_num, query->type_num, remote->name, remote->service, get_sockname(socktype)); @@ -652,7 +652,7 @@ static void process_query_xfr(const query_t *query) // Use the first nameserver from the list. srv_info_t *remote = HEAD(query->servers); - DBG("Quering for owner(%s), class(%u), type(%u), server(%s), " + DBG("Querying for owner(%s), class(%u), type(%u), server(%s), " "port(%s), protocol(%s)\n", query->owner, query->class_num, query->type_num, remote->name, remote->service, get_sockname(socktype)); diff --git a/src/utils/dig/dig_params.h b/src/utils/dig/dig_params.h index 7287fb7..c9caa3b 100644 --- a/src/utils/dig/dig_params.h +++ b/src/utils/dig/dig_params.h @@ -90,7 +90,7 @@ typedef struct { int32_t wait; /*!< Ignore truncated response. */ bool ignore_tc; - /*!< Stop quering if servfail. */ + /*!< Stop querying if servfail. */ bool servfail_stop; /*!< Class number (16unsigned + -1 uninitialized). */ int32_t class_num; @@ -116,7 +116,7 @@ typedef struct { /*! \brief Settings for dig. */ typedef struct { - /*!< Stop processing - just pring help, version,... */ + /*!< Stop processing - just print help, version,... */ bool stop; /*!< List of DNS queries to process. */ list_t queries; diff --git a/src/utils/nsupdate/nsupdate_params.h b/src/utils/nsupdate/nsupdate_params.h index 599c9b4..e823f75 100644 --- a/src/utils/nsupdate/nsupdate_params.h +++ b/src/utils/nsupdate/nsupdate_params.h @@ -43,7 +43,7 @@ /*! \brief nsupdate-specific params data. */ typedef struct { - /*!< Stop processing - just pring help, version,... */ + /*!< Stop processing - just print help, version,... */ bool stop; /*!< List of files with query data. */ list_t qfiles; -- 1.9.0

11 let, 10 měsíců

2
1
0 0

Audit the consistency of zone files, out of sync MX

by Maren S. Leizaola

Hello, What do you guys recommend to audit every resource record in a zone file against all the records in all the DNS. I want something that I feed the master zone file and then goes to each NS server and ensures that the records are correct in all of them. For some strange reason all my DNS servers have the same SOA Serial, but after deleting two MX records, some 4 out of 5 the DNS servers have not taken this update. I've yet to figure out the cause, but I see that SOA Serial is not to be trusted. Regards, Maren.

11 let, 10 měsíců

1
1
0 0

Re: [knot-dns-users] knot-dns-users Digest, Vol 28, Issue 9

by Maren S. Leizaola

On 2/24/2014 7:00 PM, knot-dns-users-request(a)lists.nic.cz wrote: > Date: Mon, 24 Feb 2014 09:16:27 +0100 > From: Jan Kadlec <jan.kadlec(a)nic.cz> > To: "Maren S. Leizaola" <leizaola(a)hk.com> > Cc: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] GLUE and additional records. > Message-ID: > <1393229787.1717.12.camel(a)labs.jan.kadlec.ws.eth.1.office.nic.cz> > Content-Type: text/plain; charset="UTF-8" > > Hello Maren and thanks for your report. Knot normally sends glue records > in additional section, it seems as if you might have encountered a bug. > Could you provide more data? One NS, A (AAAA) combination and a dig > output for this combination should be enough. Thanks again, Jan. > The environment is as follows. I host hk.com on 6 DNS servers, right now 5 are bind and one is Knot. hk.com's name servers are a,b,c,d,e,f.udrtld.net b is running Knot. Try this link www.intodns.com/hk.com This reports that B provides no glue. Please ignore the errors on f. i've yet not setup urdtld.net on it. dig -cA hk.com @b.udrtld.net when I do a dig -cA hk.com @a.udrtld.net Am I making any mistakes here? Maren.

11 let, 11 měsíců

4
9
0 0

GLUE and additional records.

by Maren S. Leizaola

Hello, I am currently testing Knot on our zones and find that it does not give any of the additional records which contain the IP of the names servers ie knot servers donot provide Glue records. This is one good thing that Bind does at it reduces the number of queries a resolver has to make. Is there any way for us to be able to do this. Regards, Maren.

11 let, 11 měsíců

2
1
0 0

/help

by Maren S. Leizaola

/subscribe /list

11 let, 11 měsíců

1
0
0 0

Knot DNS 1.4.3

by Marek Vavruša

Hi Everyone, I think the time is ripe for a small status update, preview of things to come and a new patch release. Sounds good? So, at the moment, our team at the CZ.NIC Labs is working towards the next major thing, but I'd like to reiterate that we didn't forget about the 1.4 and as of today we have a new release with several important backported bugfixes, here's the brief version: * Two bugs related to authenticated denial of existence proof with a certain combination of wildcard expansions triggering an assertion failure * Comparison of $ORIGIN and zone file in configuration is case insensitive * Corrupted journal data caused a cleanup failure during the zone loading In addition to the bugfixes, we have also slipped in a small enhancement - "include" statement in the configuration can include whole directory, this is useful if you have really a lot of includes in one place. Now a brief status update on what are we working on and what can you expect in the next few weeks/months. The next major release is going to happen later this spring and it's going to be focused on three things mostly - covering the code by tests, cleaning up and polishing existing features. There's going to be a feature or two, but that is not the main focus. The reason is the functionality we have piled up over the time has taken it's toll and now is the right time to sit back and make the features leaner and meaner (that includes usability as well), as that was always an integral idea behind Knot DNS. Plus less things means less things to break, right? I'd like to thank namely Petr Stastny and Olafur Gudmundsson (among others) for bugreports, ideas and thoughts. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz.asc 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

11 let, 11 měsíců

1
0
0 0

Feature request: force zone retransfer

by Anand Buddhdev

Hi Knot developers, I have a feature request: I'd like a knotc command that will force Knot to transfer a zone that is configured as a slave. The only command I can issue at the moment is "refresh", but this will not transfer a zone if Knot has a higher serial than the master. Such a forced transfer command is useful to help recover from situations where due to some operational error on the master server, the serial number has gone back, and we deliberately need our Knot server to sync to that old serial number. Without this command, the only way to make Knot recover is to stop it, delete the zone file from disk and start it again. But this is not ideal on a running server with lots of zones, because the stop and start times can be quite high (in our case, 37s to stop, and 1m30s to start). Both BIND and NSD provide such commands to ignore the serial number check and force zone transfers. I'd love to see such a command for Knot too. Regards, Anand

11 let, 11 měsíců

2
1
0 0

Case handling of zone names and in $ORIGIN

by Olafur Gudmundsson

I started to play with the dnssec signing features in Knot. I had this in my .conf file B-100.tld { file "B-100.zone"; …. } In the B-100.zone file I had $ORIGIN B-100.tld. I get Jan 31 16:27:32 bigredone knot[31315]: [error] Zone 'B-100.tld.': mismatching origin in the zone file. Jan 31 16:27:32 bigredone knot[31315]: [error] Failed to load zone 'B-100.tld.'. When I changed to $ORIGIN b-100.tld. Same error When I changed the conf line for B-100 to b-100 zone got loaded, I when I changed Origin to upper case but kept the lower case in conf file then zone was loaded. Summary: conf file requires zone name to be lower case, origin can be either case. (not documented) I do not think this what users expect. Either respect the case that users present or downcase both zone name and name on $ORIGIN line Also I would be great to have knot-checkzone command that one can use to verify the syntax of zone with output to standard output. Olafur

11 let, 11 měsíců

2
1
0 0

DS records

by Sime Ramov

Hello, I'm using Knot DNSSEC automatic signing and all is well and working. How would one go about obtaining proper DS records for registrar glue with least amount of trouble? Thanks for Knot DNS, by far the most pleasant experience in comparison with all other DNS servers. I've had zero issues with it, flawless operation from the start!

11 let, 11 měsíců

3
3
0 0

Knot DNS 1.4.2 patch release

by Jan Včelák

Hello List! We really appreciate your feedback on the previous release - both positive and negative. Thank you for that, it motivates us to make Knot DNS even better. Today, CZ.NIC Labs proudly announce the Knot DNS 1.4.2. There are quite a lot of changes: * The new release includes a compatibility fix for the AXFR/IXFR issues, which occurred when accepting transfers from tinydns/axfrdns. * In some cases, a TSIG did not fit into the outgoing transfer causing the transfer to be terminated. This problem was addressed as well. * Also, journal files are newly created only when necessary. It means that some disk space is spared when IXFR, DDNS, and DNSSEC signing are disabled. Feel free to delete the existing journal files if the zones fits into this category. * In addition, problems with incorrect logging categories regarding zones were reported. The logging was reviewed and should be appropriate with the new release. * We also fixed several problems in DNSSEC. Firstly, the 'knotc signzone' command was broken and caused a deadlock of the main server thread. It does not happen with the new version. Secondly, prior to this release, the signatures were refreshed two hours before their expiration, which was found to be extremely insufficient. With the new release, signatures are refreshed one tenth of the signature lifetime before their expiration. With the default configuration, the signature lifetime is 30 days, which implies that the signatures are refreshed three days before the expiration. * Moreover, RRSIGs in the additional records not-fitting into the DNS message do not cause packet truncation, but are simply skipped. We are looking forward to your reactions and comments. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz.asc Best Regards, Jan -- Jan Včelák, 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

11 let, 11 měsíců

4
6
0 0

RRSIG in additional section: reason for TC?

by Hauke Lampe

Hello. I configured "max-udp-payload 1464" and noticed that Knot 1.4 sets tc if it can't fit RRSIGs for records in the additional section while 1.3.4 didn't. I was wondering what the reasoning is behind this behaviour. Shouldn't validating resolvers ignore unsigned record sets in the additional section anyway? In my tests, Knot 1.4 almost always sets tc unless it can fit all DNSKEYs, nameserver addresses and their signatures in the additional section. That seems a bit excessive. There are only a few narrow buffer sizes ranges that don't result in a truncated response, depending on the reply content: > $ l=""; i=1800; j=$i; while [ "$i" -lt "4097" ]; do n="`dig +bufsize=$i +ignore +norec +dnssec openchaos.org soa @nsig17.openchaos.org |grep ";; flags:"`"; [ "$l" != "$n" ] && { echo "$j - $(($i-1)): $l"; l=$n; j=$i; }; i=$(($i+1)); done; echo "$j - $(($i-1)): $n" > 1883 - 1898: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 4 > 2102 - 2129: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 6 > 2333 - 2348: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 8 > 2552 - 2567: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 10 > 2771 - 2798: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 12 > 3002 - 3017: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 > 3221 - 3236: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 16 > 3440 - 3455: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 18 > 3659 - 3686: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 20 > 3890 - 4096: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 22 FWIW, the attached patch works for me. It should remove the last additional record if its RRSIG doesn't fit. Hauke

11 let, 12 měsíců

2
1
0 0

Warning messages does not contain domain name

by Petr Šťastný

Hi, the majority of warning messages does not contain particular domain name (zone name), so it is impossible to figure which zone file is wrong. For example: > 2014-01-23T20:13:07 [warning] encountered identical extra SOA record > 2014-01-23T20:13:07 [warning] encountered identical extra SOA record > 2014-01-23T20:13:07 [warning] TTL does not match TTL of its > RRSet.Changing to 19200 Can you please add zone names into all error and warning messages related to one zone? Thanks Petr Šťastný

12 let

2
1
0 0

Disable journals

by Petr Šťastný

Hello, I want to use Knot for master zones only without any DNS updates, so journal files are not needed. But they are created for every zone and it seems impossible to disable them. But this is bad in my situation when I want to serve 200000+ zones, because it creates 200000+ journal files in one directory (but they are never used). Should be possible to disable journal files or create them only in case of need or at lease divide them into more subdirectories? It would be also nice to be able to choose another directory for journal files in configuration. "storage" option is for both (zone files and journal files). Or explicitly state journal file path and filename in "zone" section. Thanks Petr Šťastný

12 let

2
3
0 0

Knot 1.4.0 a retezec duvery.

by Josef Karliak

Hoj vespolek. trosku jsem se uz ztratil s dnssecem s knotem. Vygeneroval jsem si klice, rekl knotu, kde ma klice hledat, knot je podepsal, zadna stiznost od nej. Klic jsem zadal i do keysetu na web4u, to proslo taky. Ale pokud si udelam drill my zony, drill oznami, ze mi chybi DS zaznam nebo trusted key: drill -TD ajetaci.cz Warning: No trusted keys were given. Will not be able to verify authenticity! ;; Domain: . ;; Signature ok but no chain to a trusted key or ds record [S] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b} . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} Checking if signing key is trusted: New key: . 172800 IN DNSKEY 256 3 8 AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX195Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6WybBZ6kuqED ;{id = 33655 (zsk), size = 1024b} [S] cz. 86400 IN DS 54576 10 2 397e50c85ede9cde33f363a9e66fd1b216d788f8dd438a57a423a386869c8f06 ;; Domain: cz. ;; Signature ok but no chain to a trusted key or ds record [S] cz. 18000 IN DNSKEY 256 3 10 ;{id = 40877 (zsk), size = 1024b} cz. 18000 IN DNSKEY 257 3 10 ;{id = 54576 (ksk), size = 2048b} cz. 18000 IN DNSKEY 256 3 10 ;{id = 54602 (zsk), size = 1024b} [S] Existence denied: ajetaci.cz. DS ;; No ds record for delegation ;; Domain: ajetaci.cz. ;; Signature ok but no chain to a trusted key or ds record [S] ajetaci.cz. 3600 IN DNSKEY 257 3 5 ;{id = 36256 (ksk), size = 2048b} ajetaci.cz. 3600 IN DNSKEY 256 3 5 ;{id = 11937 (zsk), size = 1024b} [S] ajetaci.cz. 3600 IN A 77.48.63.10 ;;[S] self sig OK; [B] bogus; [T] trusted -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and check. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

12 let

4
8
0 0

Logging categories

by Petr Šťastný

Hi, I think there is something wrong with logging categories. Documentation says: > server - Messages related to general operation of the server. > zone - Messages related to zones, zone parsing and loading. I use Knot 1.4.1 with the following configuration: > log { > file "/var/log/knot/knot-server.log" { > server error, warning, notice, info; > } > > file "/var/log/knot/knot-zone.log" { > zone error, warning, notice, info; > } > > stderr { > any error, warning; > } > } Everything is logged only into knot-server.log and knot-zone.log is always empty. knot-server.log file contains: > 2014-01-20T21:45:12 Knot DNS 1.4.1 starting. > 2014-01-20T21:45:12 Rate limiting set to 20 responses/sec. > 2014-01-20T21:45:12 Binding to interface 0.0.0.0 port 53. > 2014-01-20T21:45:12 Binding to interface :: port 53. > 2014-01-20T21:45:12 Configured 2 interfaces and 1 zones. > 2014-01-20T21:45:12 Changing group id to '1001'. > 2014-01-20T21:45:12 Changing user id to '1001'. > 2014-01-20T21:45:12 Server started as a daemon, PID = 25371 > 2014-01-20T21:45:12 PID stored in > '/usr/local/knot/1.4.1/var/run/knot/knot.pid' > 2014-01-20T21:45:12 Server changed directory to /. > 2014-01-20T21:45:12 Zone 'xxxx.eu.' loaded (serial 2013042301) > 2014-01-20T21:45:12 Loaded 1 out of 1 zones. > 2014-01-20T21:45:12 Starting server... > 2014-01-20T21:45:12 Binding remote control interface to > /usr/local/knot/1.4.1/var/run/knot/knot.sock > 2014-01-20T21:45:25 Reloading configuration... > 2014-01-20T21:45:25 Zone 'xxx.eu.' is up-to-date (serial 2013042301) > 2014-01-20T21:45:25 Loaded 1 out of 1 zones. > 2014-01-20T21:45:25 Configuration reloaded. And the question is: why are messages related to zone loading logged in "server" category and not in "zone" category (which is said in documentation)? Thanks Petr Šťastný

12 let

2
1
0 0

Re: [knot-dns-users] 1.4.0 dumping zones with non-existent dates

by daniel.salzman＠nic.cz

Hi Anand, Never mind. I understand your situation. Initially, we had just timestamps in zone dumps. I prefer this, since it makes smaller dumps and it is faster to process such records. Afterwards, we turned it off due to incompatibility with Bind. Because Bind is unable to load these dumps if you need it. Is there still anybody who requires human-readable timestamps in zone dumps from Knot? If not, we probably disable this functionality. Thanks, Dan On 2014-01-10 23:08, Anand Buddhdev wrote: > On 10/01/2014 19:42, daniel.salzman(a)nic.cz wrote: > >> We have probably found the problem. The function gmtime, which we use, >> is not thread safe. So I have replaced it with a better one. Please, >> try the attached patch. > > Hi Daniel, > > Thanks for this. However, I prefer not to test this on our current Knot > servers, as they are running in production. I have applied Marek's > earlier patch which disabled human-readable timestamps, and that's > keeping this problem away. > > Actually, I even asked Marek why you convert the timestamps to > human-readable in the zone dumps. After all, the zone files are only > going to be read back in by Knot, so you'd save some cycles when > writing > and reading the zones, by not converting them back and forth between > human-readable and unix timestamp. > > Is it reasonable to ask that you just dispense with human-readable > timestamps? > > Regards, > > Anand

12 let

4
4
0 0

Knot DNS 1.4.1 patch release

by Marek Vavruša

Hi Everyone, about a week ago, CZ.NIC Labs released the 1.4.0 and received some positive responses, but also discovered a few issues here and there. I'll try to summarize the important bits. Since the 1.4.1, OpenSSL >= 1.0.0 is required on configure as we ran into several issues with the older versions. If that means a problem for you, please let us know, we can always try to work something out. That also fixes compile failures on some platforms with OpenSSL < 1.0.0 Moreover, we've ran into a race condition when generating timestamps in the zone file. This affects both 1.3 & 1.4 users, so if you run Knot on slave with secured zones and experience a refusal to load a zone after reload, I advise you to rebootstrap the zones from the master. As for the other issues, we've fixed an empty APL record support and immediate zone file syncing if you use that (it didn't flush the zone correctly after resign and 'knot zonestatus' didn't handle this properly). All that plus more code coverage bugfixes and papercuts. Yet again, many thanks to our dear users for the bug reports, hints and nudges in the right direction. Last thing, as you can see, we've dropped the bz2 source packages. I hope that doesn't affect anyone, two should be more than enough. Here's a full change log: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.1.tar.xz.asc Kind Regards, Marek, CZ.NIC Labs -- Marek Vavruša 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

1
0
0 0

1.4.0 dumping zones with non-existent dates

by Anand Buddhdev

Hello Knot users, We discovered today that When Knot 1.4.0 dumps zones to disk, it sometimes writes out the dates in RRSIG expiry and inception fields like this: 20140230203521 Yes, that's apparently 30 February! If you later restart Knot, or reload it, it will refuse to load this zone, and begin returning REFUSED responses for it. I spoke with the good folk at CZNIC, and Marek quickly provided me with a patch, attached here. It turns off pretty-printing of the dates, so that the expiry and inception dates are written in unix time. This fixes the problem for us, so if you're running Knot in production, you may want to apply this patch too. We don't yet know where this bug is, but needless to say Marek and his colleagues are investigating, and I'm sure a proper fix for it will appear in due course. Regards, Anand Buddhdev RIPE NCC

12 let

1
0
0 0

Knot DNS 1.4.0 released!

by Marek Vavruša

Hi Everyone, I hope you had a terrific Christmas. Now, I know it's all work, but after some time spent in the release candidate, CZ.NIC Labs are proud to release Knot DNS 1.4.0 final version. There have been a several bugfixes, odds and ends since the last release candidate. Namely NSEC3/transfer related bugs and case sensitivity of QNAME, there's a link for an exhaustive list of changes below. But allow me to reiterate what's new since the 1.3 version. Shall we? Since the first beta, we have brought a new major feature on the table. A technology preview of an automatic DNSSEC signing. Now, since it's not a final product, there are still a few shortcomings; mainly key management and auxiliary tools missing. However, that shouldn't stop you from giving it a try! We've written a short "how to" on our wiki page here: https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-quickstart But it's really as simple and creating signing keys and setting "dnssec-enable on;" There are few more enhancements like IDN in the utilities, zone serial policies and fancier zone file printout. Plus a lot of changes under the bonnet. Say for example the memory consumption, which is significantly lower (~35% for our large zones). We've also doubled our (continuous) efforts in producing both unit and operational test cases, not to mention Knot DNS being kindly accepted in the Coverity Scan program for open source software. We've also spent some time on other related projects. Say the comparison of the authoritative name servers, that you can find here: https://www.knot-dns.cz/pages/benchmark.html The whole effort is open source, you can try it yourself or even create new test cases, any feedback is welcome. https://gitlab.labs.nic.cz/labs/dns-benchmarking With all that, the work is far from finished. We're going to further polish the Knot DNS 1.4 features and prepare a new version at the same time. By the way, we have a few surprises for you in that department as well. Last but not least, we and the whole CZ.NIC Labs would like to thank you, our users and supporters, who poured a lot of time into helping us shape the Knot DNS the way it is. It's truly appreciated. Here's a full change log: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0.tar.xz.asc Kind Regards, Marek, CZ.NIC Labs -- Marek Vavruša 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
5
0 0

Feature request: inherit xfr-in, xfr-out, etc from "zones" section

by Anand Buddhdev

Hello Knot devs, The Knot zones directive allows some options at the top-level (such as "storage", "disable-any", etc). However, the following options can only be specified per zone: xfr-in xfr-out notify-in notify-out update-in Could you make it so that these options can also be specified at the top level so that all zones specified after can inherit the same options. This is useful when I have the same master or set of masters for a whole bunch of zones, and I don't need to specify them each time for each zone separately. Regards, Anand

12 let

3
2
0 0

Knot 1.4.0-rc2 is case-sensitive!

by Anand Buddhdev

I exposed Knot 1.4.0-rc2 to real queries, and noticed it was giving REFUSED responses for a significant number of queries. Digging further, it looks like the QNAMEs were mixed-case, such as: 42.234.11.86.In-adDR.ArPA So here's where I discovered a show-stopper bug: # dig +norec @193.0.9.5 ptr 42.234.11.86.in-addr.arpa ; <<>> DiG 9.9.4-P1 <<>> +norec @193.0.9.5 ptr 42.234.11.86.in-addr.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16021 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;42.234.11.86.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 234.11.86.in-addr.arpa. 86400 IN NS ns1.virginmedia.net. 234.11.86.in-addr.arpa. 86400 IN NS ns2.virginmedia.net. 234.11.86.in-addr.arpa. 86400 IN NS ns3.virginmedia.net. 234.11.86.in-addr.arpa. 86400 IN NS ns4.virginmedia.net. # dig +norec @193.0.9.5 ptr 42.234.11.86.In-adDR.ArPA ; <<>> DiG 9.9.4-P1 <<>> +norec @193.0.9.5 ptr 42.234.11.86.In-adDR.ArPA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 57269 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;42.234.11.86.In-adDR.ArPA. IN PTR # dig +norec @193.0.9.5 ptr 42.234.11.86.IN-ADDR.ARPA ; <<>> DiG 9.9.4-P1 <<>> +norec @193.0.9.5 ptr 42.234.11.86.IN-ADDR.ARPA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18592 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;42.234.11.86.IN-ADDR.ARPA. IN PTR

12 let

2
1
0 0

How do I provide AXFR to the world?

by Anand Buddhdev

Hi people, For some zones I'm operating, I wish to provide AXFR to the world. How do I define a remote that matches 0.0.0.0/0 and ::/0? Regards, Anand

12 let

2
3
0 0

Graceful back-off for failing AXFRs

by Anand Buddhdev

Hi Knot developers, I'm testing Knot 1.4.0-rc2, which is configured with 5167 zones, all slaves. When I start Knot, it has to bootstrap all of them. It manages to bootstrap 4331 of them, but for the other 832, I get SERVFAIL from the master. Knot schedules retries for them within a 5-minute period, with some jitter. But with 832 zones, they keep coming up for AXFR continuously, and Knot keeps trying continuously. I'd like to request an improvement to Knot's scheduler so that it tries failing zones less and less frequently, to avoid being stuck in a retry cycle. How about some kind of exponentail back-off with a sane maximum of something like 24 hours? Before anyone asks why those 832 zones are SERVFAILing, I'll tell you. They're not under my direct control, and I can't get the operators to fix that easily, but I'm stuck with them, so I have to deal with them. Regards, Anand Buddhdev RIPE NCC

12 let

2
3
0 0

include directive in zones section

by Anand Buddhdev

Hello Knot developers, I appear to have run into a bug. I'm trying to run Knot 1.3.4, and the zones section of my config looks like this: zones { ripe.net { file "ripe.net.zone"; xfr-in admin; notify-in admin; } nro.net { file "nro.net.zone"; xfr-in admin; notify-in admin; } ... ... ... include "/etc/knot/ns.ripe.net.zones"; } However, when I try to verify this config, I get: # knotc -c default.conf checkconf 2013-12-20T22:43:19 [error] Config error in 'default.conf' (line 922 token ';') - syntax error 2013-12-20T22:43:19 [error] Couldn't parse config file, refusing to continue. If I remove the include directive, the configuration verifies. The documentation says I should be able to use the include directive almost anywhere in the config file. ---- A.9 include Statement The include statement is a special statement which can be used almost anywhere on any level in the configuration file. It makes inclusion of another file possible. The path of the included file can be either absolute or relative to a configuration file currently being processed. ---- Am I hitting some kind of bug where the include directive isn't being recognised inside the zones section? If it is a bug, I would *really* appreciate a fix if possible. I know it's Xmas and all, but I'm setting up some servers with Knot, and I'd love to be able to use the config this way instead of working around it. Regards, Anand

12 let, 1 měsíc

2
3
0 0

Knot 1.3.4 crash

by Anand Buddhdev

Hi Knot devs, I'm setting up Knot 1.3.4 on one of our production systems, and it keeps crashing. I ran it under gdb, and I have this: knotd: libknot/updates/xfr-in.c:905: xfrin_process_axfr_packet: Assertion `node != ((void *)0)' failed. The output of "thread apply all bt" is: Thread 133 (Thread 0x7fffd07ef700 (LWP 26754)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec9f0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec9f0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 132 (Thread 0x7fffd08f0700 (LWP 26753)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec950) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec950) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 131 (Thread 0x7fffd09f1700 (LWP 26752)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec8b0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec8b0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 130 (Thread 0x7fffd0af2700 (LWP 26751)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec810) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec810) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 129 (Thread 0x7fffd0bf3700 (LWP 26750)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec770) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec770) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 128 (Thread 0x7fffd0cf4700 (LWP 26749)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec6d0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec6d0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 127 (Thread 0x7fffd0df5700 (LWP 26748)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec630) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec630) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 126 (Thread 0x7fffd0ef6700 (LWP 26747)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec590) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec590) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 125 (Thread 0x7fffd0ff7700 (LWP 26746)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec4f0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec4f0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 124 (Thread 0x7fffd14ab700 (LWP 26745)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec450) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec450) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 123 (Thread 0x7fffd15ac700 (LWP 26744)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec3b0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec3b0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 122 (Thread 0x7fffd16ad700 (LWP 26743)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec310) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec310) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 121 (Thread 0x7fffd17ae700 (LWP 26742)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec270) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec270) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 120 (Thread 0x7fffd18af700 (LWP 26741)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x8ec1d0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x8ec1d0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 119 (Thread 0x7fffd19b0700 (LWP 26740)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6cc0e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6cc0e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 118 (Thread 0x7fffd1eec700 (LWP 26739)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6cc040) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6cc040) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 117 (Thread 0x7fffd1fed700 (LWP 26738)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc2a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc2a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 116 (Thread 0x7fffd20ee700 (LWP 26737)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc200) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc200) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 115 (Thread 0x7fffd21ef700 (LWP 26736)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc160) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc160) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 114 (Thread 0x7fffd22f0700 (LWP 26735)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc0c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc0c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 113 (Thread 0x7fffd23f1700 (LWP 26734)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dc020) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dc020) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 112 (Thread 0x7fffd2be6700 (LWP 26733)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbf80) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbf80) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 111 (Thread 0x7fffd3122700 (LWP 26732)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbee0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbee0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 110 (Thread 0x7fffd3223700 (LWP 26731)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbe40) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbe40) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 109 (Thread 0x7fffd3324700 (LWP 26730)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbda0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbda0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 108 (Thread 0x7fffd3425700 (LWP 26729)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbd00) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbd00) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 107 (Thread 0x7fffd3526700 (LWP 26728)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbc60) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbc60) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 106 (Thread 0x7fffd3627700 (LWP 26727)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbbc0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbbc0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 105 (Thread 0x7fffec654700 (LWP 26726)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dbb20) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dbb20) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 104 (Thread 0x7fffec755700 (LWP 26725)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dba80) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dba80) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 103 (Thread 0x7fffec856700 (LWP 26724)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db9e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db9e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 102 (Thread 0x7fffec957700 (LWP 26723)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db940) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db940) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 101 (Thread 0x7fffeca58700 (LWP 26722)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db8a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db8a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 100 (Thread 0x7fffecb59700 (LWP 26721)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db800) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db800) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 99 (Thread 0x7fffecc5a700 (LWP 26720)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db760) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db760) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 98 (Thread 0x7fffecd5b700 (LWP 26719)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db6c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db6c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 97 (Thread 0x7fffece5c700 (LWP 26718)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db620) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db620) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 96 (Thread 0x7fffecf5d700 (LWP 26717)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db580) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db580) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 95 (Thread 0x7fffed05e700 (LWP 26716)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db4e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db4e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 94 (Thread 0x7fffed15f700 (LWP 26715)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db440) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db440) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 93 (Thread 0x7fffed260700 (LWP 26714)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db3a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db3a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 92 (Thread 0x7fffedd9d700 (LWP 26713)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db300) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db300) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 91 (Thread 0x7fffede9e700 (LWP 26712)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db260) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db260) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 90 (Thread 0x7fffedf9f700 (LWP 26711)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db1c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db1c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 89 (Thread 0x7fffeea81700 (LWP 26710)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db120) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db120) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 88 (Thread 0x7fffeeb82700 (LWP 26709)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6db080) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6db080) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 87 (Thread 0x7fffeedb7700 (LWP 26708)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dafe0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dafe0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 86 (Thread 0x7fffeeeb8700 (LWP 26707)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daf40) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daf40) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 85 (Thread 0x7fffeefb9700 (LWP 26706)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daea0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daea0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 84 (Thread 0x7fffef5f9700 (LWP 26705)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dae00) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dae00) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 83 (Thread 0x7fffef6fa700 (LWP 26704)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dad60) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dad60) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 82 (Thread 0x7fffef7fb700 (LWP 26703)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dacc0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dacc0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 81 (Thread 0x7fffef8fc700 (LWP 26702)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dac20) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dac20) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 80 (Thread 0x7fffef9fd700 (LWP 26701)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6dab80) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6dab80) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 79 (Thread 0x7fffefafe700 (LWP 26700)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daae0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daae0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 78 (Thread 0x7ffff42dc700 (LWP 26699)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6daa40) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6daa40) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 77 (Thread 0x7ffff43dd700 (LWP 26698)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da9a0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da9a0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 76 (Thread 0x7ffff44de700 (LWP 26697)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da900) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da900) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 75 (Thread 0x7ffff45df700 (LWP 26696)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da860) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da860) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 74 (Thread 0x7ffff46e0700 (LWP 26695)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da7c0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da7c0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 73 (Thread 0x7ffff47e1700 (LWP 26694)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da720) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da720) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 72 (Thread 0x7ffff48e2700 (LWP 26693)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da680) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da680) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 71 (Thread 0x7ffff49e3700 (LWP 26692)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040ad01 in tcp_loop_worker (thread=0x6da5e0) at knot/server/tcp-handler.c:597 #2 0x00000000004951be in thread_ep (data=0x6da5e0) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 70 (Thread 0x7ffff4ae4700 (LWP 26691)): #0 0x00007ffff70b7343 in poll () from /lib64/libc.so.6 #1 0x000000000040aaf7 in tcp_loop_master (thread=0x6da540) at knot/server/tcp-handler.c:520 #2 0x00000000004951be in thread_ep (data=0x6da540) at knot/server/dthreads.c:170 #3 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 69 (Thread 0x7ffff536a700 (LWP 26690)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9f90) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9f90) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 68 (Thread 0x7ffb77bff700 (LWP 26689)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9ef0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9ef0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 67 (Thread 0x7ffff546b700 (LWP 26688)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9e50) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9e50) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 66 (Thread 0x7ffff556c700 (LWP 26687)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9db0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9db0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 65 (Thread 0x7ffff7feb700 (LWP 26686)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9d10) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9d10) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 64 (Thread 0x7ffff6170700 (LWP 26685)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9c70) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9c70) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 63 (Thread 0x7ffff606f700 (LWP 26684)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9bd0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9bd0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 62 (Thread 0x7fffeffff700 (LWP 26683)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9b30) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9b30) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 61 (Thread 0x7ffff5f6e700 (LWP 26682)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9a90) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9a90) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 60 (Thread 0x7ffff5e6d700 (LWP 26681)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d99f0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d99f0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 59 (Thread 0x7ffff51df700 (LWP 26680)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9950) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9950) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 58 (Thread 0x7ffff4be5700 (LWP 26679)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d98b0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d98b0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 57 (Thread 0x7ffff41b6700 (LWP 26678)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9810) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9810) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 56 (Thread 0x7fffd3f28700 (LWP 26677)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9770) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9770) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 55 (Thread 0x7fffef4ba700 (LWP 26676)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d96d0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d96d0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 54 (Thread 0x7fffeec83700 (LWP 26675)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9630) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9630) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 53 (Thread 0x7fffee8a0700 (LWP 26674)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9590) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9590) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 52 (Thread 0x7fffedc62700 (LWP 26673)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d94f0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d94f0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 51 (Thread 0x7fffedb61700 (LWP 26672)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9450) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9450) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 50 (Thread 0x7fffec539700 (LWP 26671)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d93b0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d93b0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 49 (Thread 0x7fffec438700 (LWP 26670)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9310) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9310) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 48 (Thread 0x7fffec337700 (LWP 26669)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9270) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9270) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 47 (Thread 0x7fffec236700 (LWP 26668)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d91d0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d91d0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 46 (Thread 0x7fffec135700 (LWP 26667)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9130) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9130) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 45 (Thread 0x7fffd29f3700 (LWP 26666)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d9090) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d9090) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7fffd28f2700 (LWP 26665)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8ff0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8ff0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7fffd12fa700 (LWP 26664)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8f50) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8f50) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7fffd11f9700 (LWP 26663)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8eb0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8eb0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7fffd10f8700 (LWP 26662)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8e10) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8e10) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7fffd0672700 (LWP 26661)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8d70) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8d70) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7fffd0571700 (LWP 26660)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8cd0) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8cd0) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7fff8ddad700 (LWP 26659)): #0 0x00007ffff70b95e3 in select () from /lib64/libc.so.6 #1 0x0000000000409808 in udp_reader (h=0x6cc4f0, thread=<value optimized out>) at knot/server/udp-handler.c:595 #2 0x00000000004099fb in udp_master (thread=0x6d8c30) at knot/server/udp-handler.c:640 #3 0x00000000004951be in thread_ep (data=0x6d8c30) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7fff8d621700 (LWP 26658)): #0 0x00007ffff6dc698e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000043dcb0 in evsched_next (s=0x6cc590) at common/evsched.c:206 #2 0x00000000004095cb in evsched_run (thread=0x6cd820) at knot/server/server.c:49 #3 0x00000000004951be in thread_ep (data=0x6cd820) at knot/server/dthreads.c:170 #4 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x7fffd0470700 (LWP 26657)): #0 0x0000000000440a80 in _log_msg (src=LOG_ZONE, level=128, msg=0x7fffd046e930 "[debug] Created new node for the record.\n") at common/log.c:245 #1 0x0000000000440c94 in log_msg (src=LOG_ZONE, level=7, msg=0x4a43e8 "Created new node for the record.\n") at common/log.c:308 #2 0x0000000000433f1c in xfrin_process_axfr_packet (xfr=0x7ffb516c4590) at libknot/updates/xfr-in.c:836 #3 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb516c4590) at libknot/nameserver/name-server.c:3973 #4 0x000000000040d429 in xfr_task_xfer (thread=0x6d33d0) at knot/server/xfr-handler.c:759 #5 xfr_process_event (thread=0x6d33d0) at knot/server/xfr-handler.c:853 #6 xfr_worker (thread=0x6d33d0) at knot/server/xfr-handler.c:1119 #7 0x00000000004951be in thread_ep (data=0x6d33d0) at knot/server/dthreads.c:170 #8 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #9 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7fffd036f700 (LWP 26656)): #0 0x00007ffff701c4ab in vfprintf () from /lib64/libc.so.6 #1 0x00007ffff70218e0 in buffered_vfprintf () from /lib64/libc.so.6 #2 0x00007ffff701c51e in vfprintf () from /lib64/libc.so.6 #3 0x00007ffff70d80eb in __fprintf_chk () from /lib64/libc.so.6 #4 0x0000000000440a4d in fprintf (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at /usr/include/bits/stdio2.h:98 #5 _log_msg (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at common/log.c:255 #6 0x0000000000440c94 in log_msg (src=LOG_ZONE, level=7, msg=0x4a43e8 "Created new node for the record.\n") at common/log.c:308 #7 0x0000000000433f1c in xfrin_process_axfr_packet (xfr=0x7ffb502d5c10) at libknot/updates/xfr-in.c:836 #8 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb502d5c10) at libknot/nameserver/name-server.c:3973 #9 0x000000000040d429 in xfr_task_xfer (thread=0x6d3330) at knot/server/xfr-handler.c:759 #10 xfr_process_event (thread=0x6d3330) at knot/server/xfr-handler.c:853 #11 xfr_worker (thread=0x6d3330) at knot/server/xfr-handler.c:1119 #12 0x00000000004951be in thread_ep (data=0x6d3330) at knot/server/dthreads.c:170 #13 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #14 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7fff8c71f700 (LWP 26655)): #0 0x00007ffff700a925 in raise () from /lib64/libc.so.6 #1 0x00007ffff700c105 in abort () from /lib64/libc.so.6 #2 0x00007ffff7003a4e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007ffff7003b10 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004349cd in xfrin_process_axfr_packet (xfr=0x7ffb516c2d30) at libknot/updates/xfr-in.c:905 #3 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb516c4590) at libknot/nameserver/name-server.c:3973 #4 0x000000000040d429 in xfr_task_xfer (thread=0x6d33d0) at knot/server/xfr-handler.c:759 #5 xfr_process_event (thread=0x6d33d0) at knot/server/xfr-handler.c:853 #6 xfr_worker (thread=0x6d33d0) at knot/server/xfr-handler.c:1119 #7 0x00000000004951be in thread_ep (data=0x6d33d0) at knot/server/dthreads.c:170 #8 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #9 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7fffd036f700 (LWP 26656)): #0 0x00007ffff701c4ab in vfprintf () from /lib64/libc.so.6 #1 0x00007ffff70218e0 in buffered_vfprintf () from /lib64/libc.so.6 #2 0x00007ffff701c51e in vfprintf () from /lib64/libc.so.6 #3 0x00007ffff70d80eb in __fprintf_chk () from /lib64/libc.so.6 #4 0x0000000000440a4d in fprintf (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at /usr/include/bits/stdio2.h:98 #5 _log_msg (src=LOG_ZONE, level=128, msg=0x7fffd036d930 "[debug] Created new node for the record.\n") at common/log.c:255 #6 0x0000000000440c94 in log_msg (src=LOG_ZONE, level=7, msg=0x4a43e8 "Created new node for the record.\n") at common/log.c:308 #7 0x0000000000433f1c in xfrin_process_axfr_packet (xfr=0x7ffb502d5c10) at libknot/updates/xfr-in.c:836 #8 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb502d5c10) at libknot/nameserver/name-server.c:3973 #9 0x000000000040d429 in xfr_task_xfer (thread=0x6d3330) at knot/server/xfr-handler.c:759 #10 xfr_process_event (thread=0x6d3330) at knot/server/xfr-handler.c:853 #11 xfr_worker (thread=0x6d3330) at knot/server/xfr-handler.c:1119 #12 0x00000000004951be in thread_ep (data=0x6d3330) at knot/server/dthreads.c:170 #13 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #14 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7fff8c71f700 (LWP 26655)): #0 0x00007ffff700a925 in raise () from /lib64/libc.so.6 #1 0x00007ffff700c105 in abort () from /lib64/libc.so.6 #2 0x00007ffff7003a4e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007ffff7003b10 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004349cd in xfrin_process_axfr_packet (xfr=0x7ffb516c2d30) at libknot/updates/xfr-in.c:905 ---Type <return> to continue, or q <return> to quit--- #5 0x000000000041ddc8 in knot_ns_process_axfrin (nameserver=<value optimized out>, xfr=0x7ffb516c2d30) at libknot/nameserver/name-server.c:3973 #6 0x000000000040d429 in xfr_task_xfer (thread=0x6d3290) at knot/server/xfr-handler.c:759 #7 xfr_process_event (thread=0x6d3290) at knot/server/xfr-handler.c:853 #8 xfr_worker (thread=0x6d3290) at knot/server/xfr-handler.c:1119 #9 0x00000000004951be in thread_ep (data=0x6d3290) at knot/server/dthreads.c:170 #10 0x00007ffff6dc29d1 in start_thread () from /lib64/libpthread.so.0 #11 0x00007ffff70c0b6d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7ffff7fec880 (LWP 26450)): #0 0x00007ffff70b97ee in pselect () from /lib64/libc.so.6 #1 0x000000000040796b in remote_poll (r=<value optimized out>) at knot/ctl/remote.c:418 #2 0x00000000004045d7 in main (argc=<value optimized out>, argv=<value optimized out>) at knot/main.c:353

12 let, 1 měsíc

1
0
0 0

Knot a OpenWRT

by Liquid

Dobrý den, bude někdy dostupný balíček Knot DNS serveru i pro OpenWRT platformu? Liquid

12 let, 1 měsíc

2
1
0 0

Knot DNS 1.4.0-rc2 & 1.3.4

by Marek Vavruša

Hi Everyone, we're on a fast track for the 1.4.0 final release as a late Christmas present now, so I'd like to give you a second preview of what is to come. On top of all that, we've encountered a several bugs, namely a race condition in event scheduling and bad additionals processing in special cases, so we decided to break the jinx of today's date and release a new stable version as well with backported fixes. But I digress, what's new in the 1.4.0 rc2 ? We implemented IDN support in the utilities, DNSSEC signing now supports GOST algorithm and several other enhancements. Speaking of which, 1.4.0 users can rejoice over prettier zone files, where DNSSEC-related data are written separately from the others, thus improving readability. Then there's configuration, where 'dnssec-keydir' and 'storage' can be configured for each zone separately and lower memory consumption. In fact we have a new benchmark section on our webpage which we update every now and then, so you can have a look not only at the response rate but also at the startup time and the memory consumption that I was talking about. Here's the page: https://www.knot-dns.cz/pages/benchmark.html The whole benchmarking is open source, so you can have a look at the scenarios, download the test suite yourself and see how we measure things. I'd like to thank Jonathan Hoppe and all for the bugreports and feedback. It's very appreciated. That's all, enjoy the spooky Friday 13th and the weekend. Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc2.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.4.tar.xz.asc Kind Regards, Marek

12 let, 1 měsíc

1
0
0 0

dnssec_keydir and storage per zone config patch

by Kamil Sopko

Hi, I found this project quite promising, but I would like to configure dnssec_keydir and storage per zone . Now all keys and db files are in one directory, that is probably OK if you have couple of zones, also if they are very big, but we have configured about 48k zones(this can be configured to tree and separated by includes), which means at start 48.000 db files and 48.000x4 = 192.000 DNSSEC key files(later when rotating keys it can be even more). It is probably acceptable when accessing db files, because I did not found any directory crawling here, but only from performance point of view, not from administrator's (backups/listing/quick fixes etc). I thing problem is in dnssec_keydir, becouse of way how keys are filtered(libknot/dnssec/zone-keys.c method knot_load_zone_keys) by name and included or removed from zone. Also as I understand updating(insert/delete inodes) large directories can harm performance of updating a lot. I think It will often block listing of files for key searching, slowdown parallel writing to directories etc. Also crawling large array for few keys for zone(192k lines for 4 files). Compare: one dnssec_keydir /data: list whole directory 192k for find 4 lines per zone dnssec_keydir /data/e/ex/exa/exam/example.com/K* (this structure is example and can be configurable by dnssec_keydir variable in zone, think of it as emulating some sort of binary tree): 6 x access to sub directory+ list only one directory for 4 lines (max 6-8 when rotating) I attached patch, which I believe solve this with little performance penalty and little more memory usage(only for those which want tree structure for example). About structure it should not be created on demand, but precreated by administrator/script . I believe it can save lots of time and disk io. At the end I may be totally wrong, I did not made any tests yet. Kamil -- Kamil Sopko Dodavatel technické podpory pro savana.cz s.r.o. Lounská 983/43, 405 02 Děčín VI-Letná Telefon: +420 478 472 100 Provozní doba: PO-PÁ 8-118 hod a SO-NE 9-12 hod Web: www.savana.cz

12 let, 1 měsíc

1
0
0 0

Knot DNS 1.4.0-rc1 is out!

by Jan Včelák

Hello list, some time has passed since the Knot DNS 1.4.0 beta release, and now we are proudly announcing the first release candidate! Thank you for all your notes and comments. We have fixed quite a lot of bugs and done some refactoring. But most of the efforts were put into stabilization of the automatic DNSSEC signing. There are still some issues that we are aware of, and we will fix those before gold release. But now is a perfect time to give Knot DNS 1.4 another shot! Your feedback is appreciated. Below is a list of significant changes since 1.4.0 beta: - refactored zone loading - improved journal locking - various fixes in client utilities - DNSSEC: fixed a lot of memory allocation errors - DNSSEC: improved logging (zone signing, key loading) - DNSSEC: key pre-publication is possible (uses timestamps in key file) - DNSSEC: presence of 'dnssec-keydir' config option does not enable signing - DNSSEC: improved scheduling of zone resigning Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-rc1.tar.xz.asc Best regards, Jan

12 let, 2 měsíce

1
0
0 0

Knot DNS 1.3.3 patch & 1.4.0 beta release

by Marek Vavruša

Hi Everyone, we're having a special release today. Two in one, so let's get to it briefly. First things is our first beta version ever released (did you know?). It is a sneak peek of one of the major features we are working on right now. That new thing is the automatic DNSSEC signing. While it is still an EXPERIMENTAL feature, we would like to encourage you to give it a try and let us know what you think, like or hate. This would help us immensely to change things when we still have time to do so, and iron out bugs before we bake a release candidate. The configuration is quite simple and can be found in the documentation. More so, we have written a short "how to" on our Wiki page here: https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-quickstart And the shortcomings here: https://gitlab.labs.nic.cz/labs/knot/wikis/dnssec-limitations All in all, it should be as simple as giving it a directory with keys and push the button. Is it really? A lot of changes happened under the bonnet as well (and some things still in progress!). Things like reduced memory usage, faster query processing, test modules and faster zone loading. But more on that in the final release when things settle down. Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.4.0-beta.tar.xz.asc Now back to the 1.3.3 patch release. It's probably tad less exciting, but fixes a few important bugs for example in query processing or notify messages being ignored in some cases. Also a few touch ups in the documentation and zone loading. Yet again, many thanks for the bugreports! As always, you can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.3.tar.xz.asc Best, Marek -- Marek Vavruša 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

8
22
0 0

Re: [knot-dns-users] Email lists available (1000)

by Jon Francis

12 let, 2 měsíce

1
0
0 0

Knot DNS, DNS UPDATE and OpenDNSSEC

by Matthias-Christian Ott

Hi, without DNS UPDATE OpenDNSSEC can be configured to read an unsigned zone file, sign it and reload the zone [1]. With DNS UPDATE it gets more complicated. It seems that you have to run a hidden primary that receives that updates and transfers the unsigned zones to OpenDNSSEC which in turn transfers the zones to a slave server. There are some alternatives if you manipulate zone files with custom scripts. While a hidden primary may be acceptable and zone transfers are probably the most reliable solution, it is an overkill for my use case and adds to much complexity. I could use Knot DNS to sign the zones, but it doesn't automate KSK rollovers and I need to execute a custom binary to update the keys at the registrar which is also not supported. Perhaps Knot DNS could remove all DNSSEC RRs before it transfers the zone to OpenDNSSEC, but it's kind of a hack and I'm not sure if this a good idea. OpenDNSSEC also delayed support for dynamic updates to 2.x, which means 2014 and or later. So this is not an option. Does anyone have suggestions to solve this problem? Regards, Matthias-Christian [1] http://www.bortzmeyer.org/opendnssec-nsd.html

12 let, 2 měsíce

6
9
0 0

Change on version statment

by Eric Kom

Hi, I am new on this list, and have just installed and start using Knot for the first time on freeBSD: #uname -r 10.0-BETA1 Look pretty nice and light. very close to Bind/Unix daemon configuration styles. After I have started the daemon, #knotd -d and check his status: #knotc status OK and check the version: #knotd -V Knot DNS, version 1.3.2 I tried to hide the version as above: # # This is a sample of a minimal configuration file for Knot DNS. # # For exhaustive list of all options see samples/knot.full.conf # in the source directory or refer to user manual. # system { # Identity of the server (see RFC 4892). ##identity on; ## version "My First Knot Config.."; # Version of the server (see RFC 4892) version on; # User for running server # May also specify user.group (e.g. knot.knot) user root.knot; # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage # storage "/usr/local/var/lib/knot"; # Directory for storing run-time data # e.g. PID file and control sockets # default: ${localstatedir}/run/knot, configured with --with-rundir # rundir "/usr/local/var/run/knot"; } interfaces { all_ipv4 { address 0.0.0.0; port 53; } all_ipv6 { address [::]; port 53; } } control { # Default: knot.sock (relative to rundir) listen-on "knot.sock"; # As an alternative, you can use an IPv4/v6 address and port # Same syntax as for 'interfaces' items # listen-on { address 127.0.0.1@5533; } # Specifies ACL list for remote control # Same syntax as for ACLs in zones # List of remotes or groups delimited by comma # Notice: keep in mind that ACLs bear no effect with UNIX sockets # allow server0, admins; } #remotes { # master0 { # address 198.51.100.1@53; # } # slave0 { # address 203.0.113.1@53; # } #} zones { # Example master zone # example.com { # file "/usr/local/etc/knot/example.com.zone"; # xfr-out slave0; # notify-out slave0; # } # # Example slave zone # example.net { # file "/usr/local/var/lib/knot/example.net.zone # xfr-in master0; # notify-in master0; # } } log { syslog { # log errors of any category any error; # for <category> and <severity> see above # log also warnings and notices from category 'zone' zone warning, notice; # log info from server server info; } # Log fatal, warnings and errors to stderr stderr { any error, warning; } After I have reloaded the daemon with: #knotc reload OK The version remain the same. Another question is, when I tried to run the command knotd -c knot.conf, I received errors as above: root@chris:/usr/local/etc/knot # knotd -c knot.conf 2013-10-25T19:46:00 Reading configuration '/usr/local/etc/knot/knot.conf' ... 2013-10-25T19:46:00 [error] Cannot bind to socket (errno 48). 2013-10-25T19:46:00 [error] Could not bind to UDP interface 0.0.0.0 port 53. 2013-10-25T19:46:00 [error] Cannot bind to socket (errno 48). 2013-10-25T19:46:00 [error] Could not bind to UDP interface :: port 53. 2013-10-25T19:46:00 [warning] Server started, but no zones served. and the errors makes me to pkill knot the process and start the daemon again. I my doing wrong? Sorry for the configuration statements in the mail. -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

12 let, 2 měsíce

2
1
0 0

Knot DNS 1.3.2

by Lubos Slovak

Hi there, 1.4.0 is nearly finished, but it will take some time until it's stable, so we fixed some minor issues in the current stable version and released 1.3.2. Now you can specify the max UDP payload to be used with EDNS0 in the configuration. We also fixed bug causing the max payload to limit also some TCP responses. Besides that, we fixed build on SLE 10 and a problem with reloading, when files included in configuration file were not closed. Everything is in its usual place: Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.2.tar.xz.asc Packages available at www.knot-dns.cz should be updated as well. Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

12 let, 3 měsíce

1
0
0 0

Knot DNS 1.3.1 patch release

by Marek Vavruša

Hi Everyone, while we are busy with the new stuff for the 1.4.0, we decided to backport a few important patches and release 1.3.1 as soon as possible. Feature wise, not much has changed - the ACLs are a little bit smarter and look for the longest address prefix match, but otherwise it's a patch only release. Namely a bug that caused a few extra bytes in an answer with NSID was fixed, also a potential interoperability issue with TSIG signature over multiple packets in zone transfers and TSIG key secret being wrongly parsed without quotes. As always, you can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.1.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. I wish you pleasant last bits of summer. Kind Regards, Marek -- Marek Vavruša 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, 4 měsíce

3
2
0 0

Knot-DNS port FreeBSD 9.1

by Robert Vojcik

Zdravim, mozno sa to uz tu riesilo. Planujete novu verziu 1.3.1 propagovat aj do FreeBSD portov ? Aktualne je tam verzia 1.3.0 rc1. Samozrejme je moznost si to skompilovat rucne, ale preferoval by som porty ak mate v plane ich udrzovat :) -- Robert

12 let, 4 měsíce

4
4
0 0

Duplicate CNAME output in kdig

by Erwin Lansing

I was just giving kdig and khost a spin, when I noticed some very long output for a simple query with khost. Looks like the aliases is expanded multiple times: erwin@panda:/home/erwin % khost www.droso.dk www.droso.dk. is an alias for koala.droso.dk. koala.droso.dk. has IPv4 address 213.239.220.246 www.droso.dk. is an alias for koala.droso.dk. koala.droso.dk. has IPv6 address 2a01:4f8:a0:7163::2 www.droso.dk. is an alias for koala.droso.dk. erwin@panda:/home/erwin % host www.droso.dk www.droso.dk is an alias for koala.droso.dk. koala.droso.dk has address 213.239.220.246 koala.droso.dk has IPv6 address 2a01:4f8:a0:7163::2 I would say once is enough :-) Cheers, Erwin -- Med venlig hilsen/Best Regards Erwin Lansing Network and System Administrator DK Hostmaster A/S Kalvebod Brygge 45, 3. sal 1560 København V Tlf. 33 64 60 60 Fax.: 33 64 60 66 Email: erwin(a)dk-hostmaster.dk Homepage: http://www.dk-hostmaster.dk .dk Danmarks plads på Internettet ------------------------------------------------------------------------- This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee please notify the sender immediately and delete this e-mail from your system. You are not permitted to disclose, distribute or copy the information in this e-mail. --------------------------------------------------------------------------

12 let, 5 měsíců

2
1
0 0

system.nsid reconfiguration bug

by Anand Buddhdev

Hello Knot developers, I'm trying out Knot 1.3.0 final, and testing the new options for system.identity, system.version and system.nsid. At first, I did this: system { identity yes; version yes; nsid yes; } The alert ones will note that I didn't use "on", but accidentally used "yes", so Knot parsed them all as strings, and gave me unexpected but correct results. ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt id.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15951 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 79 65 73 (y) (e) (s) ;; QUESTION SECTION: ;id.server. CH TXT ;; ANSWER SECTION: id.server. 0 CH TXT "yes" ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt version.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56914 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 79 65 73 (y) (e) (s) ;; QUESTION SECTION: ;version.server. CH TXT ;; ANSWER SECTION: version.server. 0 CH TXT "yes" Note that the NSID value is also "yes". So I realised my mistake, and changes the values from "yes" to "on", and HUPped the server. Now I get: ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt id.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27835 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: Messages has 7 extra bytes at end ;; QUESTION SECTION: ;id.server. CH TXT ;; ANSWER SECTION: id.server. 0 CH TXT "admin.authdns.ripe.net" ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.9.3-P2 <<>> +norec +nsid @193.0.0.198 ch txt version.server ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60856 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: Messages has 7 extra bytes at end ;; QUESTION SECTION: ;version.server. CH TXT ;; ANSWER SECTION: version.server. 0 CH TXT "Knot DNS 1.3.0" Note the warnings from dig about the extra bytes at the end. It seems that if you change the value of NSID and reconfigure the server, it does not appear to pick up the new value correctly. Stopping Knot completely and starting it fixes it, but there appears to be a bug during reconfiguration.

12 let, 5 měsíců

6
12
0 0

Výhodné nabídky ubytování v Chorvatsku

by Ubytování v Chorvatsku

12 let, 5 měsíců

1
0
0 0

Knot DNS v1.3.0 final!

by Marek Vavruša

Hi Everyone, as promised last week, I am proud to announce the 1.3.0 final is out! It's been a long release cycle since the last final release, but it brought lots and lots of bugfixes and a slew of new features. Let me reiterate briefly what's new since the 1.2.0 - one of the most visible features is the new zone file parser, which eliminated the whole zone compilation process and sped up both startup and preparation. There's also a magical configure option --enable-fastparser which makes it even faster (about 2x), very close to loading a binary zone. We also brought our own alternative to DNS utilities like dig, host and nsupdate which aim to be compatible with the ISC counterparts, but also bring some nimble enhancements like pretty comments and output for dig. No smaller are changes to the configuration. Features like groups of remotes, include in config, UNIX sockets for remote control, new knotc commands and general build scripts overhaul that make it nicer for the package maintainers and users. There also was a major refactoring effort under the bonnet (and more to come), which shows in a lower memory consumption, maintainability and trim code base. For many many more, check our web pages or have a look at the NEWS file for an exhaustive list of changes and bugfixes. Back on the ground, we fixed several bugs since rc5 last week. Namely answering from names at or below insecure delegation points, new defaults for CH TXT special zones, randomly disconnected transfers and secondary groups not being initialized when dropping privileges. Also the bootstrap retry timer is now progressive. Many thanks for Anand Buddhdev, Jonathan Hoppe, Johan Ihren, Erwin Lansing and many others who have sent constructive reports, ideas, encouragements and actual code (How cool is that?). As always, you can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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, 5 měsíců

2
1
0 0

Knot DNS 1.3.0-rc5

by Marek Vavruša

Hi, as the 1.3.0 final release is coming out next monday, we would like you to check if everything works for you. There are three major fixed bugs - interrupts during AXFR bootstrap, which is now miles faster for a large number of zones. Also support for obsolete record types in zone transfers. And finally, out of zone records are now discarded during zone transfer, but the transfer as a whole is accepted. There is a new known issue, in which slave zone transfer fails to reschedule. We haven't been able to reproduce that, so if you experience this, please let us know. You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc5/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc5.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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, 5 měsíců

3
8
0 0

knotc doesn't wait with "-w"

by Anand Buddhdev

Hello Knot developers, I'm testing 1.3.0-rc4, and have found something that looks like a bug. I'm running knot using the CentOS upstart supervisor, and in the upstart script, I have: pre-stop exec knotc -c $CONF -w stop This means that when I run "initctl stop knot", upstart will run "knotc -c /etc/knot/knot.conf -w stop". The "-w" is supposed to make knotc wait until the server has stopped. However, in reality this is not happening. When the stop command is given, Knot logs this: 2013-07-17T22:48:23 Stopping server... 2013-07-17T22:48:23 Server finished. 2013-07-17T22:48:23 Shut down. And knotc returns *immediately*. However, if I examine the process table, I see the knotd process still running. It takes knotd about 10 more seconds to actually exit, at 22:48:33. This is problematic for upstart. Since knotc has returned, but the knotd process hasn't yet died, upstart thinks that it has not responded to the stop request, and so upstart uses the sledgehammer (kill -9) to stop the knotd process. My assumption is that the knotd process is still doing housekeeping stuff, so the KILL signal is not a good idea. By the looks of it, the "-w" flag to knotc isn't doing what it's supposed to, ie. wait for the server to exit. Could you please investigate this and fix it? (As an aside, I can work around this in upstart by using the option "kill timeout 60" which will make upstart wait at least 60 seconds before trying a KILL signal, by which time knotd should have exited. But this is just a work-around, not a solution). Regards, Anand Buddhdev RIPE NCC

12 let, 6 měsíců

2
3
0 0

Knot DNS 1.3.0-rc4

by Marek Vavruša

Hi there, it seems like we're on streak of fixing stuff this summer, so we have a new fourth release candidate! Main reason is, that we wanted to address two major issues before the 1.3.0 goes golden. First one is a performance regression with AXFR bootstrapping, which also failed to reschedule the request at some points of failure. This should be now fixed with a small but neat performance boost thanks to asynchronous mode of connecting. Second major bug was a RRSIG ending up in a wrong section in an answer to a DS query. After a bit of a discussion, we have decided to reintroduce the 'pidfile' config option and also a new '--with-configdir' configure option to set the default config file directory, which now defaults to $(sysconfdir)/knot. Huge thank you goes to Jonathan Hoppe and Erwin Lansing for bugreports! You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc4/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc4.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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, 6 měsíců

2
1
0 0

各个费用

by 张经理

我司有商品销售、广告、建筑安装、服务业、租赁影视制作、培训咨询、网络服务、翻译、印刷会务会议、餐饮住宿、材料、文化娱乐、道路交通国际运输、增值税、海关等票.收费合理为客户节省运作成本提供优质服务. 联系电话：13430930130 业务QQ：780215123 联系人：张经理注；可验证后付款顺祝商祺

12 let, 6 měsíců

1
0
0 0

Listening on IPv6 address

by Leoš Bitto

Hello, it seems that knotd suffers from the same issue as described here: http://lists.scusting.com/index.php?t=msg&th=244420 I have Debian 7.0 with http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-i386/net/knot_1.2.0-… and this is in /var/log/syslog after reboot: Jun 3 22:37:43 ns knot[2091]: Binding to interface 2xxx:xxxx:xxxx:xxxx::1 port 53. Jun 3 22:37:43 ns knot[2091]: [error] Cannot bind to socket (errno 99). Jun 3 22:37:43 ns knot[2091]: [error] Could not bind to UDP interface 2xxx:xxxx:xxxx:xxxx::1 port 53. I have a static IPv6 address configured in /etc/network/interfaces. Restarting knot later binds to this IPv6 address without any problem - it is only the first start which fails (during OS booting). What do you think that is the proper way of making knotd reliably listen on a static IPv6 address? I would prefer if I could avoid restarting knotd. Leos Bitto

12 let, 6 měsíců

2
6
0 0

obsolete rundir

by jh＠netriplex.com

Hello Knot folks: The 'rundir' obsoletes 'pidfile' config option, as the PID file will always be placed in 'rundir'." This is cool, unless you want to run multiple instances of KNOT on a single machine. Can you reconsider this? Jonathan

12 let, 6 měsíců

3
2
0 0

Bootstraping issue in 1.3

by jh＠netriplex.com

Hello KNOT folks, We've found an issue 1.3 with bootstrapping. We're using FreeBSD 9.x, but we also quickly confirmed it exists on Ubuntu 12.x to confirm it was not isolated to FreeBSD. We're testing with about 3000 to 4000 zones, so our environment is not even very large at this point and the bootstrapping failures are very problematic. There are three causes that we've seen thus far: 1. If the AXFR TCP connect is interrupted by a signal, the whole AXFR is aborted and the bootstrap is rescheduled instead of selecting on the socket to either get the successful connection, or until it times out/fails. This can result in a flood of connects, with little to no progress in the bootstrapping. 2. When connected, if a recv() is interrupted by a signal, it isn't retried. This results in connections being dropped that don't need to be dropped. 3. If a successful connect is made, but the remote end subsequently drops it (e.g., resets the connection), then the bootstrap fails without being rescheduled. This was found when slaving from a non-KNOT DNS server that may have TCP rate limiting enabled, or something of that nature. Either way, the fact that it is not rescheduled is very undesirable. I suspect that there are other cases of interrupted system calls not being handled correctly. Here is some additional info that may help find the root cause: - The greater the latency between the master and slave, the worse the problem is. We tested with a slave 80 ms RTT away and it was very bad. - The more worker threads you have, the worse the problem is. So even locally (slave 0 ms away from master) we could reproduce the issue fairly easily. Hopefully this can be remedied! Cheers, Jonathan

12 let, 6 měsíců

2
1
0 0

Knot 1.3.0-rc3 bug report

by Anand Buddhdev

Hi Knot people, I've been trying out rc3, and I've found a few issues, as documented below: 1. In the knotc man page, the "-s" option shows the default as @rundir@/knot.sock. I guess that should have been substituted with the compile-time setting, but wasn't. 2. knotc start doesn't do anything now. It should be removed. 3. knotc restart only stops the server, but does not start it. It should be removed. 4. When configured as a slave, and Knot receives a zone via AXFR containing the following record: <owner-obscured>. 86400 IN TXT "Alliance Fran\195\167aise de Kotte" it serves this record correctly when queried over DNS: dig @a.b.c.d +norec +short txt <owner-obscured>. "Alliance Fran\195\167aise de Kotte" But when saving the zone to disk, this record gets written out as: <owner-obscured>. 86400 IN TXT "Alliance Fran\4294967235\4294967207aise de Kotte" So when Knot restarts and tries to load this zone, it gives an error: Error in zone file /var/lib/knot/XX:4875: Number is bigger than 8 bits. 5. I have configured Knot to log to the file /var/log/knot/knot.log. Most logging goes into it. However, some error messages are still leaking into syslog, for example, the following appears in both Knot's log file, as well as in /var/log/messages (via syslog): logfile: 2013-06-28T20:17:25 [error] Incoming AXFR of 'XX.' with 'a.b.c.d@53': General error. /var/log/messages: Jun 28 20:17:25 admin knot[1630]: [error] Incoming AXFR of 'XX.' with 'a.b.c.d@53': General error. I would expect Knot to send logging to syslog only while it is starting, and it hasn't setup its logging to file yet. Once logging to a file has started, there should be no more logs to syslog, so this looks like a bug, albeit harmless. That's about it for Friday evening :) Regards, Anand Buddhdev RIPE NCC

12 let, 6 měsíců

2
1
0 0

Knot DNS v1.3.0-rc3 released!

by Marek Vavruša

Hi Everyone, I'm happy to announce the third and probably last release candidate for Knot DNS 1.3.0 is out there! This release candidate is a bit special to us, featuring not only a slew of bugfixes but also introducing a new feature. Quite a lot of you asked for a tool to estimate memory consumption for given zone, this is now a new action 'memstats' available in knotc utility. The usage is quite similar to the 'checkzone' command, but it prints out estimated memory consumption instead. You can also pick specific zones if you like. Second quite substantial change is deprecation of 'knotc start'. The preferred method of startup is now using knotd directly, optionally with -d flag for running in background. Also, knotd doesn't create PID files when running in foreground. This is to play nice with managed init scripts and to be able to write out PID atomically. On top of that, you can also alter default 'storage' and 'rundir', see ./configure --help for that. The 'rundir' obsoletes 'pidfile' config option, as the PID file will always be placed in 'rundir'. Third and last substantial change is that knotc now uses UNIX sockets by default and is also now a preferred mode of operation, although IP sockets are still supported. We believe this is safer for now, as the control protocol is not encrypted. It is also enabled by default, to disable control interface completely, add an empty control section to the configuration. But of course, being a release candidate, we didn't forget to pack in a bugfixes. Namely processing of IXFR with a lot of serial changes, processing of TSIG keyfile in knotc and a couple performance regressions related to zone transfers. Big thanks for numerous hours of testing and witty feedback for this release goes to Anand Buddhdev, thank you! You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc3.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Kind regards, Marek -- Marek Vavruša 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, 6 měsíců

2
1
0 0

DNSSEC implementation survey

by Ondřej Surý

[sorry for cross-post, please don't cross-post when replying] Hi, we are currently implementing DNSSEC in Knot DNS and we would like to gather opinions on this topic. I think we have all have more experience of DNSSEC deployment now and it would be very valuable for us to gather that experience and forge an implementation that would be liked by the users. Could you please spare a few minutes and fill a little survey of ours on this topic? https://docs.google.com/forms/d/1gS-Z1NAL78oFOU51HR6jmg-ZkAevU2CrvCHQgrNnXL… If you don't want to give your answers to NSA :), you can reply to this email (the Reply-To is set to knot-dns-users(a)lists.nic.cz), or just send the feedback back to me. Thank you very much, 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/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

12 let, 7 měsíců

1
0
0 0

PID files are passé

by Anand Buddhdev

Dear knot users/developers, I'm testing Knot 1.3.0-rc2. One issue I've run into is when knot exits uncleanly. In this case, it leaves its PID file behind in /var/lib/knot/knot.pid. On the following attempt to start knot, it sees the PID file, and refuses to start, so I have to remove the stale PID file by hand. If I run knot under a supervisor, such as upstart, then it tries to run knot, fails, tries again rapidly in succession, and eventually gives up, at which point knot isn't running. My first observation is that in cases where knot is running under a supervisor, the PID file is not necessary. The supervisor knows knot's PID, and can signal it directly (to reload, or stop). Could you consider making the PID file optional? As in, if in knot.conf, I have: pidfile ""; then knot should not attempt to write (or read or delete) a PID file at all. Alternatively, could you make knot a bit smarter so that if it detects a PID file at startup, but that PID is either not in use, or the process using it is not knot, then it should remove the PID file? Without either of these possibilities, I have to add logic in my startup scripts or supervisor scripts to remove any stale PID files. If I only had one instance of knot, I could do that simply with "rm -f /var/lib/knot/knot.pid", but I'd like to run multiple instances of knot, and so I would have multiple PID files, whose locations I would have to extract from the config file first in order to delete them reliably. This starts to get hairy... I hope I have made a reasonable case for providing an option to not record a PID file, or clean up one before starting. My preference is for the first option, ie. not writing a PID file. Regards, Anand Buddhdev RIPE NCC

12 let, 7 měsíců

3
8
0 0

Knot DNS 1.3.0-rc2 released

by Marek Vavruša

Hi, this is hopefully a last release candidate before the final goes out. Thanks to a massively helpful feedback, we've tackled a few issues from the first rc, namely a name compression-related bug, proper resolution of some CNAME chain loops and a couple log messages and minor annoyances. Also a small sneak peek, as to what can you expect in the final release. Upon several requests, we will add a new (sort of) feature - a memory requirements estimation tool. This should give you a rough idea about how much memory you need to load the zones or for transfers. If you have any special experience about the memory requirements of 1.3.0-rc1, please let us know, this would be immensely helpful to fine tune the estimates. Thanks again for support and very constructive remarks and questions! You can find the full changelog at: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc2.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Enjoy the weekend, Marek -- Marek Vavruša 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, 7 měsíců

3
2
0 0

Estimating Knot's memory usage

by Anand Buddhdev

Dear Knot developers, I'm testing Knot 1.3.0-rc1 now. One of the things I'd like to be able to do is to estimate Knot's memory usage without actually loading all my zones into it (because if it runs out of memory it will be killed). One very crude way was to load a single zone from a plain text zone file, and comparing the memory used by knot with the size of the zone on disk. For a zone of size 229MB, knot is using about 1.3GB of RAM. So I could say that knot wants about 6x as much RAM for each zone. Is this a reasonable asumption? Alternatively, since you know how knot uses memory for a zone, are you able to provide a small program which can read zones one at a time, calculate the RAM required for each zone, and then print a summary of the total RAM required to load all those zones into knot? We frequently get questions from our users along the lines of "I'd like you to slave this new zone" or "we are going to sign this zone; will your server be able to load it?" It would help an operator immensely if he can get an estimate of the additional RAM required. Regards, Anand Buddhdev RIPE NCC

12 let, 7 měsíců

2
3
0 0

Semantic check warning with wildcard

by Anand Buddhdev

Our BIND server slaves a zone which has the following record (I have replaced the actual TLD with placeholders): *.XX. 60 IN CNAME SERVER.SLD.XX. BIND loads this zone without complaining. However, knot 1.3.0-rc1 refuses to load this zone with the following error: 2013-06-07T13:53:50 [warning] Semantic warning in node: *.XX.: CNAME: CNAME cycle! 2013-06-07T13:53:50 [error] Semantic check found fatal error on line=10 2013-06-07T13:53:54 [error] Zone could not be loaded (-9992).2013-06-07T13:53:54 [error] Zone XX. could not be loaded. As a side note, it looks like there's a newline missing somewhere, because two log lines have appeared on a single line. And what's the -9992 in brackets? Regards, Anand

12 let, 7 měsíců

2
1
0 0

Loaded -12 out of 0 zones?

by Anand Buddhdev

Testing knot 1.3.0-rc1, I'm seeing a strange message in the log if I start it without defining any zones: 2013-06-07T10:44:13 Binding to interface 127.0.0.1 port 5353. 2013-06-07T10:44:13 Configured 1 interfaces and 0 zones. 2013-06-07T10:44:13 2013-06-07T10:44:13 Changing group id to '10073'. 2013-06-07T10:44:13 Changing user id to '10073'. 2013-06-07T10:44:13 Loading 0 zones... 2013-06-07T10:44:13 Loaded -12 out of 0 zones. 2013-06-07T10:44:13 [warning] Not all the zones were loaded. 2013-06-07T10:44:13 Starting server... 2013-06-07T10:44:13 Server started in foreground, PID = 10514 2013-06-07T10:44:13 PID stored in /var/lib/knot/knot.pid 2013-06-07T10:44:13 [warning] Server started, but no zones served. Notice the "-12 out of 0 zones.". Bug? Anand

12 let, 7 měsíců

2
1
0 0

Knot DNS 1.3.0-rc1 is out!

by Marek Vavruša

Hi everyone, we've been very busy for the last couple months, and I'm glad to let you know, that the Knot DNS v1.3.0 first release candidate is finally out! This is a feature-full release, packing a lot of new stuff and improvements. The major change since 1.2.0 is the zone compilation, which is now deprecated and zone files are parsed directly on startup. This was made possible with the new zone file parser, which is neck to neck in terms of speed with whole parsing to loading a precompiled zone. So no more 'compile' steps. Configuration file is also improved with the handy 'group' keyword, that allows you to make groups of remotes and also a support to include another part of config file. This is useful for example if you want to store keys elsewhere. We also now support queries to pseudo CH zone (RFC4892 style), so that is configurable as well (we support identity, version and hostname). On the backend part, we have overhauled several internal structures to lower memory consumption and improved speed and scheduling of zone transfers. Log messages for those are improved as well, giving a more verbose overview of what was transferred, which serial and how long. Apart from that, there are a lot of smaller performance improvements, revamped build system and a lot of small details. For example zone files written out on slave contain a source address, time and other useful information. See NEWS or gitlog for more details. Last new (sort of) feature is, that we included our own DNS tools. Namely kdig, khost and knsupdate. They are quite compatible with BIND9 tools, but they also bring several improvements in logging, prettified output and checks. Be sure to check them out. We also had a terrific user feedback, thanks to Erwin Lansing, Anand Buddhdev, Jan-Piet Mens and everyone for the reports. So that's mostly it! For a full overview of changes see: https://gitlab.labs.nic.cz/knot/blob/v1.3.0-rc1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.bz2 https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.bz2.asc https://secure.nic.cz/files/knot-dns/knot-1.3.0-rc1.tar.xz.asc Packages available at www.knot-dns.cz will be updated soon as well. Kind regards, Marek -- Marek Vavruša 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, 7 měsíců

1
0
0 0

Question about recursion

by Joerg Stephan

Hey guys, i am currently playing around with some dns solutions, currently its knot :-) Is there any solution for recursion. I would like to add an powerdns server to any node which could do lookups for new zones while the configfile isnt written. As you may know registrys like denic are using realtime checks while ordering a domain. Regards Joerg

12 let, 8 měsíců

3
3
0 0

knot 1.2.0 dropping privileges too early

by Erwin Lansing

Thanks for the 1.2.0, some really nice features in there. I especially like the zonestatus command. I have one problem though. It seems that knot drops its root privileges too early, before trying to bind to the interface. Configured with: system { user bind.bind }; Results in: Apr 23 12:26:26 l knot[25585]: [error] Could not bind to UDP interface 127.0.0.1 port 53. Apr 23 12:26:26 l knot[25585]: [error] Could not bind to UDP interface ::1 port 53. Changing to root.bind, makes it work, hence my guess it's related to dropping privileges. This is on FreeBSD 9.0. Any hints appreciated. Best, Erwin -- Med venlig hilsen/Best Regards Erwin Lansing Network and System Administrator DK Hostmaster A/S Kalvebod Brygge 45, 3. sal 1560 København V Tlf. 33 64 60 60 Fax.: 33 64 60 66 Email: erwin(a)dk-hostmaster.dk Homepage: http://www.dk-hostmaster.dk .dk Danmarks plads på Internettet ------------------------------------------------------------------------- Dette er en e-mail fra DK Hostmaster A/S. Denne e-mail kan indeholde fortrolig information, som kun er til brug for den tiltænkte modtager. Hvis du ved en fejl har modtaget denne e-mail, bedes du venligst straks give afsenderen besked om dette og slette e-mailen fra dit system uden at offentliggøre, videresende eller tage kopi af meddelelsen. This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee please notify the sender immediately and delete this e-mail from your system. You are not permitted to disclose, distribute or copy the information in this e-mail. --------------------------------------------------------------------------

12 let, 9 měsíců

2
4
0 0

Debian repository

by Igor Živković

Hello, I can't access your deb packages: W: Failed to fetch http://deb.knot-dns.cz/debian/dists/wheezy/main/source/Sources 403 Forbidden [IP: 81.91.84.116 80] W: Failed to fetch http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-amd64/Packages 403 Forbidden [IP: 81.91.84.116 80] Could you please check it out? -- Igor Živković

12 let, 9 měsíců

2
1
0 0

Query timeout when testing

by jh＠netriplex.com

Hi, We're using the latest version 1.2.0 after updating from 1.1.0. It seems that when we run a dnsperf against it, we now get many query timeouts. It isn't that we're overloading the server, because we can run a 2nd server with dnsperf and get similar throughput (22k qps) but it too has query timeouts of about just under 1%. This seemed like maybe it was the response rate limiting, but it says it is off by default. To be sure, I set the parameter in the config to be off. Am I missing something? Is there something else I need to turn off? Thanks for any guidance anyone can provide! Jonathan

12 let, 9 měsíců

2
2
0 0

Knot DNS 1.2.0 final is out!

by Marek Vavruša

Hello everyone, we're happy to announce that the Knot DNS 1.2.0 final is out after the fourth release candidate. Just to reiterate what's new and fixed in the 1.2.0, we brought 3 new features in the 1.2.0. First is a support for dynamic updates (DDNS) including forwarding to the primary master, which received a couple of bugfixes in the early release candidates. Since the third release candidate there is a Response Rate Limiting as a new way to combat increasing amplification/reflection attacks. It's been slightly reworked since the release candidate and disabled by default. You can enable it by setting 'rate-limit' config option to a sensible value. Last feature is a reworked control utility which is now able to control the daemon remotely and even introduced a few new commands, namely 'zonestatus' to fetch the status of served zones. Aside from the new features, it also fixes a few bugs. Namely missing RRSIGs in the response to the ANY type, processing of some malicious domain names and a detection of broken implementation of recvmmsg() on some Linux distributions. As usual, you can find a full list of changes at https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0/e… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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, 9 měsíců

1
0
0 0

Knot DNS 1.2.0-rc4 released

by Marek Vavruša

Hi everyone, as an outcome of the discussions on the RRL mailing lists and a stellar feedback in recent weeks, we have decided to slip yet another release candidate before the 1.2.0 finally goes out. The release candidate features a reworked classification in RRL in respect to the RRL technical memo and also includes code to resolve hash collisions in the former implementation. Also a new 'zonestatus' command was introduced to knotc and a several bugs were fixed, namely logfile ownership problems, faster rate of SOA queries on refresh and knotc respecting 'control' section in configuration. As usual, you can find a full list of changes at https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0-r… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc4.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc4.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Have a nice weekend, Marek -- Marek Vavruša 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, 10 měsíců

1
0
0 0

Knot memory usage

by Anand Buddhdev

On a server with 16 GB of RAM, my instance of BIND can load my 5174 zones into memory and use around 13 GB. Knot didn't do so well. At some point while trying to XFR-in these zones, it hit the memory limit and the Linux out-of-memory killer came along and killed it. When I started it up again, it began loading zones in from the disk, but then appeared to go into some kind of loop, and the CPU usage was 100%. This is usually a sign that it is stuck in some kind of loop or deadlock. The only want to stop it is with a KILL signal (TERM doesn't work). The log didn't output anything. How can I help debug this? Do you have any numbers on how much RAM Knot will require given a bunch of zones? This would allow me to estimate how much RAM I will need in a server for the zones I have. Regards, Anand

12 let, 10 měsíců

3
5
0 0

Query logging

by jh＠netriplex.com

Hello, Is there any existing functionality to log queries? I've enabled all existing logging for the "answer" category and do not see any. But maybe it is unsupported in version 1.1.0? log { syslog { answering all; } } Thanks, Jonathan

12 let, 10 měsíců

5
7
0 0

Documentation nits

by Jan-Piet Mens

Hello, I'd like to mention a few nits about Knot's documentation, if you don't mind. :) 1. Docs linked to from https://www.knot-dns.cz/documentation.html have URLs which don't look permanent; this makes it difficult to link to individual pages. It would be better imo, to have permanent URIs. 2. The usage message for [knotc flush] says "Flush journal and update zone files.". I understand this to mean zones that have received updates (RFC2136) will be written out, but this doesn't occur. I note zones are written out only at the end of a `zonefile-sync' period. 3. ixfr-from-differences, while documented in the manual, points to 'Controlling running daemon', but it doesn't say there, that the syntax is 'on/off'. Enabling this in zones {} doesn't seem to do anything here: I was expecting to see a "*.ixfr" or some such file containing diffs, but I get none; neither for incoming xfr, nor for DNS updates. 4. Docs specify in 'Controlling running daemon' there is a knotc option -a, but the code doesn't have that: knotc: invalid option -- 'a' Same for 'Running Knot DNS' chapter. Regards, -JP

12 let, 10 měsíců

3
2
0 0

knotc refresh speed

by jh＠netriplex.com

Hello, Yesterday I had Knot 1.1.0 installed and with 4000 test zones on a slave server configuration, a knotc refresh would hit my master to check SOA on all zones very quickly (I would see over 600 queries per second). It could generally complete the task in well under 60 seconds. Today I have upgraded to 1.2.0-RC3 and with the same 4000 test zones on a slave server configuration a knotc refresh is extremely slow. It issues SOA queries to the master at about 10 queries per second. Why this change? Is there any setting I can implement to speed this up? In a production environment with 250k+ zones, this obviously won't work. Thanks! Jonathan

12 let, 10 měsíců

3
2
0 0

No response via UDP

by Jan-Piet Mens

Hello, I'm pretty sure I have tomatoes (or other vegetables) on my eyes, but Knot won't answer UDP queries here, running on Centos 6.3 in an OpenVZ container. This is the minimal configuration and the results I'm seeing: $ knotc -V Knot DNS, version 1.2.0-rc3 $ cat knot.sample.conf system { identity "knot 1.2-rc2"; storage "/etc/knot"; } interfaces { my-iface { address 127.0.0.1@53; } } zones { example.com { file "example.com.zone"; } } log { syslog { any info, debug, notice, warning, error; } } $ knotc -c knot.sample.conf start 2013-03-11T18:07:44.244202+01:00 Starting server... 2013-03-11T18:07:44.244337+01:00 Zone 'example.com.' is up-to-date. $ netstat -anp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 11408/knotd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 486/sshd tcp 0 0 172.16.153.104:22 172.16.153.1:64881 ESTABLISHED 554/sshd tcp 0 0 :::22 :::* LISTEN 486/sshd udp 0 0 127.0.0.1:53 0.0.0.0:* 11408/knotd unix 2 [ ] DGRAM 8840414 11408/knotd $ dig @127.0.0.1 example.com any ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> @127.0.0.1 example.com a ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached $ dig +tcp @127.0.0.1 example.com a ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> +tcp @127.0.0.1 example.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20248 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;example.com. IN A ;; AUTHORITY SECTION: example.com. 60 IN SOA localhost. root.localhost. 1997022700 28800 14400 3600000 86400 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Mar 11 18:08:32 2013 ;; MSG SIZE rcvd: 79 Mar 11 18:07:44 knot knot[11408]: Binding to interface 127.0.0.1 port 53. Mar 11 18:07:44 knot knot[11408]: Configured 1 interfaces and 1 zones. Mar 11 18:07:44 knot knot[11408]: Mar 11 18:07:44 knot knot[11408]: Loading 1 compiled zones... Mar 11 18:07:44 knot knot[11408]: Loaded zone 'example.com.' serial 1997022700 Mar 11 18:07:44 knot knot[11408]: Loaded 1 out of 1 zones. Mar 11 18:07:44 knot knot[11408]: Starting server... Mar 11 18:07:44 knot knot[11408]: Server started as a daemon, PID = 11408 Mar 11 18:07:44 knot knot[11408]: PID stored in /etc/knot/knot.pid Can you please help me open my eyes? Thanks, -JP

12 let, 10 měsíců

2
6
0 0

debug code compile failure

by Anand Buddhdev

I thought I'd enable debugging code to try and figure out why the server goes into a loop. So I added the following to configure: --enable-debug=server,zones,xfr,packet,dname,rr,ns,hash,compiler,stash However, Knot doesn't compile now. The compile fails with: ... ... libknot/packet/packet.c: In function 'knot_packet_parse_question': libknot/packet/packet.c:311: error: 'bp' undeclared (first use in this function) libknot/packet/packet.c:311: error: (Each undeclared identifier is reported only once libknot/packet/packet.c:311: error: for each function it appears in.) If I remove the packet debug option, I can compile Knot again. Regards, Anand

12 let, 10 měsíců

4
9
0 0

Bootstrapping lots of slave zones

by Anand Buddhdev

Hello Knot developers, I configured an instance of Knot 1.2.0rc3 with 5174 slave zones, and started it. I wanted to see how long it would take to transfer all the zones in. It has been running for about an hour, and it still hasn't managed to load all the zones from its master. I'll pick just one zone as an example to show how long it took: # grep apnic.net /var/log/knot/knot.log 2013-03-09T00:50:19.361489-00:00 Will attempt to bootstrap zone apnic.net. from AXFR master in 37s. 2013-03-09T01:06:31.330875-00:00 Will attempt to bootstrap zone apnic.net. from AXFR master in 35s. 2013-03-09T01:16:19.741644-00:00 Incoming AXFR transfer of 'apnic.net.' with '193.0.0.198@53' key 'ripencc-20110222.': Started. 2013-03-09T01:16:35.282203-00:00 Will attempt to bootstrap zone apnic.net. from AXFR master in 52s. 2013-03-09T01:52:16.477212-00:00 Will attempt to bootstrap zone apnic.net. from AXFR master in 37s. 2013-03-09T01:56:02.806828-00:00 Will attempt to bootstrap zone apnic.net. from AXFR master in 13s. 2013-03-09T01:57:00.901518-00:00 Incoming AXFR transfer of 'apnic.net.' with '193.0.0.198@53' key 'ripencc-20110222.': Started. 2013-03-09T01:57:01.096493-00:00 Incoming AXFR transfer of 'apnic.net.' with '193.0.0.198@53' key 'ripencc-20110222.': Finished. >From the time Knot decided it needed to bootstrap apnic.net, to the time it actually transferred the zone in, it took 67 minutes! All that while, it was responsing with SERVFAIL for the zone. While the zone "apnic.net" has now been loaded, Knot is still busy loading many of the other zones. I can't tell how far it is. Perhaps there could be a command for knotc, called "zonestatus" which would print out a list of all configured zone, and their statuses. I understand that transferring in lots of zones takes time. However, if I start an instance of BIND with the same slave zones, it can transfer them all in within about 15-20 minutes. Knot appears to be much slower in comparison. Do you have any suggestions for speeding things up? Regards, Anand

12 let, 10 měsíců

3
4
0 0

knotc not reading control options from config file

by Anand Buddhdev

Hello Knot developers, I'm testing the use of multiple instances of Knot on the same server. For this simple test, I have two configurations, A.conf and B.conf, as follows. Note that I'm bind the control interface to two different ports. A.conf: ... ... interfaces { a { address A; } } remotes { ctl { address 127.0.0.1; } } control { listen-on { address 127.0.0.1@5553; } allow ctl; } B.conf: ... ... interfaces { b { address B; } } remotes { ctl { address 127.0.0.1; } } control { listen-on { address 127.0.0.1@5554; } allow ctl; } I then start both instances: knotd -c A.conf knotd -c B.conf Now, if I run "knotc -c A.conf reload" then the A instance reloads, as I expect. However, if I run "knotc -c B.conf reload", then it is still the A instance that reloads. The only way I can get the B instance to reload is to run "knotc -p 5554 reload". This is not what I expected. I expected that if I give knotc a configuration file, then it will use the address and port numbers in there, so that it can signal the correct instance of Knot. In comparison, the upcoming NSD4 *does* do this. It has an "nsd-control" command, and if I give it a configuration file as a parameter, then it uses the control port settings from that file to signal the appropriate instance of NSD, and not just the default one. Would you consider getting knotc to also behave the way nsd-control does? After all, knotc *does* read some configuration from the file, so ideally it should also read the control section and use the appropriate address and port numbers from there. Regards, Anand Buddhdev RIPE NCC

12 let, 10 měsíců

2
1
0 0

Log file ownership

by Anand Buddhdev

Dear Knot developers, I've been playing with Knot version 1.2.0-rc3, and run into a small issue. Apologies if it has already been reported. I'm using a configuration like this: system { ... ... user knot.knot; } log { file "/var/log/knot/knot.log" { ... } } When I start Knot, it starts running as root, and creates the file /var/log/knot/knot.log, as root. It then switches to the non-privileged user "knot". Now it can no longer continue writing to the log file. Could you please add some code (to go before it changes the UID) to change the ownership of the log file to the user it is about to switch to? Regards, Anand

12 let, 10 měsíců

3
3
0 0

syslog server?

by jh＠netriplex.com

Hello, Is there any plan to add the ability to allow logging to a syslog server vs. a log file? Regards, Jonathan

12 let, 10 měsíců

2
4
0 0

Log messages leaking to syslog

by Anand Buddhdev

I've configured Knot 1.2.0-rc3 to log to a file with this: log { file "/var/log/knot/knot.log" { any debug, info, notice, warning, error; } } However, some log messages are appearing in /var/log/messages via syslog, for example: Mar 9 11:51:37 ams3 knot[30177]: [error] Incoming AXFR transfer of '0.0.0.0.a.2.ip6.arpa.' with '193.0.0.198@53' key 'ripencc-20110222.': Zone transfer refused by the server. Looks like some parts of Knot are not honouring the file log option. Regards, Anand

12 let, 10 měsíců

1
0
0 0

Plain text copy of zone files

by Anand Buddhdev

Hello Knot developers, I've added some zones to my Knot configuration like this: zones { example.com { file example.com; xfr-in master; notify-in master; } } After Knot has started up, I see the following files in the storage directory: example.com example.com.db example.com.db.crc example.com.diff.db I see that Knot keeps a copy of the zone in a compiled form. Why does it also dump the plain text zone? This would be okay for a small number of zones, but if I want to load a few thousand zones, then all those plain text copies of the zone files will take up unnecessary space on the disk. I tried to turn off the plain text copy by removing the "file example.com" config line, but then Knot created a file called "example.com..zone" (yes, with two dots) to keep a plain text copy of the zone anyway. Is it possible to turn off this plain text dump of the zone? Regards, Anand

12 let, 10 měsíců

1
0
0 0

Knot DNS 1.2.0-rc3 release

by Marek Vavruša

Hi everyone, I'm happy to announce that the 3rd and hopefully final release candidate of Knot DNS 1.2.0 is out! This one not only brings a few bugfixes, but also a new feature. The hot topic of the day - Response Rate Limiting, based on the work of Vernon Schryver and Paul Vixie (http://www.redbarn.org/dns/ratelimits). If you're not familiar with the topic, it is a way to combat DNS amplification and reflection attacks. General idea is to identify flows in outgoing responses and block responses exceeding the rate limit. To get at least some degree of service for victims a mechanism called SLIP is used, causing each Nth blocked response to be sent as truncated, thus enabling legitimate requests to reconnect over TCP. You can enable rate limiting by setting option "rate-limit" to a value greater than 0, for example: system { rate-limit 100; } For more about rate limiting knobs, refer to the documentation or a sample configuration. Any feedback is more than welcome before it lands in the final version! As usual, you can find a full list of changes at https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2.0-r… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc3.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2.0-rc3.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Have a nice weekend, Marek -- Marek Vavruša 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, 10 měsíců

1
0
0 0

Knot DNS v1.2-rc2

by Marek Vavruša

Hi everyone, it's been a while since the first release candidate was released. For the last few days, we've been busy testing, ironing out encountered bugs and polishing. We fixed a few issues related mainly to DDNS parsing code and processing of some non-standard domain names. As for every release candidate, all users of 1.2rc1 are recommended to update. If everything goes smooth, we'll have a final release shortly. Thanks everyone for a feedback related to last release! You can find a full list of changes at https://redmine.labs.nic.cz/projects/knot-dns/repository/revisions/v1.2-rc2… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2-rc2.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2-rc2.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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, 11 měsíců

1
0
0 0

Single address limitation per interface and remote server

by Matthias-Christian Ott

I just successfully migrated a several zones from NSD to Knot DNS. The migration was straightforward and quick, but I limiting the number of addresses per interface and remote server to one doesn't make sense to me especially with dual stack hosts. This is more intuitive to me in NSD. What is the rationale behind the current syntax? Regards, Matthias-Christian

12 let, 12 měsíců

2
1
0 0

Knot DNS 1.2-rc1 finally out!

by Marek Vavruša

Hi Everyone, we're proud to announce, that release candidate for the next major release 1.2 is out! Apart from a couple bugfixes, it features full DDNS support (including update forwarding). There are a few limitations related to DNSSEC-signed zones, please refer to user manual for more information. Access control for dynamic updates could be configured in a similar fashion to transfers, using the 'update-in' keyword. Next major thing is an updated remote control tool. Basic commands for start/stop/restart/compile and checks are the same as they were, but the command for refresh/flush/status could be executed remotely given the right configuration. You can enable remote control interface with a new config section 'control', f.e.: control { listen-on { address 127.0.0.1@5553; } allow remote0; } You can also specify a remote with associated TSIG key for security reasons. Knot control tool then accepts host, port and TSIG key as a parameter, f.e.: $ knotc -s 127.0.0.1 -p 5553 status Key could be also specified in a file instead of a command line parameter. But that is just a tip of the iceberg. For more smaller features, like configurable TCP timeouts or LOC support, refer to RELNOTES and a user documentation. RELNOTES: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.2-rc1/… Sources: https://secure.nic.cz/files/knot-dns/knot-1.2-rc1.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.2-rc1.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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

13 let

4
6
0 0

knot performace?

by AndyChen

Hi, does the knot have performance test, if have, wuold you give the report? Best wishes!

13 let

2
2
0 0

Knot DNS 1.1.3 just released!

by Marek Vavruša

Hi everyone, it's been two weeks since the rc1 was released, and I'm happy to announce, that the Knot DNS 1.1.3 is finally out! The release candidate fixed a couple issues related to answering DS queries, parsing of improper zone files and a wrong ARCOUNT in some error responses when EDNS0 was enabled. As for every bugfix release, we recommend all 1.1.2 users to update, even if no new features were added. Enjoy and have a merry Christmas. Full list of changes is at https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.1.3/en… Sources: https://secure.nic.cz/files/knot-dns/knot-1.1.3.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.1.3.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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

13 let, 1 měsíc

1
0
0 0

Knot DNS 1.1.3-rc1 released

by Lubos Slovak

Hi, we've recently fixed some issues in Knot DNS, mainly answering to DS queries (thanks to reports by Phil Regnauld, Casey Deccio and Erwin Lansing!). Other fixes are listed here: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.1.3-rc… After the usual one week, the final 1.1.3 will be released. Sources: https://secure.nic.cz/files/knot-dns/knot-1.1.3-rc1.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.1.3-rc1.tar.gz.asc Packages at www.knot-dns.cz will be updated ASAP. Meanwhile, we're still working on 1.2 which is a bit delayed - dynamic updates are giving us a hard time. But we're doing our best to release it before Christmas. Regards, Lubos

13 let, 1 měsíc

1
0
0 0

Knot DNS 1.1.2 final is out!

by Marek Vavruša

Hi, we are announcing that Knot DNS 1.1.2 is finally out! The release candidate from last week fixed a crash with duplicate zone names and slave zones not refreshing properly. Since then, we fixed debug build. As this is a bugfix release, we strongly recommend all 1.1.1 users to update, even if no new features were added. Enjoy! Full list of changes is at https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.1.2/en… Sources: https://secure.nic.cz/files/knot-dns/knot-1.1.2.tar.gz GPG signature: https://secure.nic.cz/files/knot-dns/knot-1.1.2.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Cheers, Marek -- Marek Vavruša 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

13 let, 2 měsíce

1
0
0 0

Bugfix release Knot DNS v1.1.2-rc1

by Lubos Slovak

Hi, we've recently corrected two issues: the server crashed when trying to reload configuration with duplicate zones and zone transfers scheduling was broken, causing sometimes (but very rarely) some zones not to be synced with master properly, so we are releasing the fixed version right away. Sources of this version are here: http://public.nic.cz/files/knot-dns/knot-1.1.2-rc1.tar.gz GPG signature: http://public.nic.cz/files/knot-dns/knot-1.1.2-rc1.tar.gz.asc Final v1.1.2 will be released in a week. Kind regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 2 měsíce

1
0
0 0

Knot DNS 1.1.1 is out

by Lubos Slovak

Hello, final release 1.1.1 of Knot DNS was just released. We just fixed one small bug since last week's release candidate. Now should be stable. Enjoy and stay tuned for version 1.2, which should be out in late November and will bring the long desired support for Dynamic Updates and some other improvements! Kind regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 2 měsíce

1
0
0 0

Knot DNS v1.1.1-rc1

by Lubos Slovak

Hello, a bugfix release of Knot DNS is out (v1.1.1-rc1). We're releasing it as a release candidate in order to get the fixes to you as soon as possible. Proper release will follow in a week. We've fixed some crashes, TSIG algorithm name comparison and improved compression. For full list of changes see RELNOTES in the source directory or here: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.1.1-rc… The sources are available in the usual place: http://public.nic.cz/files/knot-dns/knot-1.1.1-rc1.tar.gz GPG signature: http://public.nic.cz/files/knot-dns/knot-1.1.1-rc1.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 3 měsíce

1
0
0 0

Problem with UDP queries

by Eduardo Duarte

Hello, I have setup a KNOT dns server but I'm having troubles with the UDP queries. The server is not answering to the UDP queries but it is answering to queries in TCP. The server is running on a CentOS release 6.3 (Final) and the configuration file is the following. *************knot.conf*********** system { identity "Yet.another.server"; nsid "Yet.another.server"; storage "/opt/knot_run/knot-minimal"; pidfile "/opt/knot_run/knot.pid"; user root; } interfaces { ipv4 { address 127.0.0.1@53; } ipv4 { address 193.137.197.25@53; } } remotes { ns-test01 { address 193.136.192.86@53; } ns-test02 { address 193.136.192.87@53; } ns-test03 { address 193.137.196.30@53; } ns-test04 { address 193.137.196.31@53; } } zones { zonetest-01.dns.pt { file "/opt/knot_run/zones/zonetest01"; xfr-in ns-test01; notify-in ns-test01; } zonetest-06.dns.pt { file "/opt/knot_run/zones/zonetest06"; } } log { file "/opt/knot_run/log/knot.log" { any all; } } ********************************** The output of the log file is ********knot.log****************** 2012-09-17T10:25:40.208574+01:00 Stopping server... 2012-09-17T10:25:40.210677+01:00 Server finished. 2012-09-17T10:25:40.211260+01:00 Shut down. 2012-09-17T10:25:40.230967+01:00 Binding to interface 127.0.0.1 port 53. 2012-09-17T10:25:40.231283+01:00 Binding to interface 193.137.197.25 port 53. 2012-09-17T10:25:40.232162+01:00 Loading 2 compiled zones... 2012-09-17T10:25:40.233783+01:00 Loaded zone 'zonetest-01.dns.pt.' 2012-09-17T10:25:40.237553+01:00 Loaded zone 'zonetest-06.dns.pt.' 2012-09-17T10:25:40.238983+01:00 Loaded 2 out of 2 zones. 2012-09-17T10:25:40.239044+01:00 Configured 2 interfaces and 2 zones. 2012-09-17T10:25:40.239078+01:00 2012-09-17T10:25:40.239111+01:00 Starting server... 2012-09-17T10:25:40.240688+01:00 Server started as a daemon, PID = 8599 2012-09-17T10:25:40.240772+01:00 PID stored in /opt/knot_run/knot.pid ********************************* And an example of the query's ********************************* [root@ns-test06 ~]# dig @127.0.0.1 zonetest-06.dns.pt +tcp ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.1 <<>> @127.0.0.1 zonetest-06.dns.pt +tcp ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;zonetest-06.dns.pt. IN A ;; ANSWER SECTION: zonetest-06.dns.pt. 3600 IN A 193.137.196.42 ;; AUTHORITY SECTION: zonetest-06.dns.pt. 3600 IN NS ns-test01.dns.pt. zonetest-06.dns.pt. 3600 IN NS ns-test02.dns.pt. zonetest-06.dns.pt. 3600 IN NS ns-test03.dns.pt. zonetest-06.dns.pt. 3600 IN NS ns-test04.dns.pt. zonetest-06.dns.pt. 3600 IN NS ns-test06.dns.pt. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Sep 17 10:25:49 2012 ;; MSG SIZE rcvd: 202 [root@ns-test06 ~]# dig @127.0.0.1 zonetest-06.dns.pt ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.1 <<>> @127.0.0.1 zonetest-06.dns.pt ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ********************************* Can anyone help me with this problem? Best regards, -- Eduardo Duarte SIT-DNS DNS.PT - https://www.dns.pt/ FCCN - http://www.fccn.pt/

13 let, 4 měsíce

3
3
0 0

Cannot use unknown RRtypes in Knot?

by Paul Hoffman

Greetings. This seems a bit odd. I have a zone file with: ===== $TTL 6 test79.example.com. IN SOA foo.example.com. dns.test79.example.com. ( 201209150 5m 1m 2w 5m ) test79.example.com. IN NS foo.example.com. test79.example.com. IN TYPE79 \# 4 deadface ===== Trying to compile it gives: ===== Parsing file '/home/dns/Files/foo.conf', origin 'test79.example.com.' ... /home/dns/Files/foo.conf:4: error: bad unknown RDATA Parser finished with error, not dumping the zone! error: Compilation of 'test79.example.com.' failed, knot-zcompile return code was '1' ===== This zone file works fine in BIND, NSD, and PowerDNS. It seems that either Knot cannot use the standard mechanism for defining unknown RRtypes (RFC 3597), or it maybe has a different syntax. Clues are appreciated. --Paul Hoffman

13 let, 4 měsíce

2
1
0 0

Knot controlled by multiple users

by Peter Andreev

Hi! I run Knot with option apn@knot-test:/home/apn>grep user /usr/local/etc/knot/knot.conf user bind.dns; apn@knot-test:/home/apn>ps uaxww | grep knot bind 9925 0.0 0.8 33760 8736 ?? Ss 4:03PM 0:00.07 /usr/local/sbin/knotd -d -c /usr/local/etc/knot/knot.conf apn@knot-test:/home/apn>knotc -V Knot DNS, version 1.1.0-rc2 apn@knot-test:/home/apn>uname -a FreeBSD knot-test.local 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Everything is fine except for one: I can't control Knot via knotc under my account and have to raise my privileges. apn@knot-test:/home/apn>knotc running 2012-09-03T17:33:20.801730+04:00 Using '/usr/local/etc/knot/knot.conf' as default configuration. 2012-09-03T17:33:20.802876+04:00 Server PID not found, probably not running. 2012-09-03T17:33:20.803099+04:00 [warning] PID file is stale. apn@knot-test:/home/apn>knotc reload 2012-09-03T17:57:01.706820+04:00 Using '/usr/local/etc/knot/knot.conf' as default configuration. 2012-09-03T17:57:01.707934+04:00 [warning] Server PID not found, probably not running. apn@knot-test:/home/apn>knotc refresh 2012-09-03T17:57:11.314605+04:00 Using '/usr/local/etc/knot/knot.conf' as default configuration. 2012-09-03T17:57:11.315736+04:00 [warning] Server PID not found, probably not running. I believe that is because of using of kill(2) in pid_running(). So I'm wondering how unprivileged user can send commands to Knot? Thanks in advance. -- AP

13 let, 4 měsíce

2
1
0 0

Knot DNS v1.1.0 released!

by Lubos Slovak

Dear users, we proudly announce the release of Knot DNS 1.1. During last months we perfected many Knot DNS' features, did lots of testing, fixed all revealed bugs and improved the performace in many ways. Since RC2 we just fixed syncing of journal to zone, which didn't update the compiled database, just the text zone file. For the list of all important changes, please see RELNOTES either in the source directory, or online: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.1.0/en… Here are the source files: http://public.nic.cz/files/knot-dns/knot-1.1.0.tar.gz and GPG signature of the tarball: http://public.nic.cz/files/knot-dns/knot-1.1.0.tar.gz.asc Packages will be available soon on http://www.knot-dns.cz. Regards, Lubos

13 let, 4 měsíce

1
0
0 0

Knot DNS v1.1.0-rc2

by Lubos Slovak

Hi, second Release Candidate of Knot DNS 1.1 is out now. We slightly improved and fixed the user manual, fixed two minor bugs: - generating journal for IXFR when the zone contains IPSECKEY and APL records in binary format, - possible leak on server shutdown with a pending transfer and fixed the behaviour of slave server using TSIG. It did not sign SOA queries to master, causing it to fail the zone version check when talking to Bind with allow-query configured to use TSIG key. Source files are available here: http://public.nic.cz/files/knot-dns/knot-1.1.0-rc2.tar.gz GPG signature: http://public.nic.cz/files/knot-dns/knot-1.1.0-rc2.tar.gz.asc Packages will be updated soon at the usual place on http://www.knot-dns.cz. Please provide us with any feedback before the final 1.1 release next week. Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 5 měsíců

1
0
0 0

Knot DNS v1.1.0-rc1

by Lubos Slovak

Dear Knot DNS users, we've just released a Release Candidate of Knot DNS 1.1. The new version brings a lot of enhancements and bugfixes which improve stability and interoperability of Knot DNS. It also contains a complete User manual for easier deployment. The manual can be either built from the sources ('make pdf' or 'make html'), or accessed online via Knot DNS website (http://www.knot-dns.cz). Here are some highlights of changes in the new version: - Improved speed of incoming IXFR even more. - Optimized loading of many zones. - Option to disable authoritative ANY answers as a mitigation to recent DDoS reflection attacks. - Fixed some problems and leaks cased if an IXFR transfer failed (e.g. because of malformed data). - Improved malformed packet parsing and handling. - Fixed answering in some special cases. We also implemented an option to generate zone differences from zone reload and using them for IXFR journal. Thus Knot DNS may serve as IXFR primary master (until now, it needed to obtain the differences by a transfer from some other master). However, this feature is only experimental, so use it with care. We do not guarantee that the results will be always good or that it won't compromise the stability of the server. For full list of changes see RELNOTES in the source directory or here: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.1.0-rc… Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-1.1.0-rc1.tar.gz GPG signature: Packages will be available soon on http://www.knot-dns.cz. Kind regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 5 měsíců

2
2
0 0

DNS test suite - list of non-standard DNS queries

by Petr Spacek

Hello list, I found an article http://blog.nic.cz/2012/07/19/zavazna-vzdalena-zranitelnost-v-dns-serveru-n… which mentions "list of non-standard DNS queries" for test purposes. Is it possible to obtain this list and related tools? I looked into latest Knot sources tarball and I found nothing :-) I'm developer of BIND 9 plugin and I want to explore and re-use mentioned tests for configurations with this plugin (https://fedorahosted.org/bind-dyndb-ldap/). I'm not a member of knot-dns-users list, please add me to Cc in reply. Thanks for your time. -- Petr Spacek Red Hat Czech

13 let, 5 měsíců

1
0
0 0

Using Knot in dual stack environment

by Ondřej Caletka

Hi, I am having difficulties running knot on an dualstack host. I want Knot to listen on all IPv4 and all IPv6 interfaces. I am using this interfaces section in config file: interfaces { allv4 { address 0.0.0.0; } allv6 { address [::]; } } Using this config, Knot listens only on v4 address and gives an error binding the v6 address: 2012-07-27T13:21:44.646094+02:00 Binding to interface 0.0.0.0 port 53. 2012-07-27T13:21:44.646197+02:00 [error] Cannot bind to socket (98). 2012-07-27T13:21:44.646233+02:00 [error] Could not bind to TCP interface :: port 53. 2012-07-27T13:21:44.646240+02:00 Binding to interface :: port 53. Changing interface order the other way around results in listening on v6 only with same error, yet also v4 connections are accepted, probably due to IPV6_V6ONLY socket option not being turned on by Knot. When I tried changing listening port on either line, problem disappeared. I am using Debian package, version 1.0.6-1~bpo60+1. Cheers, Ondřej Caletka

13 let, 5 měsíců

2
2
0 0

Problem instaling KNOT

by Eduardo Duarte

Hello, I'm new to KNOT and I'm trying to install it on a CentOS 6.3 (Final) minimal install, I already updated openssl to the newest version and install all the pre-requirements but when I run make command I get the following error: ************************* BINDIR=\"/usr/local/sbin\" -g -O2 -fpredictive-commoning -I/usr/local/include -mmmx -msse -msse2 -msse3 -MT journal.lo -MD -MP -MF .deps/journal.Tpo -c knot/server/journal.c -fPIC -DPIC -o .libs/journal.o In file included from knot/server/journal.c:26: ./common/crc.h:30:18: error: zlib.h: No such file or directory In file included from knot/server/journal.c:26: ./common/crc.h: In function 'crc_init': ./common/crc.h:49: warning: implicit declaration of function 'adler32' make[2]: *** [journal.lo] Error 1 make[2]: Leaving directory `/root/knot-1.0.6/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/knot-1.0.6/src' make: *** [all-recursive] Error 1 ************************* Can any of you guys help me? Best regards, -- Eduardo Duarte SIT-DNS DNS.PT - https://www.dns.pt/ FCCN - http://www.fccn.pt/

13 let, 6 měsíců

3
4
0 0

Fwd: Re: Fail to serve RFC 2317-ish zone

by Lubos Slovak

Sorry, didn't send it to the list before.. L. -------- Original Message -------- Subject: Re: [knot-dns-users] Fail to serve RFC 2317-ish zone Date: Wed, 04 Jul 2012 15:12:59 +0200 From: Lubos Slovak <lubos.slovak(a)nic.cz> To: Koh-ichi Ito <kohi(a)kkdlabs.jp> Hi there, thanks for the report! It's true that Knot DNS actually imposes quite rigid rules to domain names. We will probably change that in future. But we forgot about the RFC 2317 case, so thanks once more for the notice. Will add support for / in domain names in the next release - that should suffice. Regards, Lubos On 07/04/2012 12:48 PM, Koh-ichi Ito wrote: > Dear team, > > I found that Knot DNS v1.0.6(from tarball) fails to serve > RFC 2317-ish zone, 32/27.2.0.192.in-addr.arpa, in this case. > > -----[ knot.conf ]------------------------------------------ > system { > storage "/proj/knot-dns/var"; > } > zones { > 32/27.2.0.192.in-addr.arpa { > file "/proj/dns/etc/namedb/32_27.2.0.192.in-addr.arpa"; > } > } > > -----[ zone data ]------------------------------------------ > $TTL 1d > $ORIGIN 32/27.2.0.192.in-addr.arpa > @ IN SOA ns.example1.jp. hostmaster.example1.jp. ( > 2012070401 > 20m > 15m > 4w > 15m ) > NS ns.example1.jp. > > -----[ The result ]----------------------------------------- > kohi@lars[1]% /usr/bin/sudo /proj/knot-1.0.6/sbin/knotc -c /proj/knot-dns/etc/knot-2317.conf checkzone 32/27.2.0.192.in-addr.arpa > [sudo] password for kohi: > 2012-07-04T19:47:33.287327+09:00 [error] Config '/proj/knot-dns/etc/knot-2317.conf' - syntax error on line 5 (current token '32'). > 2012-07-04T19:47:33.287980+09:00 [error] Failed to parse configuration '/proj/knot-dns/etc/knot-2317.conf'. > kohi@lars[2]% > ------------------------------------------------------------ > > Thanks in advance. > > Koh-ichi Ito > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 6 měsíců

1
0
0 0

Web frontend?

by Alvaro Pinel

Hi, Is there any frontend for knotdns? We have different kind of users and for non technicians is more difficult to manage from command line. ¡Thanks!

13 let, 6 měsíců

2
1
0 0

cpu_set_t causes compile error on FreeBSD 8.3

by Koh-ichi Ito

Hello team, I experienced the following compile error while installing knot-1.0.6(tarball from WWW site) on FreeBSD 8.3. % make Making all in src make all-am /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Wall -Ilibknot -DLIBEXECDIR='"/pub/knot-1.0.6/libexec"' -DSYSCONFDIR='"/pub/knot-1.0.6/etc"' -DSBINDIR='"/pub/knot-1.0.6/sbin"' -I/pub/include -I/usr/local/include -mmmx -msse -msse2 -msse3 -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c -o utils.lo `test -f 'libknot/util/utils.c' || echo './'`libknot/util/utils.c : : libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Wall -Ilibknot -DLIBEXECDIR=\"/pub/knot-1.0.6/libexec\" -DSYSCONFDIR=\"/pub/knot-1.0.6/etc\" -DSBINDIR=\"/pub/knot-1.0.6/sbin\" -I/pub/include -I/usr/local/include -mmmx -msse -msse2 -msse3 -MT dthreads.lo -MD -MP -MF .deps/dthreads.Tpo -c knot/server/dthreads.c -fPIC -DPIC -o .libs/dthreads.o knot/server/dthreads.c: In function 'dt_setaffinity': knot/server/dthreads.c:864: error: 'cpu_set_t' undeclared (first use in this function) knot/server/dthreads.c:864: error: (Each undeclared identifier is reported only once knot/server/dthreads.c:864: error: for each function it appears in.) knot/server/dthreads.c:868: warning: implicit declaration of function 'pthread_setaffinity_np' knot/server/dthreads.c:868: error: expected expression before ')' token *** Error code 1 Stop in /u1/share/pub/src/knot-dns/knot-1.0.6/src. *** Error code 1 Stop in /u1/share/pub/src/knot-dns/knot-1.0.6/src. *** Error code 1 Stop in /u1/share/pub/src/knot-dns/knot-1.0.6. As an ad-hoc workaround, the following trial works fine. % cd src % mv config.h config.h.ORG % cp config.h.ORG config.h % ed config.h 10154 /HAVE_PTHREAD_SETAFFINITY_NP #define HAVE_PTHREAD_SETAFFINITY_NP 1 s/^#define/#undef/ s/ 1$// p #undef HAVE_PTHREAD_SETAFFINITY_NP s/^#define/#undef/ s/ 1$// p #undef HAVE_PTHREAD_SETAFFINITY_NP w 10151 q % diff -u config.h.ORG config.h --- config.h.ORG 2012-06-30 14:56:16.000000000 +0900 +++ config.h 2012-06-30 15:08:09.000000000 +0900 @@ -107,7 +107,7 @@ #define HAVE_PSELECT 1 /* Define to 1 if you have the `pthread_setaffinity_np' function. */ -#define HAVE_PTHREAD_SETAFFINITY_NP 1 +#undef HAVE_PTHREAD_SETAFFINITY_NP /* Define to 1 if you have the `regcomp' function. */ #define HAVE_REGCOMP 1 % cd .. As long as invoke via knotc and easy query via dig, the result binary seems to work fine. Thanks in advance -- kkdlabs.jp, featuring Koh-ichi Ito as just another DNS freak in town.

13 let, 6 měsíců

2
2
0 0

origin doesn't taken from knot.conf

by Koh-ichi Ito

Hello again. Here's another one. I noticed that zone data contains relative notation such as '@' but no $ORIGIN causes error. knotc checkzone says: ----- kohi@lars[1]% /usr/bin/sudo /proj/knot-1.0.6/sbin/knotc checkzone example1.jp [sudo] password for kohi: 2012-07-04T19:52:19.603883+09:00 Using '/proj/knot-dns/etc/knot.conf' as default configuration. 2012-07-04T19:52:19.615871+09:00 [error] /proj/dns/namedb/example1.jp:3: @ used, but no $ORIGIN specified. 2012-07-04T19:52:19.631618+09:00 [error] /proj/dns/namedb/example1.jp:11: Zone file does not contain SOA record! ----- And knotc compile says: ----- kohi@lars[2]% /usr/bin/sudo /proj/knot-1.0.6/sbin/knotc compile 2012-07-04T19:54:02.023025+09:00 Using '/proj/knot-dns/etc/knot.conf' as default configuration. 2012-07-04T19:54:02.039299+09:00 Parsing file '/proj/dns/namedb/example1.jp', origin 'example1.jp.' ... 2012-07-04T19:54:02.051637+09:00 [error] /proj/dns/namedb/example1.jp:3: @ used, but no $ORIGIN specified. 2012-07-04T19:54:02.052790+09:00 [error] /proj/dns/namedb/example1.jp:11: Zone file does not contain SOA record! 2012-07-04T19:54:02.053653+09:00 [error] Compilation of 'example1.jp.' failed, knot-zcompile return code was '1' ----- It complains even though it knows that "origin 'example1.jp.' ...". Is this behavior by design policy? Or I wish it to be enhanced. Best regards, Koh-ichi Ito

13 let, 6 měsíců

4
6
0 0

pidfile empty when running as unpriviliged user

by Tom Hendrikx

Hello, Yesterday I replaced one of my authoritative servers with knot 1.0.5 (previously powerdns). I am already delighted by the simplicity of knot, so thank you for a nice piece of software. I tried some configurations and noticed that I was unable to correctly run as an unprivileged user. It seems that the problem is: - start knotd as root.root - create empty pidfile (owned by root.root) - drop privileges to user 'knot.knot' - write pid to pidfile (and fail doing so) - log error: 2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Failed to create PID file '/var/lib/knot/knot.pid'. 2012-06-11T22:23:06+02:00 julie knot[31184]: Server started as a daemon, PID = 31184 2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Server running without PID file. When stopping knotd later on, the following is logged, and knotd does not stop running. 2012-06-11T22:23:38+02:00 julie knot[31210]: [warning] Server PID not found, probably not running. I guess that either the pid file need to be chowned to the unprivileged user before privileges are dropped, or the pid needs to be written to the file earlier. Note that the file *is* created (despite the error messages saying something else), but it is empty. Kind regards, Tom

13 let, 6 měsíců

2
6
0 0

Fail to serve RFC 2317-ish zone

by Koh-ichi Ito

Dear team, I found that Knot DNS v1.0.6(from tarball) fails to serve RFC 2317-ish zone, 32/27.2.0.192.in-addr.arpa, in this case. -----[ knot.conf ]------------------------------------------ system { storage "/proj/knot-dns/var"; } zones { 32/27.2.0.192.in-addr.arpa { file "/proj/dns/etc/namedb/32_27.2.0.192.in-addr.arpa"; } } -----[ zone data ]------------------------------------------ $TTL 1d $ORIGIN 32/27.2.0.192.in-addr.arpa @ IN SOA ns.example1.jp. hostmaster.example1.jp. ( 2012070401 20m 15m 4w 15m ) NS ns.example1.jp. -----[ The result ]----------------------------------------- kohi@lars[1]% /usr/bin/sudo /proj/knot-1.0.6/sbin/knotc -c /proj/knot-dns/etc/knot-2317.conf checkzone 32/27.2.0.192.in-addr.arpa [sudo] password for kohi: 2012-07-04T19:47:33.287327+09:00 [error] Config '/proj/knot-dns/etc/knot-2317.conf' - syntax error on line 5 (current token '32'). 2012-07-04T19:47:33.287980+09:00 [error] Failed to parse configuration '/proj/knot-dns/etc/knot-2317.conf'. kohi@lars[2]% ------------------------------------------------------------ Thanks in advance. Koh-ichi Ito

13 let, 6 měsíců

1
0
0 0

Knot DNS on Google+

by Ondřej Surý

Hi all, we have created page for Knot DNS on Google+ [1]. We will try to use that channel for communicating short interesting stuff from the development. You will not be bored, we promise :) 1. https://plus.google.com/u/0/111568815130451558383/posts Feel free to join the channel and/or spread the word around. 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/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

13 let, 7 měsíců

1
0
0 0

Knot DNS v1.0.6

by Lubos Slovak

Hi, another bugfix release of Knot DNS is out. This one corrects behaviour with wildcard CNAMEs, when DNSSEC is requested (some NSECs/NSEC3s were missing) and fixes some potential problems from incorrect use of RCU synchronisation. The sources are available here: http://public.nic.cz/files/knot-dns/knot-1.0.6.tar.gz GPG signature: http://public.nic.cz/files/knot-dns/knot-1.0.6.tar.gz.asc Packages available at www.knot-dns.cz will be updated soon as well. We are planning another release soon, with a lot of improvements and small fixes in answers. Also we found out that the IXFR is still quite slow with too many changes (more than 50 000 RRs changed) and are working on that as well. Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 7 měsíců

1
0
0 0

Knot DNS hotfix

by Lubos Slovak

Dear Knot DNS users, yesterday's release contained an ugly bug that caused Knot not to create journal files, which lead to IXFR being non-functional at all. We are very sorry for this and immediately released a hotfix marked as 1.0.5. Please, download the fixed version here: http://public.nic.cz/files/knot-dns/knot-1.0.5.tar.gz GPG signature: http://public.nic.cz/files/knot-dns/knot-1.0.5.tar.gz.asc Packages will be updated soon as well. With regards and apologies, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 8 měsíců

1
0
0 0

Documentation?

by Johan Ihrén

Hi, While knot seems to work fine for me given my testing sofar I would like to see the full documentation. In the man pages there is this reference: The full documentation for Knot is maintained as a Texinfo manual. If the info and Knot programs are properly installed at your site, the command info Knot should give you access to the complete manual. I know what info is, but where is the actual texinfo file? I cannot find it in the distribution. Regards, Johan

13 let, 8 měsíců

2
2
0 0

KnotDNS 1.0.4

by Lubos Slovak

Hello, after some time, we are finally releasing version 1.0.4 of Knot DNS. However, we hope the improvements we made are worth the waiting. First of all, we sped up incoming IXFR processing A LOT. Also memory consumption of the processing is slightly improved. Besides, we addressed some bugs reported by our users and made some other improvements. To name a few: - Parallel loading of zones to the server. - Support for TLSA (RR type 52). - knotc checkzone (as a dry-run of zone compile). - knotc refresh for forcing Knot to update all zones from master servers. - Copying OPCODE and RD bit from query to NOTIMPL responses. - Fixed crash when NS or MX points to an alias. For full list of changes see RELNOTES in the source directory or here: https://git.nic.cz/redmine/projects/knot-dns/repository/revisions/v1.0.4/en… Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-1.0.4.tar.gz Packages will be available soon on http://www.knot-dns.cz Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labshttp://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email:lubos.slovak@nic.cz WWW:http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign athttp://thinkBeforePrinting.org

13 let, 8 měsíců

1
0
0 0

thoughts

by Mathieu Arnold

Hi, After moving one of my authoritative nameservers from bind to nsd, I thought why not migrate another one to knot, it seems nice... :-) So, I started writing a small script to output the knot conf bits I needed only to find out that I can't find a way to do includes, like I do with bind or nsd. What's the usual way to do that kind of things ? Is it possible to have more than one keys, remotes and zones sections ? Regards, -- Mathieu Arnold

13 let, 8 měsíců

3
4
0 0

Knot DNS v1.0.3

by Lubos Slovak

Dear users, we have just released a hotfixed version of Knot DNS. These last changes address several issues: - The last release slowed down the compilation a lot, due to some changes in underlying code. This has been improved, so that the compilation should be as fast as before. - It turned out that Knot DNS was applying ENDS0 UDP payload limit also to TCP queries - we are sorry for such a bug, it should be OK now. - Besides, a missing include for FreeBSD was added and a potential crash with many concurrent transfers was fixed too. Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-1.0.3.tar.gz Packages will be available soon on http://www.knot-dns.cz Next version is due to be released in a short time, featuring support for new RR type TLSA (52). Enjoy! Lubos

13 let, 9 měsíců

2
2
0 0

Knot 1.0.1 starting problem.

by Peter Andreev

Hello, list! I encountered a problem when I tried to start Knot on FreeBSD 8.0. When I tried start from rc.d script, Knotc freezed for 5 minutes until I killed it. When I tried "knotc start" nothing happened. And when I tried start directly knotd, the following was happened: dnssec-slave2# knotd -c /srvs/knot/etc/knot.conf Reading configuration '/srvs/knot/etc/knot.conf' ... Assertion failed: (knot_node_new_node(knot_dname_node(dname)) != NULL), function xfrin_switch_node_in_dname_table, file libknot/updates/xfr-in.c, line 2264. Abort -- AP

13 let, 9 měsíců

2
3
0 0

Knot DNS 1.0.2

by Lubos Slovak

Hi, another release of Knot DNS is out. Beside some small fixes we improved configuration options, log messages and slightly optimized overall performance. For all changes made, see RELNOTES in the source directory. Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-1.0.2.tar.gz Packages will be available soon on http://www.knot-dns.cz Kind regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labshttp://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email:lubos.slovak@nic.cz WWW:http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign athttp://thinkBeforePrinting.org

13 let, 9 měsíců

2
1
0 0

Knot DNS now in FreeBSD ports

by Leo Vandewoestijne

Hello knotty people ;) Both userspace-rcu and knot are now in the FreeBSD ports collection. http://www.freshports.org/dns/knot/ -- Met vriendelijke groet, With kind regards, Leo Vandewoestijne.

13 let, 10 měsíců

2
1
0 0

Crashing Knot 1.0.1

by Sebastian Castro

Hi: I'm trying to test Knot 1.0.1 with a basic configuration, and I managed to crash it. Compiled from source on a Ubuntu 11.04, serving one signed zone. uname -a Linux turista 2.6.38-13-generic-pae #55-Ubuntu SMP Tue Jan 24 15:54:51 UTC 2012 i686 i686 i386 GNU/Linux autoreconf -if ./configure --prefix=/opt/knot make sudo make install The configuration file looks like this system { identity "knot 1.0.1"; storage "/opt/knot/var/knot"; } interfaces { my-iface { address 192.168.22.152@53; } } zones { co.nz { file "/opt/knot/etc/co.nz"; } } log { syslog { any warning, error; } } Then root@turista:/opt/knot# sbin/knotc -c etc/knot.conf compile Parsing file '/opt/knot/etc/co.nz', origin 'co.nz.' ... Compilation successful. root@turista:/opt/knot# sbin/knotc -c etc/knot.conf -i start control: Running in interactive mode. Reading configuration '/opt/knot/etc/knot.conf' ... And when I send a query to the server dig dnskey co.nz @192.168.22.152 I get this in syslog Mar 15 17:00:44 turista kernel: [1487877.778230] knotd[6010]: segfault at 0 ip (null) sp b489e03c error 14 in knotd[8048000+50000] The error is consistent. If I restart the server, wait a little bit to load, and then send the query, it crashes. Running under gdb provides the following backtrace (gdb) bt #0 0x00000000 in ?? () #1 0x0804f2d4 in udp_master_recvmmsg (thread=0x850b5f0, thread_stat=0x0) at knot/server/udp-handler.c:427 #2 0x0804f6f6 in udp_master (thread=0x850b5f0) at knot/server/udp-handler.c:526 #3 0x08085adc in thread_ep (data=0x850b5f0) at knot/server/dthreads.c:160 #4 0xb7e56e99 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #5 0xb7d999ee in clone () from /lib/i386-linux-gnu/libc.so.6 If you need anything else, please let me know. Unfortunately I can't send you the zone. Cheers, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

13 let, 10 měsíců

1
0
0 0

Bugfix release of Knot DNS

by Lubos Slovak

Hi, a bugfix release of Knot DNS was made today. Some minor bugs were fixed and some simple features added. Here are some of the changes: - Implemented jitter to REFRESH/RETRY timers - Problem with creating IXFR journal for bootstrapped zone - Race condition in processing NOTIFY/SOA queries - TSIG improper assignment of algorithm type For all changes made since the last release, see RELNOTES in the source directory. Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-1.0.1.tar.gz Packages will be available shortly on http://www.knot-dns.cz Have a nice weekend! Regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 10 měsíců

1
0
0 0

knotc compile/reload

by Jan-Piet Mens

Hello, Congratulations to the release of Knot 1.0 which I'm looking at a bit now, starting off with a minimal configuration. system { storage "/etc/knot"; user: "root"; } interfaces { ipv4 { address 127.0.0.1@53; } } keys { my-key hmac-md5 "xxxx"; } remotes { local0 { address 127.0.0.1; } mastr { address 192.168.1.145; } m2 { address 192.168.1.53; key my-key; } } zones { example.com { file "example.com.zone"; } inline.aa { file "inline.aa"; semantic-checks off; xfr-in mastr; notify-in mastr; } jpmens.net { file "jpmens.net"; semantic-checks off; xfr-in m2; notify-in m2; xfr-out local0; } } Apologies for nitpicking on these rather cosmetic issues, but maybe they can be addressed in a future version: An invocation of `knotc -c knot.conf compile' complains that slave zone files don't (yet) exist. (True enough: they haven't yet been transferred): Zone file 'inline.aa' doesn't exist. Zone file 'jpmens.net' doesn't exist. Parsing file 'example.com.zone', origin 'example.com.' ... Compilation successful. After launching Knot with `knotc -c knot.conf start', zones are populated from the master server(s) and I see the *.db and *.db.crc files. The zones are loaded and I can query them. So far, so good. :) A small change to `example.com.zone' and a compile, again warns that the slave zone files don't exist. In effect it is true: the filenames I've configured in knot.conf do not exist, but the message is confusing because the zones have been loaded/exist. knotc -c knot.conf compile Zone file 'inline.aa' doesn't exist. Zone file 'jpmens.net' doesn't exist. Parsing file 'example.com.zone', origin 'example.com.' ... Compilation successful.' A subsequent server reload `knotc -c knot.conf reload' says in the log that the file(s) I just compiled are out of date: Loading 3 compiled zones... warning: Database for zone 'example.com' is not up-to-date. Please recompile. Loaded zone 'example.com.' Zone 'inline.aa.' is up-to-date, no need for reload. Zone 'jpmens.net.' is up-to-date, no need for reload. Loaded 3 out of 3 zones. Configuration reloaded. Regards, -JP

13 let, 10 měsíců

1
0
0 0

Knot DNS v1.0.0 released!

by Lubos Slovak

Dear Knot DNS users, special days deserve special events and this day will surely be extraordinary not only for us, but for the whole DNS community. CZ.NIC Labs released first stable version of Knot DNS! Please visit our websize http://www.knot-dns.cz for more information and all relevant links. Source files are available here: http://public.nic.cz/files/knot-dns/knot-1.0.0.tar.gz (SHA256: ab947ff09655f44bd4106da65764810ff760b646b83e9b0939ee994f943372a6) Packages will be available shortly from usual repositories. Instructions on how to setup them are available at http://www.knot-dns.cz. Lots of testing has been done in the past few weeks and we believe Knot DNS is as stable and bugfree as possible. Thank you all for support and feedback! We will continue developing Knot DNS - there is still place for a lot of optimizations, minor tweaks or new features, so stay tuned for next releases. Thank you again for using Knot DNS! Kind regards, Lubos, CZ.NIC Labs -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

13 let, 10 měsíců

1
0
0 0

Knot DNS 1.0 - RC1 released!

by Lubos Slovak

Hi, CZ.NIC Labs are proud to announce the first Release Candidate of Knot DNS! There are a lot of new features and some bug fixes that should make Knot DNS substantially more stable and secure. To pick just few interesting new features: - Support for NSID. - Support for root zone. - Dropping privileges after binding to port 53. - Automatic zone compile on server start. For all changes made since the last release, see RELNOTES in the source directory. Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-1.0-rc1.tar.gz (Sha256: b0e79159386555ce4086a43231fcf97b28cafc83) Packages will be available shortly from usual repositories. Instructions on how to setup them are available at http://www.knot-dns.cz. We will be grateful for any feedback from you to make the final release as stable and bugfree as possible. We will release the final 1.0 version shortly after more testing we plan to do in following weeks. Regards, Lubos, CZ.NIC Labs -- Ľuboš Slovák Knot DNS CZ.NIC Labshttp://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email:lubos.slovak@nic.cz WWW:http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign athttp://thinkBeforePrinting.org

13 let, 11 měsíců

1
0
0 0

Knot DNS - 0.9.1

by Lubos Slovak

Hi, a (mostly) bugfix release of Knot DNS was made today (v. 0.9.1). Corrected issues: - Fixed build on BSD. - Fixed parsing and dumping of some types (IPSECKEY, WKS, DLSV, APL, SPF, NSAP). Moreover, we added RRSet round-robin rotation when answering and a new pseudo-random number generator. Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-0.9.1.tar.gz Packages will follow shortly (probably tomorrow). Enjoy and be ready for the 1.0 release, which is on the way! Kind regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

14 let

1
0
0 0

Freebsd Knot-0.9

by Peter Andreev

Hello, everybody! I'm trying to compile Knot-0.9 on FreeBSD 8.2 amd64 and getting the following error: ./.libs/libknotd.a(fdset.o)(.text+0x6f): In function `fdset_init': common/fdset.c:64: undefined reference to `FDSET_KQUEUE' *** Error code 1 Stop in /home/apn/knot-0.9/src. *** Error code 1 Stop in /home/apn/knot-0.9/src. *** Error code 1 Stop in /home/apn/knot-0.9. -- -- AP

14 let

2
2
0 0

Knot DNS 0.9 released

by Lubos Slovak

Hi, we released new version of Knot DNS - 0.9. It includes full support for TSIG in both server and client. Moreover, performance on Linux was improved. There are also some bugfixes: - Knot was not accepting AXFR-style IXFR with first SOA in a separate packet (i.e. from Power DNS). - Wrong SOA TTL in negative answers. - Wrong max packet size for outgoing transfers (was causing the packets to be malformed). - Wrong handling of WKS record in zone compiler. - Problems with zone bootstrapping. Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-0.9.tar.gz Thank you again for helping us test Knot. We are looking forward to the 1.0 release, which should bring (among other) support for root zone, NSID, or improvements to IXFR. Do have a wonderful year 2012! Kind regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labshttp://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email:lubos.slovak@nic.cz WWW:http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign athttp://thinkBeforePrinting.org

14 let

1
0
0 0

Assertion `*w != 0' failed.

by Ondřej Caletka

Dobrý den, pokusně jsem nainstaloval Knot (z deb balíčků) jako slave a spustil pomocí knotc -vi start Při notify z masteru se mi u jedné zóny stalo, že se zónový soubor sice načetl, ale následně knot spadl s chybou: knotd: libknot/dname.c:616: knot_dname_to_str: Assertion `*w != 0' failed. Stalo se to několikrát za sebou, když jsem však začal zkoumat příčiny, problém se vytratil (původní soubor, který problémy způsoboval už bohužel nemám.) Nicméně jsem si všiml, že ke stejné chybě dojde i při ukončení interaktivního spuštění pomocí Ctrl+C., což by se asi dít nemělo (chyba ukazuje na porušenou strukturu knot_dname). S pozdravem Ondřej Caletka

14 let

2
1
0 0

Instalace na FreeBSD

by Josef Pinc

Dobry den, je k dispozici postup jak zkompilovat Knot DNS pod FreeBSD? Konkretne na 8.2-RELEASE koncim s chybou u ./configure: configure: error: liburcu not found liburcu jsem v portech nenasel. Diky za nakopnuti. Josef Pinc

14 let

6
13
0 0

Aktualizace ppa:cz.nic-labs/knot-dns

by Liquid

Dobry den, budete aktualizovat take balicky na ppa:cz.nic-labs/knot-dns podle aktualnich bugfix releasu? Josef Janosec

14 let, 1 měsíc

1
0
0 0

Nasazeni Knot DNS na sekundarni DNS server

by Stanislav Petr

Dobry den, zkousim nasadit Knot DNS jako jeden ze sekundarnich DNS serveru a narazil jsem na nejake problemy. 1. Prenese se mi jen mala cast zon, pak se zanou v logu obevovat nasledujci hlasky: Dec 1 15:00:31 ns4 knot[3061]: error: Failed to create journal file '/var/lib/knot/av-tech.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to open journal file '/var/lib/knot/av-tech.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to create journal file '/var/lib/knot/avalancheshop.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to open journal file '/var/lib/knot/avalancheshop.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to create journal file '/var/lib/knot/avdata.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to open journal file '/var/lib/knot/avdata.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to create journal file '/var/lib/knot/avdnachod.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to open journal file '/var/lib/knot/avdnachod.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to create journal file '/var/lib/knot/aveli.cz.diff.db' Dec 1 15:00:31 ns4 knot[3061]: error: Failed to open journal file '/var/lib/knot/aveli.cz.diff.db' 2. Server bezi pod rootem, nenasel jsem v konfiguraci ani v init scriptu (fedora) moznost nejak civilizovane nastavil uzivatele pod kterym to pobezi. 3. Pod Fedora 16 ktera pozuiva systemd neni obsluha knotu uplne idealni - chtelo by to definovat koraktne service pro systemd, ale to je vec tvorby rpm baliku pro fedoru. -- Stanislav Petr Hosting90 systems s.r.o. stanislav.petr(a)hosting90.cz

14 let, 1 měsíc

3
4
0 0

Knot DNS 0.8.1 released

by Lubos Slovak

Hi, today we released Knot DNS version 0.8.1 which brings two bugfixes: - Handling SPF records (compilation of zone with SPF failed). - Saving unknown RR types to zone file (caused failure of XFR/IN). Source files can be downloaded here: http://public.nic.cz/files/knot-dns/knot-0.8.1.tar.gz Thank you all for using Knot DNS and reporting problems. We have a few other bugs to fix in the following days. They will be aggregated in the next bugfix release which we hope to release in the following two weeks. With regards, Lubos -- Ľuboš Slovák Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic Email: lubos.slovak(a)nic.cz WWW: http://labs.nic.cz http://www.nic.cz ------------------------------------------- Please consider the environment before printing this email. Join the campaign at http://thinkBeforePrinting.org

14 let, 1 měsíc

1
0
0 0

IXFR/IN request failed

by Liquid

Dobry den, pokousim se nasadit knot-dns verze 0.8.0 jako slave server. Pro tyto ucely mam vmware virtualni stroj s 1GB ram, Ubuntu 10.04.3 x86, nainstalovano pres apt z launchpad.net. Pri zaslani notifikace master serverem se mi zona nestahne a v logu vidim hlasku: error: IXFR/IN request failed - OS lacked necessary resources. Nejaky napad jakych prostredku se serveru nedostava? Config: system { identity "knot"; storage "/var/lib/knot"; workers 2; } interfaces { my-local { address 127.0.0.1@53; } my-ipv4 { address ip4@53; } my-ipv6 { address ip6@53; } } remotes { my-master { address master_ip@53; } } + cca 50 slave zon. zony nastavene takto: mojezona.cz { file "/var/lib/knot/mojezona.cz.zone"; semantic-checks off; # vypne semantickou kontrolu # pro tuto zonu xfr-in my-master; # master server pro tuto zonu notify-in my-master; # od koho prijmout NOTIFY } Diky za pomoc. Liquid

14 let, 1 měsíc

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users