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

knot 2.3.0-3: Automatic DNSSEC signing: Current limitations and creating trusted-keys { ... }

by georg＠riseup.net

Hi all, I'm running {knot,knot-dnsutils} 2.3.0-3~bpo8+1 out of Debian jessie-backports, and enabled automatic DNSSEC signing, which works great! I've got two question, as per the subject: - According to [1], "KSK rollover is not implemented.". Does this mean, if the key was created and exists, then currently knot doesn't change / rollover the KSK? Is it safe to assume, that as long one is using this version, the key stays the same? - I'm running Unbound to do resolving and forwarding some forward and corresponding reverse zones to knot. To make DNSSEC work, I've created a trusted-keys { ... } file with all the KSK created and used by / with knot. Right now, I've created this file manually, using $ keymgr zone key show ... and $ cat $name_of_zone.json and putting it all together. Right now, is there a tool / utility / command which does this already? TIA and all the best, Georg [1] https://www.knot-dns.cz/docs/2.x/html/configuration.html#limitations

8 let, 8 měsíců

4
5
0 0

What is stored in Knot's zone timer database?

by Anand Buddhdev

Dear Knot devs, When Knot writes out the zone timer database, what pieces of information about a zone are stored? Regards, Anand

8 let, 8 měsíců

3
4
0 0

is there a out-of-the-box receipt to use knot as a DNS cache for a Tor exit relay ?

by Toralf Förster

As a lazy slacker I do wonder about such a knot-in-a-nutshell-for-tor-exit-relay-operator-dummies doc ? ;) -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7

8 let, 8 měsíců

3
6
0 0

Multi-value options in "template" and "zone" sections

by Anand Buddhdev

Hi, This is mainly a question for the Knot developers. Suppose I have: template: - id: default acl: acl1 zone: - domain: zone acl: acl2 Does "zone" get "acl2" or "acl1, acl2" applied to it? Regards, Anand

8 let, 8 měsíců

2
3
0 0

Knot DNS 2.3.1 release

by Ondřej Surý

Hi fellow Knot DNS users and other mailing list lurkers, CZ.NIC just released a new version of Knot DNS. There are some bug fixes and improvements as usual. We fixed missing glue records in some responses, and there were some other minor nits. The most notable improvement was a speed-up of conf-commit and conf-diff operations when using zonedb. Users with hundred thousands zones and more will be amazed (we hope). There's also new EDNS Client Subnet API in libknot soon to be used in our sibling project Knot Resolver. On the new features front, kdig now can print TLS hierarchy for DNS over TLS, the knotc now contains zone-purge command and we have new mod-whoami module and new dnstap logging options contributed by Robert Edmonds. We would also like to invite everyone to migrate from Knot DNS 1.6.x to the current stable Knot DNS 2.x.x release. 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.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ Regards, -- 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/ --------------------------------------------

8 let, 8 měsíců

1
0
0 0

Where can I found the module of Geoip

by hou guanghua

Dear<https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users> sir, In the discussion issue, the feature "view" as bind will be supported next version. Where can I found the source code of module Geoip? Regards, Guanghua

8 let, 8 měsíců

1
0
0 0

Knot 2 on CentOS 6

by Anand Buddhdev

I would like to thank Jan Včelák for submitting the gnutls30 package into EPEL 6. This allows one to build Knot 2 for RHEL/CentOS 6 without having to hunt down any dependencies. We still run CentOS 6 and it's useful to be able to upgrade to Knot 2 on our servers. Thanks Jan! Regards, Anand

8 let, 9 měsíců

2
1
0 0

configuring dnstap in knot 2.2.1

by Lowell Mower

Hello: I've compiled knot 2.2.1 and configured with the --enable-dnstap flag but continue to get errors when starting knot and configuring it to use dnstap to write to a file see below: * * * * * * * * * * * * * * * * * * * * * * * * ./configure: knot 2.2.1 Target: linux-gnu x86_64 Compiler: gcc -std=gnu99 CFLAGS: -g -O2 -Wall -Werror=format-security -Werror=implicit -fpredictive-commoning LIBS: -lcap-ng -ldl -lpthread -lm LibURCU: -lurcu GnuTLS: -lgnutls -lnettle -I/usr/include/p11-kit-1 Jansson: -ljansson Libedit: -ledit -I/usr/include/editline LMDB: embedded Sanitizer: LibFuzzer: no Prefix: /usr/local Run dir: ${prefix}/var/run/knot Storage dir: ${prefix}/var/lib/knot Config dir: ${prefix}/etc/knot Configuration DB mapsize: 500 MiB Timers DB mapsize: 100 MiB Knot DNS libraries: yes Knot DNS daemon: yes Knot DNS utils: yes Knot DNS documentation: yes Use SO_REUSEPORT: yes Fast zone parser: no Utilities with IDN: no Systemd integration: no Dnstap support: yes Code coverage: no Bash completions: no PKCS 11 support: no Continue with 'make' command * * * * * * * * * * * * * * * * * * * * * * * * /etc/knot.conf server: listen: 100.88.99.132 nsid: knot-2.2.1-dnsproxy-0.1.0 log: - target: syslog any: info remote: - id: authcore address: 127.0.0.1@53535 mod-dnsproxy: - id: sdt remote: authcore template: - id: default global-module: mod-dnsproxy/sdt mod-dnstap: - id: capture_all sink: /tmp/dnstap.tap template: - id: default global-module: mod-dnstap/capture_all * * * * * * * * * * * * * * * * * * * * * * * * knotc -c /etc/knot.conf reload error: config, file '/etc/knot.conf', line 21, item 'mod-dnstap', value '' (invalid item) error: failed to load configuration file '/etc/knot.conf' (invalid item) * * * * * * * * * * * * * * * * * * * * * * * * I've tried various configurations and have been using: https://www.knot-dns.cz/docs/2.x/html/configuration.html#dnstap-dnstap-enab… as a guide. What am I missing?

