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

Re: [knot-dns-users] problem with debian repository

by Ondřej Surý

Could you please flush your DNS cache (deb.knot-dns.cz should point to sophie.nic.cz now) and try again? The debarchive got broken and I couldn't fix it, so it has been replaced by reprepro. In case you can't flush your caches, please just temporarily change deb.knot-dns.cz to sophie.nic.cz. Also the repository is now signed: # wget -O - http://deb.knot-dns.cz/debian/apt.key | apt-key add - Full instructions can be found here: http://deb.knot-dns.cz/debian/README.txt 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: "Leoš Bitto" <leos.bitto(a)gmail.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Tuesday, September 9, 2014 12:06:45 PM > Subject: Re: [knot-dns-users] problem with debian repository > On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote: >> Dne 22.8.2014 09:52, Peter Hudec napsal(a): >>> Hi, >>> >>> this mail is directed for debian repository maintainers. >>> >>> The debian repository is not working properly, the Packages(.gz) and >>> Sources(.gz) files are empty. >>> >> >> I'm observing same problem. However, I've noticed that latest version of >> Knot is available in official wheezy-backports tree. >> > > http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too. > However I do not agree with the availability in the official > wheezy-backports > (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) - > the previous version 1.5.1 was not there until the last week, and the > current version 1.5.2 is not there at all (which might actually be a > good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294). > > > Leoš Bitto > _______________________________________________ > 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, 8 měsíců

1
0
0 0

problem with debian repository

by Peter Hudec

Hi, this mail is directed for debian repository maintainers. The debian repository is not working properly, the Packages(.gz) and Sources(.gz) files are empty. http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-amd64/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-i386/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/source/Sources .... I tested only wheezy distribution release. best regards Peter Hudec

11 let, 8 měsíců

3
2
0 0

Knot DNS 1.5.2 bugfix release

by Jan Kadlec

Hello list! Today, Knot DNS version 1.5.2 has been released by CZ.NIC Labs. This is a bugfix release. Unfortunately, while doing some internal testing, we've found a remote vulnerability that can crash the server. So far, we've had no reports that would suggest that someone else has discovered this vulnerability, but it is important all users upgrade as soon as possible. CVE for this vulnerability is CVE-2014-0486. We've also included a couple more fixes: Knot was refusing AXFR-style IXFR transfers, meaning these transfers had to be sent twice. Further, Knot was not properly escaping the hash character in domain names when saving the text zone file. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz.asc Again, we advise all users to upgrade immediately. We are truly sorry for any inconvenience caused by this. 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ů

2
1
0 0

knot init in Debian

by Zdeněk Zámečník

I have following issue with Knot: when I try to stop it by command /etc/init.d/knot stop then the daemon is still running. If i run command knotc stop then it's stopped but immediately run again. If I kill it by command kill, it's the same... As I found the /etc/init.d/knot is not working at all and Knot is probably run during boot by /etc/init/knot.conf and I'm not able to control it. The "unkillable" proccess is named /usr/sbin/knotd -c /etc/knot/knot.conf My environment: Debian 7 AMD64, OpenVZ container, kernel 2.6.32-openvz-042stab092.2-amd64, Knot 1.5.0-1 I tried to install Knot on another older machine where is Debian 7 too but upgraded from 6 and it's KVM virtual machine. There it works correctly via init.d script and the proccess is named /usr/sbin/knotd *-d* -c /etc/knot/knot.conf Do you have an idea why it's working on older machine correctly and on the second with OpenVZ not? Thanks for any help. Zdenek Z.

11 let, 9 měsíců

6
10
0 0

multimaster docs?

by Nicolás Reynolds

hi, i see knot 1.5.0 has multimaster support but i can't find more info/docs on this, can you point me to it? -- D

11 let, 9 měsíců

3
3
0 0

Knot and systemd

by Anand Buddhdev

Hello Knot folk, I'm building Knot RPM packages for use on CentOS 7, and I have to write systemd unit files. Before I write anything, I'd love to hear from others who may already have done such work, to learn from it. Let me describe my ideas. On my existing Knot servers running on CentOS 6 with upstart, I have 2 upstart scripts, viz. knot.conf, and knot-instance.conf. The knot.conf upstart script looks in /etc/knot for .conf files, and for each one, runs knot-instance with the config file as a parameter. This way, a simple "start knot" will start all instances. In systemd, there is better support for instances, so I want to create a knot@.service template unit, and a knot.target target unit. Then, I can create new instances with "systemctl enable knot(a)conf1.conf" and "systemctl enable knot(a)conf2.conf". Finally, running "systemctl start knot.target" should start all configured instances. Does this sound reasonable? I would also like to know about Knot's built-in support for systemd. I can't find any documentation about it. Could one of the devs please describe what Knot actually does if it's compiled with systemd support? Would you mind adding this information to the online documentation? Regards, Anand

11 let, 9 měsíců

2
3
0 0

Knot DNS 1.5.1 release

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, 9 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 měsíců

1
0
0 0

Knot 1.5 - what does state "idle" mean?

by Anand Buddhdev

11 let, 12 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, 12 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, 12 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, 12 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.

12 let

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

12 let

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.

12 let, 1 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.

12 let, 1 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

12 let, 1 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

12 let, 1 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

12 let, 1 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

12 let, 2 měsíce

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

12 let, 2 měsíce

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.

12 let, 2 měsíce

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

12 let, 2 měsíce

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.

12 let, 3 měsíce

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.

12 let, 3 měsíce

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.

12 let, 3 měsíce

2
1
0 0

/help

by Maren S. Leizaola

/subscribe /list

12 let, 3 měsíce

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

12 let, 3 měsíce

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

12 let, 3 měsíce

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

12 let, 3 měsíce

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!

12 let, 3 měsíce

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

12 let, 4 měsíce

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

12 let, 4 měsíce

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, 4 měsíce

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, 4 měsíce

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 měsíce

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, 4 měsíce

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 měsíce

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, 4 měsíce

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, 4 měsíce

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, 4 měsíce

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, 5 měsíců

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, 5 měsíců

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, 5 měsíců

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, 5 měsíců

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, 5 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, 5 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, 5 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, 5 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, 5 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, 6 měsíců

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, 6 měsíců

8
22
0 0

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

by Jon Francis

12 let, 6 měsíců

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, 7 měsíců

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, 7 měsíců

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, 8 měsíců

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, 8 měsíců

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, 9 měsíců

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, 9 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, 9 měsíců

6
12
0 0

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

by Ubytování v Chorvatsku

12 let, 9 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, 9 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, 10 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, 10 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, 10 měsíců

2
1
0 0

各个费用

by 张经理

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

12 let, 10 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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 12 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

13 let

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

13 let, 1 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ć

13 let, 1 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

13 let, 1 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

13 let, 1 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

13 let, 2 měsíce

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

13 let, 2 měsíce

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

13 let, 2 měsíce

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

13 let, 2 měsíce

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

13 let, 2 měsíce

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users