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

by Lisa Bahler

I've written aknot module, which is functioning well. I've been asked to add functionality to it that would inhibit any response from knot, based upon the client's identity. I know the identity; I just need to figure out how to inhibit a response. I just noticed the rrl module, and I looked at what it does. I emulated what I saw and set pkt->size = 0 and returned KNOTD_STATE_DONE. When I ran host -a, it returned that no servers could be reached. When I ran dig ANY, I ultimately got the same response, but dig complained three times about receiving a message that was too short in length. I really want NO message to be returned. How do I force this?

8 let, 8 měsíců

2
7
0 0

Fwd: Re: Edit zonefile

by libor.peltan＠nic.cz

Hi Volker, thank you for your question. Your suggestion is almost correct, just a little correction: knotc zone-freeze $ZONE # wait for possibly still running events (check the logs manually or so...) knotc zone-flush $ZONE # eventually with '-f' if zone synchronization is disabled in config $EDITOR $ZONEFILE # you SHALL increase the SOA serial if any changes made in zonefile knotc zone-reload $ZONE knotc zone-thaw $ZONE Reload before thaw - because after thaw, some events may start processing, making the modified zonefile reload problematic. BR, Libor Dne 5.9.2017 v 23:17 Volker Janzen napsal(a): > Hi, > > I've setup knot to handle DNSSEC signing for a couple of zones. I like to update zonefiles on disk with an editor and I want to clarify which steps need to be performed to safely edit the zonefile on disk. > > I currently try this: > > knotc zone-freeze $ZONE > knotc zone-flush $ZONE > $EDITOR $ZONE > knotc zone-thaw $ZONE > knotc zone-reload $ZONE > > As far as I can see knot increases the serial on reload and slaves will be notified. > > Is this the correct command sequence? > > > Regards > Volker > > > _______________________________________________ > 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, 8 měsíců

3
4
0 0

Edit zonefile

by Volker Janzen

Hi, I've setup knot to handle DNSSEC signing for a couple of zones. I like to update zonefiles on disk with an editor and I want to clarify which steps need to be performed to safely edit the zonefile on disk. I currently try this: knotc zone-freeze $ZONE knotc zone-flush $ZONE $EDITOR $ZONE knotc zone-thaw $ZONE knotc zone-reload $ZONE As far as I can see knot increases the serial on reload and slaves will be notified. Is this the correct command sequence? Regards Volker

8 let, 8 měsíců

1
0
0 0

Knot DNS 2.5.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.5.4. This patch version mainly fixes some journal related issues, possible server crash with statistics module enabled, and improves keymgr. See the changelog for more details. Changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.4/NEWS Documentation: https://www.knot-dns.cz/docs/2.5/html/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.5.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.5.4.tar.xz.asc Regards, Daniel

8 let, 8 měsíců

2
2
0 0

Full journal causing repeated zone transfers

by Chuck Musser

Hi, Recently, we noticed a few of our Knot slaves repeatedy doing zone transfers. After enabling zone-related logging, these messages helped narrow down the problem: Aug 8 17:42:14 f2 knot[31343]: warning: [our.zone.] journal: unable to make free space for insert Aug 8 17:42:14 f2 knot[31343]: warning: [our.zone.] IXFR, incoming, 1.2.3.4@53: failed to write changes to journal (not enough space provided) These failures apparently caused the transfers to occur over and over. Not all the zones being served showed up in these messages, but I'm pretty sure that the ones with a high rate of change were more likely to do so. I do know there was plenty of disk space. A couple of the tunables looked relevant: max-journal-db-size: we didn't hit this limit (used ~450M of 20G limit, the default) max-journal-usage: we might have hit this limit. The default is 100M. I increased it a couple of times, but the problem didn't go away. Eventually, we simply removed the journal database and restarted the server and the repeated transfers stopped. At first I suspected that it somehow was losing track of how much space was being allocated, but that's a flimsy theory: I don't really have any hard evidence and these processes had run at a high load for months without trouble. On reflection, hitting the max-journal-usage limit seems more likely. Given that: 1. Are the messages above indeed evidence of hitting the max-journal-usage limit? 2. Is there a way to see the space occupancy of each zone in the journal, so we might tune the threshold for individual zones? On the odd chance that there is a bug in this area: we are using a slightly older dev variant: a branch off 2.5.0-dev that has some non-standard, minimal EDNS0 client-subnet support we were interested in. The branch is: https://github.com/CZ-NIC/knot/tree/ecs-patch. Thanks, Chuck