8 let, 9 měsíců

3
4
0 0

DNS Cookies support

by Ulrich Wisser

Hi everybody! Today I wrote some code to test support for DNS Cookies. But unfortunately I couldn't find any servers supporting DNS Cookies. Of course this is most likely an error in my code. I couldn't find anything in the documentation, so my question is, does knot 2.3.0 support DNS Cookies? Could someone please point me to a server supporting DNS Cookies? What would be a good test? Right now I do send a query with a cookie and see if I get a cookie in return. Kind Regards Ulrich -- Ulrich Wisser ulrich(a)wisser.se

8 let, 10 měsíců

3
4
0 0

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

8 let, 10 měsíců

1
0
0 0

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

8 let, 10 měsíců

4
8
0 0

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

8 let, 10 měsíců

1
0
0 0

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

8 let, 10 měsíců

1
0
0 0

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

8 let, 10 měsíců

4
5
0 0

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

8 let, 10 měsíců

1
0
0 0

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

8 let, 10 měsíců

1
0
0 0

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

8 let, 10 měsíců

2
1
0 0

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

8 let, 11 měsíců

1
0
0 0

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

8 let, 11 měsíců

2
4
0 0

Knot Debian installation - 301 Moved Permanently [IP: 217.31.192.140 80],

by Maren S. Leizaola

Hello, Even if I force wget to accept your expired certificate I can't get apt-get update to work when pointing to your servers. It has been like this for a few days now. Hit http://ftp.debian.org wheezy-updates/main Translation-en/DiffIndex Err http://deb.knot-dns.cz wheezy/main amd64 Packages 301 Moved Permanently [IP: 217.31.192.140 80] Ign http://deb.knot-dns.cz wheezy/main Translation-en W: Failed to fetch http://deb.knot-dns.cz/knot/dists/wheezy/main/binary-amd64/Packages 301 Moved Permanently [IP: 217.31.192.140 80] E: Some index files failed to download. They have been ignored, or old ones used instead. Could someone have a look at this please? DO you think that many users have just switched back to bind because of this? or is it just me? Regards, Maren.

8 let, 11 měsíců

3
2
0 0

Re: [knot-dns-users] forcing minimal fragment size for IPv6 datagrams

by Daisuke HIGASHI

Hi, I anyway wrote a patch for disabling PMTUD for UDP socket (for both IPv4/IPv6), and posted to issue tracker: https://gitlab.labs.nic.cz/labs/knot/issues/467#note_24304 This patch includes extra bonus for mitigating DNS fragmentation attack for IPv4 UDP, by using Linux's newer sockopt IP_PMTUDISC_OMIT. I tried to illustrate how PMTUD badly interact with DNS over UDP, which draft-andrews-dnsext-udp-fragmentation is addressing. Assuming that there is a small MTU link between DNS requester and DNS responder. Responder is serving large response, which size is exceeding that small MTU (1454): Apparently many DNS operator don't want timeout and retransmission. MTU MTU MTU Requester--1500--[router1]--1454--[router2]--1500-- Responder | . . | | . . | o --------------------------------------------->| 1. Requester initiates | . . | DNS query. | . . | | . .<-------------o 2. Responder generates | . . | large DNS resnponse | . . | (packet size > 1454) | . . | | . o------------->| 3. Intermediate router | . . | drops large packet | . . | due to small MTU, and | . . | generates ICMPv6 | . . | "Packet Too Big", | . . | since the response | . . | packet can't go | . . | through the link. | . . | | . . | Responder would learn | . . | smaller path MTU toward | . . | requester, but | . . | does not resend | . . | the response. (It's UDP!) ~ ~ ~ ~ | . . | o---------------------------------------------->| 4. After timeout | . . | requester retries | . . | query. | . . | |<----------------------------------------------| 5. Responder generates | . . | fragmented DNS response | . . | which can go throgh | . . | the "MTU 1454" link. | . . | Regards, -- Daisuke Higashi

8 let, 11 měsíců

1
0
0 0

glue and TC flag revisited

by Jan Včelák

Hello. There has been a rather long discussion about the change in TC flag setting for glue records after the Knot DNS 2.1.1 release. Based on the feedback, we have decided to tune the server's behavior a little bit. First of all, the definitions for "glue" differ and the recent RFC 7719 (DNS Terminology) doesn't help. So just to make this absolutely clear, let's define "mandatory glue": Mandatory glue are non-authoritative address records for the name servers in the delegation and within the bailiwick of that delegation. RFC 1034 Section 4.3.2 [1] describes the algorithm for response construction. As per step 3.b, we include mandatory glue into the additional section. If it doesn't fit, the TC flag is set. And as per step 6., we include other authoritative address records for name servers in the delegation. If these records don't fit, the TC flag is not set. [1] https://tools.ietf.org/html/rfc1034#section-4.3.2 Let's show that on an example. Consider the following zone: $ORIGIN tc.test. @ SOA ns admin 1 60 60 1800 60 ns AAAA 2001:DB8::1 foo NS ns.foo ns.foo AAAA 2001:DB8::10 bar NS bar NS a.ns.bar NS b.ns.bar NS ns.foo NS ns NS foo.test. bar AAAA 2001:DB8::20 a.ns.bar AAAA 2001:DB8::30 Now query for www.bar.tc.test would result in a response with delegation. The authority section would contain NS records for bar.tc.test. And the additional section will contain address records for following names as follows: - bar required (mandatory glue) - a.ns.bar required (mandatory glue) - ns optional (authoritative record, possibly with RRSIG) - b.ns.bar omitted (mandatory glue but unavailable) - ns.foo omitted (non-authoritative outside bailiwick) - foo.test omitted (non-authoritative outside zone) So what do you think? Is it better? This change is already included in the master branch (in case you want to test it). But there is still some time to change it before the next release. Best regards, Jan

