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

by Ondřej Surý

Dear Knot Resolver users, CZ.NIC is proud to announce the release of Knot Resolver 1.3.0. The biggest feature of this release is the support for DNSSEC Validation in the forwarding mode, the feature many people were eagerly awaiting for. We have also squeezed refactoring of AD flag handling and several other bugfixes. The 1.3.0 is currently the recommended release to run at your recursive nameservers. Here's the 1.3.0 changelog: Security -------- - Refactor handling of AD flag and security status of resource records. In some cases it was possible for secure domains to get cached as insecure, even for a TLD, leading to disabled validation. It also fixes answering with non-authoritative data about nameservers. Improvements ------------ - major feature: support for forwarding with validation (#112). The old policy.FORWARD action now does that; the previous non-validating mode is still avaliable as policy.STUB except that also uses caching (#122). - command line: specify ports via @ but still support # for compatibility - policy: recognize 100.64.0.0/10 as local addresses - layer/iterate: *do* retry repeatedly if REFUSED, as we can't yet easily retry with other NSs while avoiding retrying with those who REFUSED - modules: allow changing the directory where modules are found, and do not search the default library path anymore. Bugfixes -------- - validate: fix insufficient caching for some cases (relatively rare) - avoid putting "duplicate" record-sets into the answer (#198) Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.3.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.0.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ 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

1
0
0 0

include statement does not seem to work since update to 2.5.1

by André Keller

Hi, we updated knot from 2.4.3 to 2.5.1 and the include statement does not seem to work anymore: error: config, file '/etc/knot/zones.conf', line 5, item 'domain', value 'example.net' (duplicate identifier) error: config, file '/etc/knot/knot.conf', line 73, include '' (duplicate identifier) error: failed to load configuration file '/etc/knot/knot.conf' (duplicate identifier) cat > /etc/knot/knot.conf << 'EOF' # THIS CONFIGURATION IS MANAGED BY PUPPET # see man 5 knot.conf for all available configuration options server: user: knot:knot listen: ["0.0.0.0@53", "::@53"] version: log: - target: syslog any: info key: - id: default algorithm: hmac-sha512 secret: pLEG3Z6uvMtKiQsmOp4tMDyyxENLyJGx8kIbud24tfHdY0uRO82Qix8D2opoA/rndcd2fdt9Ba1LhHDefCK1VQ== remote: - id: ns1 address: ["xxxx1", "yyyy1"] key: default - id: ns2 address: ["xxxx2", "yyyy2"] key: default - id: ns3 address: ["xxxx3", "yyyy3"] key: default acl: - id: notify_from_master action: notify address: ["xxxx1", "yyyy1"] key: default - id: transfer_to_slaves action: transfer address: ["xxxx2", "xxxx2", "xxxx3", "yyyy3"] key: default policy: - id: default_rsa algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 template: - id: default file: /var/lib/knot/zones/%s.zone kasp-db: /var/lib/knot/kasp storage: /var/lib/knot - id: master_default acl: ["transfer_to_slaves"] file: /var/lib/knot/zones/%s.zone ixfr-from-differences: on notify: ["ns2", "ns3"] serial-policy: unixtime storage: /var/lib/knot - id: master_dnssec acl: ["transfer_to_slaves"] dnssec-policy: default_rsa dnssec-signing: on file: /var/lib/knot/zones/%s.zone notify: ["ns2", "ns3"] storage: /var/lib/knot zonefile-sync: -1 - id: slave acl: ["notify_from_master"] master: ns1 serial-policy: unixtime storage: /var/lib/knot include: "/etc/knot/zones.conf" EOF cat > /etc/knot/zones.conf << 'EOF' # THIS CONFIGURATION IS MANAGED BY PUPPET # see man 5 knot.conf for all available configuration options zone: - domain: example.net template: slave - domain: example.com template: slave - domain: example.org template: slave EOF If I add the content from zones.conf into knot.conf it works. It seems like the included file gets parsed twice, when I add a domain twice, it will fail at the line with the duplicate zone. If there are no duplicate domains in the file, it always fails at the first domain found. Is this a bug or something with our setup? Regards André

8 let

3
4
0 0

Knot DNS 2.5.1 released

by Ondřej Surý

Dear Knot DNS users, CZ.NIC has released Knot DNS 2.5.1 that fixes issues that some users might experience when upgrading existing DNSSEC enabled installations of Knot DNS. Knot DNS 2.5.1 (2017-06-07) =========================== Bugfixes: --------- - pykeymgr no longer crash on empty json files in the KASP DB directory - pykeymgr no longer imports keys in the "removed" state - Imported keys in the "removed" state no longer makes knotd to crash - Including an empty configuration directory no longer makes knotd to crash - pykeymgr is distributed and installed to the distribution tarball Thank you for using Knot DNS. Feel free to write us, fill an issue or just say thank you if you are happy with Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.5.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.5.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ 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, 1 měsíc

1
0
0 0

Knot DNS 2.5.0 and 2.4.4 releases

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has just released the 2.5.0 version of Knot DNS with the following features: - New LMDB-based KASP database, which no longer uses JSON files and provides better performance and robustness. With this change, the keymgr syntax has been redesigned and new pykeymgr utility was introduced for migration from the previous version. - Automatic DNSSEC signing newly supports KSK rollover and optional shared KSK keys. During the key submission, CDS and CDNSKEY records are generated. A periodical checking for new DS at the masters or a maximum time interval can be configured for automatic finalization of the rollover or by manual calling the zone-ksk-submitted knotc command. - Completely new query module API with dynamic loading functionality. So, for example, the dnstap module can be a separate package in a repository. - Zone events freeze and thaw knotc operations, which allow reliable manual zone modification along with possible automatic modifications. - Zone journal can be used to store full zone contents beside the subsequent zone differences if the zone file synchronization is disabled. This configuration is especially interesting on slave servers. Manual zone flush is still possible with an optional destination directory parameter. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.0/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.5.0.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.5.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.5/html/ In addition to that, Knot DNS 2.4.4 patch release has been released, including some event timing and journal fixes. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.4/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.4.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.4.4.tar.xz.asc Regards, Daniel

8 let, 1 měsíc

3
6
0 0

Is output that there is no http module

by Yoshihito Horigome

8 let, 1 měsíc

2
2
0 0

knot-resolver configure for localhost stub zone

by Jerry Lundström

Hi, I have the following configuration working for unbound, how can I get the same behavior working in knot-resolver? server: do-not-query-localhost: no domain-insecure: "stubzone" local-zone: "stubzone" nodefault stub-zone: name: "stubzone" stub-addr: 127.0.0.2 I run this for various testing and what I want is to redirect a zone to a local DNS server and I also what the resolver to follow any delegations it receives. Cheers, Jerry

8 let, 2 měsíce

2
1
0 0

DNSSEC ZSK Rollover information

by knot.dirk＠o.banes.ch

Dear all, I setup knot to do an automatic rollover of the zsk after 180 days policy: - id: policy keystore: keystore manual: off single-type-signing: off algorithm: rsasha256 ksk-size: 4096 zsk-size: 2048 zsk-lifetime: 180d propagation-delay: 1d However I can not see on which date this will be. root@vserver:~# keymgr zone key list yyy.ch - 28f58xx 6862 - 79fb61b77xx 63816 root@vserver:~# keymgr zone key list yyy.ch - 28f58xx 6862 - 79fb61b77xx 63816 root@vserver:~# keymgr zone key show yyy.ch Name of zone and key have to be specified. root@vserver:~# keymgr zone key show yyy.ch 28f58xx id 28f58xx keytag 6862 algorithm 8 size 4096 flags 257 publish 1491505038 active 1491505038 retire 0 remove 0 root@vserver:~# keymgr zone key show yyy.ch 79fb61b77xx id 79fb61b77xx keytag 63816 algorithm 8 size 2048 flags 256 publish 1491504999 active 1491504999 retire 0 remove 0 How do I know it is activated and when it will be ? I imported the keys - can this be the reason ? Thank you and best regards Dirk

8 let, 2 měsíce

2
1
0 0

Question on DNSSEC

by Volker Janzen

Hi all, I'm currently looking for alternatives which do automatic DNSSEC signing as a master DNS server. I run a Knot secondary instance and added a manual and auto signing zone, because I want to understand the differences and which is better for my needs. I added this to my knot.conf policy: - id: rsa algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 - id: manual manual: on zone: - domain: "auto.test." file: "/etc/knot/master/auto.test.zone" dnssec-signing: on dnssec-policy: default - domain: "manual.test." file: "/etc/knot/master/manual.test.zone" dnssec-signing: on dnssec-policy: manual I'm not sure about how some things work, perhaps someone can answer my questions. When auto signing is used, the ZSKs are rolled automated? And the KSK rollover is not possible at all? Even not manual? For manual mode, I followed these steps to generate the keys: $ keymgr zone key generate manual.test algorithm RSASHA256 size 1024 $ keymgr zone key generate manual.test algorithm ECDSAP256SHA256 size 256 This results in dig @localhost DNSKEY manual.test +short 256 3 8 AwEAAbGES3TH8jPCIhcdc93dbDNoUkDn5YmviG2/lkCESDcIvzpRFjsC ATAZEIEo1LosM6cALS8AVkxKK/BSOpuvLHvhX7O+ny7eX5X/C2PHnGs+ WMieIhbjLJWdIsNCMhSqQ7vTlguFmHbUdyzV+8dnrMl1GSpdSc1P0Fyp vjxDM5+H 256 3 13 H+qtCYv9A0RlqQCOtDyGGEMhVgn92wPdZ+WrqRAqb/MJ3RzdDSyhaX2p B/TU5F8mQccrVIdiJriT+zmWpoW9sA== I don't understand why there is no DNSKEY with SEP set. Shouldn't it be there? Regards, Volker

8 let, 2 měsíce

2
1
0 0

Knot Resolver 1.2.6 release

by Ondřej Surý

Dear Knot Resolver users, a bugfix release of Knot Resolver 1.2.6 has been released. We have fixed a nasty bug that caused some names to stop resolving if there was a packet lost. We apologize for any inconvenience this might have caused. And thank to all Turris Omnia users and Stéphane Bortzmeyer who provided valuable debugging information. In this release, we have also fixed a handling of AD flag for NODATA answers not covered due opt-out NSEC3 and several other small bugs. The update from 1.2.5 to 1.2.6 is recommended. The update from 1.1.x to 1.2.x branch is strongly recommended, the 1.1.x branch is no longer supported. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.6/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.6.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.6.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ 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, 2 měsíce

1
0
0 0

When reverse lookup is done, Block is outputted

by Horigome Yoshihito

Hello, I set it up as below and forward it to kometch.local of the internal domain which is the stub zone, but when reverse lookup it will be output as block. kometch@dns02:~$ drill 192.168.122.1 -x ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 43732 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; 1.122.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: ;; AUTHORITY SECTION: blocked. 900 IN SOA blocked. . 0 3600 900 604800 900 ;; ADDITIONAL SECTION: ;; Query time: 1 msec ;; SERVER: 192.168.122.223 ;; WHEN: Fri Apr 14 22:13:57 2017 ;; MSG SIZE rcvd: 86 # kresd.conf modules = { 'hints > iterate', -- Hints AFTER iterate 'policy > hints', -- Policy AFTER hints 'view < rrcache', -- View BEFORE rrcache predict = { window = 30, -- 15 minutes sampling window period = 24*(60/15) -- track last 6 hours }, 'daf', 'stats' } modules.list() -- Check module call order --stub forward policy.add(policy.pattern(policy.FORWARD('192.168.122.223@10053', '192.168.122.224@10053'), '\7kometch\5local')) In this case, how should it be set? Best regards.

8 let, 2 měsíce

2
6
0 0

Upgrade broke journal

by Bastien Durel

Hello, For the second time after an upgrade, one of my knot instance did not restart. (actually, it restarts but does not respond to queries) I got theses messages in log : 2017-03-27T17:11:16 warning: [durel.eu.] discontinuity in chages history (2017032310 -> 2017032309), dropping older changesets 2017-03-27T17:11:16 error: [durel.org.] zone event 'load' failed (invalid parameter) 2017-03-27T17:11:16 error: [durel.eu.] failed to store changes into journal (invalid parameter) 2017-03-27T17:11:16 error: [durel.eu.] zone event 'load' failed (invalid parameter) 2017-03-27T17:11:27 warning: [durel.eu.] discontinuity in chages history (2017032310 -> 2017032309), dropping older changesets 2017-03-27T17:11:27 error: [durel.eu.] failed to store changes into journal (invalid parameter) 2017-03-27T17:11:27 error: [durel.eu.] zone event 'load' failed (invalid parameter) 2017-03-27T17:11:27 warning: [durel.org.] discontinuity in chages history (2017032310 -> 2017032309), dropping older changesets 2017-03-27T17:11:27 error: [durel.org.] failed to store changes into journal (invalid parameter) 2017-03-27T17:11:27 error: [durel.org.] zone event 'load' failed (invalid parameter) removing all files in journal/ directory and restarting it leads to normal behaviour. Do you have hints about these error ? Thanks, -- Bastien Durel

8 let, 3 měsíce

2
4
0 0

Re: [knot-dns-users] Knot DNS 2.4.3 released

by Tobias Geerinckx-Rice

Hullo, Thanks for a new version of Knot DNS! Knot DNS 2.4.3 is now available in the GNU Guix[1] package manager & operating system. Perhaps this might warrant an entry under ‘Distribution packages’ on https://www.knot-dns.cz/download/? I also noticed that the ‘Full Knot DNS 2.4.3 changelog’ link at https://www.knot-dns.cz/2017-04-11-version-243.html still points to the change log for 2.4.2. Kind regards, T G-R (not subscribed to this list) [1]: https://gnu.org/s/guix

8 let, 3 měsíce

2
1
0 0

Knot DNS 2.4.3 released

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release the 2.4.3 release of Knot DNS. This release contains many improvements over 2.3.x release of Knot DNS. The Knot DNS 2.4.x is the new stable branch. Starting from the 2.4.0 release we are going to support current stable (2.4.x) and previous stable (2.3.x) branches, and at the same time we are deprecating previous Knot DNS 1.6.x release. The changelog for Knot DNS 2.4.3 is as follows: Improvements: ------------- - Speed-up of rdata addition into a huge rrset - Introduce check of minumum timeout for next refresh - Dnsproxy module can forward all queries without local resolving Bugfixes: -------- - Transfer of a huge rrset goes into an infinite loop - Huge response over TCP contains useless TC bit instead of SERVFAIL - Failed to build utilities with disabled daemon - Memory leaks during keys removal - Rough TSIG packet reservation causes early truncation - Minor out-of-bounds string termination write in rrset dump - Server crash during stop if failed to open timers DB - Failed to compile on OS X older than Sierra - Poor minimum UDP-max-size configuration check - Failed to receive one-record-per-message IXFR-style AXFR - Kdig timeouts when receiving RCODE != NOERROR on subsequent transfer message Thank you for using Knot DNS. Feel free to write us, fill an issue or just say thank you if you are happy with Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.4.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.4.3.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ 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, 3 měsíce

1
1
0 0

Knot na CentOS/Debian

by Ondřej Ašenbryl, WEDOS

Dobrý den, již nějakou dobu se trápím s kompilací Knot DNS 2 na CentOS. Nedaří se žádný z verzí 2+ na CentOS 6 ani 7, ani na Debianu. Problém je s knihovnami gnutls a nettle. Ať dělám co dětám, tak mi configure skript končí chybou "configure: error: Package requirements (gnutls >= 3.3 nettle) were not met: ...". GnuTLS se podařilo aktualizovat do verze 3.3, s nettle je všude nějaký problém. Chtěl jsem proto poprosit, zda s tím máte již zkušenost a příp. nějaký osvědčený návod. Knot ve verzi 1.6.X byl naprosto bez problémů, toto se ale bohužel, i po mnoha pokusech, nedaří. Velice děkuji za odpověď, Ondřej Ašenbryl

8 let, 3 měsíce

1
0
0 0

Knot Resolver 1.2.5 release

by Ondřej Surý

Dear Knot Resolver users, a bugfix release of Knot Resolver 1.2.5 has been released. This is a packed release that contains fixes to the DNSSEC validation as well as other improvements and little bugfixes: Security -------- - layer/validate: clear AD if closest encloser proof has opt-outed NSEC3 (#169) - layer/validate: check if NSEC3 records in wildcard expansion proof has an opt-out - dnssec/nsec: missed wildcard no-data answers validation has been implemented Improvements ------------ - modules/dnstap: a DNSTAP support module (Contributed by Vicky Shrestha) - modules/workarounds: a module adding workarounds for known DNS protocol violators - layer/iterate: fix logging of glue addresses - kr_bitcmp: allow bits=0 and consequently 0.0.0.0/0 matches in view and renumber modules. - modules/padding: Improve default padding of responses (Contributed by Daniel Kahn Gillmor) - New kresc client utility (experimental; don't rely on the API yet) Bugfixes -------- - trust anchors: Improve trust anchors storage format (#167) - trust anchors: support non-root TAs, one domain per file - policy.DENY: set AA flag and clear AD flag - lib/resolve: avoid unnecessary DS queries - lib/nsrep: don't treat servers with NOIP4 + NOIP6 flags as timeouted - layer/iterate: During packet classification (answer vs. referral) don't analyze AUTHORITY section in authoritative answer if ANSWER section contains records that have been requested The update from 1.2.4 to 1.2.5 is recommended. The update from 1.1.x to 1.2.x branch is strongly recommended, the 1.1.x branch is no longer supported. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.5/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.5.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.5.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 3 měsíce

1
0
0 0

odd delays when a fresh kresd 1.2.4 tries to resolve www.ietf.org

by Daniel Kahn Gillmor

hey knot folks-- I'm running kresd 1.2.4. If i start it with an empty/missing cache, and then receive a query for an A record for "www.ietf.org", there is a substantial delay in the response. I'm trying to debug the delay from the kresd logging output (gathered via systemd's journald) and i don't understand what's happening. I'm attaching the logs from the server and client. The client (kdig), is doing three queries, waiting 10 seconds after one query completes before sending the next query. timestamps of both sides are in UTC. In particular, the delay appears to be related to resolving AAAA records for'ns1.yyz1.afilias-nst.info, but i don't know why. i do note that the first time it shows up it's answered with "=> using root hints", but then subsequent times don't seem to say that. I'm not sure what this means. Note the multiple pauses in the server timeline, as the resolver seems to go quiet. can anyone reproduce this result, or help me to interpret the logs? Regards, --dkg 0 dkg@alice:~$ date -u -Ins; dig +tls @dns.cmrg.net www.ietf.org; sleep 10; date -u -Ins; dig +tls @dns.cmrg.net www.ietf.org; sleep 10; date -u -Ins; dig +tls @dns.cmrg.net www.ietf.org; date -u -Ins 2017-03-29T15:29:23,075479458+00:00 ;; TLS session (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 38148 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.ietf.org. IN A ;; Received 30 B ;; Time 2017-03-29 10:29:36 CDT ;; From 199.58.81.218@853(TCP) in 12702.6 ms 2017-03-29T15:29:46,218745354+00:00 ;; TLS session (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1748 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.ietf.org. IN A ;; ANSWER SECTION: www.ietf.org. 1779 IN CNAME www.ietf.org.cdn.cloudflare.net. www.ietf.org.cdn.cloudflare.net. 286 IN A 104.20.0.85 www.ietf.org.cdn.cloudflare.net. 286 IN A 104.20.1.85 ;; Received 138 B ;; Time 2017-03-29 10:29:47 CDT ;; From 199.58.81.218@853(TCP) in 65.0 ms 2017-03-29T15:29:57,033222048+00:00 ;; TLS session (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 40041 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.ietf.org. IN A ;; ANSWER SECTION: www.ietf.org. 1768 IN CNAME www.ietf.org.cdn.cloudflare.net. www.ietf.org.cdn.cloudflare.net. 275 IN A 104.20.0.85 www.ietf.org.cdn.cloudflare.net. 275 IN A 104.20.1.85 ;; Received 138 B ;; Time 2017-03-29 10:29:57 CDT ;; From 199.58.81.218@853(TCP) in 66.2 ms 2017-03-29T15:29:57,356839607+00:00 0 dkg@alice:~$ Mar 29 15:29:23.073292 systemd[1]: Starting Knot DNS Resolver daemon... Mar 29 15:29:23.138659 kresd[15749]: [tls] RFC 7858 OOB key-pin (0): pin-sha256="3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=" Mar 29 15:29:23.139305 kresd[15749]: [tls] RFC 7858 OOB key-pin (1): pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=" Mar 29 15:29:23.140125 kresd[15749]: [ ta ] keyfile '/usr/share/dns/root.key': not writeable, starting in unmanaged mode Mar 29 15:29:23.141499 kresd[15749]: [ ta ] key: 19036 state: Valid Mar 29 15:29:23.141499 kresd[15749]: [ ta ] new state of root trust anchors: Mar 29 15:29:23.141499 kresd[15749]: . 172800 DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 Mar 29 15:29:23.142429 systemd[1]: Started Knot DNS Resolver daemon. Mar 29 15:29:23.487464 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'A' Mar 29 15:29:23.488145 kresd[15749]: [18605][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:23.488442 kresd[15749]: [18605][resl] => using root hints Mar 29 15:29:23.488672 kresd[15749]: [57308][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:23.488897 kresd[15749]: [57308][plan] plan '.' type 'DNSKEY' Mar 29 15:29:23.489121 kresd[15749]: [35296][iter] '.' type 'DNSKEY' id was assigned, parent id 57308 Mar 29 15:29:23.489443 kresd[15749]: [35296][resl] => querying: '2001:dc3::35' score: 10 zone cut: '.' m12n: '.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:23.569419 kresd[15749]: [35296][iter] <= rcode: NOERROR Mar 29 15:29:23.570171 kresd[15749]: [35296][vldr] <= parent: updating DNSKEY Mar 29 15:29:23.570557 kresd[15749]: [35296][vldr] <= answer valid, OK Mar 29 15:29:23.570951 kresd[15749]: [35296][resl] <= server: '2001:dc3::35' rtt: 81 ms Mar 29 15:29:23.571238 kresd[15749]: [38748][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:23.571491 kresd[15749]: [38748][resl] => querying: '202.12.27.33' score: 10 zone cut: '.' m12n: 'org.' type: 'NS' proto: 'udp' Mar 29 15:29:23.656393 kresd[15749]: [38748][iter] <= using glue for 'c0.org.afilias-nst.info.': '199.19.53.1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'c0.org.afilias-nst.info.': '2001:500:b::1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'b0.org.afilias-nst.org.': '199.19.54.1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'b0.org.afilias-nst.org.': '2001:500:c::1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'a2.org.afilias-nst.info.': '199.249.112.1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'a2.org.afilias-nst.info.': '2001:500:40::1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'd0.org.afilias-nst.org.': '199.19.57.1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'd0.org.afilias-nst.org.': '2001:500:f::1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'a0.org.afilias-nst.info.': '199.19.56.1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'a0.org.afilias-nst.info.': '2001:500:e::1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'b2.org.afilias-nst.org.': '199.249.120.1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= using glue for 'b2.org.afilias-nst.org.': '2001:500:48::1' Mar 29 15:29:23.657407 kresd[15749]: [38748][iter] <= referral response, follow Mar 29 15:29:23.657407 kresd[15749]: [38748][vldr] <= DS: OK Mar 29 15:29:23.657407 kresd[15749]: [38748][vldr] <= answer valid, OK Mar 29 15:29:23.657407 kresd[15749]: [38748][resl] <= server: '202.12.27.33' rtt: 85 ms Mar 29 15:29:23.657407 kresd[15749]: [15657][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:23.657407 kresd[15749]: [15657][plan] plan 'org.' type 'DNSKEY' Mar 29 15:29:23.657407 kresd[15749]: [52268][iter] 'org.' type 'DNSKEY' id was assigned, parent id 15657 Mar 29 15:29:23.657407 kresd[15749]: [52268][resl] => querying: '2001:500:f::1' score: 10 zone cut: 'org.' m12n: 'oRg.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:23.743211 kresd[15749]: [52268][iter] <= rcode: NOERROR Mar 29 15:29:23.743211 kresd[15749]: [52268][vldr] <= parent: updating DNSKEY Mar 29 15:29:23.743211 kresd[15749]: [52268][vldr] <= answer valid, OK Mar 29 15:29:23.743211 kresd[15749]: [52268][resl] <= server: '2001:500:f::1' rtt: 82 ms Mar 29 15:29:23.743211 kresd[15749]: [ 5685][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:23.743211 kresd[15749]: [ 5685][resl] => querying: '199.19.57.1' score: 10 zone cut: 'org.' m12n: 'ieTF.ORg.' type: 'NS' proto: 'udp' Mar 29 15:29:23.834259 kresd[15749]: [ 5685][iter] <= referral response, follow Mar 29 15:29:23.834259 kresd[15749]: [ 5685][vldr] <= DS: OK Mar 29 15:29:23.834259 kresd[15749]: [ 5685][vldr] <= answer valid, OK Mar 29 15:29:23.834259 kresd[15749]: [ 5685][resl] <= server: '199.19.57.1' rtt: 93 ms Mar 29 15:29:23.834259 kresd[15749]: [14306][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:23.834259 kresd[15749]: [14306][plan] plan 'ietf.org.' type 'DNSKEY' Mar 29 15:29:23.834259 kresd[15749]: [35015][iter] 'ietf.org.' type 'DNSKEY' id was assigned, parent id 14306 Mar 29 15:29:23.834259 kresd[15749]: [35015][plan] plan 'ns1.yyz1.afilias-nst.info.' type 'AAAA' Mar 29 15:29:23.834259 kresd[15749]: [17193][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:23.834259 kresd[15749]: [17193][resl] => using root hints Mar 29 15:29:23.834259 kresd[15749]: [28187][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:23.834259 kresd[15749]: [28187][plan] plan '.' type 'DNSKEY' Mar 29 15:29:23.834259 kresd[15749]: [ 5094][iter] '.' type 'DNSKEY' id was assigned, parent id 28187 Mar 29 15:29:23.834259 kresd[15749]: [ 5094][ rc ] => satisfied from cache Mar 29 15:29:23.834259 kresd[15749]: [ 5094][iter] <= rcode: NOERROR Mar 29 15:29:23.834259 kresd[15749]: [ 5094][vldr] <= parent: updating DNSKEY Mar 29 15:29:23.834259 kresd[15749]: [ 5094][vldr] <= answer valid, OK Mar 29 15:29:23.834259 kresd[15749]: [16944][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:23.834259 kresd[15749]: [16944][resl] => querying: '2001:500:9f::42' score: 10 zone cut: '.' m12n: 'iNfO.' type: 'NS' proto: 'udp' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'a0.info.afilias-nst.info.': '199.254.31.1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'a0.info.afilias-nst.info.': '2001:500:19::1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'a2.info.afilias-nst.info.': '199.249.113.1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'a2.info.afilias-nst.info.': '2001:500:41::1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'b0.info.afilias-nst.org.': '199.254.48.1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'b0.info.afilias-nst.org.': '2001:500:1a::1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'b2.info.afilias-nst.org.': '199.249.121.1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'b2.info.afilias-nst.org.': '2001:500:49::1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'c0.info.afilias-nst.info.': '199.254.49.1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'c0.info.afilias-nst.info.': '2001:500:1b::1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'd0.info.afilias-nst.org.': '199.254.50.1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= using glue for 'd0.info.afilias-nst.org.': '2001:500:1c::1' Mar 29 15:29:23.870105 kresd[15749]: [16944][iter] <= referral response, follow Mar 29 15:29:23.870105 kresd[15749]: [16944][vldr] <= DS: OK Mar 29 15:29:23.870105 kresd[15749]: [16944][vldr] <= answer valid, OK Mar 29 15:29:23.870105 kresd[15749]: [16944][resl] <= server: '2001:500:9f::42' rtt: 35 ms Mar 29 15:29:23.870105 kresd[15749]: [16734][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:23.870105 kresd[15749]: [16734][plan] plan 'info.' type 'DNSKEY' Mar 29 15:29:23.870105 kresd[15749]: [43055][iter] 'info.' type 'DNSKEY' id was assigned, parent id 16734 Mar 29 15:29:23.870105 kresd[15749]: [43055][resl] => querying: '2001:500:1c::1' score: 10 zone cut: 'info.' m12n: 'info.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:23.951853 kresd[15749]: [43055][iter] <= rcode: NOERROR Mar 29 15:29:23.951853 kresd[15749]: [43055][vldr] <= parent: updating DNSKEY Mar 29 15:29:23.951853 kresd[15749]: [43055][vldr] <= answer valid, OK Mar 29 15:29:23.951853 kresd[15749]: [43055][resl] <= server: '2001:500:1c::1' rtt: 81 ms Mar 29 15:29:23.951853 kresd[15749]: [19236][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:23.951853 kresd[15749]: [19236][resl] => querying: '199.254.50.1' score: 10 zone cut: 'info.' m12n: 'AFIliaS-nST.INfo.' type: 'NS' proto: 'udp' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'a0.dig.afilias-nst.info.': '65.22.6.1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'a0.dig.afilias-nst.info.': '2a01:8840:6::1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'b0.dig.afilias-nst.info.': '65.22.7.1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'b0.dig.afilias-nst.info.': '2a01:8840:7::1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'c0.dig.afilias-nst.info.': '65.22.8.1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'c0.dig.afilias-nst.info.': '2a01:8840:8::1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'd0.dig.afilias-nst.info.': '65.22.9.1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= using glue for 'd0.dig.afilias-nst.info.': '2a01:8840:9::1' Mar 29 15:29:24.047047 kresd[15749]: [19236][iter] <= referral response, follow Mar 29 15:29:24.047047 kresd[15749]: [19236][vldr] <= DS doesn't exist, going insecure Mar 29 15:29:24.047047 kresd[15749]: [19236][vldr] <= parent: updating DS Mar 29 15:29:24.047047 kresd[15749]: [19236][vldr] <= answer valid, OK Mar 29 15:29:24.047047 kresd[15749]: [19236][resl] <= server: '199.254.50.1' rtt: 91 ms Mar 29 15:29:24.047047 kresd[15749]: [52860][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:24.047047 kresd[15749]: [52860][plan] plan 'afilias-nst.info.' type 'DS' Mar 29 15:29:24.047047 kresd[15749]: [ 8943][iter] 'afilias-nst.info.' type 'DS' id was assigned, parent id 52860 Mar 29 15:29:24.047047 kresd[15749]: [56178][iter] 'afilias-nst.info.' type 'DS' id was assigned, parent id 52860 Mar 29 15:29:24.047047 kresd[15749]: [56178][resl] => querying: '2001:500:1b::1' score: 10 zone cut: 'info.' m12n: 'afiLIas-nst.inFO.' type: 'DS' proto: 'udp' Mar 29 15:29:24.078527 kresd[15749]: [56178][iter] <= rcode: NOERROR Mar 29 15:29:24.078527 kresd[15749]: [56178][ pc ] => answer cached for TTL=900 Mar 29 15:29:24.078527 kresd[15749]: [56178][resl] <= server: '2001:500:1b::1' rtt: 34 ms Mar 29 15:29:24.078527 kresd[15749]: [ 5798][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:24.078527 kresd[15749]: [ 5798][plan] plan 'afilias-nst.info.' type 'DS' Mar 29 15:29:24.078527 kresd[15749]: [33359][iter] 'afilias-nst.info.' type 'DS' id was assigned, parent id 5798 Mar 29 15:29:24.078527 kresd[15749]: [33359][ pc ] => satisfied from cache Mar 29 15:29:24.078527 kresd[15749]: [33359][iter] <= rcode: NOERROR Mar 29 15:29:24.078527 kresd[15749]: [33359][vldr] <= cached insecure response, going insecure Mar 29 15:29:24.078527 kresd[15749]: [23241][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:24.078527 kresd[15749]: [ 9532][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:25.338465 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'AAAA' Mar 29 15:29:25.339002 kresd[15749]: [30985][iter] 'www.ietf.org.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.339277 kresd[15749]: [44238][iter] 'www.ietf.org.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.339512 kresd[15749]: [44238][resl] => querying: '2001:500:48::1' score: 10 zone cut: 'org.' m12n: 'IeTF.org.' type: 'NS' proto: 'udp' Mar 29 15:29:25.366290 kresd[15749]: [44238][iter] <= referral response, follow Mar 29 15:29:25.366737 kresd[15749]: [44238][vldr] <= DS: OK Mar 29 15:29:25.367264 kresd[15749]: [44238][vldr] <= answer valid, OK Mar 29 15:29:25.367264 kresd[15749]: [44238][resl] <= server: '2001:500:48::1' rtt: 27 ms Mar 29 15:29:25.367264 kresd[15749]: [39313][iter] 'www.ietf.org.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.367264 kresd[15749]: [39313][plan] plan 'ietf.org.' type 'DNSKEY' Mar 29 15:29:25.367264 kresd[15749]: [35025][iter] 'ietf.org.' type 'DNSKEY' id was assigned, parent id 39313 Mar 29 15:29:25.367264 kresd[15749]: [35025][plan] plan 'ns1.yyz1.afilias-nst.info.' type 'AAAA' Mar 29 15:29:25.367264 kresd[15749]: [13190][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35025 Mar 29 15:29:25.367264 kresd[15749]: [11040][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35025 Mar 29 15:29:25.367264 kresd[15749]: [11040][resl] => querying: '2001:500:41::1' score: 10 zone cut: 'info.' m12n: 'AFIliAs-NsT.iNfO.' type: 'NS' proto: 'udp' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'a0.dig.afilias-nst.info.': '2a01:8840:6::1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'a0.dig.afilias-nst.info.': '65.22.6.1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'b0.dig.afilias-nst.info.': '2a01:8840:7::1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'b0.dig.afilias-nst.info.': '65.22.7.1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'c0.dig.afilias-nst.info.': '2a01:8840:8::1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'c0.dig.afilias-nst.info.': '65.22.8.1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'd0.dig.afilias-nst.info.': '2a01:8840:9::1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= using glue for 'd0.dig.afilias-nst.info.': '65.22.9.1' Mar 29 15:29:25.383557 kresd[15749]: [11040][iter] <= referral response, follow Mar 29 15:29:25.383557 kresd[15749]: [11040][vldr] <= DS doesn't exist, going insecure Mar 29 15:29:25.383557 kresd[15749]: [11040][vldr] <= parent: updating DS Mar 29 15:29:25.383557 kresd[15749]: [11040][vldr] <= answer valid, OK Mar 29 15:29:25.383557 kresd[15749]: [11040][resl] <= server: '2001:500:41::1' rtt: 16 ms Mar 29 15:29:25.383557 kresd[15749]: [22805][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35025 Mar 29 15:29:25.383557 kresd[15749]: [22805][plan] plan 'afilias-nst.info.' type 'DS' Mar 29 15:29:25.383557 kresd[15749]: [44795][iter] 'afilias-nst.info.' type 'DS' id was assigned, parent id 22805 Mar 29 15:29:25.383557 kresd[15749]: [44795][ pc ] => satisfied from cache Mar 29 15:29:25.383557 kresd[15749]: [44795][iter] <= rcode: NOERROR Mar 29 15:29:25.383557 kresd[15749]: [44795][vldr] <= cached insecure response, going insecure Mar 29 15:29:25.383557 kresd[15749]: [25751][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35025 Mar 29 15:29:25.383557 kresd[15749]: [25751][resl] => querying: '2a01:8840:9::1' score: 10 zone cut: 'afilias-nst.info.' m12n: 'yYz1.AFilias-nst.InFO.' type: 'NS' proto: 'udp' Mar 29 15:29:25.478535 kresd[15749]: [25751][iter] <= rcode: NOERROR Mar 29 15:29:25.478535 kresd[15749]: [25751][iter] <= found cut, retrying with non-minimized name Mar 29 15:29:25.478535 kresd[15749]: [25751][resl] <= server: '2a01:8840:9::1' rtt: 94 ms Mar 29 15:29:25.478535 kresd[15749]: [53313][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35025 Mar 29 15:29:25.478535 kresd[15749]: [53313][resl] => querying: '65.22.9.1' score: 10 zone cut: 'afilias-nst.info.' m12n: 'nS1.YYZ1.AFIlIAs-NSt.INfO.' type: 'AAAA' proto: 'udp' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'c0.dig.afilias-nst.info.': '65.22.8.1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'c0.dig.afilias-nst.info.': '2a01:8840:8::1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'b0.dig.afilias-nst.info.': '65.22.7.1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'b0.dig.afilias-nst.info.': '2a01:8840:7::1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'a0.dig.afilias-nst.info.': '65.22.6.1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'a0.dig.afilias-nst.info.': '2a01:8840:6::1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'd0.dig.afilias-nst.info.': '65.22.9.1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= using glue for 'd0.dig.afilias-nst.info.': '2a01:8840:9::1' Mar 29 15:29:25.569438 kresd[15749]: [53313][iter] <= referral response, follow Mar 29 15:29:25.569438 kresd[15749]: [53313][resl] <= server: '65.22.9.1' rtt: 90 ms Mar 29 15:29:25.569438 kresd[15749]: [61567][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35025 Mar 29 15:29:25.569438 kresd[15749]: [61567][resl] => querying: '2a01:8840:8::1' score: 10 zone cut: 'yyz1.afilias-nst.info.' m12n: 'Ns1.YyZ1.AFiLiAS-Nst.InFO.' type: 'AAAA' proto: 'udp' Mar 29 15:29:25.579537 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'A' Mar 29 15:29:25.579537 kresd[15749]: [45473][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.579537 kresd[15749]: [47453][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.579537 kresd[15749]: [47453][resl] => querying: '2001:500:c::1' score: 10 zone cut: 'org.' m12n: 'iETf.orG.' type: 'NS' proto: 'udp' Mar 29 15:29:25.607596 kresd[15749]: [61567][iter] <= rcode: NOERROR Mar 29 15:29:25.607596 kresd[15749]: [61567][resl] <= server: '2a01:8840:8::1' rtt: 34 ms Mar 29 15:29:25.607596 kresd[15749]: [47796][iter] 'ietf.org.' type 'DNSKEY' id was assigned, parent id 39313 Mar 29 15:29:25.607596 kresd[15749]: [47796][resl] => querying: '2a01:8840:9::1' score: 94 zone cut: 'ietf.org.' m12n: 'IETF.ORG.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:25.663023 kresd[15749]: [47453][iter] <= referral response, follow Mar 29 15:29:25.663023 kresd[15749]: [47453][vldr] <= DS: OK Mar 29 15:29:25.663023 kresd[15749]: [47453][vldr] <= answer valid, OK Mar 29 15:29:25.663023 kresd[15749]: [47453][resl] <= server: '2001:500:c::1' rtt: 83 ms Mar 29 15:29:25.663023 kresd[15749]: [ 9972][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.663023 kresd[15749]: [ 9972][plan] plan 'ietf.org.' type 'DNSKEY' Mar 29 15:29:25.663023 kresd[15749]: [50398][iter] 'ietf.org.' type 'DNSKEY' id was assigned, parent id 9972 Mar 29 15:29:25.663023 kresd[15749]: [50398][plan] plan 'ns1.yyz1.afilias-nst.info.' type 'AAAA' Mar 29 15:29:25.663023 kresd[15749]: [16865][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 50398 Mar 29 15:29:25.663023 kresd[15749]: [16865][ rc ] => satisfied from cache Mar 29 15:29:25.663023 kresd[15749]: [16865][iter] <= rcode: NOERROR Mar 29 15:29:25.663023 kresd[15749]: [16865][vldr] <= cached insecure response, going insecure Mar 29 15:29:25.663023 kresd[15749]: [35265][iter] 'ietf.org.' type 'DNSKEY' id was assigned, parent id 9972 Mar 29 15:29:25.700563 kresd[15749]: [47796][iter] <= rcode: NOERROR Mar 29 15:29:25.700563 kresd[15749]: [47796][vldr] <= parent: updating DNSKEY Mar 29 15:29:25.700563 kresd[15749]: [47796][vldr] <= answer valid, OK Mar 29 15:29:25.700563 kresd[15749]: [47796][resl] <= server: '2a01:8840:9::1' rtt: 37 ms Mar 29 15:29:25.700563 kresd[15749]: [60042][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.700563 kresd[15749]: [60042][plan] plan 'ns1.yyz1.afilias-nst.info.' type 'AAAA' Mar 29 15:29:25.700563 kresd[15749]: [61731][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 60042 Mar 29 15:29:25.700563 kresd[15749]: [61731][ rc ] => satisfied from cache Mar 29 15:29:25.700563 kresd[15749]: [61731][iter] <= rcode: NOERROR Mar 29 15:29:25.700563 kresd[15749]: [61731][vldr] <= cached insecure response, going insecure Mar 29 15:29:25.700563 kresd[15749]: [26102][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.700563 kresd[15749]: [26102][resl] => querying: '2a01:8840:9::1' score: 65 zone cut: 'ietf.org.' m12n: 'Www.ieTf.ORg.' type: 'A' proto: 'udp' Mar 29 15:29:25.700563 kresd[15749]: [47796][iter] <= rcode: NOERROR Mar 29 15:29:25.700563 kresd[15749]: [47796][vldr] <= parent: updating DNSKEY Mar 29 15:29:25.700563 kresd[15749]: [47796][vldr] <= answer valid, OK Mar 29 15:29:25.700563 kresd[15749]: [47796][resl] <= server: '2a01:8840:9::1' rtt: 96 ms Mar 29 15:29:25.700563 kresd[15749]: [28078][iter] 'www.ietf.org.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.700563 kresd[15749]: [28078][plan] plan 'ns1.yyz1.afilias-nst.info.' type 'AAAA' Mar 29 15:29:25.700563 kresd[15749]: [14176][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 28078 Mar 29 15:29:25.700563 kresd[15749]: [14176][ rc ] => satisfied from cache Mar 29 15:29:25.700563 kresd[15749]: [14176][iter] <= rcode: NOERROR Mar 29 15:29:25.700563 kresd[15749]: [14176][vldr] <= cached insecure response, going insecure Mar 29 15:29:25.700563 kresd[15749]: [50907][iter] 'www.ietf.org.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.700563 kresd[15749]: [50907][resl] => querying: '2a01:8840:9::1' score: 80 zone cut: 'ietf.org.' m12n: 'WWw.IETF.oRG.' type: 'AAAA' proto: 'udp' Mar 29 15:29:25.774955 kresd[15749]: [26102][resl] => querying: '2a01:8840:9::1' score: 65 zone cut: 'ietf.org.' m12n: 'Www.ieTf.ORg.' type: 'A' proto: 'udp' Mar 29 15:29:25.790360 kresd[15749]: [50907][resl] => querying: '2a01:8840:9::1' score: 80 zone cut: 'ietf.org.' m12n: 'WWw.IETF.oRG.' type: 'AAAA' proto: 'udp' Mar 29 15:29:25.795619 kresd[15749]: [26102][iter] <= rcode: NOERROR Mar 29 15:29:25.795619 kresd[15749]: [26102][iter] <= cname chain, following Mar 29 15:29:25.795619 kresd[15749]: [ 0][plan] plan 'www.ietf.org.cdn.cloudflare.net.' type 'A' Mar 29 15:29:25.795619 kresd[15749]: [26102][vldr] <= answer valid, OK Mar 29 15:29:25.795619 kresd[15749]: [26102][resl] <= server: '2a01:8840:9::1' rtt: 95 ms Mar 29 15:29:25.795619 kresd[15749]: [35662][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.795619 kresd[15749]: [35662][resl] => using root hints Mar 29 15:29:25.795619 kresd[15749]: [24605][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.795619 kresd[15749]: [24605][plan] plan '.' type 'DNSKEY' Mar 29 15:29:25.795619 kresd[15749]: [29323][iter] '.' type 'DNSKEY' id was assigned, parent id 24605 Mar 29 15:29:25.795619 kresd[15749]: [29323][ rc ] => satisfied from cache Mar 29 15:29:25.795619 kresd[15749]: [29323][iter] <= rcode: NOERROR Mar 29 15:29:25.795619 kresd[15749]: [29323][vldr] <= parent: updating DNSKEY Mar 29 15:29:25.795619 kresd[15749]: [29323][vldr] <= answer valid, OK Mar 29 15:29:25.795619 kresd[15749]: [32007][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.795619 kresd[15749]: [32007][resl] => querying: '2001:dc3::35' score: 81 zone cut: '.' m12n: 'Net.' type: 'NS' proto: 'udp' Mar 29 15:29:25.799567 kresd[15749]: [50907][iter] <= rcode: NOERROR Mar 29 15:29:25.799567 kresd[15749]: [50907][iter] <= cname chain, following Mar 29 15:29:25.799567 kresd[15749]: [ 0][plan] plan 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' Mar 29 15:29:25.799567 kresd[15749]: [50907][vldr] <= answer valid, OK Mar 29 15:29:25.799567 kresd[15749]: [50907][resl] <= server: '2a01:8840:9::1' rtt: 95 ms Mar 29 15:29:25.799567 kresd[15749]: [57109][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.799567 kresd[15749]: [57109][resl] => using root hints Mar 29 15:29:25.799567 kresd[15749]: [ 6112][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:25.799567 kresd[15749]: [ 6112][plan] plan '.' type 'DNSKEY' Mar 29 15:29:25.799567 kresd[15749]: [36416][iter] '.' type 'DNSKEY' id was assigned, parent id 6112 Mar 29 15:29:25.799567 kresd[15749]: [ 7384][iter] '.' type 'DNSKEY' id was assigned, parent id 6112 Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'i.gtld-servers.net.': '192.43.172.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'l.gtld-servers.net.': '192.41.162.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'm.gtld-servers.net.': '192.55.83.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'c.gtld-servers.net.': '192.26.92.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'f.gtld-servers.net.': '192.35.51.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'j.gtld-servers.net.': '192.48.79.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'h.gtld-servers.net.': '192.54.112.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'k.gtld-servers.net.': '192.52.178.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'd.gtld-servers.net.': '192.31.80.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'a.gtld-servers.net.': '192.5.6.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'a.gtld-servers.net.': '2001:503:a83e::2:30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'b.gtld-servers.net.': '192.33.14.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'b.gtld-servers.net.': '2001:503:231d::2:30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'g.gtld-servers.net.': '192.42.93.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= using glue for 'e.gtld-servers.net.': '192.12.94.30' Mar 29 15:29:25.878246 kresd[15749]: [32007][iter] <= referral response, follow Mar 29 15:29:25.878246 kresd[15749]: [32007][vldr] <= DS: OK Mar 29 15:29:25.878246 kresd[15749]: [32007][vldr] <= answer valid, OK Mar 29 15:29:25.878246 kresd[15749]: [32007][resl] <= server: '2001:dc3::35' rtt: 79 ms Mar 29 15:29:25.878246 kresd[15749]: [ 7543][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.878246 kresd[15749]: [ 7543][plan] plan 'net.' type 'DNSKEY' Mar 29 15:29:25.878246 kresd[15749]: [36241][iter] 'net.' type 'DNSKEY' id was assigned, parent id 7543 Mar 29 15:29:25.878246 kresd[15749]: [36241][resl] => querying: '192.55.83.30' score: 10 zone cut: 'net.' m12n: 'nEt.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:25.984605 kresd[15749]: [36241][iter] <= rcode: NOERROR Mar 29 15:29:25.984605 kresd[15749]: [36241][vldr] <= parent: updating DNSKEY Mar 29 15:29:25.984605 kresd[15749]: [36241][vldr] <= answer valid, OK Mar 29 15:29:25.984605 kresd[15749]: [36241][resl] <= server: '192.55.83.30' rtt: 109 ms Mar 29 15:29:25.984605 kresd[15749]: [21034][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.984605 kresd[15749]: [21034][resl] => querying: '192.41.162.30' score: 10 zone cut: 'net.' m12n: 'CLOUdfLArE.NeT.' type: 'NS' proto: 'udp' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns1.cloudflare.net.': '173.245.59.31' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns1.cloudflare.net.': '2400:cb00:2049:1::adf5:3b1f' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns2.cloudflare.net.': '198.41.222.131' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns2.cloudflare.net.': '2400:cb00:2049:1::c629:de83' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns3.cloudflare.net.': '198.41.222.31' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns3.cloudflare.net.': '2400:cb00:2049:1::c629:de1f' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns4.cloudflare.net.': '198.41.223.131' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns4.cloudflare.net.': '2400:cb00:2049:1::c629:df83' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns5.cloudflare.net.': '198.41.223.31' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= using glue for 'ns5.cloudflare.net.': '2400:cb00:2049:1::c629:df1f' Mar 29 15:29:25.994622 kresd[15749]: [21034][iter] <= referral response, follow Mar 29 15:29:25.994622 kresd[15749]: [21034][vldr] <= DS: OK Mar 29 15:29:25.994622 kresd[15749]: [21034][vldr] <= answer valid, OK Mar 29 15:29:25.994622 kresd[15749]: [21034][resl] <= server: '192.41.162.30' rtt: 9 ms Mar 29 15:29:25.994622 kresd[15749]: [13614][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:25.994622 kresd[15749]: [13614][plan] plan 'cloudflare.net.' type 'DNSKEY' Mar 29 15:29:25.994622 kresd[15749]: [32290][iter] 'cloudflare.net.' type 'DNSKEY' id was assigned, parent id 13614 Mar 29 15:29:25.994622 kresd[15749]: [32290][resl] => querying: '2400:cb00:2049:1::c629:df1f' score: 10 zone cut: 'cloudflare.net.' m12n: 'cLouDFlarE.nET.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:26.016448 kresd[15749]: [32290][iter] <= rcode: NOERROR Mar 29 15:29:26.016448 kresd[15749]: [32290][vldr] <= parent: updating DNSKEY Mar 29 15:29:26.016448 kresd[15749]: [32290][vldr] <= answer valid, OK Mar 29 15:29:26.016448 kresd[15749]: [32290][resl] <= server: '2400:cb00:2049:1::c629:df1f' rtt: 21 ms Mar 29 15:29:26.016448 kresd[15749]: [14537][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:26.016448 kresd[15749]: [14537][resl] => querying: '2400:cb00:2049:1::c629:df83' score: 10 zone cut: 'cloudflare.net.' m12n: 'cdn.ClOUDFLAre.nET.' type: 'NS' proto: 'udp' Mar 29 15:29:26.038435 kresd[15749]: [14537][iter] <= rcode: NOERROR Mar 29 15:29:26.038435 kresd[15749]: [14537][iter] <= found cut, retrying with non-minimized name Mar 29 15:29:26.038435 kresd[15749]: [14537][ pc ] => answer cached for TTL=900 Mar 29 15:29:26.038435 kresd[15749]: [14537][resl] <= server: '2400:cb00:2049:1::c629:df83' rtt: 21 ms Mar 29 15:29:26.038435 kresd[15749]: [24680][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:26.038435 kresd[15749]: [20950][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:27.078953 kresd[15749]: [64168][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:27.078953 kresd[15749]: [37681][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:28.797213 kresd[15749]: [40633][iter] '.' type 'DNSKEY' id was assigned, parent id 6112 Mar 29 15:29:28.797213 kresd[15749]: [ 6648][iter] '.' type 'DNSKEY' id was assigned, parent id 6112 Mar 29 15:29:29.038982 kresd[15749]: [44052][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:29.038982 kresd[15749]: [ 8735][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:30.079540 kresd[15749]: [ 594][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:30.079540 kresd[15749]: [48191][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:31.798649 kresd[15749]: [56672][iter] '.' type 'DNSKEY' id was assigned, parent id 6112 Mar 29 15:29:31.798649 kresd[15749]: [56672][resl] => querying: '199.7.83.42' score: 10 zone cut: '.' m12n: '.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:31.812915 kresd[15749]: [56672][iter] <= rcode: NOERROR Mar 29 15:29:31.812915 kresd[15749]: [56672][vldr] <= parent: updating DNSKEY Mar 29 15:29:31.812915 kresd[15749]: [56672][vldr] <= answer valid, OK Mar 29 15:29:31.812915 kresd[15749]: [56672][resl] <= server: '199.7.83.42' rtt: 14 ms Mar 29 15:29:31.812915 kresd[15749]: [56887][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:31.812915 kresd[15749]: [56887][resl] => querying: '2001:7fd::1' score: 10 zone cut: '.' m12n: 'nEt.' type: 'NS' proto: 'udp' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'a.gtld-servers.net.': '192.5.6.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'a.gtld-servers.net.': '2001:503:a83e::2:30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'b.gtld-servers.net.': '192.33.14.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'b.gtld-servers.net.': '2001:503:231d::2:30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'c.gtld-servers.net.': '192.26.92.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'd.gtld-servers.net.': '192.31.80.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'e.gtld-servers.net.': '192.12.94.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'f.gtld-servers.net.': '192.35.51.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'g.gtld-servers.net.': '192.42.93.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'h.gtld-servers.net.': '192.54.112.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'i.gtld-servers.net.': '192.43.172.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'j.gtld-servers.net.': '192.48.79.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'k.gtld-servers.net.': '192.52.178.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'l.gtld-servers.net.': '192.41.162.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= using glue for 'm.gtld-servers.net.': '192.55.83.30' Mar 29 15:29:31.873913 kresd[15749]: [56887][iter] <= referral response, follow Mar 29 15:29:31.873913 kresd[15749]: [56887][vldr] <= DS: OK Mar 29 15:29:31.873913 kresd[15749]: [56887][vldr] <= answer valid, OK Mar 29 15:29:31.873913 kresd[15749]: [56887][resl] <= server: '2001:7fd::1' rtt: 60 ms Mar 29 15:29:31.873913 kresd[15749]: [34711][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:31.873913 kresd[15749]: [34711][plan] plan 'net.' type 'DNSKEY' Mar 29 15:29:31.873913 kresd[15749]: [12142][iter] 'net.' type 'DNSKEY' id was assigned, parent id 34711 Mar 29 15:29:31.873913 kresd[15749]: [12142][resl] => querying: '192.52.178.30' score: 10 zone cut: 'net.' m12n: 'neT.' type: 'DNSKEY' proto: 'udp' Mar 29 15:29:32.039495 kresd[15749]: [47242][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:32.039495 kresd[15749]: [47242][resl] => querying: '2400:cb00:2049:1::c629:de83' score: 10 zone cut: 'cloudflare.net.' m12n: 'wWW.iETf.ORg.Cdn.cLOuDFLARe.NEt.' type: 'A' proto: 'udp' Mar 29 15:29:32.061000 kresd[15749]: [47242][iter] <= rcode: NOERROR Mar 29 15:29:32.061000 kresd[15749]: [47242][vldr] <= answer valid, OK Mar 29 15:29:32.061000 kresd[15749]: [47242][resl] <= server: '2400:cb00:2049:1::c629:de83' rtt: 18 ms Mar 29 15:29:32.061000 kresd[15749]: [ 0][resl] finished: 4, queries: 8, mempool: 131152 B Mar 29 15:29:32.073521 kresd[15749]: [12142][iter] <= rcode: NOERROR Mar 29 15:29:32.073521 kresd[15749]: [12142][vldr] <= parent: updating DNSKEY Mar 29 15:29:32.073521 kresd[15749]: [12142][vldr] <= answer valid, OK Mar 29 15:29:32.073521 kresd[15749]: [12142][resl] <= server: '192.52.178.30' rtt: 199 ms Mar 29 15:29:32.073521 kresd[15749]: [ 3229][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:32.073521 kresd[15749]: [ 3229][resl] => querying: '192.48.79.30' score: 10 zone cut: 'net.' m12n: 'clOUDFLaRE.neT.' type: 'NS' proto: 'udp' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns1.cloudflare.net.': '173.245.59.31' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns1.cloudflare.net.': '2400:cb00:2049:1::adf5:3b1f' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns2.cloudflare.net.': '198.41.222.131' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns2.cloudflare.net.': '2400:cb00:2049:1::c629:de83' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns3.cloudflare.net.': '198.41.222.31' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns3.cloudflare.net.': '2400:cb00:2049:1::c629:de1f' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns4.cloudflare.net.': '198.41.223.131' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns4.cloudflare.net.': '2400:cb00:2049:1::c629:df83' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns5.cloudflare.net.': '198.41.223.31' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= using glue for 'ns5.cloudflare.net.': '2400:cb00:2049:1::c629:df1f' Mar 29 15:29:32.115931 kresd[15749]: [ 3229][iter] <= referral response, follow Mar 29 15:29:32.115931 kresd[15749]: [ 3229][vldr] <= DS: OK Mar 29 15:29:32.115931 kresd[15749]: [ 3229][vldr] <= answer valid, OK Mar 29 15:29:32.115931 kresd[15749]: [ 3229][resl] <= server: '192.48.79.30' rtt: 42 ms Mar 29 15:29:32.115931 kresd[15749]: [17305][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:32.115931 kresd[15749]: [17305][plan] plan 'cloudflare.net.' type 'DNSKEY' Mar 29 15:29:32.115931 kresd[15749]: [31186][iter] 'cloudflare.net.' type 'DNSKEY' id was assigned, parent id 17305 Mar 29 15:29:32.115931 kresd[15749]: [31186][ rc ] => satisfied from cache Mar 29 15:29:32.115931 kresd[15749]: [31186][iter] <= rcode: NOERROR Mar 29 15:29:32.115931 kresd[15749]: [31186][vldr] <= parent: updating DNSKEY Mar 29 15:29:32.115931 kresd[15749]: [31186][vldr] <= answer valid, OK Mar 29 15:29:32.115931 kresd[15749]: [25948][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:32.115931 kresd[15749]: [25948][resl] => querying: '2400:cb00:2049:1::c629:de1f' score: 10 zone cut: 'cloudflare.net.' m12n: 'cDN.ClOUdFlaRe.net.' type: 'NS' proto: 'udp' Mar 29 15:29:32.137736 kresd[15749]: [25948][iter] <= rcode: NOERROR Mar 29 15:29:32.137736 kresd[15749]: [25948][iter] <= found cut, retrying with non-minimized name Mar 29 15:29:32.137736 kresd[15749]: [25948][ pc ] => answer cached for TTL=900 Mar 29 15:29:32.137736 kresd[15749]: [25948][resl] <= server: '2400:cb00:2049:1::c629:de1f' rtt: 21 ms Mar 29 15:29:32.137736 kresd[15749]: [18856][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:29:32.137736 kresd[15749]: [18856][resl] => querying: '2400:cb00:2049:1::adf5:3b1f' score: 10 zone cut: 'cloudflare.net.' m12n: 'WwW.IETF.ORg.Cdn.CLOuDflARE.NET.' type: 'AAAA' proto: 'udp' Mar 29 15:29:32.156189 kresd[15749]: [18856][iter] <= rcode: NOERROR Mar 29 15:29:32.156189 kresd[15749]: [18856][vldr] <= answer valid, OK Mar 29 15:29:32.156189 kresd[15749]: [18856][resl] <= server: '2400:cb00:2049:1::adf5:3b1f' rtt: 18 ms Mar 29 15:29:32.156189 kresd[15749]: [ 0][resl] finished: 4, queries: 9, mempool: 147552 B Mar 29 15:29:33.079990 kresd[15749]: [31173][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:33.079990 kresd[15749]: [12786][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:33.103799 kresd[15749]: [ 0][plan] plan '.' type 'DNSKEY' Mar 29 15:29:33.103799 kresd[15749]: [23021][iter] '.' type 'DNSKEY' id was assigned, parent id 0 Mar 29 15:29:33.103799 kresd[15749]: [23021][ rc ] => satisfied from cache Mar 29 15:29:33.103799 kresd[15749]: [23021][iter] <= rcode: NOERROR Mar 29 15:29:33.103799 kresd[15749]: [ 0][resl] finished: 4, queries: 1, mempool: 147552 B Mar 29 15:29:33.103799 kresd[15749]: [ ta ] key: 19036 state: Valid Mar 29 15:29:33.103799 kresd[15749]: [ ta ] new state of root trust anchors: Mar 29 15:29:33.103799 kresd[15749]: . 172800 DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 Mar 29 15:29:33.103799 kresd[15749]: [ ta ] next refresh in 24 hours Mar 29 15:29:33.103799 kresd[15749]: [ 0][plan] plan '.' type 'NS' Mar 29 15:29:33.103799 kresd[15749]: [31389][iter] '.' type 'NS' id was assigned, parent id 0 Mar 29 15:29:33.103799 kresd[15749]: [31389][resl] => using root hints Mar 29 15:29:33.103799 kresd[15749]: [33816][iter] '.' type 'NS' id was assigned, parent id 0 Mar 29 15:29:33.103799 kresd[15749]: [33816][plan] plan '.' type 'DNSKEY' Mar 29 15:29:33.103799 kresd[15749]: [21488][iter] '.' type 'DNSKEY' id was assigned, parent id 33816 Mar 29 15:29:33.103799 kresd[15749]: [21488][ rc ] => satisfied from cache Mar 29 15:29:33.103799 kresd[15749]: [21488][iter] <= rcode: NOERROR Mar 29 15:29:33.103799 kresd[15749]: [21488][vldr] <= parent: updating DNSKEY Mar 29 15:29:33.103799 kresd[15749]: [21488][vldr] <= answer valid, OK Mar 29 15:29:33.103799 kresd[15749]: [61993][iter] '.' type 'NS' id was assigned, parent id 0 Mar 29 15:29:33.103799 kresd[15749]: [61993][resl] => querying: '193.0.14.129' score: 10 zone cut: '.' m12n: '.' type: 'NS' proto: 'udp' Mar 29 15:29:33.142746 kresd[15749]: [61993][iter] <= rcode: NOERROR Mar 29 15:29:33.142746 kresd[15749]: [61993][vldr] <= answer valid, OK Mar 29 15:29:33.142746 kresd[15749]: [61993][resl] <= server: '193.0.14.129' rtt: 39 ms Mar 29 15:29:33.142746 kresd[15749]: [ 0][resl] finished: 4, queries: 2, mempool: 131152 B Mar 29 15:29:36.081423 kresd[15749]: [16901][iter] 'ns1.yyz1.afilias-nst.info.' type 'AAAA' id was assigned, parent id 35015 Mar 29 15:29:36.081423 kresd[15749]: [ 0][resl] finished: 8, queries: 6, mempool: 147552 B Mar 29 15:29:46.897467 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'A' Mar 29 15:29:46.898006 kresd[15749]: [49098][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:46.898317 kresd[15749]: [49098][ rc ] => satisfied from cache Mar 29 15:29:46.898743 kresd[15749]: [49098][iter] <= rcode: NOERROR Mar 29 15:29:46.898743 kresd[15749]: [49098][iter] <= cname chain, following Mar 29 15:29:46.898743 kresd[15749]: [ 0][plan] plan 'www.ietf.org.cdn.cloudflare.net.' type 'A' Mar 29 15:29:46.898743 kresd[15749]: [64077][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:46.898743 kresd[15749]: [64077][ rc ] => satisfied from cache Mar 29 15:29:46.898743 kresd[15749]: [64077][iter] <= rcode: NOERROR Mar 29 15:29:46.898743 kresd[15749]: [64077][vldr] <= answer valid, OK Mar 29 15:29:46.898743 kresd[15749]: [ 0][resl] finished: 4, queries: 2, mempool: 147552 B Mar 29 15:29:57.229477 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'A' Mar 29 15:29:57.230003 kresd[15749]: [54278][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:29:57.230246 kresd[15749]: [54278][ rc ] => satisfied from cache Mar 29 15:29:57.230526 kresd[15749]: [54278][iter] <= rcode: NOERROR Mar 29 15:29:57.230766 kresd[15749]: [54278][iter] <= cname chain, following Mar 29 15:29:57.230980 kresd[15749]: [ 0][plan] plan 'www.ietf.org.cdn.cloudflare.net.' type 'A' Mar 29 15:29:57.231198 kresd[15749]: [10171][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:29:57.231418 kresd[15749]: [10171][ rc ] => satisfied from cache Mar 29 15:29:57.231730 kresd[15749]: [10171][iter] <= rcode: NOERROR Mar 29 15:29:57.232079 kresd[15749]: [10171][vldr] <= answer valid, OK Mar 29 15:29:57.232079 kresd[15749]: [ 0][resl] finished: 4, queries: 2, mempool: 147552 B Mar 29 15:30:00.039527 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'AAAA' Mar 29 15:30:00.040083 kresd[15749]: [ 3850][iter] 'www.ietf.org.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:30:00.040334 kresd[15749]: [ 3850][ rc ] => satisfied from cache Mar 29 15:30:00.040561 kresd[15749]: [ 3850][iter] <= rcode: NOERROR Mar 29 15:30:00.040782 kresd[15749]: [ 3850][iter] <= cname chain, following Mar 29 15:30:00.041003 kresd[15749]: [ 0][plan] plan 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' Mar 29 15:30:00.041291 kresd[15749]: [22572][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'AAAA' id was assigned, parent id 0 Mar 29 15:30:00.041539 kresd[15749]: [22572][ rc ] => satisfied from cache Mar 29 15:30:00.041758 kresd[15749]: [22572][iter] <= rcode: NOERROR Mar 29 15:30:00.042114 kresd[15749]: [22572][vldr] <= answer valid, OK Mar 29 15:30:00.042114 kresd[15749]: [ 0][resl] finished: 4, queries: 2, mempool: 147552 B Mar 29 15:30:00.226842 kresd[15749]: [ 0][plan] plan 'www.ietf.org.' type 'A' Mar 29 15:30:00.226842 kresd[15749]: [35156][iter] 'www.ietf.org.' type 'A' id was assigned, parent id 0 Mar 29 15:30:00.226842 kresd[15749]: [35156][ rc ] => satisfied from cache Mar 29 15:30:00.226842 kresd[15749]: [35156][iter] <= rcode: NOERROR Mar 29 15:30:00.226842 kresd[15749]: [35156][iter] <= cname chain, following Mar 29 15:30:00.226842 kresd[15749]: [ 0][plan] plan 'www.ietf.org.cdn.cloudflare.net.' type 'A' Mar 29 15:30:00.226842 kresd[15749]: [51701][iter] 'www.ietf.org.cdn.cloudflare.net.' type 'A' id was assigned, parent id 0 Mar 29 15:30:00.226842 kresd[15749]: [51701][ rc ] => satisfied from cache Mar 29 15:30:00.226842 kresd[15749]: [51701][iter] <= rcode: NOERROR Mar 29 15:30:00.226842 kresd[15749]: [51701][vldr] <= answer valid, OK Mar 29 15:30:00.226842 kresd[15749]: [ 0][resl] finished: 4, queries: 2, mempool: 147552 B

8 let, 3 měsíce

3
4
0 0

ZSK/KSK Key algorithm rollover

by Tobias Brunner

Hi, I'm in the process of changing the key algorithm from the former Knot default of RSASHA256 to the newer default ecdsap256sha256. For this I have just updated the DNSSEC policy and reloaded Knot. This created a new ZSK and signed the zone with this new ZSK, but also with the old one. Now the zone is signed with two ZSKs. How can I get rid of the old ZSK? I already tried to set "retire" and "remove" on the old ZSK with keymgr to a value in the near future, but that just lead to the error message "keys validation failed (missing active KSK or ZSK)" when issuing a zone-sign to this particular zone. So I'm stuck now. Additionally: How can I do a KSK rollover to also change the algorithm from RSASHA256 to ecdsap256sha256? I couldn't find a documentation explaining this step. I know that I need to have two KSKs until the DS record on the parent is updated pointing to the new key, but I don't know how to create a new KSK with Knot. Thanks in advance for explaining the process. Cheers, Tobias

8 let, 3 měsíce

4
3
0 0

Knot DNS 2.4.2 released

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release the 2.4.2 release of Knot DNS. This release contains many improvements over 2.3.x release of Knot DNS. The Knot DNS 2.4.x is the new stable branch. Starting from the 2.4.0 release we are going to support current stable (2.4.x) and previous stable (2.3.x) branches, and at the same time we are deprecating previous Knot DNS 1.6.x release. This release adds significant IXFR speedup in case of many zones, improvements to knotc status command and several other small fixes and improvements. 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.4.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.4.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.4.2.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ 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, 3 měsíce

2
2
0 0

Knot Resolver 1.2.4 release

by Ondřej Surý

Dear Knot Resolver users, a bugfix release of Knot Resolver 1.2.4 has been released. The release contains following improvements and bugfixes: Security -------- - Knot Resolver 1.2.0 and higher could return AD flag for insecure answer if the daemon received answer with invalid RRSIG several times in a row. Improvements ------------ - modules/policy: allow QTRACE policy to be chained with other policies - hints.add_hosts(path): a new property - module: document the API and simplify the code - policy.MIRROR: support IPv6 link-local addresses - policy.FORWARD: support IPv6 link-local addresses - add net.outgoing_{v4,v6} to allow specifying address to use for connections Bugfixes -------- - layer/iterate: some improvements in cname chain unrolling - layer/validate: fix duplicate records in AUTHORITY section in case of WC expansion proof - lua: do *not* truncate cache size to unsigned - forwarding mode: correctly forward +cd flag - fix a potential memory leak - don't treat answers that contain DS non-existance proof as insecure - don't store NSEC3 and their signatures in the cache - layer/iterate: when processing delegations, check if qname is at or below new authority The update from 1.2.3 to 1.2.4 is recommended. The update from 1.1.x to 1.2.x branch is strongly recommended, the 1.1.x branch is no longer supported. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.4/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.4.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.4.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 4 měsíce

1
0
0 0

Multi-master scenario

by Giovanni Civardi

Hi, i’m evaluating some DNS solution for our multi-site distributed environment. I do not want a master-slave scenario, but would like to implement some multi-master. do you think is achievable with KNOT? have you ever implemented some master-to-master synchronisation? what could be the benefits having a multi-master scenario against the classic master-slave scenario? thanks! Giovanni Civardi System Engineer MainStreaming Phone +39 02 868969.69 Web http://www.mainstreaming.tv

8 let, 4 měsíce

3
3
0 0

Knot 2.4.1 on CentOS 7

by Abdulkareem H. Ali

Hi All, I built Knot 2.4.1 rpm and tried it on CentOS7. The server isn't reading any of our zones with an error of: "failed to load persistent timers (invalid parameter)" Therefore it won't accept any notifies form master and won't read or transfer any zone. Even when I do "knotc refresh ZONE" it will fail saying zone is unknow. This is an upgrade from Knot 2.2, and same configs doesn't complain about anything and the server starts fine using that version, and load zones, and respond to DNS queries without a problem. I tried to find a procedure for a first time install for Knot and see if there is any required initialization that needs to be done but no luck. Have anyone tried Knot 2.4.1 with CentOS 7 please and successfully had it running? Note that I tried: knotc conf-check (responds with: Configuration is valid) knotc conf-read (shows all zones and template configs being read and doesn't show any warning or error) knotc conf-init knotc conf-import /etc/knot/knot.conf Either one of those will generate confdb. However, conf-init generates it but then Knot doesn't show anything in the logs (set to debug), but does generate timers folder. But conf-import show same logs with same errors above, and still won't load any of our zones. I'm using these template settings: "" mod-rrl: - id: default rate-limit: 200 # Allow 200 resp/s for each flow slip: 2 # Every other response slips template: - id: default storage: /var/lib/knot/zones journal-db: journals timer-db: timers zonefile-sync: 60 semantic-checks: on global-module: mod-rrl/default "" I'd appreciate any suggestion please. I'm new to this list, so if this is not where I was suppose to send this please accept my apologize. Thanks, Kareem. -- Abdulkareem H. Ali Network Operations Engineer CentralNic Group PLC London Stock Exchange Symbol: CNIC +44 20 3388 0600 www.CentralNic.com CentralNic Group PLC is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

8 let, 4 měsíce

3
6
0 0

Modules disabled in .deb packages

by knot.dirk＠o.banes.ch

Dear all, I'm setting up my own DNS and was not fund of the Idea to use bind. Then someone pointed me to knot which ich immediatly found interresting. After first successes I ran today into an error I could not resolve - neither find anything on the web. Finally I found this [1]. Is there a strong reason why you get specific modules only if you compile knot yourself ? For me I'm sad to say this is a no-go. I want to rely on automatic updates for security. Any chance this will be fixed ? best regards Dirk [1] https://lists.nic.cz/pipermail/knot-dns-users/2017-January/001039.html

8 let, 4 měsíce

2
1
0 0

Knot Resolver 1.2.3 release

by Ondřej Surý

Dear Knot Resolver users, a bugfix release of Knot Resolver 1.2.3 has been released. The release contains following bugfixes: - Disable storing GLUE records into the cache even in the (non-default) QUERY_PERMISSIVE mode - iterate: skip answer RRs that don't match the query - layer/iterate: some additional processing for referrals - lib/resolve: zonecut fetching error was fixed The update from 1.2.2 to 1.2.3 is recommended. The update from 1.1.x to 1.2.x branch is strongly recommended. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.3.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 4 měsíce

1
0
0 0

ECS in responses

by Chuck Musser

Hi, We would like to enable ECS responses in our Knot server in order to indicate to recursives that they should send it in requests if they can. The goal is gauge how widespread usage of this feature this is and to collect some statistics on the client networks being transmitted. We don't have a way of providing tailored responses yet (not sure how this would be done, but that's another topic.) Is there a way of enabling ECS so that it's included in responses, perhaps with a scope prefix-length of 0 (as described in section 12.1 of draft-ietf-dnsop-edns-client-subnet-08)? Thanks, Chuck

8 let, 4 měsíce

4
5
0 0

Knot Resolver 1.2.2 release

by Ondřej Surý

Dear Knot Resolver users, a bugfix release of Knot Resolver 1.2.2 has been released. The release contains following bugfixes: * In rare cases, the processing of `-k` argument would lead to out-of-bound memory access on startup * Fix fetching explicit DS queries in the resolve module * Fix crash on calling hints.del() * Fix TA bootstrapping for multiple TAs in the IANA XML file The update from 1.2.1 to 1.2.2 is recommended. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.2.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 4 měsíce

3
3
0 0

Knot DNS 2.4.1 released

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release the 2.4.1 release of Knot DNS. This release contains many improvements over 2.3.x release of Knot DNS. The Knot DNS 2.4.x is the new stable branch. Starting from this release we are going to support current stable (2.4.x) and previous stable (2.3.x) branches, and at the same time we are deprecating previous Knot DNS 1.6.x release. This is a bugfix release containing small fixes, but the upgrade is recommended. 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.4.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.4.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.4.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- 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, 5 měsíců

1
0
0 0

predict.lua error

by Horigome Yoshihito

Hello, all When using knot DNS resolver, the following error was output. Feb 06 20:19:43 dns02 kresd[24857]: error: /usr/lib/knot-resolver/predict.lua:34: 'struct rr_type' has no member named 'nil' $ kresd -V Knot DNS Resolver, version 1.2.1 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial Is it related to setting reorder_RR (true)? Is this a configuration issue in this case? Or is it a known bug? Thanks.

8 let, 5 měsíců

2
4
0 0

forward requests for only one zone

by Adam Bambuch

Hi, Is there any chance to configure the mod-dnsproxy to forward all requests for only one zone to another dns server? I have this configuration in bind configuration file: zone "example.com" IN { type forward; forwarders { 1.2.3.4; }; }; Is there any way to do it in knot? Best regards,

8 let, 5 měsíců

2
2
0 0

Knot Resolver 1.2.1 release

by Ondřej Surý

Dear Knot Resolver users, Knot Resolver 1.2.1 has been released. It was discovered during internal testing that under special query combinations the Knot Resolver can provide Insecure data from the cache on negative answers that would be otherwise Bogus due invalid signatures. The update from 1.2.0 to 1.2.1 is recommended. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.1.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 5 měsíců

1
0
0 0

Knot IXFR/AXFR issues

by Antti Ristimäki

Hello, We have a setup where a Knot DNS server is a slave and a DNS provisioning system acts as a hidden master. The DNS server process in the hidden master is some vendor specific implementation, not NSD, Bind or anything well-known. Now, for random zones we see the following errors in Knot when trying to update the zone: Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] notify, incoming, a:b:c:d::e@51097: received, serial none Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] refresh, outgoing, a:b:c:d::e@8054: remote serial 2017013116, zone is outdated Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] IXFR, incoming, a:b:c:d::e@8054: starting Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] IXFR, incoming, a:b:c:d::e@8054: failed (malformed data) Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] refresh, outgoing, a:b:c:d::e@8054: fallback to AXFR Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] refresh, remote '....' not usable As we can see, Knot first receives a notify message that triggers IXFR. For yet unknown reason, IXFR fails due to "malformed data", after which Knot fallbacks to AXFR. However, from tcpdump capture (I can share the pcap off-list, if needed) we can see, that Knot reuses the same TCP socket for AXFR as it used for IXFR, but immediately after sending the AXFR query Knot sends TCP RST to the hidden master thus closing the TCP connection, making the remote/master server to be unusable from Knot's point of view. The negative thing is that after the failure Knot gives up trying to update the zone, leaving the zone to its old SOA serial, maybe until it expires. So far we also don't know, what causes the IXFR to fail in the first place. From what we can see, the zone data seems to be valid so it's unclear why Knot fails with "malformed data". However, after manually running "knotc zone-retransfer <zone>" once, subsequent IXFRs succeed. Unfortunately we have very limited options to configure the hidden master, because as said, it is a vendor specific implementation. So we have two issues here: failing IXFR and then failure in AXFR fallback due to TCP connection reset on the Knot side. Do you have any ideas? Oh, forgot to mention that the Knot version is 2.4.0. Thank you in advance for all help, Antti

8 let, 5 měsíců

2
1
0 0

Knot DNS and statistics

by Frantisek Princ

Hello, after some testing I have deployed Knot DNS to one of our authoritative servers with almost 90k zones and it looks very well. I have one small problem with statistics, especiallly with interpreatation of statistics (mod-stats). There are some counters, but i cannot find any reliable approach, how to calculate numbers like queries per second, which is interesting for future hardware scaling. Did I missed anything? Or would it be possible to add one simple counter - something like server.uptime = (seconds from last reload).- because all counters are reset after reload. Finally, thanks for Knot DNS - well done! Best regards, Frantisek Princ

8 let, 5 měsíců

2
1
0 0

Unable to use mod-dnstap in 2.4.0

by Frantisek Princ

Hello, I am trying to use mod-dnstap on Knot DNS 2.4.0, but I am getting this error root@knot:~# knotc conf-check error: config, file '/etc/knot/knot.conf', line 27, item 'mod-dnstap', value '' (invalid item) error: failed to load configuration file '/etc/knot/knot.conf' (invalid item) Here is used configuration: server: user: knot:knot listen: [ 0.0.0.0@53, ::@53 ] log: - target: stderr any: warning - target: syslog server: info zone: notice any: error acl: - id: acl_dk-hostmaster address: [ 193.163.102.6, 2a01:630:0:40:3:4:5:6 ] action: transfer - id: acl_hu-hostmaster address: 193.239.249.0/24 action: transfer control: listen: knot.sock timeout: 30 mod-dnstap: - id: capture_all sink: /tmp/capture.tap template: - id: default global-module: mod-dnstap/captuer_all global-module: mod-stats include: /var/lib/knot-data/zones/zones_include_knot Knot DNS is installed on Debian Jessie from package (version 2.4.0-1+0~20170120113157.17+jessie~1.gbp8e34c2) I found similar topic in archives ( https://lists.nic.cz/pipermail/knot-dns-users/2016-September/000944.html ), but there was no solution. Regards, František Princ

8 let, 5 měsíců

2
4
0 0

knot 2.4 dnssec failure

by Bastien Durel

Hello, I've tried to upgrade from knot 2.3.3 to 2.4.0, but ran into a DNSSEC related error, invalidating my DNSSEC-enabled zones : 2017-01-25T15:33:42 notice: [geekwu.org.] journal, obsolete exists, file '/var/lib/knot/external/geekwu.org.db' 2017-01-25T15:33:42 error: [geekwu.org.] DNSSEC, failed to initialize (not found) 2017-01-25T15:33:42 error: [geekwu.org.] zone event 'load' failed (not found) stracing the error leads to this : [pid 16787] open("/var/lib/knot/external/keys/policy_\\x06policy.json", O_RDONLY) = -1 ENOENT (No such file or directory) I have some policy files in /var/lib/knot/external/keys: -rw-r--r-- 1 knot knot 320 janv. 26 2016 policy_default.json -rw-r--r-- 1 knot knot 320 janv. 26 2016 policy_default_rsa.json -rw-r--r-- 1 knot knot 320 juin 14 2016 policy_ecdsa.json >From where these \\x06policy may come ? Thanks, -- Bastien

8 let, 5 měsíců

4
3
0 0

Knot Resolver 1.2.0 release

by Ondřej Surý

Dear Knot Resolver users, CZ.NIC is proud to release a new release of Knot Resolver. The team has worked very hard to bring: - reworked DNSSEC Validation, that fixes several know problems with less standard DNS configurations, and it is also a solid base for further improvements - optional EDNS(0) Padding support for DNS over TLS - support for debugging DNSSEC with CD bit - DNS over TLS is now able to create ephemeral certs on the runtime (Thanks Daniel Kahn Gilmore for contributing to DNS over TLS implementation in Knot Resolver.) - configurable minimum and maximum TTL (default 6 days) - configurable pseudo-random reordering of RR sets - new module 'version' that can call home and report new versions and security vulnerabilities to the log file This release also fixes bugs, most notable ones: - The resolver was setting AD flag when running in a forwarding mode. Thanks Stéphane Bortzmeyer for reporting this issue! - We now correctly return RCODE=NOTIMPL on meta-queries and non IN class queries - Fix crash in hints module when hints file was empty - Fix non-lowercase hints We also have a new LRU implementation under the hood. That's it! Thank you for using Knot Resolver. And if you are not using it yet, please give it a try. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 5 měsíců

1
0
0 0

Knot DNS 2.4.0 released

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release the 2.4.0 release of Knot DNS. This release contains many improvements over 2.3.x release of Knot DNS. The Knot DNS 2.4.x is the new stable branch. Starting from this release we are going to support current stable (2.4.x) and previous stable (2.3.x) branches, and at the same time we are deprecating previous Knot DNS 1.6.x release. Now the new features we are so excited about! * We have a new journal to store zone changes, it's key features are: - all journals for all zones are in a single LMDB database (defaults to storage/journal; 1G size) - the occupied space is measured per zone - old changesets get preserved after zone flush until we run out of space - if zone flushing is disabled and journal gets full, it tries to free up space by merging older changesets - all changes are done by transactions, resulting in always-consistent DB (but some mutexes still necessary for opening DB && for keeping zone contents consistent with journal) - kjournalprint provides a way to list zones in journal - old journal is automatically imported, but the configuration needs to be updated manually * Thanks to qp-trie (originally proposed by Tony Finch) adapted to Knot DNS we have much lower memory consumption when Knot DNS is used with many zones * The zone timers and zone events have been refactored and improved * The SOA query and transfer now shares the TCP connection * There's a new statistics module for traffic measurements There are also several other bugfixes and improvements related to transfers, timers and other areas. 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.4.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.4.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.4.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- 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, 5 měsíců

5
6
0 0

DS record digest

by Jakub Andrys

Hi, can someone please give me any explanation (or command) how my domain registrator got from this record what i give him: liberland.cz. 3600 DNSKEY 257 3 13 ei9T3egqng+nlAHeNfF6BzggGCyvS2lU5ih2BZuvkzFGxkBdUJ0blgSiW5iYIROvAEHQv5Ls3sNPA9JIt8iRjg== this record: liberland.cz. 17999 IN DS 21107 13 2 9405F3324FDCE3F0CC4E5D94CBFB5D8A4F211E3010D447B5FD73765F9EEC20EB ??? I want sign child zones but I can't find where i get hash ,,9405F3324FDCE3F0CC4E5D94CBFB5D8A4F211E3010D447B5FD73765F9EEC20EB" And algorithm in RFC: https://tools.ietf.org/html/rfc4034#section-5.4 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); "|" denotes concatenation DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. doesn't help me :-/ Thanks and regards, Jakub

8 let, 5 měsíců

3
3
0 0

Knot Resolver 1.2.0-rc1 (Release Candidate 1) release

by Ondřej Surý

Dear Knot Resolver users, CZ.NIC is proud to release a new release candidate of Knot Resolver. The team has worked very hard to bring: - reworked DNSSEC Validation, that fixes several know problems with less standard DNS configurations, and it is also a solid base for further improvements - optional EDNS(0) Padding support for DNS over TLS - support for debugging DNSSEC with CD bit - DNS over TLS is now able to create ephemeral certs on the runtime (Thanks Daniel Kahn Gilmore for contributing to DNS over TLS implementation in Knot Resolver.) - configurable minimum and maximum TTL (default 6 days) - configurable pseudo-random reordering of RR sets - new module 'version' that can call home and report new versions and security vulnerabilities to the log file This release also fixes bugs, most notable ones: - The resolver was setting AD flag when running in a forwarding mode. Thanks Stéphane Bortzmeyer for reporting this issue! - We now correctly return RCODE=NOTIMPL on meta-queries and non IN class queries - Fix crash in hints module when hints file was empty - Fix non-lowercase hints We also have a new LRU implementation under the hood. That's it! Thank you for using Knot Resolver. And if you are not using it yet, please give it a try. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.0-rc1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0-rc1.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/latest/ -- 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, 5 měsíců

2
3
0 0

mod-synth-record + DNSSEC = SERVFAIL

by Alarig Le Lay

Hi, I use mod-synth-record to provide some reverse records for a LAN. mod-synth-record: - id: tregon-grifon type: forward prefix: ip6- ttl: 400 network: 2a00:5884:8316::/48 mod-synth-record: - id: tregon-grifon-reverse type: reverse prefix: ip6- origin: tregon-grifon.swordarmor.fr ttl: 400 network: 2a00:5884:8316::/48 They are both very simple: eddy ~ # cat /var/lib/knot/tregon-grifon.swordarmor.fr.zone.nodnssec @ 864000 IN SOA tregon-grifon.swordarmor.fr. hostmaster.swordarmor.fr. ( 2 3600 900 1209600 43200 ) 864000 IN NS tregon-grifon.swordarmor.fr. IN AAAA 2a00:5884:8316::1 A 89.234.186.16 eddy ~ # cat /var/lib/knot/6.1.3.8.4.8.8.5.0.0.a.2.ip6.arpa.zone.nodnssec @ 864000 IN SOA tregon-grifon.swordarmor.fr. hostmaster.swordarmor.fr. ( 2 3600 900 1209600 43200 ) 864000 IN NS tregon-grifon.swordarmor.fr. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tregon-grifon.swordarmor.fr. 6.2.4.c.f.6.5.5.d.7.4.d.0.4.d.f.3.5.6.2 IN PTR pika-tregon.swordarmor.fr. tregon-grifon.swordarmor.fr. is signed with DNSSEC, but I have a RRSIG only for the records in the pasted file. alarig@pikachu ~ % dig -t RRSIG tregon-grifon.swordarmor.fr. ; <<>> DiG 9.10.4-P3 <<>> -t RRSIG tregon-grifon.swordarmor.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53081 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tregon-grifon.swordarmor.fr. IN RRSIG ;; ANSWER SECTION: tregon-grifon.swordarmor.fr. 3600 IN RRSIG A 13 3 3600 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. YlT/vCMLDyGHwKLoMOdQqENwWTyhphrbBatKhhtvCteTubwBp9FCrf9b /jc0cRM07a321de7kw3cYPD3lfbPYA== tregon-grifon.swordarmor.fr. 864000 IN RRSIG NS 13 3 864000 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. l6HiWFaqz3Hys7aknEHEG6woKJ9xdYqopxNUTOYmMk94733jMnDiH5bx fDKGPjgyVCkbQWfFsJCr/udwnelSaQ== tregon-grifon.swordarmor.fr. 864000 IN RRSIG SOA 13 3 864000 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. OUWibAYe8oyRBWgGyPAxG0etUcGQe1ZEZ+1ywZIi1xQvhWMQy/0B+HNH RyQYYdJ9eXqXPP3uQRyXPTtsa+9KKQ== tregon-grifon.swordarmor.fr. 3600 IN RRSIG AAAA 13 3 3600 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. NIEEeURn0/RH9IqWxGM9W74Gf8UqDh4Bqap0NlZ4XQ+95FpfylAQKxo0 KZUNCDCXCFQ4Rpg/dJH4EhpWw8Pxtw== tregon-grifon.swordarmor.fr. 43200 IN RRSIG NSEC 13 3 43200 20161208210625 20161124210625 28440 tregon-grifon.swordarmor.fr. 6T2+GjrRU8qU/zGNmY8R9bmkNUFGPJuJQP2qkhakV0GeiyseEWA5yPDE /YIELH04KKAE3yrudo8S6xcaQ6DveQ== tregon-grifon.swordarmor.fr. 864000 IN RRSIG DNSKEY 13 3 864000 20161208210625 20161124210625 57104 tregon-grifon.swordarmor.fr. F/jepDBqQriHFUSN8mnkiNZ6l3vP5K8ob44yuHkHBupimIo4S6hvuZXD F7AnbF5GtVsZPDdjA4qumkv1HaiTFQ== ;; Query time: 160 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Mon Nov 28 11:02:27 CET 2016 ;; MSG SIZE rcvd: 794 alarig@pikachu ~ % dig -t RRSIG ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ; <<>> DiG 9.10.4-P3 <<>> -t RRSIG ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27161 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN RRSIG ;; Query time: 457 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Mon Nov 28 11:02:33 CET 2016 ;; MSG SIZE rcvd: 100 So, I get a SERVFAIL when I try to resolve the AAAA. alarig@pikachu ~ % dig -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ; <<>> DiG 9.10.4-P3 <<>> -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN AAAA ;; Query time: 2701 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Mon Nov 28 11:02:47 CET 2016 ;; MSG SIZE rcvd: 100 But it works perfectly if I use a resolver that does not verify DNSSEC alarig@pikachu ~ % dig -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. @ns0.fdn.fr ; <<>> DiG 9.10.4-P3 <<>> -t AAAA ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. @ns0.fdn.fr ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55433 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. IN AAAA ;; ANSWER SECTION: ip6-2a00-5884-8316-2653-fd40-d47d-556f-c427.tregon-grifon.swordarmor.fr. 400 IN AAAA 2a00:5884:8316:2653:fd40:d47d:556f:c427 ;; AUTHORITY SECTION: tregon-grifon.swordarmor.fr. 10800 IN NS tregon-grifon.swordarmor.fr. ;; ADDITIONAL SECTION: tregon-grifon.swordarmor.fr. 10800 IN A 89.234.186.16 tregon-grifon.swordarmor.fr. 10800 IN AAAA 2a00:5884:8316::1 ;; Query time: 105 msec ;; SERVER: 2001:910:800::12#53(2001:910:800::12) ;; WHEN: Mon Nov 28 11:03:33 CET 2016 ;; MSG SIZE rcvd: 186 -- alarig

8 let, 7 měsíců

4
5
0 0

Segfault in knot 2.3.1-1~bpo8+ and 2.3.2-1

by Jeroen Massar

Hola, As recently a variety of people claimed to me that 'running DNSSEC is not scary'.... I was like, lets try again after having tried it ~10 years ago and it failing miserably. DNSSEC auto-maintain style looks to be better; still not as nice as running dual-nsd's in master mode; but we'll live with those moving parts. It ran fine for a bit, till I noticed the signatures of the zone had expired and noticed the master simply did not bother to update the sigs anymore. So much for 'automatic' mode. Restarting it caused a nice crash: Debian provided jessie-backports 2.3.1-1~bpo8: ``` knotd[6679]: *** Error in `/usr/sbin/knotd': double free or corruption (out): 0x00007f4244042e80 *** ``` Then was like... lets try the latest edition: Debian provided unstable 2.3.2-1: ``` knotd[11892] general protection ip:7fb8f7f0f218 sp:7fb8ce1cc3b0 error:0 in libc-2.24.so[7fb8f7e98000+195000] ```` yes, that is on a newer libc, hence different style error message it seems. The 2.3.1 edition was able to report: ``` error: [example.com] changes from journal applied 1 -> 1 (invalid parameter) ```` before crashing out, the 2.3.2 just borks out. Unfortunately there are no dbgsym packages for those editions, thus can't easily dig what goes wrong where without having to resort to manually building it all. I could also not find a way to signup to: https://gitlab.labs.nic.cz/users/sign_in to be able to file a ticket about this. Any extra details that one should be providing outside of the above (link to that list is welcome ;) ) Should I attempt knot-nightly? Greets, Jeroen PS: News on https://labs.nic.cz/en/ ends in April 2016...

8 let, 7 měsíců

4
9
0 0

Knot DNS 2.3.3 released!

by Ondřej Surý

Dear Knot DNS users, CZ.NIC is proud to release a new version of Knot DNS. This is mainly bug fix release, but there are some small improvements included as well. There are few fixes related to timers and DNSSEC. We have also fixed double free in journal code, and memory leak in kzonecheck. All domains are now fully-qualified in the logs and there's a new utility to print journal contents - kjournalprint. 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.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.3.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- 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, 7 měsíců

2
1
0 0

Creating TXT/SPF records

by Tom Preissler

Hi, I am just about to create some SPF records for my domain, and it seems I can't do it the right way. The record should look like preissler.co.uk. 3600 TXT "v=spf1 mx -all" and I am creating it with knotc, interactive or not doesn't matter. knotc zone-begin preissler.co.uk knotc zone-unset preissler.co.uk preissler.co.uk. 3600 TXT "v=spf1 mx -all" knotc zone-commit preissler.co.uk this then gives me [preissler.co.uk.] preissler.co.uk. 3600 TXT "v=spf1" "mx" "-all" which is wrong. If I use "'" it's the same. Then using knotc zone-set preissler.co.uk preissler.co.uk. 3600 TXT v=spf1 mx -all I get error: (name does not belong to the zone) [preissler.co.uk] preissler.co.uk. 3600 TXT v=spf1 mx -all I am aware I could just edit the zonefiles or use DDNS probably... but surely, there must be a way? Regards Thomas -- www.preissler.co.uk | Twitter: @module0x90 GPG: BA359D78200264B363314AF5E3839138A11FFD2A

8 let, 7 měsíců

2
2
0 0

Knot na FreeBSD v jailu

by Pavol

Dobry den, pokousim se rozbehnout knot-2.3.1 (kompilace z ports) na jailu na FreeBSD 11 Problem je v tom, ze knot neodpovida na udp portu a to i kdyz to zkousim primo v jailu. Jine porty napr. smtp primo z jailu funguji, mozna je to jenom nejaka chyba v nastaveni knot-2.3.1 Toto vsechno jsem zkousel: * netcat z jailu na stejny jail udp port 53 - funguje * netcat z hostu do jailu udp 53 - funguje * netcat z jineho hostu na host kde bezi jail udp 53 - funguje Takto to dopadne primo z jailu ale i z jineho hosta: # kdig liguros.net aaaa @ns1.liguros.net ;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP) ;; WARNING: response timeout for 5.135.156.9@53(UDP) ;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP) ;; WARNING: response timeout for 5.135.156.9@53(UDP) ;; WARNING: response timeout for 2001:470:cadd:1::5@53(UDP) ;; WARNING: response timeout for 5.135.156.9@53(UDP) ;; WARNING: failed to query server ns1.liguros.net@53(UDP) Toto vidim v pfctl -s states all udp 2001:470:cadd:1::5[53] <- 2001:470:cadd:2::53[60288] NO_TRAFFIC:SINGLE all udp 2001:470:cadd:1::5[53] <- 2001:470:cadd:2::53[40209] NO_TRAFFIC:SINGLE relevantni rules pass in inet6 proto tcp from any to 2001:470:cadd:1::5 port = domain flags S/SA keep state pass in inet6 proto udp from any to 2001:470:cadd:1::5 port = domain keep state takto jsou jeste nastavene rdr na ip4 adresu jailu: rdr pass on em0 inet proto tcp from any to any port = domain -> 10.0.0.5 rdr pass on em0 inet proto udp from any to any port = domain -> 10.0.0.5 rdr pass on lo1 inet proto tcp from any to any port = domain -> 10.0.0.5 rdr pass on lo1 inet proto udp from any to any port = domain -> 10.0.0.5 i kdyz nemyslim si, ze je to pf vina, protoze se do jailu napr. pomoci netcat "dostanu" ns jail: ns:/usr/ports/dns/knot2@[22:44] # sockstat USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root knotd 1650 7 dgram -> /var/run/logpriv root knotd 1650 8 udp4 10.0.0.5:53 *:* root knotd 1650 9 tcp4 10.0.0.5:53 *:* root knotd 1650 10 udp6 2001:470:cadd:1::5:53 *:* root knotd 1650 11 tcp6 2001:470:cadd:1::5:53 *:* root knotd 1650 15 stream /var/run/knot/knot.sock Poradte mi prosim, jak danou vec dale debugovat. Predem mockrat dekuji. Pavol ############################################### English follows ############################################### I am trying to get knot 2.3.1 (from ports) working in a jail, but I am unable to connect to the udp port even when trying directly from jail. Using netcat from within jail and also from other machines gets through into the jail. I don't think it is pf's fault. How can I debug this a bit more? Thank you for your help Pavol -- Email encryption for everyone via @fsf https://u.fsf.org/zb

8 let, 7 měsíců

3
3
0 0

Re: [knot-dns-users] Knot na FreeBSD v jailu

by Pavol

Thank you, this (--enable-recvmmsg=no) fixes it for me. Hopefully the patch and new version will get into ports soon. Thank you very much for your help. Pavol, now with working DNS on FreeBSD :) On 24.11.2016 13:05, Leo Vandewoestijne wrote: > On Thu, 24 Nov 2016, Vladim??r ??un??t wrote: > >> Hi, >> I hope English will be understandable enough (to you). >> >> On 11/23/2016 11:00 PM, Pavol wrote: >>> I am trying to get knot 2.3.1 (from ports) working in a jail, but I am >>> unable to connect to the udp port even when trying directly from jail. >>> Using netcat from within jail and also from other machines gets >>> through into the jail. I don't think it is pf's fault. >>> >>> How can I debug this a bit more? >> >> Was knot compiled with recvmmsg support? The FreeBSD implementation of >> this was buggy and I don't know which version got fixed: >> https://github.com/freebsd/freebsd/pull/91 >> It's possible to disable the functions by passing --enable-recvmmsg=no >> to ./configure. >> > I was already on that, and requested that two weeks ago: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214303 > > Somehow my confirm did not came trough, I just did that again. > > -- > > With kind regards, > > > Leo Vandewoestijne > <***(a)dns.company> > <www.dns.company> > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > -- Email encryption for everyone via @fsf https://u.fsf.org/zb

8 let, 7 měsíců

1
0
0 0

Don't preserve CD flag?

by John-Paul Gignac

I'm an engineer at Dyn and I work on the same team as Matthijs Mekking. I noticed that commit 3f950e1d ( https://gitlab.labs.nic.cz/labs/knot/commit/3f950e1d3f323b0ebbd339de29f8c8b…) changes the handling of the CD bit in responses. The test code comments indicate that this is in accordance with https://tools.ietf.org/html/rfc4035#section-3.1.6, but my reading is that it contradicts section 3 of the same RFC. I was wondering if somebody could explain the history or the thinking behind this change. Thanks in advance! John-Paul Gignac

8 let, 7 měsíců

2
2
0 0

"make check" FAIL with 1.6.0/1.6.8 on Arch Linux

by Tom Preissler

Hi, I am about to migrate my authoritative Bind instance to Knot. My server is Debian Jessie, and the available packge there is 1.6.0-1. I wanted to play on my Arch Linux installation at home to try the migration out, so I am trying to compile aur/knot-lts, which is 1.6.8-1. Compiling it is fine, but "make check" fails: dnssec_sign.............FAILED 45, 50, 53, 56 (killed by signal 6, core dumped) I tried 1.6.0 directly from source as well, same for 1.6.8 from source. I even downloaded the Debian source and compiled that on AL, same error. ldd tests/.libs/lt-dnssec_sign linux-vdso.so.1 (0x00007ffc1a1d2000) libknot.so.0 => /home/tomtom/Rubbish/knot-dns/knot-lts/knot-1.6.0/src/.libs/libknot.so.0 (0x00007fda7c3b4000) liblmdb.so => /usr/lib/liblmdb.so (0x00007fda7c19f000) libzscanner.so.0 => /home/tomtom/Rubbish/knot-dns/knot-lts/knot-1.6.0/src/zscanner/.libs/libzscanner.so.0 (0x00007fda7bf45000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fda7bd2f000) libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007fda7bb29000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fda7b925000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fda7b708000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fda7b404000) liburcu.so.4 => /usr/lib/liburcu.so.4 (0x00007fda7b1fc000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fda7ad84000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fda7a9e6000) /lib64/ld-linux-x86-64.so.2 (0x00007fda7c5db000) liburcu-common.so.4 => /usr/lib/liburcu-common.so.4 (0x00007fda7a7e1000) Versions: usr/lib/liblmdb.so is owned by extra/lmdb 0.9.18-2 usr/lib/libz.so.1 is owned by core/zlib 1.2.8-4 usr/lib/libcap-ng.so.0 is owned by extra/libcap-ng 0.7.8-1 usr/lib/libdl.so.2 is owned by core/glibc 2.24-2 usr/lib/libpthread.so.0 is owned by core/glibc 2.24-2 usr/lib/libm.so.6 is owned by core/glibc 2.24-2 usr/lib/liburcu.so.4 is owned by community/liburcu 0.9.2-1 usr/lib/libcrypto.so.1.0.0 is owned by core/openssl 1.0.2.j-1 usr/lib/libc.so.6 is owned by core/glibc 2.24-2 usr/lib/liburcu-common.so.4 is owned by community/liburcu 0.9.2-1 I have attached the detailed segfault output separately. Regards Tom -- www.preissler.co.uk | Twitter: @module0x90 GPG: BA359D78200264B363314AF5E3839138A11FFD2A

8 let, 8 měsíců

2
2
0 0

Knot Resolver 1.1.0-8 is caching delegation's TTL instead of zone's TTL

by Arsen STASIC

Hi, I have recently started using Knot Resolver. Thanks for that really nice piece of software. Knot Resolver seems to cache the TTL of parent zone (= delegation) instead of the TTL which is in the zone itself. dig +noall +auth @n.ns.at univie.ac.at ns univie.ac.at. 10800 IN NS ns3.univie.ac.at. univie.ac.at. 10800 IN NS ns4.univie.ac.at. univie.ac.at. 10800 IN NS ns5.univie.ac.at. univie.ac.at. 10800 IN NS ns7.univie.ac.at. univie.ac.at. 10800 IN NS ns8.univie.ac.at. univie.ac.at. 10800 IN NS ns10.univie.ac.at. dig +noall +ans @ns10.univie.ac.at univie.ac.at ns univie.ac.at. 600 IN NS ns7.univie.ac.at. univie.ac.at. 600 IN NS ns4.univie.ac.at. univie.ac.at. 600 IN NS ns8.univie.ac.at. univie.ac.at. 600 IN NS ns3.univie.ac.at. univie.ac.at. 600 IN NS ns5.univie.ac.at. univie.ac.at. 600 IN NS ns10.univie.ac.at. dig +noall +ans @ns10.univie.ac.at ns10.univie.ac.at a ns10.univie.ac.at. 600 IN A 192.76.243.2 Knot Resolver is caching 10800 instead of 600: dig +noall +answer @127.0.0.1 ns10.univie.ac.at a ns10.univie.ac.at. 10634 IN A 192.76.243.2 Bind, unbound and pdns-recursor cache authoritative TTL (600). I have tried to file a bug report at https://gitlab.labs.nic.cz/labs/knot/issues , but I wasn't able to create a user account. cheers, -arsen

8 let, 8 měsíců

2
1
0 0

Knot DNS 2.3.2

by Ondřej Surý

Dear Knot DNS users, CZ.NIC has just released a new version of Knot DNS. This is mainly bug fix release, but there are some small improvements included as well. There are few fixes related to templates (the root zone now expands to an empty string), timers (zone transfer refresh), ENTs and CD bit handling. knotc is now faster and zone purge also purges timers. You can also specify a journal path and timeout of dnsproxy module. 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.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.2.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ -- 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

Enable Multi Core CPU in KnotDNS

by shidiq＠pandi.id

Hi All, i'm using knot dns in centos 7 and cpu usage average is 70-90%. i have multi core cpu in this server, but just 1 cpu use by knot DNS. How to enable more than 1 core cpu in knot dns? Thanks, .shidiq

8 let, 8 měsíců

2
1
0 0

xip.io functionality with Knot?

by Tobias Brunner

Hi Knot people, As xip.io is very unreliable, I was wondering if it is possible to achieve a similar service with Knot? Examples what xip.io is doing: 10.0.0.1.xip.io resolves to 10.0.0.1 www.10.0.0.2.xip.io resolves to 10.0.0.2 foo.10.0.0.3.xip.io resolves to 10.0.0.3 bar.baz.10.0.0.4.xip.io resolves to 10.0.0.4 Cheers, Tobias

8 let, 8 měsíců

2
1
0 0

snapshot 186526

by Bastien Durel

Hello, I see there's an "unreleased" snapshot in http://deb.knot-dns.cz/knot/ repository, is it intentionnal ? The following packages are currently pending an upgrade: knot 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 knot-dnsutils 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 libdnssec2 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 libknot4 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 libzscanner1 2.3.1-1+0~20161025234932.8+jessie~1.gbp186526 ======================================================================== Package Details: Reading changelogs... --- Changes for knot (knot knot-dnsutils libdnssec2 libzscanner1) --- knot (2.3.1-1+0~20161025234932.8+jessie~1.gbp186526) unstable; urgency=medium ** SNAPSHOT build @18652664b6e8eeb47ba878c1ff6790f5b6ce3451 ** * UNRELEASED -- Ondřej Surý <ondrej(a)sury.org> Wed, 26 Oct 2016 01:49:34 +0200 Regards, -- Bastien

8 let, 8 měsíců

1
0
0 0

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

9 let

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.

9 let

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

9 let

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

9 let

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

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

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

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

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

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

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

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

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

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

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

dynamically add/delete zones on the fly?

by Mark Jeftovic

Hi, is there any way to dynamically add/delete zones on-the-fly other than to rebuild your master config and reload? Thx - mark

9 let, 5 měsíců

5
6
0 0

Knot 2.1.0-rc1

by Bastien Durel

Hello, Knot 2.1.0-rc1 made its way to the debian repository. I installed it as part of today's upgrade, but it seems to not like my configuration : For each zone I got these messages : 2016-01-14T10:07:00 error: [durel.org] DNSSEC, failed to initialize (invalid parameter) 2016-01-14T10:07:00 error: [durel.org] failed to store changes into journal (invalid parameter) 2016-01-14T10:07:00 error: [durel.org] zone load failed (invalid parameter) I log zone events up to notice level. my default template is : template: - id: "default" storage: "/var/lib/knot/external" ixfr-from-differences: "on" dnssec-signing: "on" kasp-db: "keys" serial-policy: "increment" And this zone is defined as : - domain: "durel.org." file: "durel.org" notify: "corrin" acl: "acl_corrin" Which is this "invalid parameter ?" Thanks, -- Bastien

9 let, 5 měsíců

2
4
0 0

Knot DNS 2.1.0 (final release)

by Jan Včelák

Hello everyone. I'm glad to tell you that Knot DNS 2.1.0 by CZ.NIC Labs was just released. Thank you for the feedback on the release candidate. I believe we have addressed all the issues and bug reports we have received. Let me just quickly summarize the news in the 2.1.0 you already know about: SO_REUSEPORT support, binary configuration database, PKCS #11 support in DNSSEC, zone file name formatters, configurable location for timer database, experimental module for online signing, and many other improvements. If you are interested in details, please, see the 2.1.0-rc1 announcement. And now finally, we are getting to the news in the final release: - We have resolved the problem with the server crashing when configured with a high number of interfaces and threads. This problem started to affect more people because of the introduction of the SO_REUSEPORT support which causes a higher allocation of file descriptors. - We have changed the '%s' zone file name formatter behavior for the root zone. In the release candidate, the trailing dot was skipped for all zones except for the root zone. In 2.1.0, the trailing dot is skipped even for the root zone. The root zone therefore expands to an empty string. This should make your Ansible templates less hacky. - The keymgr now supports KASP database upgrade. So if you have initialized the database with Knot DNS 2.0, please, run 'keymgr init' in the KASP directory to avoid DNSSEC 'invalid parameter' errors. The command is idempotent, it won't rewrite your existing settings. - We have removed the possibility to run knotc over a network socket. The interface allows altering the configuration and possibly sensitive content (e.g. TSIG keys) could appear on the network in plain text. We are working on some better configuration interface which will (among other things) guarantee confidentiality. - We have also fixed a problem with slave zone bootstrapping when the server launches and the slave zone fails to load from a zone file. In this case, an immediate zone transfer is scheduled. Prior to this release, the transfer had to be initiated manually by knotc. Thank you for reading so far. Hopefully I haven't forgotten about anything important. And as always, we are here for you to answer any questions. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.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, 5 měsíců

1
0
0 0

script to export config from knot 1.x to 2.x

by Josef Karliak

Good morning, do somebody (or knot dns) have script to migrate from knot dns 1.6 to knot 2.x version ? 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, 6 měsíců

3
2
0 0

Manage zonefile directory in git

by Tobias Brunner

Hi everyone, I'd like to manage the directory holding all the zonefiles in git to have a workflow like "git push -> webhook -> zonefiles git pull -> knotc reload". With Knot versions <2 this was working great because Knot did not change anything in this directory. But when using Knot 2.x with DNSSEC enabled, Knot rewrites the zonefiles of DNSSEC enabled zones, creates a timers subdirectory and puts some *.db files into the zones directory. Are there any configuration parameters to change this behaviour? So that the timers subdirectory is created outside the directory holding zonefiles (preferably configurable), the *.db files are also written into a dedicated directory and signed zonefiles are saved into a different subdirectory. Or are there any proposals how I could manage the zonefiles directory with git when using Knot 2.x with DNSSEC enabled? Thanks a lot for all input. Cheers and happy new year! Tobias

9 let, 6 měsíců

6
9
0 0

Knot Puppet module now 2.x ready

by Tobias Brunner

Hi all, The Knot Puppet module is now fully Knot 2.x compatible. It can be found on Puppet forge: https://forge.puppetlabs.com/tobru/knot Any feedback and all pull requests are highly appreciated. Cheers, Tobias

9 let, 6 měsíců

1
0
0 0

Knot DNS 2.1.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Have you been good this year? CZ.NIC Labs just released a Christmas present for all Knot DNS users — a new and shiny release candidate. This version contains a bunch of new features, quite a lot of improvements and also some bug fixes. Let's start with the features: - If you run Linux, you will get a higher packet throughput for UDP thanks to the SO_REUSEPORT socket option. In some cases, we have seen 100% packet rate increase. - As an alternative to the textual configuration file, we now support a binary configuration database. This is primarily intended for users with many zones who need to reconfigure their servers quickly. For this purpose, the knotc utility adds new conf-* commands, which can be used to query and modify the server configuration on-the-fly. - DNSSEC newly implements an interface to access cryptographic tokens via the PKCS #11. This means, that you can store the private key material for DNSSEC keys more securely than before. - We have also included an experimental module for DNSSEC online signing. This can be used for instance with the other modules synthesizing records on-the-fly. As for various improvements: - The zone file name can now include formatters, which will be later substituted. For example, if you have many zones and want to sort them into directories based on their TLD, you can use '%l[0]/%s.zone' as the 'file' config option, and the zone 'example.com' will be loaded from '$storage/com/example.com.zone'. - We have added the 'timer-db' option to customize path to the database with persistent zone timers. This is useful if you have multiple knotd instances sharing a zone storage directory. - After the recent DDoS attacks, we have improved the RRL documentation to include details about the effect of the individual rate-limit-slip configuration values. We also made this option to accept zero value which will make the server drop all responses exceeding the limit. - Other small changes in the server include improved networking code so we can better handle connection timeouts. The ACL failures are now logged. And some of the critical configuration values are cached for better performance. - The kdig utility now prints a warning instead of failing with an error when a TSIG validation failure is encountered. - We've also performed some cleanup of the support libraries: libknot, libzscanner, and libdnssec. So if you are developing your own DNS application, take a look at these. And that's it. Please, refer to the documentation for more information. And if something is not clear, just ask on the mailing list and we will try to clarify any ambiguities. You will find your present under our Christmas tree. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.0-rc1/NEWS Source tarball: https://secure.nic.cz/files/knot-dns/knot-2.1.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.0-rc1.tar.xz.asc On behalf of our development team, I wish you a merry Christmas and happy New Year. 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, 6 měsíců

1
1
0 0

Knot DNS 1.6.6 and 2.0.2 (security patch release)

by Jan Včelák

Hello everyone. CZ.NIC Labs just released two security patch version of Knot DNS. Knot DNS 2.0.2 - We have recently extended our fuzzy-testing tool set by a new LibFuzzer tool, which lead to a discovery of a bug in the packet parser. A specially crafted packet with malformed NAPTR record can trigger an out-of-bound read, possibly leading to the knotd daemon crash. The new version fixes this bug. Knot DNS 1.6.6 - The 1.6 packet processing code contained the same issue in NAPTR parsing which was present in the 2.0. However, existing code paths to its occurrence were different. We are not aware of any possibility to remotely crash the server daemon at the moment. - The updated version also fixes systemd server startup notifications. - We have included the rosedb module, which has already been distributed as a separate tarball for a few releases. Users of rosedb should switch to the main releases. If you are a Knot DNS 2.0 user, we highly recommend to updated to version 2.0.2 because it is possible to cause a denial of service remotely. If you are a Knot DNS 1.6 user, we suggest to update to the latest release even though the fixed problems are not as critical as in the 2.0 branch. The sources are available as usual. Full changelogs: https://gitlab.labs.nic.cz/labs/knot/raw/v1.6.6/NEWS https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.2/NEWS Tarballs: https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.0.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.0.2.tar.xz.asc Best regards! And thank you for using Knot DNS. 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ů

2
2
0 0

[Knot-Resolver] "I yielded, not you" issue

by Florian Maury

Hi everyone, While working on my Knot-Resolver (kr) module, I came to think that the current YIELD mechanism for layers will not work properly, if multiple YIELD-enabled modules are loaded simultaneously. My understanding of how the current YIELD system works is as follows. A layer receives the current state through ((knot_layer_t*) ctx)->state. The current state can be modified by previous layers returned value. When a layer returns a YIELD state, the chain of responsability, maintained by the lib/resolve.c:ITERATE_LAYERS macro is broken (break;) and the resolution plan is evaluated once more to handle the tail element of the rplan. Once the rplan popped up all rplan_pushed queries, then the query that yielded is once more the last element of the rplan stack. This element is then evaluated, calling once more all layers, starting with the first layer. This time, the state that is provided to the layers is YIELD, except if a layer returns another value instead of returning the state as is. A layer could behave differently, based on whether it receives a YIELD state or not as "input state". This is, in fact, what is provided as example in the documentation: >>> consume = function (state, req, answer) answer = kres.pkt_t(answer) if state == kres.YIELD then print('continuing yielded layer') return kres.DONE else if answer:qtype() == kres.type.NS then req = kres.request_t(req) local qry = req:push(answer:qname(), kres.type.SOA, kres.class.IN) qry.flags = kres.query.AWAIT_CUT print('planned SOA query, yielding') return kres.YIELD end return state end end <<< The issue, I think, is that a module has no way of knowing whether it is the one that yielded or not. Let's say I have three module, A, B, and C. B and C can yield, and A only returns YIELD, when it receives YIELD as input state. On the first evaluation, A and B returns DONE. C yields. Then on the second evaluation, A returns YIELD, because it does not handle this state and only passes it along. B receives the YIELD from A. B, as said above, may yield in some cases. B will therefore handle the YIELD, and do his "YIELD" actions, ignoring the fact that the module that actually yielded was C. I suppose B and C could define flags to be capable of remembering whether they yielded on this query or not. Unfortunately, there is currently no framework to ensure uniqueness of these flags. Sadly, this email does not come up with a proposed solution. I'm only sharing a thought about what I think could be an issue. What is your take on this? Have I missed something or misunderstood how the yield state works? Thank you. Cheers, Florian

9 let, 7 měsíců

2
3
0 0

Re: [knot-dns-users] knot 1.4.4 and problem with journal size - zone not loaded

by Daniel Salzman

Hi, You can try setting https://www.knot-dns.cz/docs/1.6/singlehtml/index.html#ixfr-fslimit or simply deleting the journal file corresponding to the ajetaci.cz zone. Dan > > Good morning, > where is problem with zone ? > Error : > journal size is too small to fit the changes. > > Knot is owner of this directory. > > After loading zone I found that record on some line in the zone file is > invalid, I deleted it, increased serial and after reloading zone I could > not set it UP > > > Log records about the zone: > Nov 9 08:22:14 celer knot[20407]: Semantic checks completed for > zone=ajetaci.cz. > Nov 9 08:22:14 celer knot[20407]: Zone 'ajetaci.cz.' loaded (serial > 2015110901) > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - Signing > started... > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 36256, file Kajetaci.cz.+005+36256.private, KSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 11937, file Kajetaci.cz.+005+11937.private, ZSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 5300, file Kajetaci.cz.+007+05300.private, ZSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 58830, file Kajetaci.cz.+007+58830.private, KSK, active, public > Nov 9 08:22:14 celer knot[20407]: [error] Zone 'ajetaci.cz.' journal size > is too small to fit the changes. > Nov 9 08:22:14 celer knot[20407]: Loaded 2 out of 3 zones. > Nov 9 08:22:14 celer knot[20407]: [warning] Not all the zones were loaded. > > > Any ideas ? > Thanks and best regards > J.

9 let, 8 měsíců

4
4
0 0

*****SPAM***** knot 1.4.4 and problem with journal size - zone not loaded

by Josef Karliak

Spam detection software, running on the system "mail.nic.cz", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Good morning, where is problem with zone ? Error : journal size is too small to fit the changes. Knot is owner of this directory. After loading zone I found that record on some line in the zone file is invalid, I deleted it, increased serial and after reloading zone I could not set it UP [...] Content analysis details: (5.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.8 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4973] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 3.0 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

9 let, 8 měsíců

1
0
0 0

[Knot-Resolver] Modules meddling with the NS selection feature request

by Florian Maury

Hi everyone, While I was working on my Knot-Resolver (kr) module, I wondered how I could be able to ratelimit the trafic toward specific nameservers or influence the NS selection algorithm, in general. Unfortunately, the current NS election algorithm that is present in the lib/resolve.c driver and in lib/nsrep.c does not allow a module to register a layer to influence the NS selection. Is there any plan to add event listeners to influence NS selection, for instance by giving layers the opportunity to "congregate" and return a modifier, a lot like the "favour" IPv6 modifier/variable that is done in lib/nsrep.c:eval_addr_set? Thanks. Cheers, Florian

9 let, 8 měsíců

1
0
0 0

[Knot-Resolver] Async module unloading and cleanup event idea

by Florian Maury

Hi everyone, While working on a Knot-Resolver (kr) C module, I stumbled on a limitation of the current way layers are loaded and unloaded. My understanding is that, currently, C modules are loaded via a dlopen call, and then a callback "moduleName_init" symbol is searched and called. On unloading, a symbol "moduleName_deinit" is searched and called, and upon completion of the deinit function, a dlclose call is made to unload the module from memory. This occurs in lib/modules.c. As it happens, my C module provides callbacks (cb) for several layer hooks. Some of these cb perform potentially long-lived I/O operations. Since functions are not supposed to take a lot of CPU time, in order to maintain kr responsiveness and with respect to the event-oriented design, I chose to embrace libuv and use the uv_* functions to perform these I/O operations. This means I inserted in the uv_default_loop several cb for network or filesystem events. These cb need to be called for some operations to be successfully completed. Think about SQL commit statements and whatnot. Currently when a user wants to stop the daemon, the "graceful" procedure is to call quit() on the CLI. This procedure calls uv_stop on the uv_default_loop, thus stopping abruptly all registered cb from being ever called again. Then, modules are unloaded one by one. These unloading calls to moduleName_deinit can be blocking because no service requires responsiveness anymore. On the other hand, if a module is shutdown during normal operations, for instance, via a call to "modules.unload" from the CLI, the unloading procedure cannot perform blocking actions without generating a negative impact on the overall responsiveness. The problem is that it cannot perform non-blocking actions either because as soon as the deinit function returns, the code for the non-blocking actions "to wrap up" currently registered callbacks in the uv_default_loop is removed from memory. To solve this problem, I would suggest creating a cleanup event, sent to modules that should be unloaded. A module receiving a call to its handler for this event would be expected to wrap it up ASAP. It would, however not be expected to have completed everything at handler return time. The sender of the cleanup event could then register a uv_idle handler that would call the deinit function. The deinit function would then be in charge of ensuring the module no longer have any event handler registered in the uv loop. If no cb are present in the loop, it would return a status code allowing the caller to dlclose the module. With this approach, calling the "graceful" quit procedure would then send a cleanup event to all modules, including iterate, cache, etc. uv_stop would not need to be called anymore because the idle handler would be able to know that no handler are in the uv_loop except itself: it would then unregister itself and the uv_run call would terminate spontaneously. What is your take on this issue? Do you think the proposed solution would be acceptable? Would it work with all kind of modules (I'm thinking about the lua and go modules)? I, sadly, currently have no code to do this. I just thought it might be useful to document this on the mailing list and share ideas about it. Thank you. Cheers, Florian

9 let, 8 měsíců

1
0
0 0

[Knot-Resolver] kr_zonecut_find_cached seemingly incorrect result

by Florian Maury

Hi everyone, I have been recently working on a Knot-Resolver (kr) module for some research work. This led me to push new queries into the resolution plan, wait for the answer and then resume the "standard" kr-spooled queries. Once all queries are resolved, when my finish module callback (cb) is invoked, I write down some statistics that were collected throughout the various queries. Among the thing that I write down, I inspect some data in the cache, including zonecuts. I discovered that some information returned by lib/zonecut.c:kr_zonecut_find_cached were different from what I expected. I am not sure if this is because my call to kr_zonecut_find_cached is incorrect, if I messed up some kr internal logic or if I stumbled on a bug. Here follows a made-up domain name tree similar to what made me stumbled on this issue, what I thought should be returned by kr_zonecut_find_cached, and what is actually returned. The original query qname is example.com.. Example.com. is delegated to a company owning example.net, a DNS reseller providing DNS hosting for its clients. example.com. is gluelessly delegated to ns1.example.net. and ns2.example.net.. example.net. is gluelessly delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net.. some-famous-registrar.net. is also delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net. thus using a glued delegation. When I call kr_zonecut_find_cached in my module finish cb, with a "name" param whose value is srv1.some-famous-registrar.net., I expected the cut out-param to be filled with a kr_zonecut structure with a "name" equal to some-famous-registrar.net. and a nsset equal to srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net. Unfortunately, cut->name values net., which is of course incorrect, since some-famous-registrar is a delegated name. My call to kr_zonecut_find_cached is using a kr_cache_txn structure created by the finish cb, using the cache in ((knot_layer_t*) ctx)->((kr_request*) data)->ctx->cache. It may also be worth noting that I use "false" for the secured param of the kr_zonecut_find_cached call. If this is indeed a bug, my guess would be that example.com. delegation leads kr to ask to net. nameservers for the delegation information for example.net.. net. nameservers answer that the delegation to example.net. is through srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net.. At the same time, net. nameservers also provide the *glues* for srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net., since the net. zone contains non-authoritative IP address records for these names for the glued delegation of some-famous-registrar.net. This could make kr to believe that net. is "authoritative" in some way for srv1.some-famous-registrar.net. and therefore to think that the some-famous-registrar.net is not a delegated zone. It is however possible that I completely crashed kr zonecut logic with the additional queries that I pushed from time to time, though. Does that ring a bell to anyone? What would be, according to you, the next step I should take to better understand what is going on? Thanks for your help! Cheers, Florian

9 let, 8 měsíců

1
0
0 0

Dynamic Update

by Ulrich Wisser

Hi! Just a short feedback. Today I got the latest source from git and it compiled on my Raspberry Pi. The Dynamic Update "bug" or incompatibility is fixed. Thanks for all your help! And thanks for fixing it so fast! /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 8 měsíců

1
0
0 0

subscription

by Yves Bovard

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Community A I am a Knot DNS user, I would like to subscribe to your mailing list. How can I do that? Best regards Yves Bovard - -- SWITCH - -------------------------- Yves Bovard, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 31 yves.bovard(a)switch.ch, http://www.switch.ch -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJWJNm7AAoJEOgRvbd1sr4QoV8QAK//5Hio41UtP56JWvnBxyLo gmQRXZrD2Q6B97e0OfvFA2CLnmmKfmQwHniCWG4prgktdtsiwLscWFhBdTGk4OW9 0w9VHWc+Jvl3gDv18kmGaN9azMsoqiZ6ws3CsnEq/WdObR0a0KwJHuy3yJBJleXz NpUN58qp+kaPQ46a0o2WKgAtDpilg30tWX2k2gLPXlNfu7IGPkmp+sXrPwWFtim5 CZHeDFfPYCWlaD8Lw1VC/7u8dKUMk4yYE35ioXlMxt2Xgdeagu70ZW9EyC7Xx4EZ iPFDKdvxRpBljhc8YchXSldkg4rqtsQwE4h4Q07s7RAv/tkZKxAllodtiRtFC/TP oVQ4QUjFcbUKC5dUWCQnGVbyyzBVgdWsBnhhQKiuM1477dwKe2ugMFNvIGo7GqAJ 3HDqL+L1FteBbW9iBvHN3XRcXk4bdKBm2MvbJ3KN6SptvM7n85jhLNIV+Tao+UGP uVi3+f4KC9m2H9D7GnIjsWZQkxCfAo0di1RYG9L57wOIm/cCJYbn90nDm7sAvomb hxRAdJYCTM+xVvlhoiANqcXll9MS4yZTD5KhZR5DgZpCoJPbatxbEy3l3r9ZTFYb Xh3+plCk67mYClcbIo7Ln5+kWJMLKObTcSvHaApWJiMhrbU3eKoXNMZE+w90NSOW wcgyCg0F+VtwoN+EVWXv =9ZJL -----END PGP SIGNATURE-----

9 let, 8 měsíců

2
1
0 0

knot 1.6 an non-locl interfaces

by Peter Hudec

Hi, I need to listen on inteface which may not be present at start time. I want to ask if there is a way to enable non-local interface bind on KnotDNS 1.6. The version 2.X supports this feature, but thos version os nt available for CentOS /as I read in maliling list archive and seen the build for EPEL/. best regards Peter Hudec -- *Peter Hudec* Infraštruktúrny architekt phudec(a)cnc.sk <mailto:phduec@cnc.sk> *CNC, a.s.* Borská 6, 841 04 Bratislava Recepcia: +421 2 35 000 100 Mobil:+421 905 997 203 *www.cnc.sk* <http:///www.cnc.sk>

9 let, 9 měsíců

2
4
0 0

DDNS with python

by Ulrich Wisser

Hi! In the last few days I have tried a new service for DDNS, nsupdate.info. I have some problems with the service and I have been able to reproduce the problem in a small sample script. The attached script does update my bind9 instance but reports SERVFAIL for Knot. Unfortunately I still have not been able to get Knot to write more extensive log entries. The script uses the Python dns library from Nominum. This is the output of the script (first update to bind then to knot) $ python example.py performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 DNS error [SERVFAIL] performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 Knot didn't log anything at all. (Any hints for that config would be welcome.) Bind did log the following Oct 5 21:07:49 localhost named[23792]: client beef::cafe#59322/key example.com: updating zone 'example.com/IN': adding an RR at ' ddns.example.com.' A Some error in the script? Could someone point me to a working script? Any hints are welcome! Kind regards from Stockholm Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 9 měsíců

4
13
0 0

Knot DNS 2.0.1 patch release

by Jan Včelák

Hello everyone! CZ.NIC Labs just released Knot DNS 2.0.1. There is a lot of bug fixes, new features, and improvements since the final release. Let's start with the bug fixes: - The 2.0.1 received all the relevant bug fixes included in the 1.6.5. Namely fix for expired zones reloading, fix for race-condition in event scheduling, fix for NSEC proofs with zones containing lots of delegations, fix for TC flag setting in RRL slipped answers, fix for root label compression, and fix for journald logging without systemd. - The old version was incorrectly following CNAME when queried for the NSEC record. This is fixed in the new version. - There was a bug in the code planning DNSSEC resigning. The code hadn't considered expiration of DNSKEY RRSIGs and therefore these signatures could have had expired. This problem is resolved now. - Binding to an unavailable IPv6 address was broken on Linux (IP_FREEBIND). When the daemon was started before the network was fully up, the daemon failed to bind IPv6 addresses. This problem is fixed as well. - The knotc utility entered an infinite loop when the zonestatus or memstats command was executed for an individual zone. This shouldn't happen any more. - The dnsproxy module was not working properly as we have changed the request processing code without updating the module. This has been addressed. - There was a problem with parsing time stamps in the DNSSEC KASP database when compiled against the uClibc standard C library (e.g., in Alpine Linux). The parsing has been rewritten to work in strict POSIX environment. - We have fixed multiple problems related to endianness. We have eliminated compilation warnings on OpenBSD related to endian conversion functions. The multi-value config options parsing didn't work on big-endian machines. And we also added detection of the Nettle library version, because the version 3 changed the Base64 decoding API incompatibly. As for the new features: - The keymgr utility now supports 'zone key ds' command to retrieve DS records for a key. And also 'tsig generate' command to generate TSIG key in the format accepted by Knot DNS. - We have added module scoping. So the modules can be configured either to process all queries received by the server. Or their scope is limited to individual zones. - The 'include' config directive supports file name globbing. So you can import multiple files at once (e.g., include: conf.d/*.conf). - Same as in the 1.6.5, the 2.0.1 supports the 'request-edns-option' config option allowing to add custom EDNS0 options into the DNS queries initiated by the server. And at last but not least, the improvements: - We have decided to remove NS record from the Authority section for NOERROR responses. We used to put these records there because BIND and NSD did it. But these records are not required by any RFC and just increase the size of the response. - The persistent zone timers are written only on server shutdown for better startup performance. - The change of TTL over DDNS is now allowed without removing the existing records. - We have reviewed the documentation and fixed a couple of grammar mistakes, updated some sections, and improved formatting a little bit. - The yparser and zscanner header files are now installed. As you may see, we are not lagging behind. This list is quite long for a patch release. And we have much more up in our sleeve. Thank you for reading this far. And we are looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.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, 9 měsíců

4
6
0 0

Knot on Raspberry Pi (armhf)

by Ulrich Wisser

Hello! I have tried to get the latest version of Knot running on my Raspberry Pi 2. Unfortunately does Raspian only have packages for an old version. I updated my Pi to debian jessie. There is actually a version of Raspian based on jessie. That version of Raspian does come with slightly newer packages, but still not up to date. So I compiled my own version. 2.1.0-dev Everything works fine until the moment I try to start knotd. IT will crash with a segfault. I did recompile with --enable-debug but I do not get any debug output in syslog. I did run with gdb and got the following information SYSLOG: Sep 16 22:36:57 localhost knotd[3522]: info: Knot DNS 2.1.0-dev starting Sep 16 22:36:57 localhost knotd[3522]: info: binding to interface '2001:470:28:193::53@53' Sep 16 22:36:57 localhost knotd[3522]: info: configured 1 zones Sep 16 22:36:57 localhost knotd[3522]: info: changing GID to '1003' Sep 16 22:36:57 localhost knotd[3522]: info: changing UID to '1002' Sep 16 22:36:57 localhost knotd[3522]: info: loading zones Sep 16 22:36:57 localhost knotd[3522]: info: [example.com] zone will be loaded, serial 0 Sep 16 22:36:57 localhost knotd[3522]: info: starting server GDB: [New Thread 0x50baa200 (LWP 3526)] [New Thread 0x50aaa200 (LWP 3527)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x50baa200 (LWP 3526)] scanner_process (scanner=0x50978008) at knot/zone/zonefile.c:152 152 if (zc->ret != KNOT_EOK) { (gdb) bt #0 scanner_process (scanner=0x50978008) at knot/zone/zonefile.c:152 #1 0x76d80a14 in ?? () from /usr/lib/arm-linux-gnueabihf/libzscanner.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 147 148 /*! \brief Creates RR from parser input, passes it to handling function. */ 149 static void scanner_process(zs_scanner_t *scanner) 150 { 151 zcreator_t *zc = scanner->data; 152 if (zc->ret != KNOT_EOK) { 153 scanner->stop = true; 154 return; 155 } 156 (gdb) It seems that the scanner thread is somehow missing. But why? Anybody with experience with knot on armhf? /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

9 let, 9 měsíců

2
1
0 0

Knot 2.0.1 debian 8 (jessie) builds

by Petr Jediný

Hello, are there any plans to publish latest builds (2.0.1) for jessie? The most current package I can find is knot_2.0.0-1+0~bpo80+1_amd64.deb. Regards, PJ

9 let, 9 měsíců

2
1
0 0

Knot DNS 1.6.5 patch release

by Jan Včelák

Hello list. Today, CZ.NIC Labs releases Knot DNS 1.6.5. This patch release contains quite a lot of non-critical bug fixes and some minor improvements. Everyone is advised to upgrade. Let's go through the fixed bugs quickly: - The server no longer loads expired zones on 'knotc reload' and server startup. - We have fixed a rare race-condition in the event scheduling code. The race caused that events for some zones were significantly delayed. (We were reported that the server is occasionally ignoring notify messages for random zones when the server is receiving many notifies. We believe this bug was the cause and the problem should no longer appear.) - There was a bug in the NSEC proofs construction. When the zone contained many delegations, the NSEC proving non-existence of a covering wildcard was incorrect. The problem is fixed now. - The TC flag was not set correctly for RRL slipped answers. This problem is resolved as well. - We have disabled domain name compression for the root label '.' because it caused negative compression and some client implementations (like Go DNS) might have problem decoding these answers. - The server is now checking whether it is executed in the systemd enviroment before using journald as a sink for log messages. Also the systemd library detection at a build time was improved. - We have also eliminated compilation warnings in endian-conversion functions on OpenBSD. And as for the new features: - The persistent timers are now written to the on-disk database only on server shutdown. This change was done mainly to improve startup and reload performance. - The 'max-conn-idle', 'max-conn-handshake', 'max-conn-reply', and 'notify-timeout' config options now accept time units specification (e.g., one can use 2m instead of 120). - We have added 'request-edns-option' config option, which allows inserting custom EDNS0 options into all queries initiated by the server. And that's all folks. I would like to thank everyone involved in making this release, especially bug reporters. We are looking forward to your feedback. The sources are available 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.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.5.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, 10 měsíců

2
2
0 0

Refreshing DNSKEY RRset signatures

by Antti Ristimäki

Hi, I'm running Knot 2.0.0 and automatically signing my zone with manual key management policy. When I manually refreshed the signatures by running "knotc signzone <zone>", all the signatures were refreshed as expected, except the DNSKEY RRset, whose signature remained untouched. I thought this wouldn't be a big deal, as Knot would probably automatically refresh DNSKEY RRset signature when about 1/10 of its lifetime will be remaining. However, when I now look at "knotc zonestatus", it shows that the next resigning is scheduled far beyond the exipration of the DNSKEY RRset signature. So, is my DNSKEY RRset signature going to be expired or is DNSKEY handled in some special way so that it will be eventually refreshed before expiring? My current DNSKEY RRSIG will expire at 20150828172101: nxdomain.fi. 600 IN RRSIG DNSKEY 8 2 600 20150828172101 20150729172101 61894 nxdomain.fi. qQJm..... But the next resigning is scheduled on 2015-09-14: nxdomain.fi. type=master | serial=2015081708 | DNSSEC resign in 647h56m43s | automatic DNSSEC, resigning at: 2015-09-14T02:26:59 Thanks, Antti

9 let, 10 měsíců

2
1
0 0

first time install got failed

by Ken Peng

Hi, My system is debian 6.0 (yes I know it's out of date). When I installed knot from source following the document, I got failed as below. How can I get continued? thanks. $ autoreconf -i -f libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:35: error: possibly undefined macro: AC_SUBST If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:93: error: possibly undefined macro: AS_IF configure.ac:102: error: possibly undefined macro: AC_MSG_WARN configure.ac:122: error: possibly undefined macro: AC_DEFINE configure.ac:163: error: possibly undefined macro: AC_MSG_ERROR configure.ac:251: error: possibly undefined macro: AC_SEARCH_LIBS autoreconf: /usr/bin/autoconf failed with exit status: 1

9 let, 10 měsíců

2
8
0 0

More fine-grained ACLs

by Matthias-Christian Ott

Network renumbering requires that A and AAAA RRs are directly or indirectly (DHCP) updated. This in turn requires dynamic DNS updates (RFC 2136). Although Knot DNS allows dynamic updates, it is not really prepared to securely handle this scenario. Knot DNS can either allow an address or key to update RRs in a zone via ACLs which is not fine-grained enough to useful for this purpose because it is questionable from a security perspective (under a certain threat model etc.). Assume that example.com uses dynamic DNS updates to update A and AAAA RRs to be prepared to renumber its network. If example.com uses a DHCP server to update the RRs, it suffices to take over the DHCP server of example.com to update any RRs in the zone of example.com, including NS, MX, TLSA and SSHFP RRs. If every host of example.com updates its own A and AAAA RRs directly and indirectly via a DHCP server, the problem is still the same, even if you move every hostname in a separate zone, for example it suffices to take over the webserver that serves example.com to change the MX RRs of example.com. With more fine-grained ACLs the problem would not exist. Currently ACLs consist of a subject (address and key), operation (transfer, notify, update, control) and object (zone). I think it would suffice to extend the object of an ACL to a triple (zone, name, type) similar to dynamic update policies in BIND. Perhaps it would also be useful to be able to use wildcards and negation. Are there any plans to extend the ACL mechanism in this way? Regards, Matthias-Christian

9 let, 10 měsíců

2
1
0 0

Keymgr broken?

by shadice＠arcor.de

Hi Is keymgr broken or what am I doing wrong? /knot# mkdir kasp /knot# cd kasp /knot/kasp# keymgr init /knot/kasp# keymgr zone add example.com policy none /knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 2048 ksk id 36b49807bcdf448c5034cf37688b99616760529c keytag 24400 knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 1024 Cannot retrieve zone from KASP (malformed config value). Regards, shadice

9 let, 11 měsíců

2
2
0 0

knot 2.0.0 and systemd type notify

by Daniel Stirnimann

Hello I've built knot 2.0.0 and created a rpm for redhat 7 and have a problem with the knot.service systemd file. I've used the rpm SPECS and knot.conf, knot.service file from the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=670057 and adapted the SPECS file slightly to get it working on redhat 7. The knot.service file has the following Service section: [Service] Type=notify ExecStart=/usr/sbin/knotd ExecReload=/usr/sbin/knotc reload Restart=on-abort ExecStartPre=/usr/sbin/knotc checkconf If I use the type "notify" and start the service (systemctl start knot) the command does not complete but stays in the foreground. After a few seconds, minutes systemd gets a timeout and terminates the service: systemd: knot.service operation timed out. Terminating. knot[32446]: info: stopping server knot[32446]: info: shutting down systemd: Failed to start Knot DNS server daemon. systemd: Unit knot.service entered failed state. I now changed the knot.service file to use type "simple" [1] and that works and resolves the problem. However, I believe to have read that type "notify" should work. Is this a bug? Daniel [1] http://www.freedesktop.org/software/systemd/man/systemd.service.html

9 let, 11 měsíců

2
2
0 0

Problems with serial-policy

by shadice＠arcor.de

Hi I have problems in v2.0.0 with the serial-policy definition as it is not working as expected. Here is my knot.conf which I am using: # knot.conf server: user: knot:knot udp-workers: 1 tcp-workers: 1 background-workers: 1 listen: 0.0.0.0@53 listen: ::@53 log: - target: syslog any: debug template: - id: default storage: /opt/knot semantic-checks: on dnssec-signing: on kasp-db: kasp serial-policy: increment zone: - domain: example.com dnssec-signing: off 2015-08-11T18:27:33 info: configuration is valid Using increment as serial-policy, first the serial gets incremented by 1. After that, it will stay at 1, nevertheless how many changes I make. info: [example.com] loaded, serial 0 -> 1 info: [example.com] loaded, serial 1 -> 1 info: [example.com] loaded, serial 1 -> 1 info: [example.com] loaded, serial 1 -> 1 Using unixtime as serial-policy, the serial stays always at 0. info: [example.com] loaded, serial 0 -> 0 info: [example.com] loaded, serial 0 -> 0 info: [example.com] loaded, serial 0 -> 0 info: [example.com] loaded, serial 0 -> 0 Am I doing it wrong? Do you use in anyway a RTC? because I do not have it. Regards shadice

9 let, 11 měsíců

2
1
0 0

RoseDB & DNSProxy performance in production

by iorecvsendclose

Has anyone used the rosedb or dnsproxy modules extensively in production? I'm concerned about whether it would reliably scale as well as Knot does without it. I'm evaluating knot in hopes that I can use it to offer part of my would-be service to potentially millions of websites. I'm planning a free usage tier would would hopefully be heavily utilized. Regarding the specific implementation, I want to provide an authoritative DNS server that returns predefined values based on record types/host (rosedb). If the host/record combo conditions aren't met, proxy the request to the original nameserver(s). After reviewing the nightly code it looks like I'll likely need to invest a lot of time in order to support that chained query plan. Thank you for any feedback in advance. -Anonymous Coward

9 let, 11 měsíců

2
1
0 0

Reduce memory usage

by shadice＠arcor.de

Hi Knot DNS v2.0.0 reserves up to 620 MB memory on my Raspberry Pi. But it actually uses only 0.4 % of the available 512 MB memory. How can I limit the memory reservation/allocation to 100 MB? Regards shadice

9 let, 11 měsíců

2
1
0 0

prepare-environment

by Antti Ristimäki

Hi, I just upgraded to Knot 2.0 from the PPA repository and noticed that the script /usr/lib/knot/prepare-environment is still expecting the old style configuration format and as such is not working with the new YAML formatted configuration. As a consequence the /run/knot directory is not chown'ed to the configured user:group and the control socket creation fails. Cheers, Antti

9 let, 11 měsíců

2
1
0 0

Changes in Knot DNS repositories for Debian and Ubuntu

by Ondřej Surý

Hey all, if you are using Knot DNS repositories for Debian and/or Ubuntu, the repositories with just 'knot' will start shipping (or already started) shipping Knot DNS 2.0. There will be no Knot DNS 2.0 packages for Debian wheezy, since we don't want to backport that many libraries. If you absolutely have to stay on Debian wheezy, please switch to Knot DNS LTS. if you want to stay with Knot DNS LTS (1.6.x) replace the part that says /debian or /knot with /knot-lts or /knot-dns with /knot-dns-lts The full instructions should be soon up on the webpages, but TL;DR for Knot DNS LTS: Debian: su - wget -O - http://deb.knot-dns.cz/knot-lts/apt.key | apt-key add - rm -f /etc/apt/sources.list.d/knot.list echo "deb http://deb.knot-dns.cz/knot-lts/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/knot-lts.list apt-get update apt-get install knot Ubuntu: # remove ppa-purge ppa:cz.nic-labs sudo add-apt-repository -r ppa:cz.nic-labs/knot-dns sudo add-apt-repository ppa:cz.nic-labs/knot-dns-lts sudo apt-get update sudo apt-get install knot Cheers, -- Ondřej Surý -- Chief Science Officer -------------------------------------------- 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, 11 měsíců

3
4
0 0

AXFR - RFC1912

by Filipe Cifali

I'm migration from PowerDNS using AXFR and some of the domains fall on Section 2.4 having CNAME on top domains. Is there a way to ignore the warning and receive the query? An example of troublesome domain transfer: Jun 30 11:33:40 p-01 knot[2930]: info: [strangedomain.com] AXFR, incoming, 127.0.0.1@53: starting Jun 30 11:33:40 p-01 knot[2930]: warning: [strangedomain.com] semantic check, node 'strangedomain.com.' (CNAME, node contains other records than RRSIG and NSEC/NSEC3) Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] AXFR, incoming, 127.0.0.1@53: failed (failed) Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] transfer, failed (no active master) I'm running on Gentoo compiling Knotd 1.6.4 from source w/ no special flags. Thanks in advance! -- [ ]'s Filipe Cifali Stangler

10 let

5
13
0 0

Re: [knot-dns-users] AXFR - RFC1912

by Filipe Cifali

Sure, but was a silly mistake I made, Since I was testing on localhost over to another IP on the same machine, all the queries where going from the Local IP to loopback (even though I forced on the remotes flag w/ "via"). So all I had to do was actually serve everything through loopback (only different ports) to make things work. The debug showed the incoming query via *127.0.0.1 <http://127.0.0.1>:<randomport>* The wrong setup I made was: Knotd listening on 192.168.0.1:53; PowerDNS listening on 127.0.0.1:53; PowerDNS couldn't talk to Knotd there, so I changed to: Knotd listening on 127.0.0.1:*53*; PowerDNS listening on 127.0.0.1:*54*; And then they started talking AXFR properly Since this is only a test setup to a larger scale migration I was just testing how AXFR performs w/ tons of data to load (250mb of zone files) and frequent updates that I was running in the same virtual machine. BTW, is a good practice to use the zones over tmpfs or since the knotd already throw everything at RAM on the runtime I don't need it? I didn't liked the load times (but I do understand the existence of knotc and why I should not keep "restarting" knotd). On Tue, Jul 7, 2015 at 4:34 PM, Ondřej Surý <ondrej.sury(a)nic.cz> wrote: > Hi Filipe, > > could you share your findings? We would like to know what was the solution > if another user happens to have the same problem. > > Feel free to share them in private if you don't want to do that publicly. > > Cheers, > -- > Ondřej Surý -- Chief Science Officer > -------------------------------------------- > 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/ > -------------------------------------------- > > ------------------------------ > > *From: *"Filipe Cifali" <cifali.filipe(a)gmail.com> > *To: *"Ondřej Surý" <ondrej.sury(a)nic.cz> > *Cc: *knot-dns-users(a)lists.nic.cz > *Sent: *Tuesday, July 7, 2015 9:26:03 PM > > *Subject: *Re: [knot-dns-users] AXFR - RFC1912 > > Oh I made it work after debugging enough I could get the info needed. > Without debug is very hard to understand why AXFR fails, it only returns > "connection refused". > > Thanks for the attention anyway :) > > On Tue, Jul 7, 2015 at 3:10 PM, Ondřej Surý <ondrej.sury(a)nic.cz> wrote: > >> Also what does the Knot DNS logs say at debug level? >> >> We definitely have a user with similar setup (I'm Bccing him, so he can >> respond at his will) - PowerDNS as a primary and Knot DNS as a secondary. >> >> If you are into a deeper debugging, could you capture the packets between >> Knot secondary and PowerDNS primary? >> >> Cheers, >> Ondrej >> -- >> Ondřej Surý -- Chief Science Officer >> -------------------------------------------- >> 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/ >> -------------------------------------------- >> >> ------------------------------ >> >> *From: *"Filipe Cifali" <cifali.filipe(a)gmail.com> >> *Cc: *knot-dns-users(a)lists.nic.cz >> *Sent: *Tuesday, July 7, 2015 5:41:17 PM >> *Subject: *Re: [knot-dns-users] AXFR - RFC1912 >> >> Yes, w/ aa flag and all the SOA record >> >> >> On Tue, Jul 7, 2015 at 12:12 PM, Jan Včelák <jan.vcelak(a)nic.cz> wrote: >> >>> Hello Filipe, >>> >>> does the PowerDNS server respond to SOA queries over TCP? >>> >>> $ dig +tcp @127.0.0.1 zone.name SOA >>> >>> Cheers, >>> >>> Jan >>> >>> On Tuesday, July 07, 2015 11:59:00 AM Filipe Cifali wrote: >>> > Thanks, I finished fixing all the zones now, finally. >>> > >>> > Anyone has ever used PowerDNS as master of a Knotd slave? I'm missing >>> > something since PowerDNS returns connection refused after the initial >>> > transfer, like it's not responding correctly to PowerDNS. >>> > >>> > Since I can dig AXFR @127.0.0.1 (which has PowerDNS running) I don't >>> see >>> > how he can be wrong. >>> > >>> > I'm not sure where to go looking for the problem here. >>> > >>> > Best Regards, >>> > >>> > [ ]'s >>> > >>> > On Thu, Jul 2, 2015 at 8:49 AM, Jan Včelák <jan.vcelak(a)nic.cz> wrote: >>> > > Hello Filipe, >>> > > >>> > > On Thursday, July 02, 2015 07:57:46 AM Filipe Cifali wrote: >>> > > > it's only failing for the zones w/ problems w/ CNAMEs, ignoring the >>> > > > semantic-check off on the config. >>> > > >>> > > I have just taken a look to make sure: This particular check is >>> mandatory >>> > > and >>> > > cannot be disabled. And I'm quite sure I want to keep it that way. >>> The >>> > > CNAME >>> > > in apex is not allowed. And we would have to define some behavior >>> how to >>> > > answer when this happens, which makes a little sense. >>> > > >>> > > You should rather urge your clients to fix their zones because this >>> > > problem >>> > > can lead to random resolution failures. >>> > > >>> > > Cheers, >>> > > >>> > > Jan >>> > > _______________________________________________ >>> > > knot-dns-users mailing list >>> > > knot-dns-users(a)lists.nic.cz >>> > > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >>> >>> _______________________________________________ >>> knot-dns-users mailing list >>> knot-dns-users(a)lists.nic.cz >>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >>> >> >> >> >> -- >> [ ]'s >> >> Filipe Cifali Stangler >> >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >> >> > > > -- > [ ]'s > > Filipe Cifali Stangler > > -- [ ]'s Filipe Cifali Stangler

10 let

1
0
0 0

Knot DNS 2.0.0 (final release)

by Jan Včelák

Hello everyone! CZ.NIC Labs just released a final version of Knot DNS 2.0. There are only a few changes since the release candidate. The synchronization of zone file can be now disabled; knsupdate was improved to accept TSIG algorithm in interactive mode; and some small bugs have been resolved. I believe you are tuned to this channel and it makes a little sense to repeat all the new features we put into 2.0 in details. Just to sum up the most important things: - Knot DNS 2.0 uses new configuration format based on YAML. The new format adds zone templates, improves remotes and ACLs specification, and in general makes the configuration more readable. You can convert your existing 1.6 configuration using the knot1to2 utility. - We have a new DNSSEC backend. It is based on GnuTLS instead of OpenSSL. And it contains basic support for KASP (Key And Signature Policy). At the moment, it can generate initial zone signing keys and perform automatic ZSK rollover. For more details, please, take a look at the full change log, previous release e-mails, documentation, or just ask. We are looking forward to your feedback, feature requests, and even bug reports. And thank you for using Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.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

10 let

7
15
0 0

Knot DNS 1.6.4 patch release

by Jan Včelák

Hello everyone! On behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.4. The patch release contains a bunch of non-critical bug fixes and a few improvements. The update is recommended but not necessary. Lots of changes are related to zone transfers. We resolved a problem where an incoming NOTIFY message was lost during ongoing transfer of the same zone. The AA flag in AXFR/IXFR queries is no longer set as recommended by the RFC. And in multi-master environment, if a master server is not available then the other master servers are tried immediately without waiting a SOA retry time. The kdig utility was also updated. A new '+generic' option causes printing of all resource records as if they were unknown records (according to RFC 3597). The '+noall' option now hides the TSIG section. And the Dnstap SocketProtocol is logged correctly if there is a failover from UDP to TCP. The zone parsing and dumping was improved as well. The zone parser can now read TXT/SPF strings longer than 255 characters which are automatically chopped into multiple strings. And the zone dumps will no longer print class name with the SOA record, which unifies the behavior across all resource record types, making the text processing of a zone file easier. Last but not least, we have resolved two build issues: Knot DNS can be now compiled against LibreSSL instead of OpenSSL without patching. And fast zone parser is forcibly disabled when compiling with Clang (this is a workaround for a bug in Clang optimizer which emits invalid code for the scanner). Thank you for attention. You can grab the sources 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.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.4.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

10 let

1
0
0 0

Additional section

by Charles Musser

Hi, We've been running Knot 1.6.3 as a slave server and it's been working well. However, I notice that a "dig" against this slave for a domain does not return an "ADDITIONAL" section, but the same query against another slave that runs BIND does return one. I couldn't find any Knot configuration directive that would control this. Is there something I missed or additional configuration needed elsewhere to make the ADDITIONAL info available? Thanks, Chuck

10 let

2
3
0 0

Knot DNS 2.0.0-rc1 (release candidate)

by Jan Včelák

Hello list! The first release candidate of Knot DNS 2.0 by CZ.NIC Labs is available. The most significant changes since 2.0.0-beta are related to the server configuration. We have renamed a few configuration options for the sake of consistency and intuitiveness. And we have significantly improved the way how remotes and ACLs are defined. In prior version, each remote was assigned just one address, which led to quite long configuration files. The updated version allows specification of multiple addresses (and multiple TSIG keys), making the configuration file shorter and more readable. We have also added a basic support for zone file name patterns. At the moment, you can use the '%s' pattern in the template/file configuration option and the pattern will be substituted by a zone name. We would like to add another patterns in future. Feel free to let us know which patterns you would find useful. The 2.0.0-rc1 version also contains all bug fixes and improvements, which are included in the upcoming 1.6.4 stable release. And the icing on the cake is Bash and ZSH completion scripts for keymgr. Please, give the release candidate a try. We are looking forward to your feedback and bug reports. And as always, thank you for using Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0-rc1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.0-rc1.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

10 let

1
0
0 0

[PATCH] kdig: Record the dnstap SocketProtocol correctly when retrying over TCP

by Robert Edmonds

Previously, kdig's write_dnstap() function passed net->srv->ai_protocol as dt_message_fill()'s 'protocol' parameter, but net->srv->ai_protocol is not actually guaranteed to be the socket protocol used for the query/response. When kdig's process_query_packet() retries over TCP, it only sets net->socktype to SOCK_STREAM in an already initialized net_t and calls itself. The addrinfo's in the net_t aren't updated, so they have the original values from the first invocation of process_query_packet(), i.e., the lookup that occurred over UDP. However, net->socktype is actually what controls whether TCP or UDP is ultimately used in net_connect(). Instead of passing net->srv->ai_protocol to dt_message_fill(), map net->socktype to an IPPROTO_* value. (Which is what kdig does elsewhere via get_sockname(), which is why the formatted output written to stdout at the same time, e.g. "127.0.0.1@53(TCP)" doesn't have a similiar bug.) --- src/utils/kdig/kdig_exec.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/utils/kdig/kdig_exec.c b/src/utils/kdig/kdig_exec.c index b91a958..1f6a64d 100644 --- a/src/utils/kdig/kdig_exec.c +++ b/src/utils/kdig/kdig_exec.c @@ -44,6 +44,7 @@ static int write_dnstap(dt_writer_t *writer, Dnstap__Message msg; Dnstap__Message__Type msg_type; int ret; + int protocol = 0; if (writer == NULL) { return KNOT_EOK; @@ -54,8 +55,14 @@ static int write_dnstap(dt_writer_t *writer, msg_type = is_response ? DNSTAP__MESSAGE__TYPE__TOOL_RESPONSE : DNSTAP__MESSAGE__TYPE__TOOL_QUERY; + if (net->socktype == SOCK_DGRAM) { + protocol = IPPROTO_UDP; + } else if (net->socktype == SOCK_STREAM) { + protocol = IPPROTO_TCP; + } + ret = dt_message_fill(&msg, msg_type, net->local_info->ai_addr, - net->srv->ai_addr, net->srv->ai_protocol, + net->srv->ai_addr, protocol, wire, wire_len, qtime, rtime); if (ret != KNOT_EOK) { return ret; -- 2.1.4

10 let, 1 měsíc

2
1
0 0

Updating slaves

by Amar Cosic

Hello list, anyone can point me to documentation or manual what is right way to update slaves. What I want to is when I change record X on master that slaves also pick that change without me manualy have to do this. My configuration is OK as on initial zone transfers slaves got data/zones OK. I tried knotc reload knotc flush knotc refresh and restarting knotc service. On all this there was nothing in syslog and slaves are not updating ty. -- Amar Ćosić amar.cosic(a)gmail.com amar(a)amar.ba

10 let, 2 měsíce

3
3
0 0

Knot DNS 1.6.3 patch release

by Jan Včelák

Hello list, CZ.NIC Labs just released Knot DNS 1.6.3. This patch release contains a few rather serious bug fixes and some minor improvements. Update is highly recommended. When performing our internal benchmarking, we discovered a serious performance drop for large NSEC-signed zones (not NSEC3). In construction of NSEC proofs for NXDOMAIN responses, the server got into a loop possibly causing iteration over all domain names in the zone. The problem was present in Knot DNS since the beginning of the project. We are sorry for not noticing this earlier. The new version also handles TCP short-writes properly. Prior to this fix, sending a response over TCP could fail if the socket send buffer was small (e.g., in default configuration on FreeBSD). In addition, if the buffers are too small, we increase their size on server initialization to make fast-path processing more likely. We also fixed possible out-of-bound memory accesses revealed by American Fuzzy Lop fuzzer. One such an access was in the zone parser (long domain names in zone origin) and two in the packet parser (TSIG with empty RDATA and malformed NAPTR). As for the improvements: The zone parser now supports CDS and CDNSKEY RR types, the documentation now includes default values for TCP config options, and more detailed message is emitted when a zone reload fails. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.3.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

10 let, 2 měsíce

3
2
0 0

Knot DNS 2.0.0-beta release

by Jan Včelák

Hello everyone! Today, CZ.NIC Labs releases Knot DNS 2.0.0-beta. We finally managed to complete, stabilize, and document all new features of the upcoming Knot DNS version. We are aware of some glitches in this release, however we think that it is ready to be tested by a wider audience. There are two key features of Knot DNS 2.0: # New DNSSEC implementation I wrote quite a lot about the new DNSSEC in the 1.99.1 release announcement. Since then, only a few things changed. There was a bug in the ZSK rotation algorithm. The old DNSKEY was removed too soon possibly breaking the validation. This problem is resolved now. The keymgr utility has a new manual page. And the documentation was updated to reflect all changes. # New configuration format This change is quite significant for the future development of Knot DNS. And it will affect everyone using the software. We decided to switch from a custom configuration format to YAML. Internally, the configuration is stored in a binary database (LMDB). At the moment, you won't probably notice anything about the database. However we are working on a new interface, which will allow making changes into the configuration without a full server reload. If you have Knot DNS with thousands of zones, you will benefit this for sure. We don't support full YAML specification, but there is a certain level of compatibility. We plan to extend the support so you can generate the config from your favorite scripting language. Some configuration options (and configuration sections) were renamed. We changed the concept how the incoming and outgoing connections are configured. We split 'remotes' to 'remote' and 'acl'. 'remote' defines target for outgoing connection (zone transfer source, notification target). And 'acl' defines rules for accepting connections initiated by a remote client (outgoing transfer, incoming notification, and incoming update). At the moment, only one address can be specified for each 'remote' or 'acl'. In addition, we removed 'groups' as it was complicating the implementation. We are aware that the current state is not ideal. And we are looking for feedback and suggestions from the community. We are not just removing and changing things - we added support for zone templates, which is something a lot of our users asked for. A template allows you to configure options shared among multiple zones. A change in the template affects all zones, which use the template. To convert the configuration from the 1.6 to the 2.0 format, the knot1to2 tool is provided. The tool doesn't support conversion for answering modules (e.g. synth_record), but should handle anything else. Please, review the configuration after performing the automatic conversion. That's all, folks! Please, give it a try. Experiment with the new DNSSEC and play around with the new configuration. And most importantly, let us know what do you think. Thank you for using Knot DNS! Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.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

10 let, 2 měsíce

2
3
0 0

Work-around for Knot's configuration syntax

by Anand Buddhdev

I'm generating my Knot's config from a Jinja2 template, and I'm having a problem with one thing. For example, if I have a list of elements, [e1,e2,e3,e4], and I want to generate a "groups" config for these based on a condition, and I do: groups { mygroup { {% for x in list %} {% if condition %} {{ x }}, {% endif %} {% endfor %} } However, this results in a syntax error, because the last element ends with a comma, and then there's a closing bracket. I tried to insert the comma conditionally, by checking to see if it was the last element, but this can also fail if the last element didn't match the condition. So I thought about this ugly hack: groups { mygroup { {% for x in list %} {% if condition %} ,{{ x }} {% endif %} {% endfor %} } Notice that I have the comma *before* each element. This results in an opening brace, a comma, and then the other elements. My supposition is that Knot's syntax parser is okay with this, because it just sees a null first element. If I check this with knotc's "checkconf", it says the syntax is okay. Can I safely use such a config? Regards, Anand

10 let, 2 měsíce

4
4
0 0

Use of recvmmsg in Knot

by Anand Buddhdev

Dear Knot developers, In Knot 1.6.3, is it safe to leave out the "interfaces" section of the config on a multi-homed server? Will Knot enumerate all the addresses on the host and bind to them, or will it bind to 0.0.0.0 and ::? Secondly, if bound to 0.0.0.0 and ::, will Knot use recvmmsg correctly and set the source address in UDP reply packets to the address the query was sent to? Regards, Anand

10 let, 2 měsíce

2
1
0 0

key file format for nsupdate

by Andrew Stevenson

Hi, I am trying to use nsupdate from knot 1.6.1. I have generated key files using dnssec-keygen from BIND 9.9.5. i.e. dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com Whenever I try to use the files with nsupdate -k <file> though I get: ; Error: failed to read key file: public key file is invalid I have also tried without the “-C” to dnssec-keygen. Are there different flags I need? Or does someone have an example of the file format required? Thanks, Andrew

10 let, 3 měsíce

2
2
0 0

Short write?

by Linus Nordberg

Hi, I'm looking at knot-1.6.1 after have experienced failure with sending AXFR after a zone grew due to enabling DNSSEC, adding a lot of records. I don't know much about iovecs, but isn't this a short write? --8<---------------cut here---------------start------------->8--- libknot/internal/errcode.h: enum knot_error { ... KNOT_ECONNREFUSED = -ECONNREFUSED, ... KNOT_ERROR_MIN = -1000, ... KNOT_ERROR = KNOT_ERROR_MIN, ... KNOT_ECONN, ... }; libknot/internal/net.c: int tcp_send_msg(int fd, const uint8_t *msg, size_t msglen) { ... int total_len = iov[0].iov_len + iov[1].iov_len; int sent = writev(fd, iov, 2); if (sent != total_len) { return KNOT_ECONN; } ... } knot/server/tcp-handler.c: tcp_handle() { ... while (state & (NS_PROC_FULL|NS_PROC_FAIL)) { uint16_t tx_len = tx->iov_len; state = knot_process_out(tx->iov_base, &tx_len, &tcp->query_ctx); /* If it has response, send it. */ if (tx_len > 0) { if (tcp_send_msg(fd, tx->iov_base, tx_len) != tx_len) { ret = KNOT_ECONNREFUSED; break; } } } ... } --8<---------------cut here---------------end--------------->8--- Happy to file a bug report if that's a more proper way of reporting bugs.

10 let, 3 měsíce

2
1
0 0

[PATCH] Add "forced generic" dump style, and kdig +generic option

by Robert Edmonds

This patch adds a new "forced generic" dump style which dumps resource record types and data in the generic RFC 3597 representation format, even for known resource record types. A corresponding +generic option to kdig enables this dump style. Generic representation format is very handy when dealing with older DNS software that may not support a new resource record type, or with systems where it is more convenient to use the generic format even with known types. It is also a nice debugging / educational feature. (No need to fire up Wireshark.) --- man/kdig.1.in | 3 +++ src/libknot/rrset-dump.c | 10 +++++++++- src/libknot/rrset-dump.h | 2 ++ src/utils/kdig/kdig_params.c | 13 +++++++++++++ 4 files changed, 27 insertions(+), 1 deletion(-) diff --git a/man/kdig.1.in b/man/kdig.1.in index 4772e27..b6f2286 100644 --- a/man/kdig.1.in +++ b/man/kdig.1.in @@ -178,6 +178,9 @@ Use EDNS version (default is 0). Disable IDN transformation to ASCII and vice versa. IDNA2003 support depends on libidn availability during project building! .TP +.BR +generic +Use the generic representation format when printing resource record types and data. +.TP .BI +client= SUBN Set EDNS client subnet SUBN=IP/prefix. .TP diff --git a/src/libknot/rrset-dump.c b/src/libknot/rrset-dump.c index dd4625d..2f503c1 100644 --- a/src/libknot/rrset-dump.c +++ b/src/libknot/rrset-dump.c @@ -1774,6 +1774,10 @@ int knot_rrset_txt_dump_data(const knot_rrset_t *rrset, return ret; } + if (style->generic) { + return dump_unknown(&p); + } + switch (rrset->type) { case KNOT_RRTYPE_A: ret = dump_a(&p); @@ -1941,7 +1945,11 @@ int knot_rrset_txt_dump_header(const knot_rrset_t *rrset, } // Dump rrset type. - if (knot_rrtype_to_string(rrset->type, buf, sizeof(buf)) < 0) { + if (style->generic) { + if (snprintf(buf, sizeof(buf), "TYPE%u", rrset->type) < 0) { + return KNOT_ESPACE; + } + } else if (knot_rrtype_to_string(rrset->type, buf, sizeof(buf)) < 0) { return KNOT_ESPACE; } if (rrset->rrs.rr_count > 0) { diff --git a/src/libknot/rrset-dump.h b/src/libknot/rrset-dump.h index 4519159..e44cca3 100644 --- a/src/libknot/rrset-dump.h +++ b/src/libknot/rrset-dump.h @@ -46,6 +46,8 @@ typedef struct { bool human_ttl; /*!< Format timestamp as YYYYMMDDHHmmSS. */ bool human_tmstamp; + /*!< Force generic data representation. */ + bool generic; /*!< ASCII string to IDN string transformation callback. */ void (*ascii_to_idn)(char **name); } knot_dump_style_t; diff --git a/src/utils/kdig/kdig_params.c b/src/utils/kdig/kdig_params.c index ec7ec9f..6fafb22 100644 --- a/src/utils/kdig/kdig_params.c +++ b/src/utils/kdig/kdig_params.c @@ -54,6 +54,7 @@ static const style_t DEFAULT_STYLE_DIG = { .empty_ttl = false, .human_ttl = false, .human_tmstamp = true, + .generic = false, .ascii_to_idn = name_to_idn }, .show_query = false, @@ -551,6 +552,15 @@ static int opt_noidn(const char *arg, void *query) return KNOT_EOK; } +static int opt_generic(const char *arg, void *query) +{ + query_t *q = query; + + q->style.style.generic = true; + + return KNOT_EOK; +} + static int opt_nsid(const char *arg, void *query) { query_t *q = query; @@ -805,6 +815,8 @@ static const param_t kdig_opts2[] = { /* "idn" doesn't work since it must be called before query creation. */ { "noidn", ARG_NONE, opt_noidn }, + { "generic", ARG_NONE, opt_generic }, + { "client", ARG_REQUIRED, opt_client }, { "time", ARG_REQUIRED, opt_time }, @@ -1363,6 +1375,7 @@ static void kdig_help(void) " +[no]nsid Request NSID.\n" " +[no]edns=N Use EDNS (=version).\n" " +noidn Disable IDN transformation.\n" + " +generic Use generic representation format.\n" " +client=SUBN Set EDNS client subnet IP/prefix.\n" " +time=T Set wait for reply interval in seconds.\n" " +retry=N Set number of retries.\n" -- 2.1.4

10 let, 4 měsíce

2
1
0 0

Statistics

by Julian Brost

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, does Knot have a feature like "rndc stats" in BIND or "nsd-control stats" that allows you to get some statistics about how many queries were handled and what their result were (like SERVFAIL etc.)? Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU8zytAAoJECLcYT6QIdBtLg8P/2wF5gwHQigZ5dI5S2pztM0C ryKAV5h6mqSuO91S+qA7IAP3GpAlzs5GrNYW9kGXspo+w9mwb/D5+mNhDSOGyoW9 iItT16TATzwpNK89Gw2uRhVJ2BhYTuQTmrp3WwAYHAe6wYGOQdBtZoel5UzSrm5e I//3DFgmpGHSwITRcxOBl2MYhRpHEhiBQdUjk2MmTcy/L3GF1HMlY2oHuy4sFZk+ lL6x9N/NX/6K5OspF8p8eoNQ7LIBIA6OKNhz08SdsAKSe1F76pL+FPnb8iQUC6Ao EXkdeFftxOxocL+TTSpAhqEF86IXvRsiNSic8wjYXt9blsMcOAJQFNgU25Bs5+IV u8EtZgcusq5SbHD0Dp5wYkNV4BYYmjU2omzjxMtqV4MFZG9V8XFlXbfVwC64fsUe YfYjvK071EK2hVHTrui637tnS8uEcTJa0X8lpCEgYsy+6/EGyQ3H/8eyu77jZT57 yeZnfG4Ai/QrgS6w3jEu3+uk+kwds2wYHqHbIIw3o0GQ8awQ0kPC6tKg0dXI7aFN tlYBM0mycQv3hFSk7x6jxJ1UPWVxdIOrNg8Vgg8FsgWnXu+JHJJxEV7uoj5DogTJ PaSFOQccTrVoa1vwJgiHLmOALdY/5FDb9cddN1GBgj2wqcUkS/hR8tSRNXkLShhX BTijrkJTR8qeiEEFgthp =bPR2 -----END PGP SIGNATURE-----

10 let, 4 měsíce

2
1
0 0

Knot DNS 1.6.2 patch release

by Jan Včelák

Hello everyone, on behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.2. The patch release contains one new feature and a few small bug fixes. With the new version, a number of concurrent TCP clients connected to the server can be limited. The limit is set using the 'max-tcp-clients' configuration option in the 'system' section. Purpose of this setting is to avoid resource exhaustion when the server is under a load. And the default value for the option is 100. When the limit is hit, new connections are not being accepted for a few seconds. Active connections are not affected. Please note, that we have also slightly lowered defaults for TCP idling timeouts. As for the bug fixes: A possible file descriptor leak when terminating inactive TCP clients was fixed. Scheduled events for zones switched from slave mode to master mode are handled correctly. And compilation of Dnstap features on FreeBSD works now. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz.asc Thank you for using Knot DNS. 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

10 let, 4 měsíce

2
2
0 0

Knot DNS 1.99.1 (preview of DNSSEC with KASP)

by Jan Včelák

Hello everyone! After months of keeping our secrets, we would like to share with you a preview of a new DNSSEC implementation in Knot DNS. The new DNSSEC will be one of the key features for the upcoming Knot DNS 2.0. If you are watching our source repository, you may have noticed a tag v1.99.0 appearing silently at the end of 2014. At that time, Knot DNS was already using the newly implemented DNSSEC, but the only visible change was a different key format. And internally, GnuTLS/Nettle was replaced OpenSSL for cryptographic operations. Today, CZ.NIC Labs releases Knot DNS 1.99.1. The next step towards the 2.0. Knot DNS 1.99.1 adds initial support for DNSSEC KASP (Key And Signature Policy). This is our vision of real-world DNSSEC deployment. Essentially, you define a policy (used algorithm, key sizes, key lifetime, signature lifetime, etc.) and the server will do the heavy lifting. It will generate keys and publish/roll them correctly, so you don't have to compute and set timing meta-data on private keys manually. At the moment, the KASP support is quite limited: Single algorithm, single KSK, and single ZSK can be specified in the policy. The server is able to generate initial keys and perform ZSK rollovers (key pre-publish method). More features are coming soon. A documentation on KASP [1] is currently available on the project wiki, including the reference manual for a new management utility keymgr [2]. [1] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-setup [2] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-keymgr-reference Source archives are available as usual: https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.gz Please note, that Knot DNS 1.99.1 is not ready to replace Knot DNS 1.6.x. We are looking forward to hear some feedback from you. And we are happy to answer all your questions and concerns. 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

10 let, 4 měsíce

5
14
0 0

DNSSEC and slave zones?

by Jan-Piet Mens

Good evening, I don't seem to be able to configure Knot 1.6.1 to sign a zone it slaves in: example.com { file "/usr/local/etc/knot/aa/example.com.zone"; xfr-in home; dnssec-keydir "/usr/local/etc/knot/aa"; dnssec-enable on; } If I omit the two 'dnssec-*' parameters, the zone is slaved in. Adding them, however, results in no transfer; log shows: notice: [example.com] automatic DNSSEC signing enabled, disabling incoming XFRs Is it currently possible with Knot to sign a slaved zone? Regards, -JP

10 let, 5 měsíců

2
1
0 0

Re: [knot-dns-users] Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Leo

Hi, > How would one go about converting from PowerDNS to KnotDNS on an active > realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary > disruption of services to existing DNS users? > If it's truly anycast it should only be easier, I would simply: - stop announcing the anycasted prefix at node #1 - once you see no queries anymore: convert and test - after finishing: switch on routing - repeat untill node #last Unless you have bizarre performance complications, above would be more safe than converting an active node. Did I maybe misunderstand the question? Or did you mean: "how to convert from pdns with a transactional SQL backend to a conventional DNS setup with Knot" ..? Leo

10 let, 5 měsíců

1
0
0 0

Knot DNS and IN NS records

by Eugene Bolshakoff

Hello All, I've decided to use Knot DNS as secondary nameserver for my local zone. I have several subnets connected via VPN and they have their own nameservers. So, there are records in my zone zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 zu.mithril. 3600 IN NS zu-gw.vpn.mithril. and I want to resolve domain in zu.mithril: BIND (master): # dig @tessa.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @tessa.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7626 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; ANSWER SECTION: melissa.zu.mithril. 0 IN A 172.19.3.1 ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 143 msec ;; SERVER: 172.19.37.1#53(172.19.37.1) ;; WHEN: Wed Jan 14 19:24:27 2015 ;; MSG SIZE rcvd: 92 KNOT (secondary): # dig @mira.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @mira.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10182 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 0 msec ;; SERVER: 172.19.38.2#53(172.19.38.2) ;; WHEN: Wed Jan 14 19:24:51 2015 ;; MSG SIZE rcvd: 76 I understand that it's happening because of recursion in bind, but how can I solve this problem in knot? -- With best regards, Eugene Bolshakoff

10 let, 5 měsíců

2
1
0 0

Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Ret Law

How would one go about converting from PowerDNS to KnotDNS on an active realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary disruption of services to existing DNS users?

10 let, 6 měsíců

3
2
0 0

Knot DNS v1.6.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing a new version of Knot DNS. This release introduces a new feature and fixes few bugs. The new feature is a support for Single Type Signing Scheme in automatic DNSSEC implementation. As far as bugfixes are concerned, we've fixed a couple of problems with IXFR/DDNS journal file. Most importantly, it was sometimes not respecting its file size limit (ixfr-fslimit configuration option). We've also fixed incompatibility with OpenSSL 0.9.8. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz.asc There are not many changes in this release, but those of your who use IXFR or DDNS should definitely upgrade. Regards 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

10 let, 6 měsíců

6
7
0 0

Knot 1.6.1 and journal size tuning

by Anand Buddhdev

Hi Knot developers, I've now installed version 1.6.1 on some servers, and I'm observing some journal related issues, and I have questions about them. First off, here's one issue: 2014-12-15T06:00:56 info: [203.in-addr.arpa] NOTIFY, incoming, 193.0.0.198@53535: received serial 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] refresh, outgoing, 193.0.0.198@53: master has newer serial 3006121317 -> 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:57 warning: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: failed to write changes to journal (not enough space provided) 2014-12-15T06:00:58 notice: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: fallback to AXFR 2014-12-15T06:00:58 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:59 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: finished, serial 3006121317 -> 3006121318, 0.65 seconds, 171 messages, 7960312 bytes So it looks like the IXFR is too big, and won't fit into the journal, and Knot is falling back to AXFR. When I requested this IXFR by hand, I got: $ dig ixfr=3006121317 203.in-addr.arpa @193.0.0.198 ... ... ;; XFR size: 121779 records (messages 170, bytes 7963389) The size of the IXFR in bytes is below the configured file size limit (10M), but I suspect that 7963389 bytes probably take up more room in the journal, so Knot can't write into it, and is falling back to AXFR. Are you able to tell me (approximately of course), how much disk space is required for a given number of bytes of IXFR? This will help me tune the setting of ixfr-fslimit to avoid this unnecessary fallback to AXFR.

10 let, 6 měsíců

3
2
0 0

Knot 1.6.1 and full journal

by Anand Buddhdev

Hi Knot developers, I have another question about journals. I've noticed that for one zone, the journal size is 9M (with my configured limit at 10M). Now, I see this each time in the logs: 2014-12-15T07:56:02 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:13:09 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:16:35 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:20:27 notice: [103.in-addr.arpa] journal is full, flushing It looks like once a journal is close to the maximum size, then it just remains at that size, with the result that each time an IXFR comes in, and overflows the journal, Knot wants to flush the changes to disk immediately. Does Knot discard old records from the journal at this point? Anand

10 let, 6 měsíců

3
2
0 0

zlib dependency

by Matthias-Christian Ott

Knot DNS depends on zlib to calculate Adler-32 checksums. A comment in crc.h states that it “should be removed”. I want to use knsupdate on OpenWRT and would also like to remove the dependency. Unfortunately, there is no single library that provides only Adler-32 checksums and every examined software either relies on zlib or its bundled implementation of varying quality and speed. Other projects seem to use CRC32C because there is an instruction to calculate it in the SSE4.2 instruction set. But again there is no library that only implements only CRC32C checksums. Switching to CRC32C would also make the journal format incompatible. I'm inclined to just copy the reference implementation from RFC 1950 for my purposes but wanted to check with the upstream maintainers whether there are any plans or ideas. It would also be nice if the configure script would have an option to not include and compile unused functionality from libknot and libzscanner to minimize binaries sizes. - Matthias-Christian

10 let, 7 měsíců

3
4
0 0

failed (connection refused)

by Eric Kom

Good day All, Please I got a connection refused when trying to setup a master and slave on the same network. THIS IS AN EXTRACT FROM MY MASTER KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { storage "/var/lib/knot"; metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-out slaveOnKnot; notify-out slaveOnKnot; } } root@ns1:~# knotc reload OK root@ns1:~# grep knot /var/log/syslog Nov 27 07:10:41 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 07:10:41 ns1 knotd[469]: 2014-11-27T07:10:41 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: 2014-11-27T08:08:09 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 09:27:33 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:27:33 ns1 knotd[469]: info: reloading configuration Nov 27 09:27:34 ns1 knotd[469]: info: configuration reloaded Nov 27 09:27:34 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014102701 -> 2014112700 Nov 27 09:27:34 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) Nov 27 09:29:46 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:29:46 ns1 knotd[469]: info: reloading configuration Nov 27 09:29:47 ns1 knotd[469]: info: configuration reloaded Nov 27 10:13:37 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:13:37 ns1 knotd[469]: info: reloading configuration Nov 27 10:13:37 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:14:15 ns1 knotd[469]: info: reloading configuration Nov 27 10:14:15 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014112700 -> 2014112701 Nov 27 10:14:15 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) THIS IS AN EXTRACT FROM MY SLAVE KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage # storage "/var/lib/knot"; # # # Example slave zone metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-in masterOnKnot; notify-in masterOnKnot; } } root@ns2:~# knotc reload OK root@ns2:~# grep knot /var/log/syslog Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@10548: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@13456: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@60566: unauthorized request Nov 27 08:47:30 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@54094: unauthorized request Nov 27 09:28:36 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:28:36 ns2 knotd[397]: info: reloading configuration Nov 27 09:28:36 ns2 knotd[397]: info: [metropolitanbuntu.co.za] zone will be bootstrapped, serial 0 Nov 27 09:28:36 ns2 knotd[397]: info: configuration reloaded Nov 27 09:28:36 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:28:36 ns2 knotd[397]: 2014-11-27T09:28:36 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: 2014-11-27T09:29:01 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: 2014-11-27T09:29:54 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:30:02 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:30:02 ns2 knotd[397]: info: reloading configuration Nov 27 09:30:02 ns2 knotd[397]: info: configuration reloaded Nov 27 09:31:49 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:49 ns2 knotd[397]: 2014-11-27T09:31:49 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: 2014-11-27T09:31:56 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: 2014-11-27T09:32:34 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: 2014-11-27T09:34:15 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: 2014-11-27T09:37:59 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: 2014-11-27T09:45:29 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: 2014-11-27T10:00:45 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:14:26 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 10:14:26 ns2 knotd[397]: info: reloading configuration Nov 27 10:14:26 ns2 knotd[397]: info: configuration reloaded -- -- 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

10 let, 7 měsíců

3
4
0 0

When will you remove the limitation that a zone be signed by a KSK and ZSK ?

by Olafur Gudmundsson

In your documentation you say: Single-Type Signing Scheme is not supported. I only want to sign with a single key in some cases, i.e. there is no value in having the split as updating my parent is easy. Olafur

10 let, 8 měsíců

2
2
0 0

Rhel 6.3 RPM ?

by Lynch Davis

I am looking around for an rpm deployment since I have a "hardened" box that I wanted to install this on. Was going to try to build my own, but it looks like libucru is not readily available for the this distribution either. help or links? Thanks, Lynch

10 let, 8 měsíců

2
1
0 0

synchronized processing for specific RR Type

by Lynch Davis

Hi - I was reading on the faq about zone events serialization. Has this feature been implemented? I am experimenting with a processing that would require this feature, and if I could simply add a query processor and specify serialization, a majority of my problem (I think) would be solved. I have yet to explore the full feature set of the query_processor to know if this is a correct statement, but I am hopefull. Thanks, Lynch

10 let, 8 měsíců

2
1
0 0

Knot DNS 1.6.0 (final release)

by Jan Včelák

Hello everyone! CZ.NIC Labs proudly presents the final release of Knot DNS 1.6.0. This version also becomes an LTS (Long-term support) version of the Knot DNS software. We added two more bugfixes on top of the features covered by the previous e-mails announcing the release candidates. And as this is the final release, let's highlight the most important changes: The only new feature in Knot 1.6.0 is 'persistent zone timers'. The refresh, expire, and flush zone timers are now stored in file-backed database. Thus, the state of the timers survives a complete restart of the server. (Please note that the feature is optional and requires the LMDB library.) The processing of letter case in RDATA domain names was modified: In most cases, the names are converted to lower-case letters. The exception are RR types, which are treated case-sensitively in DNSSEC. With this change, some Knot DNS internals were simplified and also problems with invalid signatures issued by Knot DNS for mixed-case RR sets should be gone. A few minor bugs in EDNS processing were resolved. And since the -rc2, we fixed forced zone retransfer (knotc refresh -f <zone>), which got broken at some point during 1.5 development. And we also corrected slave zone expiration, when the master is responding to SOA queries but refusing the transfer. We would like to thank Anand Buddhdev for helping us in testing the release candidates and also for reporting the last two bugs. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.0.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

10 let, 8 měsíců

3
4
0 0

How to allow certain hosts to do AXFR?

by Rainer Duffner

Hi, is it possible to allow certain IPs to AXFR all zones? I need this for our helpdesk, so they can send zonefiles to customers etc. I don’t want knot to send ixfrs etc. to these IPs.

10 let, 8 měsíců

3
2
0 0

KNOT zone file

by Eric Kom

Hi all, I'm new on KNOT, and has been running BIND for many years now and would like to set up another master server to serve the domain metropolitanbuntu.co.za on a different network based on Debian and Knot. The Knot-DNS server its running fine: root@ns1:/etc/knot# knotc status OK The metropolitanbuntu.co.za zone was defined in the knot.conf file, just simple definition: zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage storage "/var/lib/knot"; # # Example master zone # example.com { # file "/etc/knot/example.com.zone"; # xfr-out slave0; # notify-out slave0; # } # # Example slave zone # example.net { # file "/var/lib/knot/example.net.zone # xfr-in master0; # notify-in master0; # } metropolitanbuntu.co.za { file "/var/lib/knot/metropolitanbuntu.co.za.zone"; } } After ran: root@ns1:/etc/knot# knotc -c knot.conf reload OK And checked the Syslog: root@ns1:/etc/knot# grep knot /var/log/syslog Oct 18 09:33:23 ns1 knotd[414]: info: remote control, received command 'refresh' Oct 18 09:33:47 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:33:47 ns1 knotd[414]: info: reloading configuration Oct 18 09:33:47 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:33:47 ns1 knotd[414]: info: configuration reloaded Oct 18 09:42:24 ns1 knotd[414]: info: remote control, received command 'status' Oct 18 09:45:03 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:45:03 ns1 knotd[414]: info: reloading configuration Oct 18 09:45:03 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:45:03 ns1 knotd[414]: info: configuration reloaded The metropolitanbuntu.co.za zone look up to date. My question is: its the zone file looks like the BIND one? do I have to create it, may be I missed the zone declaration in the Knot manual? It is possible to do the master to master replication from BIND to KNOT? Thanks for your support. -- -- 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

10 let, 8 měsíců

2
3
0 0

Subject: how to assign multiple addresses for one zone?

by Junyoung Park

Hi! I have a question to configure knot dns for split-dns server. (only master , no slaves) If my router have two interfaces, eth0 (connected with ISP) and eth1 (internal private). About same zone (ex. example.com), i want to responses different ways for eth0, eth1. (ex. eth0, www.example.com -> read /etc/knot/external.example.zone, eth1, www.example.com -> /etc/knot/internal.example.zone) How can i configure it?

10 let, 8 měsíců

5
4
0 0

DNSSEC and Zone files

by dptrash＠arcor.de

I have DNSSEC in knot-dns activated. It always signs my file and it is very difficult to change my zone file with the dnssec stuff inside. Is it possible, to keep the zone file clean and it creates a .signed file for dnssec?

10 let, 8 měsíců

2
1
0 0

Knot DNS 1.6.0-rc2 (release candidate)

by Jan Včelák

Hello list! The second release candidate of Knot DNS 1.6.0 by CZ.NIC Labs is here! The update contains just a few changes, which improve the new persistent slave zones timers feature. The database for the zone timers was being opened before the privileges were dropped and UID/GID changed. As a result, the database could not be reopened after invoking the "knotc reload" command and updated timers could not be written into the database. This problem is resolved now. If you are updating from -rc1, you will need to fix the database ownership to match your knotd user. We also increased the maximal size of the database from 10 MB to 100 MB. This should be enough for thousands of slave zones. And finally, we improved a logging of errors related to database operations. If you have a time to try the new release candidate, please, do so. The final release will probably slip a few days, but it is still scheduled for the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.xz Have a nice weekend! Best regards, Jan, CZ.NIC Labs

10 let, 8 měsíců

1
0
0 0

Knot DNS 1.6.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Today, CZ.NIC Labs presents the first release candidate of Knot DNS 1.6.0. This comes quite soon after the release of the 1.5.3, which took place about a month ago. For this time, we were really conservative about inclusion of new features. We want to maintain Knot DNS 1.6.0 as a stable version and we intend to provide bug fixes for this release for a longer period of time. The 1.6.0 brings just one new feature - persistent timers for slave zones: The server stores zone expire, refresh, and flush timers in the file-backed database. The timers are written whenever they change and are recovered when the server is started. As a result, the timers will survive a full server restart. The persistent timers feature is an optional feature and depends on the LMDB library. Please, make sure the library is available at the build time and check the output of the 'configure' script, if you want to use this feature. We also modified domain names letter-case handling in RDATA. Previously, we preserved letter case of domain names in RDATA fields. With the 1.6.0, the domain names are converted to lower-case letters, unless the RR type is "new" and should be handled case-sensitively for compatibility with old servers. We believe that this approach is RFC-compliant. The letter case handling modification allowed us to simplify the DNSSEC signing code a little bit and also resolved problems with invalid signatures issued by Knot DNS for some mixed-case RR sets. All the other changes are various small bug fixes. Please, give Knot DNS 1.6.0-rc1 a try and report any troubles you encounter. We are looking forward to your feedback. If everything goes well, we plan to release the final version at the beginning of the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.xz Best regards, Jan, CZ.NIC Labs

10 let, 9 měsíců

1
0
0 0

Feature requests

by josten＠no-io.net

Hey everyone, I have a production Knot DNS setup; there are two features that I believe would make it even better than what it is now. * Under the zones section a way to just "push" all master zones to slaves; the slaves should just accept any zone from a verified master in the slaves knot.conf. * The ability to just load zones from disk without explicitly stating the zone in knot.conf. For example in /var/lib/knot/example.com.zone; Knot DNS automatically loads the example.com.zone without it being identified in the knot.conf under the zone section. Of course it should do checks (like it does now) before loading the zone, and then gracefully fail and log to the logging mechanism. Other than that; awesome DNS server!

10 let, 9 měsíců

2
1
0 0

[PATCH] dnstap: Fix ProtobufCBufferSimple usage that is incorrect as of protobuf-c 1.0.0

by Robert Edmonds

protobuf-c 1.0.0 added a new 'allocator' field to ProtobufCBufferSimple that controls memory allocation, which must be NULL in order to request the default system allocator. Allocating ProtobufCBufferSimple objects on the stack without zeroing the entire object can result in protobuf-c's memory allocation functions dereferencing a garbage pointer. Note that the use of the zero initializer in this instance generates a warning on some gcc versions: dnstap.c: In function 'dt_pack': dnstap.c:26:2: warning: missing braces around initializer [-Wmissing-braces] ProtobufCBufferSimple sbuf = {0}; ^ dnstap.c:26:2: warning: (near initialization for 'sbuf.base') [-Wmissing-braces] This warning is spurious and was fixed recently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=211289 --- src/dnstap/dnstap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/dnstap/dnstap.c b/src/dnstap/dnstap.c index 41d42e7..cf3770c 100644 --- a/src/dnstap/dnstap.c +++ b/src/dnstap/dnstap.c @@ -23,7 +23,7 @@ uint8_t* dt_pack(const Dnstap__Dnstap *d, uint8_t **buf, size_t *sz) { - ProtobufCBufferSimple sbuf; + ProtobufCBufferSimple sbuf = {0}; sbuf.base.append = protobuf_c_buffer_simple_append; sbuf.len = 0; -- 2.0.0

10 let, 9 měsíců

2
1
0 0

knot-1.4.4-49.1.i586 on opensuse 12.2 and automatic resign zone not approved ?

by Josef Karliak

Good afternoon, I made a change in our zone, changed serial of the zone and reload the zone. When I check the syslog, I saw some complains, that the signatures was out of date. For example: Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: A. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: AAAA. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: NSEC. This happens for all records in the zone. Last change was 11.8.2014, knot signed it and planned resign to 7.9.2014: Aug 11 13:39:10 slimak knot[22992]: Semantic checks completed for zone=fnhk.cz. Aug 11 13:39:10 slimak knot[22992]: Zone 'fnhk.cz.' reloaded (serial 2014081101) Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing started... Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-09-07T11:39:10. Aug 11 13:39:10 slimak knot[22992]: Loaded 5 out of 5 zones. Aug 11 13:39:10 slimak knot[22992]: Applied differences of 'fnhk.cz.' to zonefile. Aug 11 13:39:10 slimak knot[22992]: Configuration reloaded. Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081102). on 7.9.2014 the zone was resigned automatically: Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing zone... Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-10-04T11:39:10. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Started (serial 2014081102 -> 2014081103). Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Serial 2014081102 -> 2014081103. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Finished in 0.01s. And after today's changes knot told me that the signatures was out of date. I've this similar version of knot on my own server, there is no problem Any ideas ? Thanks and best regards J.Karliak -- 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.

10 let, 9 měsíců

2
2
0 0

Problem with CNAME in uppercase

by Didier ALBENQUE

Hi, I am currently testing knot and I have found a problem when CNAME are in uppercase. My primary server is running with BIND. I have these two declarations : myserver IN A 10.1.1.1 myserver-alias IN CNAME MYSERVER On the knot secondary server, after zone transfer, all seems ok : myserver.mydomain.fr. 900 A 10.1.1.1 myserver-alias.mydomain.fr. 900 CNAME MYSERVER.mydomain.fr. But when I ask knot for myserver-alias, I have a NXDOMAIN response (tcpdump output below) : 17:00:29.718834 IP dns-client.38146 > knot-server.domain: 4787+ A? myserver-alias.mydomain.fr. (43) 17:00:29.719011 IP knot-server.domain > dns-client.38146: 4787 NXDomain*- 1/1/0 CNAME MYSERVER.mydomain.fr. (123) 17:00:29.719555 IP dns-client.54520 > knot-server.domain: 2945+ A? myserver-alias.mydomain.fr.mydomain.fr. (54) 17:00:29.719637 IP knot-server.domain > dns-client.54520: 2945 NXDomain*- 0/1/0 (111) Tested with knot 1.5.1 and 1.5.2 Best regards, -- Didier ALBENQUE SG/SDSI/BSE Architecte technique Le café est un breuvage qui fait dormir, quand on n'en prend pas. Alphonse Allais ---------------------------------------------------------------------- Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.

10 let, 9 měsíců

2
2
0 0

Debian archive signing key, available over https?

by Andreas Olsson

Greetings Regarding the gpg key used to sign http://deb.knot-dns.cz/debian/. Any chance that that key could be available for downloaded by way of https://, or perhaps just have its fingerprinted listed on https://www.knot-dns.cz/pages/download.html? While the https:// CA model is far from perfect it'd still like to think it being a step up compared to regular http://, and at the same time a lot easier to document than the process of following the signatures in a gpg web of trust. // Andreas

10 let, 9 měsíců

2
2
0 0

Knot DNS v1.5.3 bugfix release

by Jan Kadlec

Hello list! CZ.NIC Labs are releasing a new version of Knot DNS today. This release fixes a regression that got introduced in the 1.5.2 release. This bug was causing Knot slaves to crash when receiving some specific IXFRs (more info: https://gitlab.labs.nic.cz/labs/knot/issues/294). Users that use Knot DNS as a slave should definitely upgrade. We've also added fixes for other issues we've recently discovered. Among those fixes are a fix to a very rare synchronization error during server reload (https://gitlab.labs.nic.cz/labs/knot/issues/296) and a fix to make dynamic query modules work properly with DNSSEC (https://gitlab.labs.nic.cz/labs/knot/issues/295). Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz.asc We apologize for two bugfix releases in such a short time, please be assured that we're expanding our tests and we'll also be changing our release policy to try to prevent any future regressions. Special thanks for bug reports go to Anand Buddhdev and Bastien Durel. Regards 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

10 let, 9 měsíců

1
0
0 0

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

by Ondřej Surý

JFTR I did push the 1.5.2 to wheezy-backports directly since 1.5.2 contains a remote vulnerability, so it's available there - see https://tracker.debian.org/knot Cheers, -- 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

10 let, 10 měsíců

1
0
0 0

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

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

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

10 let, 10 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
0
0 0

Knot 1.5 - what does state "idle" mean?

by Anand Buddhdev

11 let, 1 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, 1 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, 1 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, 1 měsíc

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users