8 let, 8 měsíců

2
2
0 0

Instalace DNS serverů

by Milan Černý

Dobrý den, omlouvám se jestli se obracím na špatnou adresu, tuto jsem dostal telefonátem na vaši zákaznickou linku. Měl bych zájem o odbornou instalaci a konfiguraci vašich DNS serverů v naší společnosti. Jsme společnost, která poskytuje internetové služby a jednalo by se o interní DNS resolvery pro naše zákazníky na našem (pravděpodobně virtualizovaném) hardwaru. Jednalo by se o placenou jednorázovou instalaci a prvotní nastavení - možná včetně nějaké konzultace. (bohužel si však nemohu dovolit Váš support). Potřeboval bych tedy vědět, zdali poskytujete podobné služby (případně na koho se mohu obrátit) a alespoň orientační odhad ceny výše uvedeného zásahu. Předem děkuji za Váš čas a zpětnou vazbu. S pozdravem Milan Černý vedoucí informačních systémů Planet A, a.s. provozovatel sítě AIM kanceláře společnosti: U Hellady 4 140 00 Praha 4 - Michle www.a1m.cz<http://www.a1m.cz/> +420 246 089 203 tel +420 246 089 210 fax +420 603 293 561 gsm milan.cerny(a)a1m.cz<mailto:milan.cerny@a1m.cz>

8 let, 9 měsíců

1
0
0 0

Knot Resolver 1.3.3 security release

by Vladimír Čunát