8 let, 12 měsíců

1
0
0 0

receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED

by Roger Murray

Hello Everybody, I am seeing a response from a knot name server that I am working on that has me a little confused. When I do zone transfer requests from clients that aren’t allowed to do a zone transfer I expect to receive rcode 5 REFUSED, but I am receiving rcode 9 NOTAUTH. Is this the expected behaviour? Is this configurable? Best Regards, /rog knotd (Knot DNS), version 2.2.1 on Ubuntu 14.04 installed from .cz package knot: Installed: 2.2.1-1+trusty+1 Candidate: 2.2.1-1+trusty+1 Version table: *** 2.2.1-1+trusty+1 0 500 http://ppa.launchpad.net/cz.nic-labs/knot-dns/ubuntu/ trusty/main amd64 Packages

9 let

4
4
0 0

should NSEC3 be default?

by Jan Včelák

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision... We would appreciate any comments from your point of view. :-) Jan

9 let

7
11
0 0

RRL and dnsproxy

by Matthijs Mekking

Hi, I recently started trying out Knot DNS and it has been a pleasure so far. I like the query modules and how easy it is to construct a query plan. I am thinking of putting knot as the public-facing server and enable RRl on it. However, I noticed that rate limiting comes *before* forwarding the unsatisfied query to the remote backend. This means effectively that all the queries will be rate limited by error classification. Wouldn't it be better to apply ratelimits after all stages of the query plan have been processed? In other words, rate limit based on the final response, rather than an intermediate state. This way you can truly use knot as a rate-limiting, public-facing server protecting your backend name server. Thoughts? Best regards, Matthijs

9 let

2
2
0 0

Knot DNS 2.2.1 patch release

by Jan Včelak

Hello everyone. CZ.NIC Labs has just released a patched version of Knot DNS. The 2.2.1 version contains some important bug fixes and a few small improvements. Let's jump directly into it: - The previous version was inconsistent in setting the TC flag for delegations with a glue. We have decided to modify the behavior slightly and the TC flag is now set always if a complete glue doesn't fit the response. - Logging of individual categories (server or zone) didn't work in the previous release. This problem is now resolved. Logging all categories (any configuration option) was not affected. - We have eliminated data race in the code responsible for zone file flushing. When more zone files were flushed concurrently, flushing of some zones could fail. This problem is fixed in the new release. - If you are running Knot DNS on OpenWRT, we advise you to update to the new release. There has been a critical bug possibly making the server to crash. - There had been several issues with the control utility: The timeout for reconfiguration is now parsed correctly. The "maxreaders limit reached" error is gone. And the interactive mode now completes multiple zone names if allowed by the command. The server will also refuse to perform the reload, if there is an active configuration transaction. - We have removed switch for Link Time Optimization from the configure script, because LTO is still rather problematic. If you want to use LTO, set the CFLAGS and LDFLAGS appropriately. - We have improved the logging and status messages to differentiate between an unavailable zone and a zone with zero serial. - We have added a list of PKCS #11 devices which had been tested with automatic DNSSEC signing. We are looking forward to your feedback. The sources are available as usual: Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.2.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz.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
13
0 0

Re: [knot-dns-users] Question about "views" and "RPZ"

by Marek Vavruša

Hey Jake, yes it does, RPZ is supported for views as is any other policy. There's an example of setting RPZ for a source-address subnet view in the documentation: http://knot-resolver.readthedocs.io/en/latest/modules.html#id3 Cheers, Marek > Does KnotDNS Resolver support the use of different RPZ's per-view? > > Looking to create a DNS setup that allows recursion to two separate > groups, one using one RPZ setup, the other using another. > > Is this possible with Knot? > > Thanks, > -jake > _______________________________________________ > 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, 1 měsíc

1
0
0 0

Kernel Connection Multiplexor

by Robert Edmonds

Hi, Linux 4.6 was just released, and it includes a new feature called "Kernel Connection Multiplexor": http://kernelnewbies.org/Linux_4.6#head-d86a7a8affd7cefef85fff400e39403718b… 1.5. Kernel Connection Multiplexor, a facility for accelerating application layer protocols This release adds Kernel Connection Multiplexor (KCM), a facility that provides a message-based interface over TCP for accelerating application layer protocols. The motivation for this is based on the observation that although TCP is byte stream transport protocol with no concept of message boundaries, a common use case is to implement a framed application layer protocol running over TCP. Most TCP stacks offer byte stream API for applications, which places the burden of message delineation, message I/O operation atomicity, and load balancing in the application. With KCM an application can efficiently send and receive application protocol messages over TCP using a datagram interface. The kernel provides necessary assurances that messages are sent and received atomically. This relieves much of the burden applications have in mapping a message based protocol onto the TCP stream. KCM also make application layer messages a unit of work in the kernel for the purposes of steerng and scheduling, which in turn allows a simpler networking model in multithreaded applications. In order to delineate message in a TCP stream for receive in KCM, the kernel implements a message parser based on BPF, which parses application layer messages and returns a message length. Nearly all binary application protocols are parseable in this manner, so KCM should be applicable across a wide range of applications. DNS-over-TCP is definitely amenable to this scheme, since messages are framed with a 2-byte message length value. It also sounds like it can be combined with recvmmsg(): Q: What about the problem of a connections with very slow rate of incoming data? As a result your application can get storms of very short reads. And it actually happens a lot with connection from mobile devices and it is a problem for servers handling a lot of connections. A: The storm of short reads will occur regardless of whether KCM is used or not. KCM does have one advantage in this scenario though, it will only wake up the application when a full message has been received, not for each packet that makes up part of a bigger messages. If a bunch of small messages are received, the application can receive messages in batches using recvmmsg. Maybe this could help speed up a DNS server, or even improve resistance against slowloris style TCP attacks. -- Robert Edmonds edmonds(a)debian.org

