knot-dns-users

knot-dns-users@lists.nic.cz

4 participants
755 discussions

Re: [knot-dns-users] Error with secondaries: IXFR failed to start (not enough memory)

by daniel.salzman＠nic.cz

On 2016-08-22 19:55, Hugo Salgado wrote: > Hi Daniel. > Yes, I changed the storage directory to other location with right > permissions, and now the logs said: > > 2016-08-22T17:52:21 info: [manojitos.cl] zone loader, semantic check, > completed > 2016-08-22T17:52:21 info: [manojitos.cl] loaded, serial 2016010416 -> > 2016010417 > 2016-08-22T17:52:21 info: [manojitos.cl] NOTIFY, outgoing, > 200.1.123.7@53: serial 2016010417 > 2016-08-22T17:52:22 info: [manojitos.cl] IXFR, outgoing, > 200.1.123.7@16933: incomplete history, fallback to AXFR > 2016-08-22T17:52:22 info: [manojitos.cl] AXFR, outgoing, > 200.1.123.7@16933: started, serial 2016010417 > 2016-08-22T17:52:22 info: [manojitos.cl] AXFR, outgoing, > 200.1.123.7@16933: finished, 0.00 seconds, 1 messages, 3820 bytes > > So there's no error. > > Thanks a lot. Can I suggest to improve the previous error log? Maybe > if it can say "bad permission" instead of "not enough memory" could > be better to administrators :) > Of course, the message is very confusing. Best, Daniel > Best, > > Hugo > > > On 08/22/2016 01:22 PM, daniel.salzman(a)nic.cz wrote: >> Hi, >> >> You have the storage directory under /etc. I suspect the server is not >> allowed to create a zone journal file there. The journal is important >> for IXFR. >> Could you verify that? In such a case you can configure proper >> zone.file location >> but different zone.storage directory. >> >> Daniel >> >> On 2016-08-22 16:18, Hugo Salgado wrote: >>> Hi Daniel. Here I'm attaching my .conf. >>> >>> Thanks a lot! >>> >>> Hugo >>> >>> On 08/22/2016 05:46 AM, Daniel Salzman wrote: >>>> Hi Hugo, >>>> >>>> I can't reproduce your problem. Could you send me your configuration >>>> file >>>> please? Don't forget to mangle sensitive information, like TSIG key. >>>> >>>> Thank you, >>>> Daniel >>>> >>>> On 08/19/2016 07:57 PM, Hugo Salgado wrote: >>>>> Hi. >>>>> I have a KNOT master with a small zone (32 records), which is >>>>> logging an >>>>> error after the secondary (BIND) tries to update the zone. AFAIK, >>>>> Bind >>>>> tries with IXFR first, but my master says: >>>>> >>>>> 2016-08-19T16:32:12 error: [manojitos.cl] IXFR, outgoing, >>>>> 200.1.123.7@29095: failed to start (not enough memory) >>>>> >>>>> After that the secondary retries with AXFR, and that works: >>>>> >>>>> 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, >>>>> 200.1.123.7@13644: started, serial 2016011013 >>>>> 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, >>>>> 200.1.123.7@13644: finished, 0.00 seconds, 1 messages, 2573 bytes >>>>> >>>>> The error is the same the first time I provision the zone in the >>>>> secondary as in following updates. Is there a bug in the error >>>>> message, >>>>> or should I worry for some memory requirement in my server (or >>>>> service)? >>>>> >>>>> I'm with Knot 2.3.0 on a FreeBSD 10.3-release-p7. The secondary is >>>>> not >>>>> under my administration, but I was told is Bind with an up-to-date >>>>> version. >>>>> >>>>> Thanks! >>>>> >>>>> Hugo >>>>> >>>>> _______________________________________________ >>>>> knot-dns-users mailing list >>>>> knot-dns-users(a)lists.nic.cz >>>>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >>>>

9 let, 7 měsíců

dnsproxy module performance

by Matthijs Mekking

Hi, I recently tested the mod-dnsproxy performance and I am disappointed in the results: Knot in our test setup can do ~320K QPS. When using our own proxy in front of knot, we achieve quite a performance hit, only able to do ~120K QPS. However, when configuring knot to use the mod-dnsproxy, the performance drops to ~7K QPS. I am planning to investigate what causes this significant drop, but if you have any insights or other measurements already I would love to hear about them. Best regards, Matthijs

9 let, 7 měsíců

Error with secondaries: IXFR failed to start (not enough memory)

