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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3
4
0 0

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

by Toralf Förster

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

8 let, 8 měsíců

3
6
0 0

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

by Anand Buddhdev

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

8 let, 8 měsíců

2
3
0 0

Knot DNS 2.3.1 release

by Ondřej Surý

Hi fellow Knot DNS users and other mailing list lurkers, CZ.NIC just released a new version of Knot DNS. There are some bug fixes and improvements as usual. We fixed missing glue records in some responses, and there were some other minor nits. The most notable improvement was a speed-up of conf-commit and conf-diff operations when using zonedb. Users with hundred thousands zones and more will be amazed (we hope). There's also new EDNS Client Subnet API in libknot soon to be used in our sibling project Knot Resolver. On the new features front, kdig now can print TLS hierarchy for DNS over TLS, the knotc now contains zone-purge command and we have new mod-whoami module and new dnstap logging options contributed by Robert Edmonds. We would also like to invite everyone to migrate from Knot DNS 1.6.x to the current stable Knot DNS 2.x.x release. And that's it! Thank you for using Knot DNS. And we are really looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.3.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.3.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.x/html/ Regards, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

8 let, 8 měsíců

1
0
0 0

Where can I found the module of Geoip

by hou guanghua

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

8 let, 8 měsíců

1
0
0 0

Knot 2 on CentOS 6

by Anand Buddhdev

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

8 let, 8 měsíců

2
1
0 0

configuring dnstap in knot 2.2.1

by Lowell Mower

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

8 let, 9 měsíců

3
4
0 0

DNS Cookies support

by Ulrich Wisser

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

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

4
8
0 0

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

by Hugo Salgado

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

8 let, 10 měsíců

1
0
0 0

KNOT - Web GUI

by Ing. Peter Palhazy | NWS

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

8 let, 10 měsíců

1
0
0 0

Knot DNS 2.3.0 release

by Jan Včelák

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

8 let, 10 měsíců

4
5
0 0

Knot Resolver 1.1.0 released

by Ondřej Surý

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

8 let, 10 měsíců

1
0
0 0

Knot DNS 1.6.8 patch release

by Jan Včelák

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

8 let, 10 měsíců

1
0
0 0

Old ZSK not removed from zone

by Ulrich Wisser

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

8 let, 10 měsíců

2
1
0 0

AXFR size limit (CVE-2016-6171)

by Jan Včelák

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

8 let, 11 měsíců

1
0
0 0

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

by georg＠riseup.net

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

8 let, 11 měsíců

2
4
0 0

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

by Maren S. Leizaola

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

8 let, 11 měsíců

3
2
0 0

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

by Daisuke HIGASHI

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

8 let, 11 měsíců

1
0
0 0

glue and TC flag revisited

by Jan Včelák

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

8 let, 11 měsíců

1
0
0 0

receiving rcode 9 NOTAUTH when expecting rcode 5 REFUSED

by Roger Murray

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

9 let

4
4
0 0

should NSEC3 be default?

by Jan Včelák

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

9 let

7
11
0 0

RRL and dnsproxy

by Matthijs Mekking

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

9 let

2
2
0 0

Knot DNS 2.2.1 patch release

by Jan Včelak

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

9 let

7
13
0 0

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

by Marek Vavruša

Hey Jake, yes it does, RPZ is supported for views as is any other policy. There's an example of setting RPZ for a source-address subnet view in the documentation: http://knot-resolver.readthedocs.io/en/latest/modules.html#id3 Cheers, Marek > Does KnotDNS Resolver support the use of different RPZ's per-view? > > Looking to create a DNS setup that allows recursion to two separate > groups, one using one RPZ setup, the other using another. > > Is this possible with Knot? > > Thanks, > -jake > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >

9 let

1
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

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

systemd integration on Centos 7

by Matthew Pounsett

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

9 let, 1 měsíc

2
2
0 0

Fedora23 knot 2.2.0 issue in knot.service

by Brad Garrison

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

9 let, 1 měsíc

2
1
0 0

Knot DNS 2.2.0 release

by Jan Včelak

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

9 let, 1 měsíc

1
0
0 0

Statistics

by Roger Murray

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

9 let, 1 měsíc

3
3
0 0

knot resolver with knot1 daemon

by Josef Karliak

Good morning, it is able to run knot resolver daemon with knot 1.6.x ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

9 let, 2 měsíce

2
1
0 0

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

by Josef Karliak

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

9 let, 2 měsíce

2
1
0 0

preserve case in labels?

by Gert Doering

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

9 let, 2 měsíce

4
11
0 0

Concurrent Update

by masoud hematpour

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

9 let, 2 měsíce

2
1
0 0

knot 2 do not load zone after migrated from 1.6

by Josef Karliak

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

9 let, 2 měsíce

3
8
0 0

notify question

by Brett

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

9 let, 2 měsíce

2
2
0 0

Knot 2.x Installation instructions

by Volker Janzen

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

9 let, 3 měsíce

2
4
0 0

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

by Robert Edmonds

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

9 let, 3 měsíce

2
1
0 0

Rate limiting

by John Bond

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

9 let, 3 měsíce

2
1
0 0

DNSTAP socket problem

by Matthew Pounsett

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

9 let, 3 měsíce

2
3
0 0

Knot Zone Check

by Daniel Stirnimann

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

9 let, 4 měsíce

3
2
0 0

Knot DNS 2.1.1 patch release

by Jan Včelak

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

9 let, 4 měsíce

2
1
0 0

Knot DNS 1.6.7 patch release

by Jan Včelak

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

9 let, 4 měsíce

2
1
0 0

next week releases

by Jan Včelak

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

9 let, 4 měsíce

2
4
0 0

Troubles compiling Knot 2.1

by Bruno Pagani

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

9 let, 4 měsíce

4
6
0 0

IP source on IPv6

by Alarig Le Lay

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

9 let, 4 měsíce

2
3
0 0

Knot Ubuntu update

by Volker Janzen

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

9 let, 4 měsíce

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users