9 let, 1 měsíc

2
2
0 0

Question about "views" and "RPZ"

by elsif

Does KnotDNS Resolver support the use of different RPZ's per-view? Looking to create a DNS setup that allows recursion to two separate groups, one using one RPZ setup, the other using another. Is this possible with Knot? Thanks, -jake

9 let, 1 měsíc

1
0
0 0

systemd integration on Centos 7

by Matthew Pounsett

I'm building my own RPM for Knot 2.2.0 on Centos 7 due to the fact that the system version is still 1.x. I'm building it with systemd integration, and I've borrowed the systemd service file from the Fedora RPM. I'm having issues at startup, though. I'm wondering if it's related to the use of 'Type=notify', since knot seems to be running, but then after a delay of 30 seconds systemd decides it has failed and kills it. I'm attaching useful bits below. Any thoughts on the cause? My service file is: [Unit] Description=Knot DNS server daemon [Service] Type=notify ExecStart=/usr/sbin/knotd ExecReload=/usr/sbin/knotc reload Restart=on-abort ExecStartPre=/usr/sbin/knotc conf-check # Breaks daemon reload #CapabilityBoundingSet=cap_net_bind_service cap_setuid cap_setgid [Install] WantedBy=multi-user.target And this is what knot is reporting at startup: ● knot.service - Knot DNS Server Loaded: loaded (/etc/systemd/system/knot.service; disabled; vendor preset: disabled) Active: failed (Result: timeout) since Thu 2016-05-12 19:52:34 UTC; 3min 19s ago Process: 5875 ExecStart=/usr/sbin/knotd (code=exited, status=0/SUCCESS) May 12 19:51:04 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:51:04 info: starting server May 12 19:51:04 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:51:04 info: server started in the foreground, PID 5875 May 12 19:51:04 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:51:04 info: control, binding to '/var/run/knot/knot.sock' May 12 19:52:34 master01.test.conundrum.com systemd[1]: knot.service start operation timed out. Terminating. May 12 19:52:34 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:52:34 info: stopping server May 12 19:52:34 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:52:34 info: updating zone timers database May 12 19:52:34 master01.test.conundrum.com systemd[1]: Failed to start Knot DNS Server. May 12 19:52:34 master01.test.conundrum.com systemd[1]: Unit knot.service entered failed state. May 12 19:52:34 master01.test.conundrum.com systemd[1]: knot.service failed. May 12 19:52:34 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:52:34 info: shutting down And finally, the config report from building the package: knot 2.2.0 Target: linux-gnu x86_64 Compiler: gcc -std=gnu99 CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DNDEBUG -Wno-unused -Wall -Werror=format-security -Werror=implicit -fpredictive-commoning LIBS: -lcap-ng -ldl -lpthread -lm -Wl,-z,relro LibURCU: -lurcu GnuTLS: -lgnutls -lnettle -I/usr/include/p11-kit-1 Jansson: -ljansson Libedit: -ledit -ltinfo -I/usr/include/editline LMDB: shared -llmdb Sanitizer: LibFuzzer: no Prefix: /usr Run dir: /var/run/knot Storage dir: /var/lib/knot Config dir: /etc/knot Configuration DB mapsize: 500 MiB Timers DB mapsize: 100 MiB Knot DNS libraries: yes Knot DNS daemon: yes Knot DNS utils: yes Knot DNS documentation: yes Use SO_REUSEPORT: yes Fast zone parser: yes Utilities with IDN: yes Systemd integration: yes Dnstap support: yes Code coverage: no Bash completions: no PKCS 11 support: no

9 let, 1 měsíc

2
2
0 0

Fedora23 knot 2.2.0 issue in knot.service

by Brad Garrison

I've just upgraded to 2.2.0 and noticed that knot failed to start. Upon inspection, I found that: /usr/lib/systemd/system/knot.service had the following line: ExecStartPre=/usr/sbin/knotc checkconf I think this is an error. I had to modify it to: ExecStartPre=/usr/sbin/knotc conf-check and then reimport the knot.conf file to get knot to start successfully.

9 let, 1 měsíc

2
1
0 0

Knot DNS 2.2.0 release

by Jan Včelak