by Hugo Salgado

Hi. I have a KNOT master with a small zone (32 records), which is logging an error after the secondary (BIND) tries to update the zone. AFAIK, Bind tries with IXFR first, but my master says: 2016-08-19T16:32:12 error: [manojitos.cl] IXFR, outgoing, 200.1.123.7@29095: failed to start (not enough memory) After that the secondary retries with AXFR, and that works: 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, 200.1.123.7@13644: started, serial 2016011013 2016-08-19T16:32:12 info: [manojitos.cl] AXFR, outgoing, 200.1.123.7@13644: finished, 0.00 seconds, 1 messages, 2573 bytes The error is the same the first time I provision the zone in the secondary as in following updates. Is there a bug in the error message, or should I worry for some memory requirement in my server (or service)? I'm with Knot 2.3.0 on a FreeBSD 10.3-release-p7. The secondary is not under my administration, but I was told is Bind with an up-to-date version. Thanks! Hugo

9 let, 7 měsíců

KNOT - Web GUI

by Ing. Peter Palhazy | NWS

Dobry den, zamyslame pouzit KNOT na DNS serveroch. Avsak potrebujeme k tomu aj nejaky WEB GUI. Disponujete niecim takym? Pripadne viete o nejakom pouzitelnom? Na Vasej www stranke som to zatial zial nenasiel.. dakujem --

9 let, 7 měsíců

Knot DNS 2.3.0 release

by Jan Včelák

Hello! CZ.NIC just released a new version of Knot DNS. There are some bug fixes and improvements as usual. But most of the changes are new features. The bug fixes are mostly insignificant, so I'll make it quick: - We have resolved a problem with NSEC-signed zones when a wildcard was incorrectly expanded below a closer empty non-terminal. - The checks on the incoming IXFR were improved so that we now refuse transfers containing non-existing records to be removed. This problem was identified in draft-song-dnsop-ixfr-fallback-01. - The kdig utility can now correctly process IXFR response with empty content (i.e. when the zone is up-to-date). - The server now makes sure that PKCS #11 modules are not loaded multiple times. As for the improvements: - The code for semantic checks was refactored and the error messages should be a bit more readable. - The TC flag setting in delegation is now set only if the mandatory glue doesn't fit. Optional glue may not fit and the TC flag won't be set See my e-mail "glue and TC flags revisited" for more details: https://lists.nic.cz/pipermail/knot-dns-users/2016-June/000905.html - With the new version, you can set different EDNS(0) payload size for IPv4 and IPv6. See max-ipv4-udp-payload and max-ipv6-udp-payload configuration options. And now the interesting new stuff: - DNSSEC policy can be now defined in the server configuration. This makes automatic signing even easier to use. It's only a few lines of the configuration file. Really. Please, have a look at the "Automatic DNSSEC signing" section in the documentation. For easy transition, if the policies are not defined in the server configuration, the ones from the old KASP database are used instead. The keymgr with the --legacy option can be used to maintain the old policies. The KASP database is still used to store signing state and private key material. This might be changed in the future versions. - We have added support for automatic NSEC3 resalting. For this purpose, the new nsec3-salt-length and nsec3-salt-lifetime policy options were added. Please note that in the previous releases, the NSEC/NSEC3 mode for DNSSEC signing was determined by the presence of NSEC3PARAM record in the zone. This is no longer true. The nsec3 policy option is used instead. Note that this option was already present in older releases but it didn't work; please check your signing policies before the upgrade. - The control interface was extended to allow changing the zone content. It's experimental, the changes are internally processed similarly to DDNS which brings the same performance drawbacks, but we would like to builds some more robust interface on top of this one. - The zone size limit for DDNS, AXFR, and IXFR can be now enforced using the max-zone-size option. The default is unlimited. This is our solution for the CVE-2016-6171. Please note that for IXFR, the effective limit for the total size of the records in the transfer is twice the configured value. However the final zone size must satisfy the limit fully. - The kdig utility can talk TLS. Also EDNS(0) padding is supported. Does your local resolver support DNS-over-TLS? Give it a try: $ kdig +tls +alignment=512 www.knot-dns.cz And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.3.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.0.tar.xz.asc Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 7 měsíců

Knot Resolver 1.1.0 released

by Ondřej Surý

