knot-dns-users

knot-dns-users@lists.nic.cz

5 participants
727 discussions

by Anand Buddhdev

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

12 let, 1 měsíc

Bootstrapping lots of slave zones

by Anand Buddhdev

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

12 let, 1 měsíc

knotc not reading control options from config file

by Anand Buddhdev

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

12 let, 1 měsíc

Log file ownership

by Anand Buddhdev

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

12 let, 1 měsíc

syslog server?

by jh＠netriplex.com

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

12 let, 1 měsíc

Log messages leaking to syslog

by Anand Buddhdev

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

12 let, 1 měsíc

Plain text copy of zone files

by Anand Buddhdev

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

12 let, 1 měsíc

Knot DNS 1.2.0-rc3 release

by Marek Vavruša

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

12 let, 1 měsíc

Knot DNS v1.2-rc2

by Marek Vavruša

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

12 let, 2 měsíce

Single address limitation per interface and remote server

by Matthias-Christian Ott

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

12 let, 2 měsíce

← Newer
1
...
65
66
67
68
69
70
71
72
73
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users