Dear Knot Resolver users, Knot Resolver 1.3.3 is a critical security release! Security -------- - Fix a critical DNSSEC flaw. Signatures might be accepted as valid even if the signed data was not in bailiwick of the DNSKEY used to sign it, assuming the trust chain to that DNSKEY was valid. Bugfixes -------- - iterate: skip RRSIGs with bad label count instead of immediate SERVFAIL - utils: fix possible incorrect seeding of the random generator - modules/http: fix compatibility with the Prometheus text format Improvements ------------ - policy: implement remaining special-use domain names from RFC6761 (#205), and make these rules apply only if no other non-chain rule applies It is strongly recommended to update from any older versions, or at least to mitigate the security problem by applying this small patch: https://gitlab.labs.nic.cz/knot/knot-resolver/commit/d7d7cae5a3.patch Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v1.3.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.3.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/v1.3.3/ --Vladimir

8 let, 9 měsíců

1
0
0 0

Knot Dns 2.5.3 and ZSK / KSK.

by Xavier Beaudouin

Hello, I am a bit news with Knot DNS 2.5.3 and also DNSSEC as well. I am succesfully migrated from a non dnssec bind to knot dns, this is working like a charm. Now I would like to migrate one zone into DNSSEC. Everything is working *except* getting keys (ZSK/KSK) to publish to Gandi. I got this tutorial (french sorry) : https://www.swordarmor.fr/gestion-automatique-de-dnssec-avec-knot.html that seems to works BUT the publication of the DNSKEY has chenged, and I didn't find a nice way to get it. Have any ideas ? Regards, Xavier

8 let, 9 měsíců

3
3
0 0

Knot Resolver 1.3.2 release

by Vladimír Čunát

Dear Knot Resolver users, Knot Resolver 1.3.2 maintenance update has been released: Security -------- - fix possible opportunities to use insecure data from cache as keys for validation Bugfixes -------- - daemon: check existence of config file even if rundir isn't specified - policy.FORWARD and STUB: use RTT tracking to choose servers (#125, #208) - dns64: fix CNAME problems (#203) It still won't work with policy.STUB. - hints: better interpretation of hosts-like files (#204) also, error out if a bad entry is encountered in the file - dnssec: handle unknown DNSKEY/DS algorithms (#210) - predict: fix the module, broken since 1.2.0 (#154) Improvements ------------ - embedded LMDB fallback: update 0.9.18 -> 0.9.21 It is recommended to update from 1.3.x, and it's strongly recommended to update from older versions, as older branches are no longer supported. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.3.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.2.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/v1.3.2/ --Vladimir

8 let, 9 měsíců

1
0
0 0

Sharing LMDB databases between knot instances

by Anand Buddhdev

Hello Knot developers, Suppose I am running two Knot DNS instances. They're listening on different interfaces, and slaving different sets of zones. If the "storage" variable is the same for these two, then the two instances of knotd will both try to write into storage/journal and storage/timers. Is this safe to do? My understanding of LMDB is that a database can be shared between different threads and processes because they using locking. Regards, Anand

8 let, 9 měsíců

2
3
0 0

failed in mdb_freelist_save()

by Yoshihito Horigome

8 let, 10 měsíců

2
4
0 0

Impossible to purge zone data for unconfigured zone

by Anand Buddhdev

Hello Knot DNS developers, I have an observation about newer versions of Knot which use the new single LMDB-based journal. Suppose I have 3 slave zones configured in my knot.conf. Let's call them zone1, zone2 and zone3. Knot loads the zones from the master and writes data into the journal. Now suppose I remove one zone (zone3) from the config, and reload knot. The zone is no longer configured, and querying knot for it returns a REFUSED response. So far all is according to my expectation. However, if I run "kjournalprint <path-to-journal> -z", I get: zone1. zone2. zone3. So the zone is no longer configured, but its data persists in the journal. If I run "knotc -f zone-purge zone3." I get: error: [zone3.] (no such zone found) I'm told that I should have done the purge first, *before* remove the zone from the configuration. However, I find this problematic for 2 reasons: 1. I have to remember to do this, and I'm not used to this modus operandi; and 2. this is impossible to do on a slave that is configured automatically from template files. On our slave servers, where we have around 5000 zones, the zones are configured by templating out a knot.conf. Adding zones is fine, but if a zone is being deleted, it will just disappear from knot.conf. We keep no state, and so I don't know which zone is being removed, and cannot purge it before-hand. Now, the same is kind of true for Knot < 2.4. But... there is one major difference. Under older versions of Knot, zone data was written into individual files, and journals were written into individual .db files. I can run a job periodically that compares zones in knot.conf with files on disk, and delete those files that have no matching zones in the config. This keeps the /var/lib/knot directory clean. But in newer versions of Knot, there is no way to purge the journal of zone data once a zone is removed from the configuration. For an operator like me, this is a problem. I would like "knotc zone-purge" to be able to operate on zones that are no longer configured, and remove stale data anyway.

8 let, 10 měsíců

3
3
0 0

Knot DNS 2.5.3 release

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.5.3. This patch version brings CSK rollover support for Single-Type Signing Scheme, fixes non-local address binding and some DNSSEC-related issues, and extends the documentation. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.3/NEWS Documentation and migration notes: https://www.knot-dns.cz/docs/2.5/html/ https://www.knot-dns.cz/docs/2.5/html/migration.html#upgrade-2-4-x-to-2-5-x Source code: https://secure.nic.cz/files/knot-dns/knot-2.5.3.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.5.3.tar.xz.asc Regards, Daniel

8 let, 10 měsíců

1
0
0 0

Knot DNS website gives 404 errors

by Anand Buddhdev

Hi Knot folks, I just tried to view https://www.knot-dns.cz/ and it gave me an HTTP 404 error. After trying to reload it twice, I got the front page, but the other parts of the site (documentation, download, etc) are all still giving me HTTP 404 errors. Regards, Anand

8 let, 10 měsíců

2
1
0 0

Git repositories cleanup

by Ondřej Surý

Dear Knot DNS and Knot Resolver users, in order to unite the git namespaces and make it more logical we have move the repositories of Knot DNS and Knot Resolver under the knot namespace. The new repositories are located at: Knot DNS https://gitlab.labs.nic.cz/knot/knot-dns Knot Resolver: https://gitlab.labs.nic.cz/knot/knot-resolver The old git:// urls were kept same: git://gitlabs.labs.nic.cz/knot-dns.git git://gitlabs.labs.nic.cz/knot-resolver.git Sorry for any inconvenience it might have caused. 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

Re: [knot-dns-users] $storage/$zone.db file lost

by Christoph Lukas

Am 09.07.2017 um 12:30 schrieb Christoph Lukas: > Hello list, > > I'm running knot 2.5.2 on FreeBSD. > In an attempt to resolve a recent semantic error in one of my zonefiles, > the $storage/$zone.db (/var/db/knot/firc.de.db) file got lost. > Meaning: I accidentally deleted it without a backup. > At point of deletion, the .db file was 1.6 MB in size. > The actual zone file was kept, the journal and DNSSEC keys untouched, > the zone still functions without any issues. > > The zone is configured as such in knot.conf: > zone: > - domain: firc.de > file: "/usr/local/etc/knot/zones/firc.de" > notify: inwx > acl: acl_inwx > dnssec-signing: on > dnssec-policy: rsa > > > This raises the following questions: > > 1) What is actually in those .db files? > 2) Are these any adverse effects to be expected now that I don't have > the file / need to re-create it? > 3) How can I re-create the file? > > Any answers will be greatly appreciated. > > With kind regards, > Christoph Lukas > As answered in https://lists.nic.cz/pipermail/knot-dns-users/2017-July/001160.html those .db files are not required anymore. I should have read the archive first ;) With kind regards, Christoph Lukas

8 let, 10 měsíců

1
0
0 0

"journal, obsolete exists, file" ...

by Thomas Preissler

Hi, I am running Knot 2.5.2-1 on a Debian Jessie, all is good, no worries. I am very pleased with Knot's simplicity and ease of configuration - which are still readable as well! I noticed recently that I am getting knotd[9957]: notice: [$DOMAIN.] journal, obsolete exists, file '/var/lib/knot/zones/$DOMAIN.db' everytime I restart Knot. I get these for all my domains I have confgured, and there is one in particular providing my own .dyn. service :-) - so I am a bit reluctant - just to delete it. But all the .db files have a fairly old timestamp (Feb 2017) and about the same. At that time (Feb 2017) I was running just one authoritative Master instance, nothing fancy. lsof also doesn't report any open files. At that time (Feb 2017) I was running just one authoritative Master instance, nothing else. Can I just delete those files? Cheers Thomas

8 let, 10 měsíců

2
1
0 0

Feature Request: Workers

by knot＠johnbond.org

Hello knot, I have recently started a long over due migration to knot 2.* and I have noticed that the server.workers config stanza is now split into three separate stanzas [server.tcp-workers, server.udp-workers & server.background-workers]. Although this is great for flexibility it does make automation a little bit more difficult. With the 1.6 configuration I could easily say something like the following workers = $server_cpu_count - 2 This meant I would always have 2 cpu cores available for other processes e.g. doc, tcpdump. With the new configuration I would need to do something like the following $avalible_workers = $server_cpu_count - 2 $udp_workers = $avalible_workers * 0.6 $tcp_workers = $avalible_workers * 0.3 $background_workers = $avalible_workers * 0.1 The above code is lacking error detection and rounding corrections which will add further complexity and potentially lacking itelagence that is available in knot to better balance resources. As you have already implemented logic in knot to ensure cpus are correctly balanced I wonder if you could add back a workers configurations to act as the upper bound used in the *-workers configuration. Such that *-workes defaults: "Default: auto-estimated optimal value based on the number of online CPUs or the value set by `workers` which ever is lower) Thanks John

8 let, 10 měsíců

2
1
0 0

problem with Knot 2.4.0 on FreeBSD 10.3 and 11.0 - i386

by Leo Vandewoestijne

Hi, I tried to install knot 2.4.0 on FreeBSD 10.3 & 11.0. On amd64 these complete fine, however on i386 they don't: https://dns.company/downloads/knot2/knot2-2.4.0_103i386.log https://dns.company/downloads/knot2/knot2-2.4.0_110i386.log Is there anything I can do better to prevent this? -- With kind regards, Leo Vandewoestijne

8 let, 10 měsíců

5
6
0 0

Knot DNS 2.5.2 and 2.4.5 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.5.2 and Knot DNS 2.4.5. Beside several fixes and improvements, these versions fix a flaw within the TSIG protocol implementation that would allow an attacker with a valid key name and algorithm to bypass the TSIG authentication if no additional ACL restrictions is set. This vulnerability was discovered by security experts from Synacktiv. Special thanks to them! Full changelogs: https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.2/NEWS https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.5/NEWS Documentation and migration notes: https://www.knot-dns.cz/docs/2.5/html/ https://www.knot-dns.cz/docs/2.5/html/migration.html#upgrade-2-4-x-to-2-5-x Source code: https://secure.nic.cz/files/knot-dns/knot-2.5.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.5.2.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.4.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.4.5.tar.xz.asc Regards, Daniel

8 let, 10 měsíců

5
7
0 0

Knot Resolver 1.3.1 release

by Vladimír Čunát

Dear Knot Resolver users, Knot Resolver 1.3.1 has been released with a few bugfixes atop 1.3.0, notably: - modules/http: fix finding the static files (bug from 1.3.0) - policy.FORWARD: fix some cases of CNAMEs obstructing search for zone cuts It is recommended to update from 1.3.0, and it's strongly recommended to update from older versions, as older branches are no longer supported. Full changelog: https://gitlab.labs.nic.cz/knot/resolver/raw/v1.3.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.1.tar.xz.asc Documentation: http://knot-resolver.readthedocs.io/en/v1.3.1/ --Vladimir

8 let, 10 měsíců

1
0
0 0

Knot DNS broke after PPA upgrade to 2.5.1-3

by Antti Ristimäki

Hi, I just upgraded my Knot DNS to the newest PPA release 2.5.1-3, after which the server process refuses to start. Relevant syslog messages: Jun 15 11:19:41 vertigo knotd[745]: error: module, invalid directory '/usr/lib/x86_64-linux-gnu/knot' Jun 15 11:19:41 vertigo knotd[745]: 2017-06-15T11:19:41 error: module, invalid directory '/usr/lib/x86_64-linux-gnu/knot' Jun 15 11:19:41 vertigo knotd[745]: critical: failed to open configuration database '' (invalid parameter) Jun 15 11:19:41 vertigo knotd[745]: 2017-06-15T11:19:41 critical: failed to open configuration database '' (invalid parameter) Could this have something to do with the following change: knot (2.5.1-3) unstable; urgency=medium . * Enable dnstap module and set default moduledir to multiarch path Antti

8 let, 11 měsíců

2
2
0 0

Help configuring dnstap

by Sarah Scheffler

Hi there, I'm having some issues configuring dnstap. I'm using Knot version 2.5.1, installed via the `knot` package on Debian 3.16.43-2. As per this documentation <https://www.knot-dns.cz/docs/2.5/html/modules.html#dnstap-dnstap-traffic-lo…>, I've added the following lines to my config file: mod-dnstap: - id: capture_all sink: "/etc/knot/capture" template: - id: default global-module: mod-dnstap/capture_all But when starting knot (e.g. by `sudo knotc conf-begin`), I get the message: error: config, file 'etc/knot/knot.conf', line 20, item 'mod-dnstap', value '' (invalid item) error: failed to load configuration file '/etc/knot/knot.conf' (invalid item) I also have the same setup on an Ubuntu 16.04.1 running Knot version 2.4.0-dev, and it works fine. Any idea what might be causing the issue here? Did the syntax for mod-dnstap change or something? Should I have installed from source? I do remember there being some special option you needed to compile a dependency with to use dnstap when I did this the first time, but I couldn't find documentation for it when I looked for it. Thanks! -Sarah

8 let, 11 měsíců

3
3
0 0

Timers in knotc zone-status show wrong values

by André Keller

Hi, after upgrade to 2.5.1 the output of knotc zone-status shows strange timestamps for refresh and expire: [example.net.] role: slave | serial: 1497359235 | transaction: none | freeze: no | refresh: in 415936h7m15s | update: not scheduled | expiration: in 416101h7m15s | journal flush: not scheduled | notify: not scheduled | DNSSEC resign: not scheduled | NSEC3 resalt: not scheduled | parent DS query: not schedule However the zone is refreshed within correct interval, so it seems its just a display issue. Is this something specific to our setup? Regards André

8 let, 11 měsíců

2
1
0 0

Knot Resolver 1.3.0 release

by Ondřej Surý

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

8 let, 11 měsíců

1
0
0 0

include statement does not seem to work since update to 2.5.1

by André Keller

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

8 let, 11 měsíců

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

1
0
0 0

Knot DNS 2.5.0 and 2.4.4 releases

by daniel.salzman＠nic.cz

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

8 let, 11 měsíců

3
6
0 0

Is output that there is no http module

by Yoshihito Horigome

9 let

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

9 let

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

9 let

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

9 let

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

9 let

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.

9 let

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 1 měsíc

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

9 let, 2 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

9 let, 2 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.

9 let, 2 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

9 let, 2 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/ --------------------------------------------

9 let, 2 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

9 let, 2 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/ --------------------------------------------

9 let, 2 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/ --------------------------------------------

9 let, 3 měsíce

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users