Hello everyone! Knot DNS 2.2.0 by CZ.NIC Labs has been just released! This release brings only a few new features, but it contains a bunch of important bugs fixes and many significant changes under the hood. Let's start with the bug fixes and improvements: - We have resolved build dependency issues on FreeBSD. And we have fixed a problem when detecting PKCS #11 support in GnuTLS. - Some bugs related to Dnstap were resolved as well. The logging module now correctly sets query/response message type. And kdig properly uses the remote address when showing the capture. - The global instances of query modules were not executed for queries hitting existing zones. This problem is fixed in the new release. - We have enabled execution of semantic checks after IXFR to unify the behavior with AXFR. Also the logging of messages related to transfers was improved a little bit. - The DNSSEC signing produces correct NSEC/NSEC3 bitmap for delegations where a glue record has the same name as the delegated zone. - We have added some fixes hopefully improving compatibility with PKCS #11 devices. The most significant change is that the generated keys are marked as sensitive. It makes perfect sense and some devices (e.g. Luna SA) actually require this attribute to be set. - The configuration transaction is not aborted when some consistency check fails. This is particularly useful, if you make a typo when changing the server configuration with knotc. We have also eliminated an incorrect error when the last zone was being removed from the server. - There are also some bug fixes and improvements in the utilities. The keymgr utility should provide more sensible error messages, new consistency checks were added, and some commands were extended a little bit. The kdig utility now properly handles AXFR responses containing only the SOA record in the first message. And kdig will also use a local resolver if the resolv.conf file is empty. - The zone event scheduler was improved. And we hope that it will speed up the event lookup if you have many many zones. And finally the new features: - We have added RRL white listing. This allows to exempt some clients from rate limiting, for example your monitoring hosts. See the rate-limit-whitelist configuration option for details. - We have added support for URI (RFC 7553) and CAA (RFC 6844) resource record types. - The knotc utility now supports interactive mode with command line editing, tab completion, and history. Just start knotc without any command and give it a try. - And the server has a new control interface we will be extending in the future. The knotc utility already uses this interface. And we also have a simple Python binding for this interface. We are definitely looking for some feedback. That's all folks. Thank you for using Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/2.2/NEWS Source archive: https://secure.nic.cz/files/knot-dns/knot-2.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.2.0.tar.xz.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, 1 měsíc

1
0
0 0

Statistics

by Roger Murray

Hey, I was wondering if any work has been done on a statistics module for Knot DNS? I have read the mailing list and saw the conversation between Daniel and Julian, but haven’t seen anything on the list since then and I don’t see anything the documentation. Best regards, /rog

9 let, 2 měsíce

3
3
0 0

knot resolver with knot1 daemon

by Josef Karliak

Good morning, it is able to run knot resolver daemon with knot 1.6.x ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

9 let, 2 měsíce

2
1
0 0

SIGSEGV of knot 2.1.1 on opensuse 13.2 x64 after add secure keystore hsm

by Josef Karliak

Good morning, I run knot2 on opensuse, configuration was migrated from 1.6. to 2.1.1, I run step by step configuration by manual to keymgr and after command : "keymgr policy add secure keystore hsm" I get a message: celer:/var/lib/knot/kasp # keymgr policy add secure keystore hsm Policy with given name alredy exists. Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen]) Previos command was keymgr keystore add hsm backend pkcs11 config "pkcs11:token=knot;pin-value=4587 libsofthsm2.so" and was successfull. On the testing "server" with knot all works fine, testing server is opensuse 42.1 x64. Problem is on opensuse 13.2 x64 There is a core dump in the attachment. In the /var/log/messages were complains to libc: Apr 11 10:25:49 celer kernel: [7927072.584757] keymgr[13591]: segfault at 7fff18000000 ip 00007f3f59c20ca4 sp 00007fff18064f18 error 4 in libc-2.19.so[7f3f59ba5000+19e000] For sure I made upgrade of glib by zypper, but no success. Any ideas ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

9 let, 2 měsíce

2
1
0 0

preserve case in labels?

by Gert Doering