Hi everyone, CZ.NIC is proud to release second production release of Knot Resolver 1.1.0. We have included fixes that allows more brokeness in the upstream DNS :) as well as several notable new features: * RFC7873 DNS Cookies * RFC7858 DNS over TLS * HTTP/2 web interface, RESTful API * Metrics exported in Prometheus * DNS firewall module * Explicit CNAME target fetching in strict mode * Query minimisation improvements * Improved integration with systemd You can read more about those features in our blogpost: http://en.blog.nic.cz/2016/08/12/knot-dns-1-1-0/ Cheers, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

9 let, 7 měsíců

Knot DNS 1.6.8 patch release

by Jan Včelák

Hey list! CZ.NIC also released Knot DNS 1.6.8 today. The release contains only one tiny feature backported from 2.3.0: - The zone size limit for DDNS, AXFR, and IXFR can be now enforced using the max-zone-size option. The default is unlimited. This is our fix for the CVE-2016-6171. That was short. :-) The tarballs are available as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v1.6.8/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.8.tar.gz.asc Cheers, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 7 měsíců

Old ZSK not removed from zone

by Ulrich Wisser

Hi! It seems I do have a problem with dnssec policy. DNSSEC for wisser.se is automatically managed by knot. If you do a "dig dnskey wisser.se" you will find a lot of old ZSK in my zone. I did some "digging" with the keymgr tool and found the following conf for all old keys algorithm 8 size 2048 flags 256 active -1 retire 0 remove 0 I guess the retire and remove values are the problem. How do I set them for the old keys? And how do I configure my policy to set them for future keys? Kind regards Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 7 měsíců

AXFR size limit (CVE-2016-6171)

by Jan Včelák

Hello everyone. I would like to provide some clarification on CVE-2016-6171 which has been assigned to Knot DNS a few days ago. The CVE is basically about a missing configuration option to limit the size of incoming AXFR. The reporter claims that the master can generate infinite outgoing zone transfer and thus exhaust the slave's resources. We believe that master and slave servers should have appropriate trust relationship. And therefore we think this problem rather fits operational security that implementation security. If your master server is trusted, then you should not be affected by this CVE. Please note that the AXFR from untrusted master is not the only possibly source of malicious zone transfer. The IXFR and DDNS qualify as well. We have been requested to add a feature to limit incoming zone transfer about a month ago [1]. The changes are almost finished and will cover AXFR, IXFR, and DDNS. The feature will be included in Knot DNS 2.3 and will be also backported for the older 1.6 release. If you have any comments or questions, don't hesitate and tell us. [1] https://gitlab.labs.nic.cz/labs/knot/issues/464 Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs https://www.knot-dns.cz -------------------------------------------- Milešovská 5, 130 00 Praha 3, Czech Republic WWW: https://labs.nic.cz https://www.nic.cz

9 let, 8 měsíců

kdig / knsupdate: "; ; ERROR: failed to parse keyfile '...' ; ; DEBUG: srv_info_free: null parameter"

by georg＠riseup.net

tl;dr: I've searched the Internets a lot these past days, but weren't able to find a way to make kdig and knsupdate work with keys. How is this handled? Hello knot people, I've got a problem with kdig and knsupdate, specifically using the -k parameter. I'm using: - Debian 8.5 - dnssec-tools 2.2-2 (out of stretch) - knot-dnsutils 2.2.0-2~bpo80+1 (out of j-bp) - dnsutils 1:9.9.5.dfsg-9+deb8u6 (out of jessie) I'm creating the key with: # dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com which gives: # cat Khost.example.com.+157+11483.* host.example.com. IN KEY 512 3 157 42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I= Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: 42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I= Bits: AAA= Doing then: # knsupdate -d -k Khost.example.com.+157+11483. which gives: ;; ERROR: failed to parse keyfile 'Khost.example.com.+157+11483.' ;; DEBUG: srv_info_free: null parameter I've found [1], and indeed, I'm running into the mentioned error if using knot-dnsutils 1.6.0-1 out of jessie. Besides this, I wasn't able to find anything useful. But, doing this: # knsupdate -y hmac-md5:host.example.com:42eRdcSUtT2opnOPVaGY9nEPsryde7snDaKLOPSjI9I= works, the same as nsupdate does: # nsupdate -k Khost.example.com.+157+11483. Could someone shed some light on what I'm doing wrong? Any help appreciated... Thanks in advance and for your work on knot! All the best, Georg [1] https://lists.nic.cz/pipermail/knot-dns-users/2015-February/000579.html

9 let, 8 měsíců

← Newer
1
...
46
47
48
49
50
51
52
...
76
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users