Hi, we're using knot DNS (2.0.2) on one of our primaries, to balance out "BIND is used everywhere". So far, we're quite happy, but today I got a complaint from our hostmaster team - triggered by a warning from DENIC that "our SOA records are inconsistent". Turns out they are, if you look at uppercase/lowercase... $ dig +short @ns.space.net space.net soa ns.space.net. hostmaster.space.net. 2016040601 28800 3600 864000 1800 $ dig +short @ns3.dns.space.net space.net soa ns.Space.Net. hostmaster.Space.Net. 2016040601 28800 3600 864000 1800 first one is knot, second is BIND, and the "mixed case" spelling is what the zone master (hidden primary) is distributing. (I understand that DNS is not case-significant, but we're using upper case in DNS labels because we like it that way...) Looking at labels inside the zone (dig axfr) shows that knot is lowercasing *everything*, not only the SOA records. So, I started looking whether there is a switch that can change knot's behaviour to just leave the labels alone, and do not lowercase everything. Google did not find anything, neither did "man knotd" or "man knot.conf". So, is there a hidden switch or compile-time feature to achieve this? thanks in advance, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

9 let, 2 měsíce

4
11
0 0

Concurrent Update

by masoud hematpour

Hello to all, I tried to look a little bit to the codes but can I ask how concurrent update is avoided? I mean RCU is used to avoid concurrent read and write. But how concurrent update is avoided? Thank you! masoud

9 let, 2 měsíce

2
1
0 0

knot 2 do not load zone after migrated from 1.6

by Josef Karliak

Good morning, I've migrated to knot2, configuration file was migrated by knot1to2 tool. Knot 2 loads, but to not load my DNSSEC signed zone (NSEC, not NSEC3). Knot2 is installed from suse dns server repo, version "knot2-2.1.1-1.1.x86_64". Error message: Apr 7 08:57:39 celer knotd[21676]: info: reloading configuration file '/etc/knot/knot.conf' Apr 7 08:57:39 celer knotd[21676]: info: configuration reloaded Apr 7 08:57:39 celer knotd[21676]: info: [domain.cz] zone loader, semantic check, completed Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] DNSSEC, failed to initialize (not found) Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] failed to store changes into journal (not found) Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] zone event 'load' failed (not found) Part of the configuration file: ... ... template: - id: "default" storage: "/var/lib/knot" zone: - domain: "domain.cz." file: "domain.cz" notify: "slave" acl: "acl_slave" semantic-checks: "on" ixfr-from-differences: "on" max-journal-size: "1073741824" dnssec-signing: "on" kasp-db: "/var/lib/knot/domain.cz.keys" ... ... Directory "/var/lib/knot/domain.cz.keys" contains zone private and public keys. What did I missed ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

9 let, 2 měsíce

3
8
0 0

notify question

by Brett

I'm fairly new to knot so this may be a strange question that I am just not quite getting the config for notify somewhere. I have this in my config: remotes { dnsp61 { address 192.168.1.173; } } zones { storage "/var/lib/knot"; dnssec-keydir "keys"; dnssec-enable off; brettcarr.uk { file "brettcarr.uk"; xfr-in dnsp61; # define 'master' for this zone notify-in dnsp61; # also allow NOTIFY from 'master' } The zone axfr's at startup no problems. The master (dnsp61) is sending notifies to the knot server (192.168.1.170) as you can see from tcpdump output below 18:24:55.310553 IP 192.168.1.173.42438 > 192.168.1.170.domain: 27743 notify [b2&3=0x2400] [1a] SOA? brettcarr.uk. (89) but the knot server is not reacting to the notify. Am I missing something? TIA -- Brett

9 let, 3 měsíce

2
2
0 0

Knot 2.x Installation instructions

by Volker Janzen

Hi, I tried to install Knot 2.x deb on Debian Jessie. Following the instructions for Knot 2.x, I got Knot 1.6 installed. Any advice how to install Knot 2 deb on Jessie? Regards Volker

9 let, 3 měsíce

2
4
0 0

[PATCH] rrset-dump: Use generic text representation for LOC with version != 0

by Robert Edmonds

LOC records are special. The first octet of a LOC record is a version number. According to RFC 1876: VERSION Version number of the representation. This must be zero. Implementations are required to check this field and make no assumptions about the format of unrecognized versions. This means that if a LOC record's VERSION field is not zero, the RR cannot be presented in the canonical presentation format, but it is still a valid wire-format RR. Currently, kdig prints a warning message "can't print whole section" and a LOC record with a blank RDATA when it attempts to dump a LOC record with a non-zero VERSION field. This commit modifies the version check in wire_loc_to_str() to fall back to the generic presentation format if the VERSION field is not 0. This particular case is even explicitly described as a use case for the generic presentation format in RFC 3597: Using the generic representation for the RDATA of an RR of known type can also be useful in the case of an RR type where the text format varies depending on a version, protocol, or similar field (or several) embedded in the RDATA when such a field has a value for which no text format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0. --- src/libknot/rrset-dump.c | 95 +++++++++++++++++++++++++----------------------- 1 file changed, 49 insertions(+), 46 deletions(-) diff --git a/src/libknot/rrset-dump.c b/src/libknot/rrset-dump.c index c71eae1..ffdd825 100644 --- a/src/libknot/rrset-dump.c +++ b/src/libknot/rrset-dump.c @@ -508,6 +508,47 @@ static void wire_len_data_encode_to_str(rrset_dump_params_t *p, p->ret = 0; } +static void wire_unknown_to_str(rrset_dump_params_t *p) +{ + int ret; + size_t in_len = p->in_max; + size_t out_len = 0; + + // Write unknown length header. + if (in_len > 0) { + ret = snprintf(p->out, p->out_max, "\\# %zu ", in_len); + } else { + ret = snprintf(p->out, p->out_max, "\\# 0"); + } + if (ret <= 0 || (size_t)ret >= p->out_max) { + return; + } + out_len = ret; + + // Fill in output. + p->out += out_len; + p->out_max -= out_len; + p->total += out_len; + + // Write hex data if any. + if (in_len > 0) { + // If wrap mode wrap line. + if (p->style->wrap) { + dump_string(p, BLOCK_INDENT); + if (p->ret != 0) { + return; + } + } + + wire_data_encode_to_str(p, &hex_encode, &hex_encode_alloc); + if (p->ret != 0) { + return; + } + } + + p->ret = 0; +} + static void wire_text_to_str(rrset_dump_params_t *p) { // First byte is string length. @@ -938,6 +979,14 @@ static void wire_loc_to_str(rrset_dump_params_t *p) // Read values. wire_ctx_t wire = wire_ctx_init_const(p->in, p->in_max); uint8_t version = wire_ctx_read_u8(&wire); + + // Version check. + if (version != 0) { + wire_unknown_to_str(p); + return; + } + + // Continue to read values. uint8_t size_w = wire_ctx_read_u8(&wire); uint8_t hpre_w = wire_ctx_read_u8(&wire); uint8_t vpre_w = wire_ctx_read_u8(&wire); @@ -953,11 +1002,6 @@ static void wire_loc_to_str(rrset_dump_params_t *p) p->in += wire_ctx_offset(&wire); p->in_max = wire_ctx_available(&wire); - // Version check. - if (version != 0) { - return; - } - // Latitude calculation. char lat_mark; uint32_t lat; @@ -1210,47 +1254,6 @@ static void wire_tsig_rcode_to_str(rrset_dump_params_t *p) p->ret = 0; } -static void wire_unknown_to_str(rrset_dump_params_t *p) -{ - int ret; - size_t in_len = p->in_max; - size_t out_len = 0; - - // Write unknown length header. - if (in_len > 0) { - ret = snprintf(p->out, p->out_max, "\\# %zu ", in_len); - } else { - ret = snprintf(p->out, p->out_max, "\\# 0"); - } - if (ret <= 0 || (size_t)ret >= p->out_max) { - return; - } - out_len = ret; - - // Fill in output. - p->out += out_len; - p->out_max -= out_len; - p->total += out_len; - - // Write hex data if any. - if (in_len > 0) { - // If wrap mode wrap line. - if (p->style->wrap) { - dump_string(p, BLOCK_INDENT); - if (p->ret != 0) { - return; - } - } - - wire_data_encode_to_str(p, &hex_encode, &hex_encode_alloc); - if (p->ret != 0) { - return; - } - } - - p->ret = 0; -} - static size_t dnskey_len(const uint8_t *rdata, const size_t rdata_len) { -- 2.7.0

9 let, 3 měsíce

2
1
0 0

Rate limiting

by John Bond

Hello All, Are there any rrl parameters similar to the following in bind. * nxdomains-per-second * referrals-per-second Thanks John

9 let, 3 měsíce

2
1
0 0

DNSTAP socket problem

by Matthew Pounsett

Hi .. I'm trying out the dnstap support in Knot, and I seem to have an issue getting it to write to a socket instead of a file. If I give it a file to write to, things seem to work as expected. When I write to a socket, the socket file is not created, and there don't appear to be any errors. Have I got something wrong? My very basic config and startup log is included below. --- server: rundir: /home/matt/etc/knot user: matt:staff listen: 0.0.0.0@5353 log: - target: /home/matt/etc/knot/logfile server: info zone: info any: info mod-dnstap: - id: capture_all sink: unix:/home/matt/etc/knot/capture.tap template: - id: default storage: /home/matt/etc/knot/zones kasp-db: /home/matt/etc/knot/kasp module: mod-dnstap/capture_all zone: - domain: myzone.test dnssec-signing: on --- 2016-02-23T18:09:47 info: Knot DNS 2.1.1 starting 2016-02-23T18:09:47 info: binding to interface '0.0.0.0@5353' 2016-02-23T18:09:47 info: changing GID to '60' 2016-02-23T18:09:47 info: changing UID to '1001' 2016-02-23T18:09:47 info: PID stored in '/home/matt/etc/knot/knot.pid' 2016-02-23T18:09:47 info: changed directory to / 2016-02-23T18:09:47 info: loading 1 zones 2016-02-23T18:09:47 info: [myzone.test] zone will be loaded, serial 0 2016-02-23T18:09:47 info: starting server 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, loaded key, tag 26654, algorithm 8, KSK yes, ZSK no, public no, active no 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, loaded key, tag 7468, algorithm 8, KSK no, ZSK yes, public yes, active yes 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, loaded key, tag 20456, algorithm 8, KSK yes, ZSK no, public yes, active yes 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, signing started 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, zone is up-to-date 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, next signing on 2016-02-29T23:43:54 2016-02-23T18:09:47 info: [myzone.test] loaded, serial 0 -> 2016022209 2016-02-23T18:09:47 info: server started as a daemon, PID 26600 2016-02-23T18:09:47 info: remote control, binding to '/home/matt/etc/knot/knot.sock' 2016-02-23T18:11:07 info: remote control, received command 'stop' 2016-02-23T18:11:07 info: stopping server 2016-02-23T18:11:07 info: updating zone timers database 2016-02-23T18:11:07 info: shutting down

9 let, 4 měsíce

2
3
0 0

Knot Zone Check

by Daniel Stirnimann

Dear all, knotc has a zone-check command. Is there a tool which can validate a zone file directly? I see that you have a DNS library which can load a zone file very fast (https://github.com/vavrusa/luajit-kdns). However this is missing the zone checker/validator. The stand alone zone check command line tool I was looking for would also verify DNSSEC signatures. Something like dnssec-verify (BIND). Daniel

9 let, 4 měsíce

3
2
0 0

Knot DNS 2.1.1 patch release

by Jan Včelak

Hello everyone. Knot DNS 2.1.1 by CZ.NIC Labs has been just declared stable. It mostly contains bug fixes. The update is highly recommended as some of the problems are quite critical. - We have resolved the problem with source address selection for UDP messages when the server is configured to listen on all available addresses (i.e., 0.0.0.0 or ::0). Prior to this release and depending on the networking configuration, the server could choose a wrong source address. - Duplicate private keys can be now imported into the KASP database. This is practical if you have the same signing key in the legacy format and share the key between multiple domains. Prior to this release, sharing the key was possible only with some hacks. - We have resolved a problem with duplicate NSEC record which had been returned for Wildcard No Data answers. In the new version, the record is inserted into the response only once. - We have fixed a possible server crash, which could happen during an incoming zone transfer when a server reload is requested. - The fix of a crash with many configured interfaces and threads was included in the previous release. However the fix was incomplete. We have found another related problems which are addressed in the new version. Thank you for the feedback and bug reports. And we are looking forward to hear back from you. :-) The sources are available on our server as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.1.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.1.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, 4 měsíce

2
1
0 0

Knot DNS 1.6.7 patch release

by Jan Včelak

Hello folks. CZ.NIC Labs just released Knot DNS 1.6.7. This patch release contains only a few improvements. Upgrade is not necessary but advised. - The server newly logs the change in the zone serial after IXFR transfers. Prior to this release, information about serial was logged only for AXFR transfers. This modification unifies the logging behavior. - We have added the 'timer-db' configuration option, which allows relocation of zone timer database. This is useful if you run multiple daemon instances sharing the same zone storage directory. - The RRL implementation newly supports zero value for the 'rate-limit-slip' option. With this setting, all responses for a flow exceeding the configured limit will be dropped. - The documentation for RRL was extended to include information about expected operational impact of various settings. As you can see, the changes are rather small. We will continue in this trend with the LTS version of Knot DNS. If you run Knot DNS 1.6 and look for a new features and improvements, please consider an early upgrade to Knot DNS 2.x. The sources are available on our server as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/1.6/NEWS Source archives: https://secure.nic.cz/files/knot-dns/knot-1.6.7.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.7.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.7.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.7.tar.gz.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, 4 měsíce

2
1
0 0

next week releases

by Jan Včelak

Hello list, this is just a quick note that we plan to do an ordinary bug fix release of Knot DNS 1.6.7 and Knot DNS 2.1.1 the next week. As for 2.1.1, we did some changes in the networking code and we want to make sure that everything is working correctly. If you can help us with testing we would be very happy. The tarball with sources for testing is available on our server: https://secure.nic.cz/files/knot-dns/knot-2.1.1-test.tar.xz Thank you. Cheers, Jan

9 let, 4 měsíce

2
4
0 0

Troubles compiling Knot 2.1

by Bruno Pagani

Hi, I’m trying to compile Knot 2.1, but it fails. Here is the error part: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -include ../../src/config.h -I./shared -I./lib -I./lib/dnssec -I../../src -I/usr/include/p11-kit-1 -fvisibility=hidden -D_FORTIFY_SOURCE=2 -march=native -O2 -pipe -fstack-protector-strong -fstack-check -Wall -Werror=format-security -Werror=implicit -fpredictive-commoning -MT lib/event/action/libdnssec_la-initial_key.lo -MD -MP -MF lib/event/action/.deps/libdnssec_la-initial_key.Tpo -c lib/event/action/initial_key.c -fPIC -DPIC -o lib/event/action/.libs/libdnssec_la-initial_key.o lib/binary.c: In function 'base64_decode_raw': lib/binary.c:47:2: warning: statement with no effect [-Wunused-value] nettle_len dst_size = dst_max_size; ^ lib/binary.c:47:13: error: expected ';' before 'dst_size' nettle_len dst_size = dst_max_size; ^ lib/binary.c:48:50: error: 'dst_size' undeclared (first use in this function) int result = nettle_base64_decode_update(&ctx, &dst_size, dst, src_len, src); ^ lib/binary.c:48:50: note: each undeclared identifier is reported only once for each function it appears in lib/binary.c:54:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ I suppose this has to do with the flags used on my system (Arch Linux) ? Thanks, Bruno

9 let, 4 měsíce

4
6
0 0

IP source on IPv6

by Alarig Le Lay

Hi, I’ve installed knot 2.0.2 on one of my server. It’s configured with three IPv6 and I manage their reliability with some source-specifi routing: alarig@bulbizarre ~ $ ip -6 route list | grep default default from 2001:470:1f13:138:715d:2fa0:b591:532f via fe80::20d:b9ff:fe3a:1fa1 dev eth0 metric 1024 default from 2a00:5881:4008:400::1 dev tun0 metric 1024 default from 2a01:240:fe00:82af:764f:b47e:d131:85e4 via fe80::20d:b9ff:fe3a:1fa1 dev eth0 metric 1024 default via fe80::20d:b9ff:fe3a:1fa1 dev eth0 metric 4 It works fine as I can ping those three IP from the same machine at the same moment. But, knot don’t take care of this and answer with the “nearest” IPv6 (like the IP source is calculated when you have several ones). bulbizarre ~ # tcpdump -i any host mc.swordarmor.fr 23:13:07.276493 IP6 2001:41d0:a:27e4::1.52203 > florizarre.swordarmor.fr.domain: 59831+ SOA? swordarmor.fr. (31) 23:13:07.276647 IP6 bulbizarre.swordarmor.fr.domain > 2001:41d0:a:27e4::1.52203: 59831*- 1/0/0 SOA (86) You can see that knot answer with 2001:470:1f13:138:715d:2fa0:b591:532f, which is the one chosen if I’m the initiator of the connection. Indeed, it works with my IRCd: 23:14:17.684155 IP6 2001:41d0:a:27e4::1.36490 > florizarre.swordarmor.fr.6697: Flags [P.], seq 53:106, ack 106, win 331, options [nop,nop,TS val 4047617704 ecr 1587664633], length 53 23:14:17.684301 IP6 florizarre.swordarmor.fr.6697 > 2001:41d0:a:27e4::1.36490: Flags [P.], seq 106:211, ack 106, win 240, options [nop,nop,TS val 1587724598 ecr 4047617704], length 105 23:14:22.555891 IP6 2001:41d0:a:27e4::1.34822 > bulbizarre.swordarmor.fr.6697: Flags [P.], seq 1:62, ack 61, win 331, options [nop,nop,TS val 4047618922 ecr 1587729432], length 61 23:14:22.555928 IP6 bulbizarre.swordarmor.fr.6697 > 2001:41d0:a:27e4::1.34822: Flags [.], ack 62, win 274, options [nop,nop,TS val 1587729469 ecr 4047618922], length 0 Is it a known bug? -- alarig

9 let, 4 měsíce

2
3
0 0

Knot Ubuntu update

by Volker Janzen

Hi, I did a "apt-get upgrade" on my Knot node. The package update fails with "Failed to initialize default key store (unknown error -13)." Can anyone tell me what that means? root@localhost:~# knotd --version knotd (Knot DNS), version 2.1.0 root@localhost:~# ps aux | grep knot knot 30048 0.0 0.6 1245236 6400 ? Ssl 16:08 0:00 /usr/sbin/knotd -d -c /etc/knot/knot.conf root@localhost:~# /etc/init.d/knot restart * Restarting Knot DNS server knotd [ OK ] root@localhost:~# ps aux | grep knot knot 30115 0.0 0.6 1245224 6200 ? Ssl 16:09 0:00 /usr/sbin/knotd -d -c /etc/knot/knot.conf root@localhost:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up knot (2.1.0-2+trusty+2) ... * Starting Knot DNS server knotd [ OK ] Failed to initialize default key store (unknown error -13). dpkg: error processing package knot (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: knot E: Sub-process /usr/bin/dpkg returned an error code (1) root@localhost:~# ps aux | grep knot knot 30115 0.0 0.6 1245236 6360 ? Ssl 16:09 0:00 /usr/sbin/knotd -d -c /etc/knot/knot.conf Kind regards, Volker

9 let, 5 měsíců

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users