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

by Thomas E.

Hi, I was trying to backup and restore a server with the new knotc zone-backup/restore command. I recognized that only half of the private keys were in the backup, which leads to an error: 2020-12-08T14:44:00+0100 error: [xxx.] DNSSEC, failed to load private keys (not exists) 2020-12-08T14:44:00+0100 error: [xxx.] DNSSEC, failed to load keys (not exists) Shouldn't the backup contain all private keys? Thanks, Thomas

5 let, 5 měsíců

1
1
0 0

Removing slave from confdb not working

by Zdenek Novy

Hello, I'm trying to remove the slave node from the master Knot, result code is 0, but no change happened. There is no information in the log file. Can you please help me, why does it happen? # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 # knotc conf-begin > OK # knotc conf-set -b template[default].notify 1 2 4 5 6 7 8 9 > OK # knotc conf-diff (no output) # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 Thanks for your help. -- Zdeněk Nový Linux administrator ACTIVE 24, s.r.o. Sokolovská 394/17 186 00 Praha 8 Web: http://www.active24.cz

5 let, 5 měsíců

4
6
0 0

Too many transactions error

by Zdenek Novy

Hello, we are facing the issue with "Too many transactions" during configuring knot via knotc - we are using confdb. We are using Python3 worker and popen function to knotc socket. This is the log from the Python worker: [2020-12-07 08:58:13,001] [INFO] adding zone xxxxxxxx [2020-12-07 08:58:13,016] [ERROR] [event worker.job] Exception in job 'dns.add_zone' Traceback (most recent call last): ...... ACK Exception: error running command: 'conf-begin' retcode: 1 out: error: (too many transactions) Is there any limitation for number of open transactions and are we able to increase it? Is it possible to see, how many open transactions there are now? I can't see any message in the log file, is it possible to log conf-begin requests? Or are there any other ways, how to determine and guard the situation? Many thanks for your help -- Zdeněk Nový Linux administrator ACTIVE 24, s.r.o. Sokolovská 394/17 186 00 Praha 8 Web: http://www.active24.cz

5 let, 5 měsíců

2
1
0 0

Removing slave from confdb not working

by Zdenek Novy

Hello, I'm trying to remove the slave node from the master Knot, result code is 0, but no change happen. There is no information in the log file. Can you please help me, why does it happen? # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 # knotc conf-begin > OK # knotc conf-set -b template[default].notify 1 2 4 5 6 7 8 9 > OK # knotc conf-diff (no output) # knotc conf-get template[default].notify > template[default].notify = 1 2 3 4 5 6 7 8 9 Thanks for your help. -- Zdeněk Nový Linux administrator ACTIVE 24, s.r.o. Sokolovská 394/17 186 00 Praha 8 Web: http://www.active24.cz

5 let, 6 měsíců

1
0
0 0

DNSSEC with multiple authoritative servers

by Nils Trampel

Hello, as I plan to migrate an existing DNS setup to Knot, not only for deploying DNSSEC but also for synthesizing some records using mod-synthrecord, I am not sure as how to setup online signing when having multiple public authoritative name servers. My uncertainty is, if it is necessary to give them the same ZSKs and do the key rollover from the outside, or if the chain of trust isn't severed when they generate their own ZSKs based from a common KSK or even their distinct KSKs, and therefore provide different signatures. Best regards and thanks, Nils -- Nils Trampel GPG: 0x012BADD8

5 let, 6 měsíců

5
10
0 0

Knot DNS 3.0.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.2! This version fixes several bugs and brings some improvements. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.2/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/3.0/html Support: https://www.knot-dns.cz/support Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

5 let, 6 měsíců

1
0
0 0

Query Log of Knot DNS

by Vu Thi Hoan

Dear! We are learning about the Knot DNS to apply to our DNS Authoritative Secondary. However, we are wondering about the query log, i have read the document of DNS Knot Software (Knot DNS Documentation Release 2.9.4/ 8.3 dnstap – Dnstap traffic logging), query log of Knot DNS cannot get directly like BIND9, query log can get by dnstap tool. For Knot DNS Software, we cannot get log query continuosly and directly to the current syslog server, since raw log need to capture and then read after stop capture. I wanna to know how to get the query log continously when using Knot DNS or softwares of your DNS and other DNS of organizations have already applied. Can you share with us and help us to deploy Knot DNS to our DNS Authoritative Secondary. Best Regards, Vũ Thị Hoàn ================================================= DNS & VNIX - Trung tâm Internet Việt Nam Mobile: +84 916 961 631 Email: hoanvt(a)vnnic.vn

5 let, 6 měsíců

2
1
0 0

Algorithm Rollover

by Thomas

Hi, the doc says that changing the policy algorithm field will trigger an algorithm rollover. Is there anything else one must consider or is the algorithm rollover done fully automated like the normal rollovers? Thanks, Thomas

5 let, 6 měsíců

2
2
0 0

Unknown algorithm: rsasha1-nsec3-sha1

by Thomas

Hi, I need to generate keys of algorithm 7. But I receive this error: # keymgr example generate algorithm=rsasha1-nsec3-sha1 size=2048 ksk=yes Unknown algorithm: rsasha1-nsec3-sha1 Error (invalid parameter) I'm using the latest version of knot. Do I get something wrong here? It you be supported, right? Thanks Thomas

5 let, 6 měsíců

2
2
0 0

dynamic updates (DDNS)

by Thomas

Hi! Is it safe to mix dynamic updates and manual editing of a zone? Thanks! Thomas

5 let, 6 měsíců

7
20
0 0

Inter-operability issues with other DNS Servers

by Evilham

Ahoj, I've searched through the archives and read documentation+RFCs to no avail, so I hope you can help out. I run the authoritative DNS servers for an associative ISP in Barcelona (eXO.cat), and we are running them in FreeBSD using Knot DNS (2.9.5, but .6 and .7's changelogs do not point to a similar issue being solved). We have since then gotten a few reports from different parties of "DNS issues", I am reasonably sure to have pinpointed this down to badly configured DNS resolvers, but our weight is really too tiny to force any change; and the doubt remains as to whether or not this is on us. Without access to the resolvers it's also a tad tricky for us to reproduce. Things do work beautifully with pretty much all of the internet. This appears to be related to: https://tools.ietf.org/html/rfc7873#section-5.2.3 (sometimes in connection with 5.2.4) Maybe someone with more experience and running at a larger scale has pointers on this topic. Specifically, I have observed: Case A: 1. (Probably Bind) Resolver contacts Knot DNS with Client Cookie and old Server Cookie 2. Knot DNS responds BADCOOKIE with the provided Client Cookie, Old Server Cookie, and adds the new server cookie. 3. Resolver contacts Knot DNS with the same Client Cookie and old Server Cokie 4. 2 and 3 repeat for a long time. 5. Domains end up not resolving. Case B: https://github.com/matrix-org/synapse/issues/8581 Their supplier says the DNS server "replies with BADCOOKIE to UDP queries", as if that were a bad thing; but from reading RFC7873, I understand that it is expected documented behaviour and the client ought to try again with the given Server Cookie. They say: "AIUI the resolver does retry, but again receives a BADCOOKIE response." I sadly don't have the tcpdump for those, but it could be just like case A again. These are the relevant bits from the config: server: rundir: "/var/run/knot" user: knot:knot listen: [ 0.0.0.0@53, ::@53 ] log: - target: syslog any: info statistics: append: off database: storage: "/var/db/knot" mod-cookies: - id: default badcookie-slip: 1 mod-rrl: - id: default rate-limit: 200 # Requests per second template: - id: default storage: "/var/db/knot/primary" semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" global-module: mod-cookies/default global-module: mod-rrl/default global-module: mod-stats - id: secondary storage: "/var/db/knot/secondary" semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" module: mod-cookies/default module: mod-rrl/default module: mod-stats - id: signed storage: "/var/db/knot/primary" dnssec-signing: on zonefile-load: difference semantic-checks: on disable-any: on serial-policy: dateserial file: "%s.zone" module: mod-cookies/default module: mod-rrl/default module: mod-stats We are not using anycast clusters or anything like that. A quick solution would be to disable cookies or to experiment with noudp, but that's something we'd like to avoid. The name servers in question are: - ns3.exo.cat - ns4.exo.cat - ns1.unchat.cat (not association, but identical setup) All tests I've ran against the servers and the associated domains (e.g. exo.cat + unchat.cat) appear to be fine. There is an odd one with https://dnsviz.net/d/unchat.cat/dnssec/, but other tests like https://www.zonemaster.net/result/d530cb253298b56c do not report any issues. Thank you in advance for any pointers you may have (and for Knot DNS!), -- Evilham

5 let, 7 měsíců

4
6
0 0

Knot upgrade

by Oto Stefan

Hallo everybody, this is just a little remark concerning the 'knot' upgrade from 2.9.x to 3.0.x. The 'update-owner-name' in the 'acl' section of the configuration file can now be either the FQDN (with trailing dot) or a relative name to the zone, while it used to be a domain name before (without obligatory dot at the end). The documentation was updated correctly: Doc for 2.9: acl - id: owner_type_rule action: update update-type: [A, AAAA, MX] # Updates are only allowed to update records of the specified types update-owner: name # The allowed owners are specified by the list on the next line update-owner-name: [a.example.com, b.example.com, c.example.com] update-owner-match: equal # The owners of records in an update must be exactly equal to the names in the list Doc for 3.0: acl - id: owner_type_rule action: update update-type: [A, AAAA, MX] # Updates are only allowed to update records of the specified types update-owner: name # The allowed owners are specified by the list on the next line update-owner-name: [a, b.example.com.] # Non-FQDN names are relative to the effective zone name update-owner-match: equal # The owners of records in an update must be exactly equal to the names in the list However; I did not notice the subtle change and was struggling for a while to bring the dynamic zone update into a working state again . Maybe, this saves a little time to someone else. Regards and thanks for a great piece of software, Oto Stefan

5 let, 7 měsíců

2
1
0 0

Warning - TCP ports binding in Knot DNS versions 3.0.0 and 3.0.1

by David Vasek

Hello Knot DNS users! We would like to inform you about a change in Knot DNS behaviour in versions 3.0.0 and 3.0.1. These two versions don't allow sharing of TCP ports between programs, including other knotd instances (SO_REUSEADDR isn't set). While this behaviour is better from point of view of security, the downside of it is that when restarting a knotd daemon, binding to a TCP port may fail after a restart if the restart is immediate. In such a case, an error is logged and Knot starts its operation on other configured ports only. To verify that all TCP ports have been bound successfully after Knot restart, please always check the log for possible errors. Such errors would be close to the initial message about Knot DNS starting. Since there was a complaint about this change, we plan to re-enable TCP ports reuse in future releases. We also ponder making knotd exit if it fails to bind to any of configured TCP ports. We would like hear from you whether such a behaviour is what you, users, want best. Please, let us know if you prefer this or a different solution. With regards, David Vašek CZ.NIC

5 let, 7 měsíců

4
3
0 0

Knot DNS 3.0.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.1! It's recommended to update from 3.0.0 version if you serve DNSSEC signed zones with NSEC3. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.1/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/3.0/html Support and sponsorship: https://www.knot-dns.cz/support Regards, Daniel

5 let, 7 měsíců

1
0
0 0

Knot DNS 2.9.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.7! This is a bugfix version of previous stable branch. It's recommended to update from older 2.9.x versions if you serve DNSSEC signed zones with NSEC3. Knot DNS 3.0.1 will be released tomorrow. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.7/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/2.9/html Support and sponsorship: https://www.knot-dns.cz/support Regards, Daniel

5 let, 7 měsíců

1
0
0 0

Debugging high CPU / Load - normal?

by Jonathan Hewlett

Hi, We run around 50 knot servers around the world, with great success - thanks for the software! We are just a little curious about seemingly high CPU usage, and how best to interpret the results, if someone could advise? Specifically, we are seeing the majority of the cpu time in 'system' and not 'user', what would that suggest is happening perhaps? Any tuning help gratefully received! Our platform (sample) 24 Core CPU E5-2440 0 @ 2.40 64Gb RAM SSD knot-2.9.5, running on Centos 8.2 Currently receiving around 4k pps Server is authoritative for a 278 zones, the largest zone file being around 600Mb Output of top top - 20:50:38 up 6 days, 4:49, 2 users, load average: 13.47, 12.34, 11.83 Tasks: 321 total, 2 running, 318 sleeping, 0 stopped, 1 zombie %Cpu0 : 4.0 us, 34.1 sy, 0.0 ni, 60.3 id, 0.3 wa, 0.7 hi, 0.7 si, 0.0 st %Cpu1 : 4.3 us, 19.4 sy, 0.0 ni, 75.3 id, 0.0 wa, 0.3 hi, 0.7 si, 0.0 st %Cpu2 : 4.3 us, 33.8 sy, 0.0 ni, 60.9 id, 0.0 wa, 0.7 hi, 0.3 si, 0.0 st %Cpu3 : 5.0 us, 21.2 sy, 0.0 ni, 73.2 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu4 : 3.3 us, 34.9 sy, 0.0 ni, 61.5 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu5 : 3.0 us, 20.2 sy, 0.0 ni, 76.2 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu6 : 4.0 us, 35.2 sy, 0.0 ni, 60.4 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu7 : 5.0 us, 18.7 sy, 0.0 ni, 76.0 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu8 : 2.0 us, 35.0 sy, 0.0 ni, 62.3 id, 0.0 wa, 0.7 hi, 0.0 si, 0.0 st %Cpu9 : 2.0 us, 20.0 sy, 0.0 ni, 77.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu10 : 3.7 us, 34.4 sy, 0.0 ni, 61.2 id, 0.0 wa, 0.7 hi, 0.0 si, 0.0 st %Cpu11 : 3.3 us, 20.7 sy, 0.0 ni, 75.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu12 : 2.3 us, 34.6 sy, 0.0 ni, 62.1 id, 0.0 wa, 0.7 hi, 0.3 si, 0.0 st %Cpu13 : 3.3 us, 20.7 sy, 0.0 ni, 75.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu14 : 2.3 us, 33.6 sy, 0.0 ni, 59.7 id, 0.0 wa, 0.7 hi, 3.7 si, 0.0 st %Cpu15 : 3.3 us, 19.7 sy, 0.0 ni, 76.3 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu16 : 2.3 us, 34.0 sy, 0.0 ni, 58.7 id, 0.0 wa, 1.0 hi, 4.0 si, 0.0 st %Cpu17 : 2.3 us, 21.5 sy, 0.0 ni, 75.8 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st %Cpu18 : 3.3 us, 34.8 sy, 0.0 ni, 57.2 id, 0.0 wa, 0.7 hi, 4.0 si, 0.0 st %Cpu19 : 5.0 us, 19.3 sy, 0.0 ni, 75.1 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu20 : 2.7 us, 35.3 sy, 0.0 ni, 60.0 id, 0.0 wa, 0.7 hi, 1.3 si, 0.0 st %Cpu21 : 1.7 us, 20.5 sy, 0.0 ni, 77.2 id, 0.0 wa, 0.3 hi, 0.3 si, 0.0 st %Cpu22 : 4.7 us, 32.4 sy, 0.0 ni, 58.5 id, 0.0 wa, 0.7 hi, 3.7 si, 0.0 st %Cpu23 : 2.3 us, 19.0 sy, 0.0 ni, 78.3 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st MiB Mem : 64107.4 total, 46764.9 free, 11733.6 used, 5608.8 buff/cache MiB Swap: 32248.0 total, 32248.0 free, 0.0 used. 51670.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 213370 knot 20 0 34.0g 9.6g 41784 S 644.9 15.3 1319:12 /usr/sbin/knotd Thanks again for this great product. Jonathan

5 let, 7 měsíců

3
9
0 0

Catalog zone configuration/zone auto configuration bootstrapping

by Frank Matthieß

Hello all, i stuck a little bit with the configuration of the new catalog zone feature in knot dns 3.0.0. The catalog zone replication is running quite well, but bootstrapping this feature to replicate the config for zones wont work for me. The zone name of the catalog zone is "zone.catalog". The primary name server uses this config: > # Configuration export (Knot DNS 3.0.0) > zone: > - domain: "zone.catalog." > file: "%s" > notify: [ "ns1.frank.REDACTED.DOM", "ns2.frank.REDACTED.DOM" ] > acl: [ "ns1.frank.REDACTED.DOM", "ns2.frank.REDACTED.DOM" ] > catalog-role: "interpret" > catalog-template: "catalog-zone-template" > > - domain: "dom-siew9tho.invalid." The zone has this content: > [zone.catalog.] zone.catalog. 60 NS nshp.frank.REDACTED.DOM. > [zone.catalog.] zone.catalog. 60 SOA nshp.frank.REDACTED.DOM. hostmaster.REDACTED.DOM. 1601540072 16384 2048 1048576 2560 > [zone.catalog.] id-ies3eidiev4ooquahgoh.zone.catalog. 0 PTR dom-siew9tho.invalid. > [zone.catalog.] version.zone.catalog. 0 TXT "2" Adding the following config to the primary works: > conf-begin > conf-set zone.domain "dom-siew9tho.invalid." > conf-commit > zone-begin dom-siew9tho.invalid. > zone-set dom-siew9tho.invalid. @ 60 SOA nshp.frank.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560 > zone-set dom-siew9tho.invalid. @ 60 NS nshp.REDACTED.DOM. > zone-commit dom-siew9tho.invalid. Query one of the secondaries (ns1) gives me: > error: (no such zone found) [dom-siew9tho.invalid.] The config of ns1: > # Configuration export (Knot DNS 3.0.0) > template: > - id: "catalog-zone-template" > storage: "/var/lib/knot/zones" > file: "%s" > semantic-checks: "on" > dnssec-signing: "off" > serial-policy: "unixtime" > kasp-db: "/var/lib/knot/kasp-db" > > zone: > - domain: "zone.catalog." > file: "%s" > master: "nshp.frank.REDACTED.DOM" > acl: "nshp.frank.REDACTED.DOM" > catalog-role: "interpret" > catalog-template: "catalog-zone-template" I'm sure i miss one or more parts and/or i have a serious misunderstanding of the bootstrapping setup for this feature. - frank -- Frank Matthieß Mail: frank.matthiess(a)virtion.de phone: +49 521 44 81 58 17 GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1 virtion GmbH Südring 11, DE 33647 Bielefeld Geschäftsführer: Michael Kutzner Handelsregister HRB 40374, Amtsgericht Bielefeld, USt-IdNr.: DE278312983

5 let, 8 měsíců

3
4
0 0

copy key from one instance to another

by Ulrich Wisser

Hi! For a special project I need to sign the same zone on two servers with the same key. How can I create a key and import it in both instances? Or export an automatically generated key from one instance and import in the other instance? Kind regards from Stockholm /Ulrich

5 let, 8 měsíců

2
1
0 0

termination of obsolete Knot DNS OBS repos

by Jakub Ružička

Following obsolete OBS package repositories will be terminated without mercy on Friday 18th September 2020: * [knot-dns](https://build.opensuse.org/project/show/home:CZ-NIC:knot-dns) * [knot-dns-latest](https://build.opensuse.org/package/show/home:CZ-NIC:knot-d… If you are using these repos, please refer to [Knot DNS download page](https://www.knot-dns.cz/download/) for links to current package repos for your favourite distribution. Jakub Ružička CZ.NIC packager

5 let, 8 měsíců

1
0
0 0

Knot DNS 3.0.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.0.0! This version introduces lots of new features. You can read more about them on this blog post https://en.blog.nic.cz/2020/09/09/knot-dns-3-0-news/ Don't forget to check the updated benchmarks https://www.knot-dns.cz/benchmark/ Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.0.0/NEWS Migration: https://www.knot-dns.cz/docs/3.0/html/migration.html#upgrade-2-9-x-to-3-0-x Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/docs/3.0/html Support and sponsorship: https://www.knot-dns.cz/support Regards, Daniel

5 let, 8 měsíců

1
0
0 0

Knot DNS 2.9.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.6! This is mostly a bug fix version with some small improvements. Just a notice, on September 9th we are going to release Knot DNS 3.0.0, which will become a new Current Latest version. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.6/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.6.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

5 let, 9 měsíců

1
0
0 0

keymgr doesn't delete (remove) keys

by Chris

I'm currently on 2.6.5, and am moving everything to a new server I've created that's using the newest version. However, I've got a couple of zones I am trying to clean up before the move. In my effort to resign these zones, I'm retiring/removing keys associated with these zones prior to resigning them. But keymgr(8) isn't working as expected. eg; 12:25pm Fri, 21 # keymgr some.zone. set 09696 retire=20200821122736 remove=20200821122755 12:28pm Fri, 21 # keymgr some.zone. list iso ... 83ded1e7f4375657fe12ca666d4bbc6c33b7edea ksk=no zsk=yes tag=09696 algorithm=5 public-only=no created=2020-05-06T04:42:32 pre-active=2020-05-06T04:42:32 publish=2020-05-06T05:42:32 ready=1970-01-01T00:00:00 active=2020-05-06T18:42:32 retire-active=1970-01-01T00:00:00 retire=2020-08-21T12:27:36 post-active=1970-01-01T00:00:00 remove=2020-08-21T12:27:55 ... As you can see, it's 12:28 but the key was not removed. What am I (missing/misunderstanding? Thanks. --Chris

5 let, 9 měsíců

2
2
0 0

KSK and ZKS roll-overs on schedule

by Thomas

Hi, I have another requirement for a capability test. I need to perform ZSK and KSK rollovers on specific times. Something like KSK rollover after exactly 60 hours. Or ZSK rollover after exactly 24 hours and another one after another 24 hours. And so on... One additional requirement is that I need to pre-generate the keys. I was thinking of doing it with manual key management enabled and to use the keymgr tool for it. But I'm unsure about how to set the key attributes correctly an in what order. At what point I have to set the new key to active, and how can I remove the old key, and so on... I have never done it manually as I normally use Knots automatic key management. Is the "knotc zone-key-rollover" useful here, or is it only useful in an automatic key management set up? I really appreciate any help here! Thanks a lot, Thomas

5 let, 9 měsíců

3
2
0 0

Re: [knot-dns-users] Unexpected behaviour of `knotc zone-set` when adding a TXT record

by Daniel Salzman

Hello, You have to escape the quotes: zone-set bastetrix.com @ 86400 TXT \"v=spf1 include:spf.messagingengine.com -all\" Regards, Daniel On 8/9/20 4:47 AM, Sadiq Saif wrote: > Hi all, > > Today I ran into some unexpected behaviour, I wanted to make a modification to the TTL (3600->86400) for the SPF TXT record for bastetrix.com, so I did the following: > > zone-set bastetrix.com @ 86400 TXT "v=spf1 include:spf.messagingengine.com -all" > > But the result was unexpected, instead of modifying the record, I got a new record that looked like this: > > bastetrix.com. 86400 IN TXT "v=spf1" "include:spf.messagingengine.com" " -all" > > RFC 7208 Section 3.3: > > 3.3. Multiple Strings in a Single DNS Record > > As defined in [RFC1035], Sections 3.3 and 3.3.14, a single text DNS > record can be composed of more than one string. If a published > record contains multiple character-strings, then the record MUST be > treated as if those strings are concatenated together without adding > spaces. For example: > > IN TXT "v=spf1 .... first" "second string..." > > is equivalent to: > > IN TXT "v=spf1 .... firstsecond string..." > > TXT records containing multiple strings are useful in constructing > records that would exceed the 255-octet maximum length of a > character-string within a single TXT record. > > If I'm not misreading this bit of the RFC, that record would result in a wrongly formatted SPF record without the correct spaces. > > And indeed when I added the same SPF record to another zone (bastetrix.net) using `knotc zone set` Fastmail's DNS record checker said that I had not added a SPF record. I had to edit the zone by hand in a text editor to fix the issue. > > Is this a bug in `knotc zone-set` or intended behaviour? Am I misunderstanding some implementation detail in TXT records or the RFC? > -- > Sadiq Saif > Bastetrix LLC >

5 let, 9 měsíců

1
0
0 0

re-sign zone

by Thomas

Hi, I have the requirement to re-sign my zones exactly every 24 hours. I'm not sure how to achieve this, because I'm not clear about the correlation of the following parameters: zsk-lifetime propagation-delay rrsig-lifetime rrsig-refresh rrsig-pre-refresh Can anybody give a hint what values I need to have an exact re-signing period of 24 hours? Thanks a lot, Thomas

5 let, 9 měsíců

3
3
0 0

Is cds-cdnskey-publish doing too many publishes?

by Jan-Piet Mens

I have the following signing policy configured in a test environment: - id: rsadefault algorithm: RSASHA256 ksk-size: 2048 ksk-lifetime: 30m zsk-size: 1024 zsk-lifetime: 2h propagation-delay: 2s dnskey-ttl: 10s zone-max-ttl: 15s nsec3: on nsec3-iterations: 5 nsec3-salt-length: 8 nsec3-salt-lifetime: 100d cds-cdnskey-publish: always ksk-submission: ds_checker ds-push: hidden-primary I notice that every five minutes Knot is updating the DS in the parent zone hosted on a BIND server. It appears that every time Knot refreshes the secondary it also updates the DS in the parent. (Logs below.) Isn't that a bit much? I realize I've configured `cds-cdnskey-publish: always', but I was expecting "always if something changes" :-) I would prefer on CDS publishing on "rollover", but then the DS record isn't added to the parent when a zone is first signed. Is this expected behaviour, respectively, is there a different configuration I should set? Thank you, -JP zone aa.tm. has an SOA refresh of 300s (5 minutes) Knot console: Jul 15 14:38:14 ods knotd[14346]: info: [aa.tm.] refresh, remote 192.168.1.140@53, remote serial 20, zone is up-to-date Jul 15 14:38:14 ods knotd[14346]: info: [aa.tm.] DS push, outgoing, remote 192.168.1.140@53, success BIND console: 15-Jul-2020 16:38:23.946 client @0x7fd5bc7f8568 192.168.1.150#58386 (aa.tm): query: aa.tm IN SOA -E(0)T (192.168.1.140) 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer (tm): query: tm IN SOA -SE(0)T (192.168.1.140) 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: signer "k-signer" approved 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: updating zone 'tm/IN': deleting rrset at 'aa.tm' DS 15-Jul-2020 16:38:23.947 client @0x7fd5bc7de168 192.168.1.150#58388/key k-signer: updating zone 'tm/IN': adding an RR at 'aa.tm' DS 54410 8 2 5EAF060C7F00846B82D66CAAB29542450383DDF99390151694CC2A95 8C78E648 ... after five minutes ... Knot console: Jul 15 14:43:14 ods knotd[14346]: info: [aa.tm.] refresh, remote 192.168.1.140@53, remote serial 20, zone is up-to-date Jul 15 14:43:14 ods knotd[14346]: info: [aa.tm.] DS push, outgoing, remote 192.168.1.140@53, success BIND console: 15-Jul-2020 16:43:24.016 client @0x7fd56c220d68 192.168.1.150#58390 (aa.tm): query: aa.tm IN SOA -E(0)T (192.168.1.140) 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer (tm): query: tm IN SOA -SE(0)T (192.168.1.140) 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: signer "k-signer" approved 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: updating zone 'tm/IN': deleting rrset at 'aa.tm' DS 15-Jul-2020 16:43:24.017 client @0x7fd59c324768 192.168.1.150#58392/key k-signer: updating zone 'tm/IN': adding an RR at 'aa.tm' DS 54410 8 2 5EAF060C7F00846B82D66CAAB29542450383DDF99390151694CC2A95 8C78E648

5 let, 10 měsíců

3
5
0 0

Revoking DNSSEC KSK (a la RFC 5011)

by Jan-Piet Mens

Hello! first of all, thank you for a wonderful authoritative DNS server; as mentioned a while back, I'm loving the automatic key management and DS push; both work a treat. I have a requirement for manual key management and that is to be able to roll KSK keys a la RFC 5011 for both BIND and Unbound instances to automatically change their trust anchors. In Knot I can retire a key and subsequently have it removed, but the key isn't revoked (a.k.a. key flags 257+128 == 385). keymgr . set 41155 active=+1mi retire=+5mi remove=+60mi As such, BIND will, when this particular KSK is removed from the DNSKEY RRset, (rightly) complain: managed-keys-zone: Active key 41155 for zone . unexpectedly missing managed-keys-zone: Key 30377 for zone . is now trusted (acceptance timer complete) I've not found the word 'revoke' in the documentation, and no flags I can set with keymgr(8) seem to indicate that I can revoke a key. Can you help me, please? As an aside, I've noticed that when keymgr's `remove' time is reached, the key is removed from the zone (which is expected), however the key itself remains in the key store. From there, I can delete it, but I can also set flags on it in such a way as that it's brought *back* into the zone. Is that expected behaviour? It's not a problem per se, I'd just like to know whether I've understood the system. Thank you and kind regards, -JP

5 let, 10 měsíců

3
4
0 0

Log query

by Smile TV

Dear all, I am deploying a DNS system using the Knot DNS software. I have read in the document and I did not see any DNS query log. So let me ask DNS Knot software can collect DNS query log? If possible, what is the configuration? Best regards, Chinhlk.

5 let, 10 měsíců

4
6
0 0

Manual Key Rollover - 2 ZSKs with same key id

by Thomas E.

Hi, I performed a manual key roll over with this command: $ knotc zone-key-rollover dnssec-test.xxx zsk The result is 2 different ZSK's with the same key id: dnssec-test.xxx. 3600 IN DNSKEY 256 3 8 ( AwEAAc5W..... ) ; ZSK; alg = RSASHA256; key id = 7030 dnssec-test.xxx. 3600 IN DNSKEY 256 3 8 ( AwEAAc7Q5U...... ) ; ZSK; alg = RSASHA256; key id = 7030 >From the log: 2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 56464, algorithm RSASHA256, KSK, public, ready, active+ 2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 7030, algorithm RSASHA256, public 2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, key, tag 7030, algorithm RSASHA256, public, active 2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, signing started 2020-07-03T14:52:59 info: [dnssec-test.xxx.] DNSSEC, zone is up-to-date Is it the indented behavior to have two ZSK's with the same key id? Thanks a lot, Thomas

5 let, 10 měsíců

4
3
0 0

Knot DNS 2.9.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.5! It's a serious bugfix version for those how use Knot DNS 2.9.0-2.9.4 for DNSSEC zone signing with automatic DNSKEY management and who rely on automatic maximum zone TTL computation. We apologize for possible inconvenience! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.5/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.5.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let

1
0
0 0

Knot DNS bug notification

by libor.peltan

Hi all, we'd like to inform you about recently found bug in Knot DNS 2.9.x. The bug affects automatic key roll-overs when automatic key management is configured https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#automatic-dnssec-sig… The ZSK, CSK or algorithm roll-over might be finished too early, so that DNSKEY and RRSIG records in resolvers' caches get out of sync, leading to temporary DNSSEC validation failure. Affected versions are Knot DNS 2.9.0 -- 2.9.4. We will release fixing version 2.9.5 soon. In the meantime, we recommend to apply the workaround: set the configuration option zone-max-ttl https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#zone-max-ttl explicitly to a value greater or equal to maximal TTL among all records in the zone. (Remove the workaround once upgraded to fixed version.) Many thanks to Anand Buddhdev from RIPE NCC for finding this bug. Caring regards, Libor Peltan CZ.NIC

6 let

2
1
0 0

Re: [knot-dns-users] Knot DNS 2.9.4 release

by Daniel Salzman

Hello Roman, Thanks for asking! I have updated the images on Docker Hub :-) Best, Daniel On 5/5/20 9:31 AM, Roman Šafránek wrote: > Hello Daniel, > are you planning to update cznic/knot docker image on Docker HUB to latest version or i'm supposed > to use docker images from https://gitlab.labs.nic.cz/knot/knot-dns/container_registry ? > > Regards, > Roman > > > Dne 05.05.2020 v 9:09 Daniel Salzman napsal(a): >> Hello Knot DNS users, >> >> CZ.NIC has released Knot DNS 2.9.4! >> >> This version brings several bugfixes and improvements. >> See the changelog for more details. >> >> Changelog: >> https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.4/NEWS >> >> Source code: >> https://secure.nic.cz/files/knot-dns/knot-2.9.4.tar.xz >> https://secure.nic.cz/files/knot-dns/knot-2.9.4.tar.xz.asc >> >> Documentation: >> https://www.knot-dns.cz/docs/2.9/html >> >> Support and funding: >> https://www.knot-dns.cz/support >> >> Regards, >> Daniel >> >> >

6 let

1
0
0 0

Knot DNS 2.9.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.4! This version brings several bugfixes and improvements. See the changelog for more details. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.4/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.4.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let

1
0
0 0

How to move signed zones and keys to another server?

by Chris

We're consolidating servers, and as a result. I need to transfer some the IPs, zones && keys to other servers. I'm trying to find the least eventful way to accomplish this. I attempted to transfer (signed) zones and IPs once before. But the slaves wouldn't accept the zones and I ultimately had to purge the journals on all the servers I had control of, and re-key and re-sign the zones to make everything work as intended. All the zones are written/kept on disk (except changes that haven't already been flushed to disk from the DB). I'm wondering if it's enough to freeze all the zones on their current serves. Then shutdown the server(s), and transfer the zones, keys, and merge the configs onto the new servers would be the correct way to do this? If not. Please advise. Thank you for all your time, and consideration. --Chris

6 let

2
1
0 0

TCP resets during AXFR

by Petr Baloun

Hi, I've setup knot to AXFR 24 zones from our MS domain controllers but three zones fail mysteriously. After enabling debug logging knot adds additional line with the reason - 'trailing data'. In the pcap file created with tcpdump I see that our server starts to send TCP resets in the middle of the transfer. Each time resets are sent after downloading approximately the same amount of data, this amount differ for each zone (81kb for one, 49kb for the second). I am able to download the zone with dig or kdig. We also have a different server with powerdns which is able to download the zones without problems. I've also tried to setup different server (with bind9) serving one of the zones and have knot to download it from there. It worked just fine. I can send the log file snippet (with zone name and ip addresses) as well as the pcap file off the record. Could you, please, help me with solving this problem? Thank you, Petr Baloun Je dobré vědět, že tento e-mail a přílohy jsou důvěrné. Pokud spolu jednáme o uzavření obchodu, vyhrazujeme si právo naše jednání kdykoli ukončit. Pro fanoušky právní mluvy - vylučujeme tím ustanovení občanského zákoníku o předsmluvní odpovědnosti. Pravidla o tom, kdo u nás a jak vystupuje za společnost a kdo může co a jak podepsat naleznete zde<https://onas.seznam.cz/cz/podpisovy-rad-cz.html> You should know that this e-mail and its attachments are confidential. If we are negotiating on the conclusion of a transaction, we reserve the right to terminate the negotiations at any time. For fans of legalese—we hereby exclude the provisions of the Civil Code on pre-contractual liability. The rules about who and how may act for the company and what are the signing procedures can be found here<https://onas.seznam.cz/cz/podpisovy-rad-cz.html>.

6 let, 1 měsíc

2
2
0 0

Modules and CNAME chain resolution

by Conrad Hoffmann

Hi, I noticed that when using e.g the GeoIP module to return a CNAME, that CNAME does not get resolved, even if it is within the instances authority. That forces the client/recursor to issue another request. Perusing the code for a while, I noticed that there is a rather simple way to achieve this: the GeoIP module, if the result is a CNAME, _could_ set `qdata->name` to the CNAME target and return `KNOT_IN_STATE_FOLLOW` instead of `KNOT_IN_STATE_HIT`. While that does seem to work, I am not so sure if it might constitute an abuse of interfaces. Returning `KNOT_IN_STATE_FOLLOW` seems legit, but I wasn't so sure about modifying `qdata` (specifically, in the context of a module). As such, I would be interested if this has ever come up before, what possible approaches might look like, what you think of the above one, and if tackling this problem is of interest at all. If I have a better understanding and there is a good approach to this, I'd be happy to submit a patch. Thanks a lot, Conrad

6 let, 1 měsíc

2
1
0 0

Running GEOIP and weighted DNS

by Avinash Amin

Hello, OS: CentOS 7.6 Knot: knot-2.9.3-1.el7.x86_64 I am trying to run knot DNS using maxmind GeoIP and it works well. Now I also want it to be able to do weighted on those answers. E.g. If country US, it will provide 3 answers and those will be weighted. Is that correct and possible? Thanks Avinash

6 let, 1 měsíc

2
1
0 0

About the signing performance

by gao

Dear KNOT team, We're now considering an update on our zone signer and KNOT DNS seems to be a good choice. I looked through your documentation and do not see the performace data about signing big zones. When the zone has about 10 millions entries , how long will it take for KNOT DNS to sign it completely? I'll appreciate it if you can give me a feedback. Best Regards! Gao

6 let, 2 měsíce

4
5
0 0

Knot DNS 2.9.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.3! See the changelog for more details. Please note that the official package repository for CentOS, Fedora, and openSUSE is newly https://copr.fedorainfracloud.org/coprs/g/cznic/knot-dns-latest/ The previous one https://build.opensuse.org/package/show/home:CZ-NIC:knot-dns-latest/knot will not be updated. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.3/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.3.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.3.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 3 měsíce

1
0
0 0

DNSSEC, failed to initialize (not enough memory)

by aeris

Hi, I try to use knot 2.9.2 on a Raspiberry Pi 2 with 1Gb of RAM under Arch Linux. When I enable DNSSec (ecdsap256sha256 algorithm), I got mars 01 16:09:05 exegol knotd[3438]: error: [aeris.eu.org.] DNSSEC, failed to initialize (not enough memory) mars 01 16:09:05 exegol knotd[3438]: error: [aeris.eu.org.] zone event 'load' failed (not enough memory) mars 01 16:09:05 exegol knotd[3438]: error: [xxx.eu.org.] DNSSEC, failed to initialize (not enough memory) mars 01 16:09:05 exegol knotd[3438]: error: [xxx.eu.org.] zone event 'load' failed (not enough memory) mars 01 16:09:05 exegol knotd[3438]: error: [imirhil.fr.] DNSSEC, failed to initialize (not enough memory) mars 01 16:09:05 exegol knotd[3438]: error: [imirhil.fr.] zone event 'load' failed (not enough memory) Those 3 zones are quite damned small (286, 19 & 16 lines), 2 containing only minimalistic entries (1 SOA, 2 NS, 3 CAA, 2 CNAME & 1 TLSA). I try to activate zones one at a time, loading the 16 lines zone is ok but loading the 19 lines one too generate the same "not enough memory" for both zones. Loading only the 19 lines zone is ok. I don't understand how DNSSec requires so many memory to not be able to load such small zones. When zones are loaded without DNSSec, knot memory is under 80MB. How I can trace the memory usage of Knot to understand why this behavior? Is there any way to restrict Knot memory to be able to load such zones? Regards, -- aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/

6 let, 3 měsíce

3
5
0 0

Knot RFC Compliance

by Thomas

Hi! Is there an overview about Knot's DNSSEC related RFC compliance or which RFCs have been implemented in Knot? Thanks, Thomas

6 let, 3 měsíce

3
2
0 0

reverse malformed data

by Bastien Durel

Hello, I have a problem with a new, small IPv6 reverse zone It's a small zone, configured like this : zone: - domain: "a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa." file: "a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa" notify: "corrin" acl: "acl_corrin" dnssec-signing: "off" module: mod-synthrecord/revovh2 There is data in the journal : root@arrakeen:/var/lib/knot/external# knotc zone-read a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 2560 SOA ns.geekwu.org. hostmaster.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 1580234956 16384 2048 1048576 2560 [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 259200 NS ns.geekwu.org. [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 259200 NS ns4.geekwu.org. [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 3600 PTR imperium.geekwu.org. [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] 2.2.1.0.0.0.0.0.0.0.0.0.1.0.0.0.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 3600 PTR git.geekwu.org. [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] a.2.a.2.0.0.0.0.0.0.0.0.1.0.0.0.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 3600 PTR corrin.geekwu.org. But if I change anything (like adding another host), on knotc reload I get this error : knotd[21892]: error: [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] zone event 'load' failed (malformed data) I've purged the zone with zone-purge, replaced the zone file with a copy of the dump, and got a new record on reload, but further edits fails the same way I'm using knot 2.9.2-1~cz.nic~buster1 for deb.knot-dns.cz/knot-latest Do you have an idea on what's going on ? Thanks, -- Bastien Durel

6 let, 4 měsíce

5
14
0 0

response rate limiting

by Thomas Krause

Hi all, I migrated from bind to knot. Everything works fine, except rrl. I "translated" the bind config rate-limit { responses-per-second 5; window 5; }; to mod-rrl: - id: default rate-limit: 5 slip: 2 # Every other response slips template: - id: default storage: "/etc/knot/zones" timer-db: "/var/lib/knot/timers" semantic-checks: on global-module: mod-rrl/default But the limiting doesn't work. I testet with for i in {1..20}; \ do dig @ns +short +tries=1 +time=1 mydomain.de a; \ done And got 20 answers quickly. Any ideas what's wrong here? (I'm unsing ver 2.7.6 @Debian 10) Best regards, Thomas.

6 let, 4 měsíce

2
1
0 0

fast keyrotation

by A. Schulze

Hello, I'm new to that list. Using NSD + DNSSEC + key rotation for many years. Now I like to check if and how KNOT's auto keyrotaton can safe me from my ugly script foo... https://lists.nic.cz/pipermail/knot-dns-users/2019-November/001721.html JP Mens mention "I'm rolling the KSK every five minutes for testing" instead I reinvent the wheel: could one post the relevant settings? Thanks, Andreas

6 let, 4 měsíce

4
4
0 0

No Usable Master

by Azzam S.A

After several successful attempts using the exact same configuration and steps mentioned in early question here <https://lists.nic.cz/pipermail/knot-dns-users/2020-January/001744.html> or here <https://gist.github.com/azzamsa/24dca2e201c3bea4f489a09f7a3a8716> (with better preview) I get stuck with no usable master The master side Jan 12 07:35:12 knot-master-1.novalocal knotd[12007]: info: [namadomain14.com.] zone file updated, serial 2018070410 Jan 12 07:35:12 knot-master-1.novalocal knotd[12007]: warning: [namadomain14.com.] notify, outgoing, remote slaveip@53, s...TAUTH' Jan 12 07:37:18 knot-master-1.novalocal knotd[12007]: info: [namadomain14.com.] control, received command 'zone-begin' Jan 12 07:37:32 knot-master-1.novalocal knotd[12007]: info: [namadomain14.com.] control, received command 'zone-set' Jan 12 07:37:37 knot-master-1.novalocal knotd[12007]: info: [namadomain14.com.] control, received command 'zone-commit' Jan 12 07:37:37 knot-master-1.novalocal knotd[12007]: info: [namadomain14.com.] zone file updated, serial 2018070410 -> 2018070412 Jan 12 07:37:37 knot-master-1.novalocal knotd[12007]: warning: [namadomain14.com.] notify, outgoing, remote slaveip@53, s...TAUTH' Jan 12 07:37:41 knot-master-1.novalocal knotd[12007]: info: control, received command 'zone-read' Jan 12 07:38:11 knot-master-1.novalocal knotd[12007]: info: [namadomain14.com.] control, received command 'zone-notify' Jan 12 07:38:11 knot-master-1.novalocal knotd[12007]: warning: [namadomain14.com.] notify, outgoing, remote slaveip@53, s...TAUTH' The slave side Jan 12 07:34:54 knot-slave-1 knotd: info: control, received command 'conf-read' Jan 12 07:35:19 knot-slave-1 systemd-logind: Removed session 2. Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-begin' Jan 12 07:35:20 knot-slave-1 knotd: notice: control, persistent configuration database not available Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-set' Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-set' Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-set' Jan 12 07:35:20 knot-slave-1 knotd: info: control, received command 'conf-commit' Jan 12 07:35:20 knot-slave-1 knotd: info: [namadomain14.com.] zone will be loaded Jan 12 07:35:20 knot-slave-1 knotd: info: [namadomain14.com.] failed to parse zone file (not exists) Jan 12 07:35:21 knot-slave-1 knotd: warning: [namadomain14.com.] refresh, remote master1 not usable Jan 12 07:35:21 knot-slave-1 knotd: error: [namadomain14.com.] refresh, failed (no usable master) Jan 12 07:35:23 knot-slave-1 knotd: warning: [namadomain14.com.] refresh, remote master1 not usable Jan 12 07:35:23 knot-slave-1 knotd: error: [namadomain14.com.] refresh, failed (no usable master) Jan 12 07:35:27 knot-slave-1 knotd: info: control, received command 'zone-read' Jan 12 07:35:29 knot-slave-1 knotd: info: control, received command 'zone-read' Jan 12 07:35:34 knot-slave-1 knotd: warning: [namadomain14.com.] refresh, remote master1 not usable Jan 12 07:35:34 knot-slave-1 knotd: error: [namadomain14.com.] refresh, failed (no usable master) Jan 12 07:36:31 knot-slave-1 knotd: warning: [namadomain14.com.] refresh, remote master1 not usable Jan 12 07:36:31 knot-slave-1 knotd: error: [namadomain14.com.] refresh, failed (no usable master) Jan 12 07:37:14 knot-slave-1 knotd: info: [namadomain14.com.] control, received command 'zone-begin' Jan 12 07:37:55 knot-slave-1 knotd: info: [namadomain14.com.] control, received command 'zone-abort' Jan 12 07:38:19 knot-slave-1 knotd: info: control, received command 'zone-read' Jan 12 07:39:12 knot-slave-1 knotd: warning: [namadomain14.com.] refresh, remote master1 not usable Jan 12 07:39:12 knot-slave-1 knotd: error: [namadomain14.com.] refresh, failed (no usable master) Problems Previously, even though I have ‘NO AUTH’ in master side. The zone in slave still crated, because I don’t get no usable master. But the sudden there is no usable master. I’ve tried: - sudo service knot restart - remove everything -> reinstall everything Both give me no luck. Thank you in advance.

6 let, 4 měsíce

1
1
0 0

Migrate Knot 1.6.5 to actual version (2.9.x)

by Josef Karliak

Good day, is there some tool to migrate configuration from 1.6.5 to actual version ? Keys, configuration, ... Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

6 let, 4 měsíce

2
1
0 0

Setting up slave zone (slave DNS server)

by Azzam S.A

Setting up slave zone (slave DNS server) I’ve asked the previous question Setting up slave zone (slave DNS server) <https://gitlab.labs.nic.cz/knot/knot-dns/issues/667>. And I’ve followed Libor Peltan’s advice to also configure the zone in the slave side. But It still didn’t work for me. Config knot.conf in *master* server # This is a sample of a minimal configuration file for Knot DNS. # See knot.conf(5) or refer to the server documentation. server: rundir: "/run/knot" user: knot:knot listen: [ 127.0.0.1@53, ::1@53 ] log: - target: syslog any: info database: storage: "/var/lib/knot" remote: - id: slave1 address: 111.11.11.111@53 acl: - id: slave1_acl address: 111.11.11.111 action: transfer template: - id: default storage: "/var/lib/knot" file: "%s.zone" zone: # # Master zone # - domain: example.com # notify: slave # acl: acl_slave # # Slave zone # - domain: example.net # master: master # acl: acl_master knot.conf in my *slave* server # This is a sample of a minimal configuration file for Knot DNS. # See knot.conf(5) or refer to the server documentation. server: rundir: "/run/knot" user: knot:knot listen: [ 127.0.0.1@53, ::1@53 ] log: - target: syslog any: info database: storage: "/var/lib/knot" remote: - id: master1 address: 222.22.22.222@53 acl: - id: master1_acl address: 222.22.22.2222 action: notify template: - id: default storage: "/var/lib/knot" file: "%s.zone" zone: # # Master zone # - domain: example.com # notify: slave # acl: acl_slave # # Slave zone # - domain: example.net # master: master # acl: acl_master conf-read result conf-read in *master* server [root@knot-master-1 centos]# knotc conf-read server.rundir = /run/knot server.user = knot:knot server.listen = 127.0.0.1@53 ::1@53 log.target = syslog log[syslog].any = info database.storage = /var/lib/knotacl.id = slave1_acl acl[slave1_acl].address = 222.22.22.222 acl[slave1_acl].action = transferremote.id = slave1 remote[slave1].address = 222.22.22.222(a)53template.id = default template[default].storage = /var/lib/knot template[default].file = %s.zone zone.domain = namadomain.com. zone[namadomain.com.].file = namadomain.com.zone zone[namadomain.com.].notify = slave1 zone[namadomain.com.].acl = slave1_acl conf-read in *slave* server [root@knot-slave-1 centos]# knotc conf-read server.rundir = /run/knot server.user = knot:knot server.listen = 127.0.0.1@53 ::1@53 log.target = syslog log[syslog].any = info database.storage = /var/lib/knotacl.id = master1_acl acl[master1_acl].address = 111.11.11.111 acl[master1_acl].action = notifyremote.id = master1 remote[master1].address = 111.11.11.111(a)53template.id = default template[default].storage = /var/lib/knot template[default].file = %s.zone zone.domain = namadomain.com. zone[namadomain.com.].master = master1 zone[namadomain.com.].acl = master1_acl Zone Read zone-read in *master* server [root@knot-master-1 centos]# knotc zone-read -- [namadomain.com.] namadomain.com. 86400 TXT "hello" [namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id. hostmaster.biz.net.id. 2018070411 3600 3600 604800 38400 zone-read in *slave* server [root@knot-slave-1 centos]# knotc zone-read -- [namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id. hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400 Steps I use to create a zone in *master* server knotc conf-begin knotc conf-set 'zone[namadomain.com]' knotc conf-set 'zone[namadomain.com].file' 'namadomain.com.zone' knotc conf-set 'zone[namadomain.com].notify' 'slave1' knotc conf-set 'zone[namadomain.com].acl' 'slave1_acl' knotc conf-commit knotc zone-begin namadomain.com knotc zone-set namadomain.com. @ 86400 SOA ns1.biz.net.id. hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400 knotc zone-set namadomain.com. @ 86400 TXT "hello" knotc zone-commit namadomain.com in *slave* server knotc conf-begin knotc conf-set 'zone[namadomain.com]' knotc conf-set 'zone[namadomain.com].master' 'master1' knotc conf-set 'zone[namadomain.com].acl' 'master1_acl' knotc conf-commit knotc zone-begin namadomain.com knotc zone-set namadomain.com. @ 86400 SOA ns1.biz.net.id. hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400 knotc zone-commit namadomain.com Problems If we look closely. I’ve crated the configuration of namadomain.com in *both* master and slave servers. Also I’ve created the SOA record of of namadomain.com in *both* master and slave servers. But I only create file config in *master* server and TXT record in *master* server (to test if AXFR zone transfer worked). Unfortunately, the file config and the TXT record is not created by slave, even though I’ve waited for more than hour (1 day actually). Am I missing something here? (I never put the zone directly in zone: section of knot.conf, I always use knotc since I will use libknot control.py to manage zones with our app <https://github.com/BiznetGIO/RESTKnot>) Also am I able to see if the knot in master emit the transfer ‘signal’ and check if knot in slave receive that signal? So It will make me easier to debug. I’ve tried to trigger knotc zone-notify namadomain.com in *master* side, and knotc zone-retransfer namadomain.com in *slave* side. But nothing changed. [root@knot-master-1 centos]# knotc zone-notify namadomain.com OK [root@knot-master-1 centos]# knotc zone-read -- [namadomain.com.] namadomain.com. 86400 TXT "hello" [namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id. hostmaster.biz.net.id. 2018070411 3600 3600 604800 38400 [root@knot-slave-1 centos]# knotc zone-retransfer namadomain.com OK [root@knot-slave-1 centos]# knotc zone-read -- [namadomain.com.] namadomain.com. 86400 SOA ns1.biz.net.id. hostmaster.biz.net.id. 2018070410 3600 3600 604800 38400 Machine # knotc --version knotc (Knot DNS), version 2.9.1 OS: CentOS 7.5 Thank you in advance.

6 let, 5 měsíců

2
1
0 0

Knot DNS 2.8.5 release

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.5! This version contains only some bugfixes backported from the 2.9 branch. Please note that the official package repository for CentOS, Fedora, and openSUSE is newly https://copr.fedorainfracloud.org/coprs/g/cznic/knot-dns/ . The previous one https://build.opensuse.org/package/show/home:CZ-NIC:knot-dns/knot will not be updated. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.5/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.5.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 5 měsíců

1
0
0 0

Issue encountered during a migration from FreeBSD to Gentoo

by Alarig Le Lay

Hi, Today I migrated my knot from FreeBSD to Gentoo (because it take too much time to stay on a supported release of FreeBSD) I rsynced my knot.conf (and changed the paths) and /var/db/knot to /var/lib/knot However, daemon failed to start because it wasn’t able to bind to /var/run/knot/knot.sock, and the permissions where good. I had to remove /var/db/knot and rsync only zones and keys. I don’t get the link from files in /var/lib and a denied permission on /var/run/knot/knot.sock, so I think that there is a bug here. Regards, -- Alarig

6 let, 5 měsíců

6
17
0 0

Knot DNS 2.9.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.2! This version fixes several 2.9-specific and some persistent bugs. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.2/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.2.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 5 měsíců

1
0
0 0

question

by ali jaberansari

Dear all, I have 2 servers and one of them I installed dnsblast. I read many time your DNS-benchmarking <https://gitlab.labs.nic.cz/knot/dns-benchmarking> project and get it from gitlab but I can't send packet more than 500K. please help. Best Regards.

6 let, 6 měsíců

1
0
0 0

automating DS submission and logging

by Jan-Piet Mens

Hello! after reading and rereading the documentation (release 2.9) section on automatic KSK management, and rereading it again, I finally understood the part which says "the user shall propagate [the DS] to the parent". In particular due to the log entry info: DS check, outgoing, remote 127.0.0.1@53, KSK submission attempt: negative and the phrasing of the "submission:" configuration stanza, I thought Knot would attempt to do so itself via dynamic update. I think I was injecting too much wishful thinking into the text. :) Now to my two questions: Is it envisioned to have Knot launch an executable in order to perform the submission? I'm thinking along the lines of Knot running at every `check-interval': ./ds-submitter zone "<cds>" "<cdnskey>" upon which the ds-submitter program could (e.g. via RFC2136) add DS RRset to the parent zone. Might be nice to have ... (I did see the bit about journald and using that to trigger DS submission, but using journald frightens me a bit.) I notice that a dynamic update on 2.9 logs info: [zone.] DDNS, processing 1 updates is there any way to get more details logged (what the update actually was)? My configuration contains: log: - target: syslog server: debug control: debug zone: debug any: debug Thank you. -JP

6 let, 6 měsíců

2
4
0 0

Knot DNS 2.9.1 release

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.1! This version primarily fixes some issues relating zone updates or compatibility with previous versions. It's recommended to update from 2.9.0. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.1/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 6 měsíců

1
0
0 0

KASP sharing

by Bastien Durel

Hello, Is KASP directory sharing possible between different knot instances ? (I have a "public" instance and a "private" one, with internal addresses, using different storage: directories, but the same kasp-db:) The internal one sometimes returns invalid DNSSEC data for non-existant names until I restart it. Is it to be expected in this setup ? Thanks, -- Bastien

6 let, 6 měsíců

2
1
0 0

slave strange behaviour

by Bastien Durel

Hello. I found another strange behaviour on my slave : it kept old RRSIG's for SOA entries. I fixed it by running zone-purge, then zone-retransfer ; <<>> DiG 9.11.5-P1-1~bpo9+1-Debian <<>> +dnssec @87.98.180.13 caa www.geekwu.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12546 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 19, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;www.geekwu.org. IN CAA ;; AUTHORITY SECTION: geekwu.org. 86400 IN SOA ns.geekwu.org. hostmaster.geekwu.org. 2019101730 3600 1200 2419200 10000 geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054714 20181104041714 54076 geekwu.org. 8b6lzlyI1fZUxwtCt9GHsRu1Ist1CtDFm+NifSTTESoMK3XAnW8gyZzp UIEmNiIRKdYnze+FsW+oEw4hm9pkW/lwgIls3tBvLKCwRseUwrj5jIbh rPK9fYuWM0RP1HBj geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054719 20181104041719 54076 geekwu.org. uoRZZ4jV2jaubsH7W3VIpIdu9iVKYnz9q+GpNHSnEDv4Mt5JcVnLChLk /eeRKSK9U7h8yFSOmxdcTBIyITlbGGBeeVbZFdQYsSshpN1Fa7YME9JU ttr5tISHoPnHlM2y geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054723 20181104041723 54076 geekwu.org. /2EY2DNqeX0GqK0eDcg3dFIqgH0346fP1XuIHM3oswRMnFMtCEDuD325 jpqByKlOkl4Edlv/GyJlJXohrdlWyTzE2xCM6ad2ordYHu0eCO8npfEi OOPc2HhtBYQUM+TU geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054727 20181104041727 54076 geekwu.org. OwfeorMdvR3Q4XvkSfNxruYJfcPRPIhsnDrrYk41L1gIYMRwEfapO/Te tza5M07CGx0rQPvFejXHRr7vzlatxvI9k9Vqrs12CR1q7ak+NVhxcM53 syCJVN/z8iKu5uYV geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054731 20181104041731 54076 geekwu.org. DpyZ6MCWuEA025ghGRJBISd0Lp7qXWb3R27+R/+FWnIytoLrIIzgRLI5 TEojx/k6hlbwFszH024T5CP5vQ1WXjIVyF9ZwNjseJ+skZgPx5ySzqrI R8WXgdpKYi4+SrYs geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054738 20181104041738 54076 geekwu.org. nNr2vNwLQSlDE7UXQWxGCiTTKb3wyx5VSzhoB8W8ovkSD9EHbcAr3QuP cR3ICASDhnWySB4NEB7i+qncT90+JEccuxvT8fBCoMHJtMy0YjNqsTLd tOOSitLogl4h8the geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054741 20181104041741 54076 geekwu.org. /28OcE9l7MXN9wKl2vpI5fxNpu6Ia1i4ku3V61Pix2JPKKJ4YhYG1BDw aBnpncgso71CiJyVz1Rsp1X50V6tGdibtP/ckRdqvl9f+W+KeCvcrcaS 8u4a5BjeqDFokrfY geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054743 20181104041743 54076 geekwu.org. GA4eFm1u4jxa+Jhu4vWa+UoucY7OES/8bKxkaIMte0AsC7bPovWdS8Qx 6zrrS9u1PEXS4dDy+PeCxPQFSefaPfiEY44J8JILTaf4OfiL+ij7RI2m MrN1e428veGFFfrY geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054746 20181104041746 54076 geekwu.org. MnF6nqK/UV+Q68Lf6mV80E4FcClEARc9gclqH4jP0gaxco/DpqGhWEgG yKM/E8ePIPOaUyRqdoiRKfWS2xcQExhqbeS+orcUjKx04BxDbp8rpCFG lRhR+QLEO4SpTrKo geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054749 20181104041749 54076 geekwu.org. MygQqAnclUn//WxI3gi04Fjkcim/7C4rusz0pj0RXOwl5yAQZMj5gFl7 v5WtUdxbysOhGiiJeHHpWWepD46E2DIlpAp/vKC8hw/DGNRSk6gT6cWl UqylhEIgKrekqVb4 geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181125063021 20181111050021 54076 geekwu.org. h1vHar/cdzpfTbVPhP6UW11aW6pB+1sfagKMBIPDif8mDjvLOP1KsTvI LuAUUNHaQgcYaoYwc9MrSQ+/se6CweK80B+O7pk+GFSWfqygyHhEvHZt YOHX183eKtYyjFix geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181125063028 20181111050028 54076 geekwu.org. hDTZuOOKCCWEYlWApA/g+RdSOKxfEGmttto8/BwUNYGBs/2dHziAIQlD y4SQh2ST1crUeHOTL7d8o+naqbt2lT7pMNqrUQy6XXYdVZ4gQ6aIjVkG Yi7kRgdG8Nksm31N geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181213181717 20181129164717 63974 geekwu.org. 6BspV1velFjzJQqmGejOSyV6A9NOg3n486/mAx4llB4d+S1KF3j7dzzX TmMalQN2QufP7NDCVaV4kmtoOgUwS/XcfAQeDJ/b5/bYNa1ERf/tV6bJ 3Z4by5PlXdqoPte5 geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190113191717 20181230174717 21289 geekwu.org. 2+WLMBHmrc2hygRoGtZbtgxikv6aHRv5xDg07nKldKKk/oR9l2GtjpUt yaMtgu+x/5Uk02eCwea+Vs41wq7BfzcZlL5SNqud9vFqCWAH3izikfLL mngKO3HHBvzxmqgy geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190213201717 20190130184717 63065 geekwu.org. 8xL2eX4atI6Z+CxwZaF4cwGmNKXY389Qsnz9qZZkXdGcnmzYct5UVBl1 LM0bR/e3D5ZCAhdFR8NynhUKPwCKaSgivjzKNmLunqDFUJgM/4fZFAP8 pXce50jpYXVMBmhm geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190316211717 20190302194717 19071 geekwu.org. FdHJKayUYfLsXu9ct9Mfvo1nVRei8xExluWbOfD9wbe/ZDqFQKyBvWKr hMrdUvSgCQ52iaTWl88cdPtho8YgGXRC+qse5rzqK+9toKbFryg/jFAX 18xJSYrntilYJm1u geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190416221717 20190402204717 14519 geekwu.org. kIBe1/zzEbX09gKk0R6MbAicxfoGjL1ojWvR/8oQBdld1yVtyMtLWKic NhkellgCaXIb7cluj/SAUQC2lr9tJxZp31oG+DhQBAG2arQAVtphxJ0p yUwD7klvUweJM49Y geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20191109090028 20191026073028 47945 geekwu.org. 9tmNQt48ZT3aTV/WkcfPpLQ3/3rpKXaDlasT9+EnRyniLrLuuHgQtRfw uxvJpillbGVn15uy9aoMDADV9K5DfdaNOgskK1v3QYgMpGtao+soydi/ Y9MyfDFUQNmSUIKD Therefore, let's encrypt checks failed when querying it with "detail": "DNS problem: SERVFAIL looking up CAA for arrakeen.geekwu.org" ; I guess their validating resolver did not picked the correct RRSIG, and failed to validate. If you want to investigate, I have another zone which have the same problem, and a bit more time before certificate expiration, for which I can provide details, journal, etc. Regards, -- Bastien Durel

6 let, 7 měsíců

2
2
0 0

no usable master

by Bastien Durel

Hello, I have a problem with a knot slave instance, which does not refresh anymore. When doing a retransfer, I have a "no usable master" error, with this error log: oct. 21 11:02:16 corrin knotd[32453]: info: [geekwu.org.] control, received command 'zone-retransfer' oct. 21 11:02:16 corrin knotd[32453]: 2019-10-21T11:02:16 info: [geekwu.org.] control, received command 'zone-retransfer' oct. 21 11:02:17 corrin knotd[32453]: info: [geekwu.org.] AXFR, incoming, remote 10.42.42.6@53, starting oct. 21 11:02:17 corrin knotd[32453]: 2019-10-21T11:02:17 info: [geekwu.org.] AXFR, incoming, remote 10.42.42.6@53, starting oct. 21 11:02:18 corrin knotd[32453]: debug: [geekwu.org.] refresh, remote master, address 10.42.42.6@53, failed (connection reset) oct. 21 11:02:18 corrin knotd[32453]: 2019-10-21T11:02:18 debug: [geekwu.org.] refresh, remote master, address 10.42.42.6@53, failed (connection reset) oct. 21 11:02:18 corrin knotd[32453]: 2019-10-21T11:02:18 warning: [geekwu.org.] refresh, remote master not usable oct. 21 11:02:18 corrin knotd[32453]: 2019-10-21T11:02:18 error: [geekwu.org.] refresh, failed (no usable master) oct. 21 11:02:18 corrin knotd[32453]: warning: [geekwu.org.] refresh, remote master not usable oct. 21 11:02:18 corrin knotd[32453]: error: [geekwu.org.] refresh, failed (no usable master) On master, I have this error log: oct. 21 11:02:16 arrakeen knotd[20289]: info: [geekwu.org.] AXFR, outgoing, remote 10.120.42.42@33435, started, serial 2019100808 oct. 21 11:02:16 arrakeen knotd[20289]: 2019-10-21T11:02:16 info: [geekwu.org.] AXFR, outgoing, remote 10.120.42.42@33435, started, serial 2019100808 oct. 21 11:02:16 arrakeen knotd[20289]: debug: TCP, send, address 10.120.42.42@33435 (connection timeout) oct. 21 11:02:16 arrakeen knotd[20289]: 2019-10-21T11:02:16 debug: TCP, send, address 10.120.42.42@33435 (connection timeout) tcpdump shows a TCP connection from 10.120.42.42 to 10.42.42.6, which is closed with a TCP FIN by 10.42.42.6 after 1.2s Do you have hints about that ? Thanks, -- Bastien Durel

6 let, 7 měsíců

2
3
0 0

[2.9] DDNS failure

by Bastien Durel

Hello, Since I upgraded to 2.9 (2.9.0-1~cz.nic~buster1), DDNS update fails: oct. 14 11:10:25 arrakeen knotd[15543]: info: [durel.org.] DDNS, processing 1 updates oct. 14 11:10:25 arrakeen knotd[15543]: error: [durel.org.] DNSSEC, failed to fix NSEC3 chain (invalid parameter) oct. 14 11:10:25 arrakeen knotd[15543]: 2019-10-14T11:10:25 error: [durel.org.] DNSSEC, failed to fix NSEC3 chain (invalid parameter) oct. 14 11:10:25 arrakeen knotd[15543]: 2019-10-14T11:10:25 error: [durel.org.] DDNS, processing failed (invalid parameter) oct. 14 11:10:25 arrakeen knotd[15543]: error: [durel.org.] DDNS, processing failed (invalid parameter) DDNS are generated with knsupdate: knsupdate -k /etc/letsencrypt.sh/hooks/tsig.key $file Is there a config change that can explain that ? Thanks, -- Bastien Durel

6 let, 7 měsíců

4
6
0 0

KSK automated rollover: New KSK generation

by Sakirnth (BFH)

Hello, I am using knot version 2.7 with automated keyrollover for DNSSEC. I am trying to understand the rollover process so that I can exactly predict when a rollover is in progress. So far I have understood this: KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)--> KSK (1) [ready] ---(submitted in parent zone)--> ---((KSK-TTL) - (DNSKEY TTL + propagation delay + DS parent TTL + x))-> KSK (2) [created and published] KSK (2) [ready] ---(submitted in parent zone)--> KSK (1) [retire-active], KSK (2) [active] ---(propagation delay + DNSKEY TTL)-> KSK (1) [removed] My observartions during the rollover: Knot configuration: DNSKEY-TTL: 12h Propagation-delay: 2h Zone TTL default: 1h KSK-lifetime: 3d ZSK lifetime: 0 Parent configuration: DS-TTL on parent: 1h KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)--> KSK (1) [ready] ---(submitted in parent zone)--> ---((3d) - (12h + 2h + 1h + x))-> KSK (2) [created and published] KSK (2) [ready] ---(submitted in parent zone)--> KSK (1) [retire-active], KSK (2) [active] ---(2h + 12h)-> KSK (1) [removed] The new key was created 19 hours before the KSK-lifetime ends. When I substract DNSKEY TTL, propagation delay and DS parent TTL its still 4 hours too early. Somebody knows why? References: https://www.knot-dns.cz/docs/2.7/html/reference.html https://tools.ietf.org/html/rfc6781.html#section-4.1.2 Thanks and Cheers, Sakirnth

6 let, 7 měsíců

2
1
0 0

Re: [knot-dns-users] 2.9.0 fails to start after upgrade

by Lukáš Kocourek

So problem is solved for me, I've tried to start with just one zone which didn’t helped, but removing journal did. Many thanks to Daniel Salzman for kind help, maybe he will post some other details after analyzing our journal records. -- Lukas Kocourek > On 2019-10-15, at 12:27, knot-dns-users-request(a)lists.nic.cz wrote: > > Message: 5 > Date: Tue, 15 Oct 2019 11:56:26 +0200 > From: Lukáš Kocourek <kocour(a)direcat.net> > To: knot-dns-users(a)lists.nic.cz > Subject: [knot-dns-users] 2.9.0 fails to start after upgrade > Message-ID: <110451DC-3CC1-419D-9066-EF784FDDAC00(a)direcat.net> > Content-Type: text/plain; charset=utf-8 > > Hi, > > I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start. > After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”. > > Here log from service start... > > Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf' > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53 > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53 > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones > > [cut] - info that all zones will be loaded > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded > [/cut] > > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server > Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating. > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing. > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL. > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'. > > Any advice what to do? > > Thank very much > > -- > Lukas Kocourek > > > > ------------------------------ > > Message: 6 > Date: Tue, 15 Oct 2019 12:27:34 +0200 > From: Daniel Salzman <daniel.salzman(a)nic.cz> > To: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] 2.9.0 fails to start after upgrade > Message-ID: <99813b76-c350-442f-35c7-2447cb07acce(a)nic.cz> > Content-Type: text/plain; charset=utf-8 > > Hi Lukáš, > > Could you try to temporarily disable some zones? We have no idea at the moment :-( > > Would it be possible to show me a snippet of your configuration? > > Daniel > > On 10/15/19 11:56 AM, Lukáš Kocourek wrote: >> Hi, >> >> I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start. >> After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”. >> >> Here log from service start... >> >> Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf' >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53 >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53 >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones >> >> [cut] - info that all zones will be loaded >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded >> [/cut] >> >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server >> Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating. >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing. >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL. >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'. >> >> Any advice what to do? >> >> Thank very much >> >> -- >> Lukas Kocourek >>

6 let, 7 měsíců

2
1
0 0

2.9.0 fails to start after upgrade

by Lukáš Kocourek

Hi, I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start. After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”. Here log from service start... Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf' Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53 Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53 Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones [cut] - info that all zones will be loaded Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded [/cut] Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating. Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing. Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL. Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'. Any advice what to do? Thank very much -- Lukas Kocourek

6 let, 7 měsíců

2
1
0 0

Knot DNS 2.9.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.0! This powerful version is full of new features, improvements, and code cleanups. Please, look at the changelog. Also note that today Knot DNS 2.7 reached its End-of-life and in the following days the official repositories will be upgraded to reflect currently supported versions (current stable -> 2.9.0, previous stable -> 2.8.4). Special thanks go to Christian Petrasch, Manuel Domke, and Jürgen Geinitz for their continuous testing! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.0/NEWS Benchmark: https://www.knot-dns.cz/benchmark/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.0.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 7 měsíců

2
1
0 0

Knot DNS 2.8.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.4! Besides various fixes and improvements, this version brings new DS push mechanism for automatic DS record uploading to parent zone during KSK rollover. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.4/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.4.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 8 měsíců

1
0
0 0

Quick Survey

by Daniel Salzman

Hello Knot DNS users, I would like to ask you if anybody uses request-edns-option configuration option? See https://www.knot-dns.cz/docs/2.8/singlehtml/index.html#request-edns-option for more info. Thank you, Daniel

6 let, 9 měsíců

1
0
0 0

Feature Request: expose knotc and keymgr API in a library

by Ray Hunter (v6ops)

Hi. Firstly, a big thank-you for knotd. I've been writing some code for automatic configuration of DNS delegations, including dnssec. It's been very straightforward with knot. The code is very clean, and the documentation extensive. Now my request: Your control programs seem to assume that the user is running knotc or keymgr and generating commands interactively or via a script. Would it be possible to expose all of the knotc and the keymgr API functions into a separate library, like libknotd-ctrl, plus a set of header files? At the moment I'm forking off external shell scripts from my program, and that works fine, but if I could call and link these control functions direct from my own code it would be great. It's probably possible already with some automake magic, but it's not easy for someone of my limited skills level. The code already exists, it'd just be some additional build steps AFAICS. -- regards, RayH <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campai…>

6 let, 9 měsíců

1
0
0 0

prometheus exporter

by Gert Doering

Hiya, trying to get our knot dns server (FreeBSD pkg, 2.8.1) to export prometheus statistics. I found https://github.com/ghedo/knot_exporter, which looks promising (and I found that knot-resolver has this all built in, but this doesn't help me :-/ ). So, I've installed the required python modules, and when I start the knot_exporter (with the right paths and everything) it complains to me: $ /tmp/knot_exporter --web-listen-port 4041 --knot-library-path ... Traceback (most recent call last): File "/tmp/knot_exporter", line 489, in <module> args.knot_socket_timeout, File "/usr/local/lib/python3.6/site-packages/prometheus_client/registry.py", line 24, in register names = self._get_names(collector) File "/usr/local/lib/python3.6/site-packages/prometheus_client/registry.py", line 64, in _get_names for metric in desc_func(): File "/tmp/knot_exporter", line 434, in collect for zone, zone_data in zone_stats["zone"].items(): KeyError: 'zone' so, I read the manual, and it says that this should be sufficient: template: - id: default storage: /usr/local/etc/dnsmgmt/data/CA/knot disable-any: true acl: [ acl_transfer, acl_notify ] global-module: mod-stats with or without mod-stats: - id: default request-protocol: on server-operation: on edns-presence: on flag-presence: on response-code: on reply-nodata: on query-type: on ... but it does not seem to make a difference. So - if one of you has a working knot-server knot.conf that exports data to prometheus, can you share it? thanks, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

6 let, 9 měsíců

3
4
0 0

Specify wildcard subdomain static hints

by Balakrishnan B

I am trying to add wildcard static hints to catch all local domains like below. But does not seem to work. hints['nextcloud.local'] = '127.0.0.1' # This works fine hints['*.local'] = '127.0.0.1' hints['.local'] = '127.0.0.1' DNSMasq supports this like https://stackoverflow.com/a/22551303 Is there way to do this in knot? Thanks, Bala

6 let, 10 měsíců

1
0
0 0

Knot DNS 2.8.3 and 2.7.8 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.3 and Knot DNS 2.7.8! The most important fix relates to excessive server load when maximum TCP clients limit is reached. It's also recommended to increase https://www.knot-dns.cz/docs/2.8/singlehtml/index.html#max-tcp-clients if TCP traffic is high. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.3/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.7.8/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.3.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.3.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.7.8.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.8.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html https://www.knot-dns.cz/docs/2.7/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 10 měsíců

1
0
0 0

Knot DNS 2.8.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.2! This version mainly fixes some Offline-KSK and geoip issues, and brings a few new features. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.2/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.2.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

6 let, 12 měsíců

1
0
0 0

Problems with serial when using knot as standalone DNSSEC signer

by Sebastian Wiesinger

Hi, we're using knot as a bump-in-the-wire DNSSEC Signer. The setup is as follows: BIND9(unsigned) -> AXFR -> knot(signing) -> AXFR -> BIND9(signed) The zone starts out with a low serial like 10 or 11. knot has a serial-policy: unixtime for the zones. Problem is, whenever an update is pushed the serial number is decreased again from unixtime back to the original serial which prevents the zone from propagating to the slaves. Example (test zone): template: - id: slave-dnssec-ecdsap256 storage: "/var/lib/knot/slave" file: "%s.zone" zonefile-load: difference dnssec-signing: on dnssec-policy: ecdsap256 master: ns1_signer notify: ns1 acl: acl_ns1 zone: - domain: xn--78jubwhb.xn--q9jyb4c template: slave-dnssec-ecdsap256 serial-policy: unixtime Here is an example where first a manual "zone-sign" is done to update the serial to current unixtime (12 -> 1559298292) and after that the zone is transferred in again which results in a serial decrease (1559298292 -> 13). [xn--78jubwhb.xn--q9jyb4c.] control, received command 'zone-sign' [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, dropping previous signatures, re-signing zone [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 49852, algorithm ECDSAP256SHA256, KSK, public, active [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 55142, algorithm ECDSAP256SHA256, public, active [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, signing started [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, successfully signed [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, next signing at 2019-06-07T12:24:52 [xn--78jubwhb.xn--q9jyb4c.] zone file updated, serial 12 -> 1559298292 [xn--78jubwhb.xn--q9jyb4c.] notify, outgoing, remote 176.9.75.248@53, serial 1559298292 [xn--78jubwhb.xn--q9jyb4c.] AXFR, outgoing, remote 176.9.75.248@60025, started, serial 1559298292 [xn--78jubwhb.xn--q9jyb4c.] AXFR, outgoing, remote 176.9.75.248@60025, finished, 0.00 seconds, 1 messages, 1819 bytes [xn--78jubwhb.xn--q9jyb4c.] notify, incoming, remote 176.9.75.248@9104, received, serial 13 [xn--78jubwhb.xn--q9jyb4c.] refresh, remote 176.9.75.248@53, remote serial 13, zone is outdated [xn--78jubwhb.xn--q9jyb4c.] IXFR, incoming, remote 176.9.75.248@53, receiving AXFR-style IXFR [xn--78jubwhb.xn--q9jyb4c.] AXFR, incoming, remote 176.9.75.248@53, starting [xn--78jubwhb.xn--q9jyb4c.] AXFR, incoming, remote 176.9.75.248@53, finished, 0.00 seconds, 1 messages, 321 bytes [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 49852, algorithm ECDSAP256SHA256, KSK, public, active [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 55142, algorithm ECDSAP256SHA256, public, active [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, signing started [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, successfully signed [xn--78jubwhb.xn--q9jyb4c.] DNSSEC, next signing at 2019-06-07T12:25:21 [xn--78jubwhb.xn--q9jyb4c.] refresh, remote 176.9.75.248@53, zone updated, 0.10 seconds, serial 12 -> 13 [xn--78jubwhb.xn--q9jyb4c.] zone file updated, serial 1559298292 -> 13 [xn--78jubwhb.xn--q9jyb4c.] notify, outgoing, remote 176.9.75.248@53, serial 13 How to prevent this? We want knot to always use the current unixtime for the zone. Best Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

7 let

2
1
0 0

Knot není dostupný na UDP

by Ondřej Budín

Dobrý den, zkouším rozjet Knot DNS, ovšem narazil jsem na problém - knotd mi neposlouchá na UDP portu. Upozornil mě na to nástroj http://dnsviz.net. Poradí mi někdo prosím, co by mohlo být špatně a jak z toho ven? Mám podezření na modul *noudp*, ovšem marně se snažím dohledat nějaké podrobnější informace, popisující jak vůbec moduly fungují a jak se s nimi pracuje. Knot jsem instaloval z repositáře https://deb.knot-dns.cz/knot-latest. knotd (Knot DNS), version 2.8.1; Debian 9 Děkuji. -- S pozdravem Ondřej Budín

7 let

2
1
0 0

Unexpect results with geoip subnet mode

by Conrad Hoffmann

Hi there, while trying to understand the algorithm employed in the `find_best_view` function in the geoip module, I started wondering whether this line is in there intentionally: https://gitlab.labs.nic.cz/knot/knot-dns/blob/4015475b0d3e11c0bd6fcac8aceb6… I am still trying to understand how this works with the actual geo data, but here is a test case using the subnet mode that yields slightly surprising results: Using a geoip config like this for zone example.com: bar.example.com: - net: 127.0.0.0/8 A: 9.9.9.9 - net: 192.0.0.0/8 A: 1.1.1.1 - net: 192.168.0.0/16 A: 4.4.4.4 - net: 192.168.1.0/24 A: 8.8.8.8 If I query bar.example.com from 192.168.1.X, I get 4.4.4.4, which is suprising because it is neither the most nor the least specific item. The binary search returns the most specific one (8.8.8.8), which is sort of what I would expect. However, above line immediately takes the `prev` item without checking for `view_strictly_in_view`. Without the above line, the whole function returns the most specific item, as I would expect. Please note that this is mostly an intuition atm, as I have not yet had the time to set up a similar test case for real geo data (which uses the same algorithm). But I figured that someone more familiar with the code might have enough context to tell whether this is correct or not or what a suitable fix might look like. Thanks a bunch, Conrad

7 let

2
2
0 0

Open Build Service package repositories update

by Tomas Krizek

Hi, I have a quick update about the upstream package repositories in Open Build Service (OBS) for Knot DNS. New repositories ---------------- - CentOS_7_EPEL - aarch64 - Fedora_30 - x86_64, armv7l, aarch64 - xUbuntu_19.04 - x86_64 - Debian_Next - x86_64 (Debian unstable rolling release) New repositories for Debian 10 and CentOS 8 should be available shortly after these distros are released, depending on their buildroot availability in OBS. Deprecated repositories ----------------------- - Arch - x86_64 Due to many issues with Arch packaging in OBS (invalid package size, incorrect signatures) and the fast pace of Arch updates, please consider this repository deprecated in favor of the knot package in Arch Community repo [1]. The Arch OBS repository will most likely be removed in the future. Also, please note I'll be periodically deleting repositories for distros that reach their official end of life. In the coming months, this concerns Ubuntu 18.10 and Fedora 28. [1] - https://www.archlinux.org/packages/community/x86_64/knot/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let

1
0
0 0

knsupdate refused after some time

by Bjoern Franke

Hi, I'm using a script to dynamically update an IPv4. After some time, the update gets refused. Script: KNOT_SERVER='194.59.205.151' KNOT_KEY='hmac-sha256:dyndns:somerandomkey' croot='schafweide.org' domain='home.schafweide.org' knsupdate -y "${KNOT_KEY}" <<EOF server ${KNOT_SERVER} zone ${croot}. update delete $domain 60 A update add $domain 60 A $1 send quit EOF Error message: ;; ->>HEADER<<- opcode: UPDATE; status: REFUSED; id: 61622 ;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1 ;;schafweide.org. IN SOA dyndns. 0 ANY TSIG hmac-sha256. 1556969992 300 32 21LTowPMGditU419LSHez6CRtRblLLZZcxtu89RCocI= 61622 NOERROR 0 ;; ERROR: update failed with error 'REFUSED' After "systemctl restart knot" the update just runs fine. I'm wondering what's wrong there. Regards Bjoern

7 let

2
2
0 0

Packages for Debian Jessie

by Danilo

Hello Knot team I have just noticed that there are no more Debian packages for Debian 8 (Jessie) at https://deb.knot-dns.cz/knot/dists/. Debian 8 is in LTS until June 30, 2020 (see https://wiki.debian.org/LTS). Is the dropping of packages for Jessie intended or not? (I plan to migrate this summer, but for now it would be good to still get security fixes for Knot.) Might be related to the PGP revocation? Danilo

7 let, 1 měsíc

2
3
0 0

(no subject)

by JCA

I have to integrate Knot in framework which will be testing for the presence of a running instance of the Knot daemon by means of 'knotc status'. This works fine, once knotd has loaded all the zones. However, when launching it there will be a window of opportunity during which 'knotc status' will fail, despite the fact that knotd is already running, but still loading its zones. Two questions: 1. Is this a correct description, or am I missing something here? 2. If it is right, is there a way, with the concourse of KNOT tools, to find out whether knotd is already running or still loading zones? I guess that, if it is a matter of just verifying that knotd is running, using the 'ps' command would be simpler. I wonder, however, whether it can be done with KNOT tools alone.

7 let, 1 měsíc

2
2
0 0

Knot DNS 2.7.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.7! This version backports some relevant fixes and improvements from 2.8.1. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.7.7/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.7.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.7.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

7 let, 1 měsíc

1
0
0 0

Weighted records

by Conrad Hoffmann

Hi there! At work, we make use something often referred to as "weighted records", a feature offered by many managed DNS vendors. We use it to implement e.g. a canary environment, where we test changes on a small portion of production traffic. I played around with knot-dns for a bit (quite impressed), and figured it might be nice to implement such a feature for it. Turns out, the code is so amazing that if you abuse the infrastructure of the geoip module, it only takes an hour (very impressed). If you are interested in trying it, read on further below, but just to state my intention: I was wondering if such a feature would be of interest at all? I realize the geoip module may not be the appropriate for such an implementation, consider this merely a demo of sorts. So here goes nothing: 1. apply attached patch 2. config file snippet: mod-geoip: - id: test config-file: /etc/knot/test.conf ttl: 600 mode: weighted zone: - domain: example.com. file: "/var/lib/knot/example.com.zone" module: mod-geoip/test 3. /etc/knot/test.conf: lb.example.com: - weight: 10 CNAME: www1.example.com. - weight: 5 CNAME: www2.example.com. Results in this: conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig @192.168.1.242 A lb.example.com +short; done | sort | uniq -c 68 www1.example.com. 32 www2.example.com. conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig @192.168.1.242 A lb.example.com +short; done | sort | uniq -c 72 www1.example.com. 28 www2.example.com. conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig @192.168.1.242 A lb.example.com +short; done | sort | uniq -c 66 www1.example.com. 34 www2.example.com. You get the idea. Anyways, any thoughts and feedback would be greatly appreciated. Thanks a lot, Conrad

7 let, 1 měsíc

2
5
0 0

Zone breaks after update to 2.8.0

by Simon Fehlmann

Hi @all I was trying to migrate knot to a new server with Ubuntu 18.04 and knot 2.8.0. I managed this by just copying the content of /var/lib/knot/* from the old to the new server. One of my domains threw an error when starting knot: knotd[5186]: error: [<zone>] zone event 'load' failed (malformed data) keymgr throws the same error. I dumped the data out of the 2.7.6 installation with mdb_dump and imported it into the 2.8.0 installation, which did not help. I then uninstalled 2.8.0 on the new server and installed 2.7.6, migrated data from the old server with the same procedure and it worked, no errors. Just out of curiosity I upgraded then the new server from 2.7.6 to 2.8.0 to see what will happen: It was the exact same behaviour, the zone couldn't load. How can I proceed here? There is obviously something wrong that the update breaks the loading of the zone. Is this on my end or a bug in knot? Thanks Simon

7 let, 1 měsíc

4
6
0 0

Knot DNS 2.8.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.1! This version fixes various DNSSEC-related issues. It's recommended to update from 2.8.0. Special thanks go to Niels Haarbo and Tuomo Soini for their help with debugging! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.1/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

7 let, 1 měsíc

1
0
0 0

Knot-DNS unused cores

by Sergey Petrov

I perfoms benchmarks with knot-dns as a authoritative server and dnsperf as a workload client. Knot server has 32 cores. Interrupts from 10Gb network card are spreaded across all 32 cores. Knot configured with 64 udp-workers. Each knot thread assigned to one core. So there are at least two knot threads assigned to one core. Then i start dnsperf with command ./dnsperf -s 10.0.0.4 -d out -n 20 -c 103 -T 64 -t 500 -S 1 -q 1000 -D htop on knot server shows 3-4 cores completly unused. Then i restart dnsperf unused cores are changes. That is the reason for unused core?

7 let, 1 měsíc

3
10
0 0

knot UDP or TCP perfermance

by Champion Xie

When we try to use the root zone file to load to verify the UDP or TCP perfermance of knot the result TCP performance is greater than UDP performance -- Best Regards!! champion_xie

7 let, 1 měsíc

2
1
0 0

DNSSEC re-sign failed (invalid parameter)

by Thomas E.

Hi! We've been experimenting with backups and disaster recovery in our knot test setup and have been running into a weird issue. Basically our backup strategy right now is to perform incremental backups of the /var/lib/knot and the /etc/knot directories via rsync. When we try to restore these backups knot starts successfully, but logs the following messages for each of the zones that are currently in a signed template: 2019-03-08T11:43:05 info: [example.com.] DNSSEC, signing zone 2019-03-08T11:43:05 error: [example.com.] zone event 'DNSSEC re-sign' failed (invalid parameter) When we try to query information about these zones via dig we receive a SERVFAIL rcode for them. All of the zones that are not processed through the DNSSEC mechanism are unaffected by this. We also experienced th same behavior, when we were experimenting with adding new zones that are signed immediately. To workaround this problem we currently add the zone in an unsigned state (aka default template) to knot and after that we switch the template of the zone to "signed". This works like a charm for new zones and can also be used to recover each of the broken zones after restoring the backup, but we'd rather not use this workaround during disaster recovery as it would impose the danger of breaking the zones if it is not performed correctly. The templates and policies in our knot.conf look like this right now: policy: - id: shared algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 zsk-lifetime: 1d ksk-lifetime: 2d ksk-shared: true ksk-submission: resolver nsec3: true cds-cdnskey-publish: always template: - id: default storage: "/var/lib/knot" semantic-checks: on global-module: mod-stats master: primary notify: secondaries acl: [primary, secondaries] serial-policy: unixtime dnssec-signing: off - id: signed dnssec-signing: on dnssec-policy: shared master: primary notify: secondaries acl: [primary, secondaries] serial-policy: unixtime zone: - domain: example.com template: signed Thanks, Thomas

7 let, 2 měsíce

3
2
0 0

KSK Rollover - Lab Policy For Testing

by Thomas

Hi, we are testing knot at the moment and are struggling with the concept of automatic KSK rollovers. We are planning to fetch the current CDS for further automatic processing and try to figure out how to achieve a policy that performs KSK rollovers in a short period of time for testing purposes. Until now we have not seen any KSK rollovers and we are not sure why this is not happening. Can someone show me an example of a policy that schedules a KSK rollover within a very short period, let's say once a day? What policy parameters must be set? And what must be the zone's parameters in terms of TTL and SOA values (expire, refresh, etc)? Thanks a lot, Thomas

7 let, 2 měsíce

6
17
0 0

running knot-resolver with only kresd-tls.socket

by Daniel Lublin

Ahoj, I'm tinkering with running knot-resolver for DNS-over-TLS (only). My kresd@1 is listening on the public interface by using a drop-in override file, following kresd.systemd(7) (kresd-tls.socket.d/override.conf). Thing is, I would like knot to not listen on port 53 on any interface, not even localhost. But this is precisely what it does. I naively tried to stop it from doing so, first with a kresd.socket.d/override.conf with: [Socket] ListenStream= But that failed with journalctl -u kresd.socket containing `kresd.socket: Unit has no Listen setting (ListenStream=, ListenDatagram=, ListenFIFO=, ...). Refusing.` And also by trying to disable that "socket-unit", with a kresd(a)1.service.d/override.conf containing: [Service] Sockets= Sockets=kresd-tls.socket Sockets=kresd-control(a)%i.socket But that did nothing. Finally, using `systemctl mask kresd.socket` I get it to stop listening on (localhost) port 53. But then instead systemd find itself in "degraded" mode... Any tip on how to accomplish this cleanly?

7 let, 2 měsíce

2
1
0 0

Security changes in our Debian repositories

by Vladimír Čunát

Hello Knot DNS users. Our deb package signing key may have been compromised and has been revoked. Open Build Service repositories are not affected. The affected systems (https://deb.knot-dns.cz/knot-latest and https://deb.knot-dns.cz/knot) now contain a new Debian repository. The packages were re-built and re-signed with a new GPG key rsa4096/0x8A0EFB02C84B1E9B. We thank to security researcher calling himself "p3n73st3r" who notified us earlier today. Regards Your Knot DNS team

7 let, 2 měsíce

2
2
0 0

Knot DNS 2.8.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.8.0! This version is full of new features and improvements. Please, look at the changelog. Also note that today Knot DNS 2.6 reached its End-of-life and in the following days the official repositories will be upgraded to reflect currently supported versions (current stable -> 2.8.0, previous stable -> 2.7.6). Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.8.0/NEWS Benchmark: https://www.knot-dns.cz/benchmark/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.8.0.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.8.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.8/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

7 let, 2 měsíce

3
4
0 0

konvert Knot DNS sigantures certs to BIND format.

by Milan Jeskynka Kazatel

Hello community, can I somehow convert stored certificates for a signed zone to BIND format? My use case is to change used topology for authoritative servers. I´m manage existing zones in Knot, now I would like to transfer it to BIND and use existing certificates for signing it on BIND due to DS records in parent zones. The knot will be reconfigured as a slave. Is it possible to achieve it? Thanks. -- Smil Milan Jeskyňka Kazatel

7 let, 2 měsíce

3
4
0 0

why is kdig different to dig?

by Arsen STASIC

Hi, I'm not sure if it was already discussed on this list. Why is BIND's dig getting a AD flag and kdig not? Obviously sends dig the AD flag by default, but why have you decided this way? dig +noall +comments @dotns1.aco.net univie.ac.at soa +qr ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52963 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d2171ad4016ceb3d ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52963 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 kdig +noall +header @dotns1.aco.net univie.ac.at soa +qr ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 25583 ;; Flags: rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 25583 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 cheers, -arsen

7 let, 3 měsíce

5
7
0 0

Re: [knot-dns-users] knot have chroot or setuid features?

by Daniel Salzman

Hi, Knot DNS doesn't call chroot. As for setuid, look at the source https://gitlab.labs.nic.cz/knot/knot-dns/blob/master/src/knot/common/proces… Another interesting feature is https://gitlab.labs.nic.cz/knot/knot-dns/merge_requests/864 Daniel On 2/21/19 9:50 AM, Champion Xie wrote: > > > -- > Best Regards!! > champion_xie

7 let, 3 měsíce

1
0
0 0

DNSSEC On-slave signing

by Milan Jeskynka Kazatel

Hello, community, could someone more describe the On-slave signing on both sides - slave and master in the case where the master server runs on bind and slave is Knot DNS? I would like to achieve signing for "hidden master" configuration. I found in Knot DNS documentation: *** It is possible to enable automatic DNSSEC zone signing even on a slave server. If enabled, the zone is signed after every AXFR/IXFR transfer from master, so that the slave always serves a signed up-to-date version of the zone. It is strongly recommended to block any outside access to the master server, so that only the slave’s signed version of the zone is served. Enabled on-slave signing introduces events when the slave zone changes while the master zone remains unchanged, such as a key rollover or refreshing of RRSIG records, which cause inequality of zone SOA serial between master and slave. The slave server handles this by saving the master’s SOA serial in a special variable inside KASP DB and appropriately modifiying AXFR/IXFR queries/answers to keep the communication with master consistent while applying the changes with a different serial. It is recommended to use UNIX time serial policy on master and incremental serial policy on slave so that their SOA serials are equal most of the time. *** Thanks for any advice. Regards, kaza

7 let, 3 měsíce

3
4
0 0

Migration from djbdns/tinydns to knot-dns.cz

by Frank Matthieß

Hello all, we want to migrate to a state of the art nameserver software. Our startingpoint is djbdns/tinydns. Our first step should be to to use zone transfer from tinydns to knot-dns (2.7.6). I configure the knot-dns a slave: # knotc conf-read … acl.id = master acl[master].address = 5.28.40.220 acl[master].action = notify remote.id = master remote[master].address = 5.28.40.220 … zone.domain = vtnx.net. zone[vtnx.net.].master = master zone[vtnx.net.].acl = master and add a initial soa rr for that domain: vtnx.net. 0 SOA ns1.vtnx.net. hostmaster.vtnx.net. 1 16384 2048 1048576 2560 This the exact soa of the running vtnx.net domain, but a diffrent serial. After triggering the notification from the master, i got this logging: Jan 24 07:53:19 ns1-neu knotd[26299]: info: [vtnx.net.] notify, incoming, 5.28.40.220@38668: received, serial none Jan 24 07:53:19 ns1-neu knotd[26299]: info: [vtnx.net.] refresh, outgoing, 5.28.40.220@53: remote serial 1548307450, zone is outdated Jan 24 07:53:19 ns1-neu knotd[26299]: warning: [vtnx.net.] IXFR, incoming, 5.28.40.220@53: malformed response SOA Jan 24 07:53:19 ns1-neu knotd[26299]: warning: [vtnx.net.] refresh, remote master not usable Jan 24 07:53:19 ns1-neu knotd[26299]: error: [vtnx.net.] refresh, failed (no usable master) What about "malformed response SOA"? Why is this an IXFR and no AXFR? - Frank -- Frank Matthieß Mail: frank.matthiess(a)virtion.de GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1 virtion GmbH Stapenhorster Straße 42b, DE 33615 Bielefeld Geschäftsführer: Michael Kutzner Handelsregister HRB 40374, Amtsgericht Bielefeld, USt-IdNr.: DE278312983

7 let, 4 měsíce

2
3
0 0

Knot DNS 2.7.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.6! This version mainly fixes a very old bug relating pending zone events upon server reload or configuration commit. If you don't use zone journal, please check if it exists and possibly drop it. It can be a consequence of a small regression introduced in the previous version. I'm sorry for that! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.6 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.6.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let, 4 měsíce

1
0
0 0

zonefile-load: difference

by Volker Janzen

Hi, I want to use Ansible to deploy zone files to my Knot signer (hidden master). The zone files should be generated from the Ansible playbook data and will not contain any DNSSEC related information, just SOA, NS, A, AAAA, TXT and MX records. I'd like to use Knot DNSSEC auto-signing. I can stop the Knot process before deploying new zone files. I use zonefile-load: difference in this case, as of the DNSKEY / CDNSKEY / CDS data should not be replaced with something new. Should this work for me, or is there anything I miss or is there even a better option? Kind regards, Volker

7 let, 4 měsíce

2
1
0 0

Knot DNS 2.7.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.5! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.5 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.5.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let, 4 měsíce

2
1
0 0

knot group in a FreeBSD jail -- Permission Denied to Knotc and Python API

by Rick van Rein

Hi, I'm working on a registry for +31 ENUM, using Knot DNS 2.6.8. The intention is to trigger the Python API from PostgreSQL database views. The postgres user, though added to the knot group and granted rw- on all of /var/db/knot/* and the knotd socket, cannot do thinkgs like conf-read through the Python API or knotc. This is where root and the postgres user diverge: 84630 knotc CALL open(0x7fffffffe100,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>) 84630 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)" 84630 knotc RET open 6 84630 knotc CALL fstat(0x6,0x7fffffffe068) 84630 knotc STRU struct stat {dev=4261341516, ino=125942, mode=0100660, nlink=1, uid=0, gid=0, rdev=4294967295, atime=1545172776.416579000, mtime=1545182138.348328000, ctime=1545182138.348328000, birthtime=1545172776.416478000, size=16, blksize=4096, blocks=2, flags=0x800 } That's root. uid=0 and gid=0 for the /tmp/SENDMDB... file. But now: 84649 knotc CALL open(0x7fffffffe0f0,0x100022<O_RDWR|O_EXLOCK|O_CLOEXEC>) 84649 knotc NAMI "/tmp/SEMDMDBrXFzK!_#un)" 84649 knotc RET open -1 errno 13 Permission denied That's user postgres, even though it is in the knot group. It seems to see the file but have no access, probably due to uid=0, gid=0. Note that matching name. --> What is this file it is trying to open, and is it always mapped to uid=0,gid=0, even if the user running "knotc conf-read" is not root? Could this be a FreeBSD things, or a jail thing? Any advise is welcome! Thanks! -Rick

7 let, 4 měsíce

2
1
0 0

Re: [knot-dns-users] knot group in a FreeBSD jail -- Permission Denied to Knotc and Python API

by Daniel Salzman

I don't think the Makefile is wrong. If you call knotc with an explicit control socket specification, no configuration file is loaded because it's not needed. So there is an issue with the configuration access. But I don't understand why knotd is not affected? You could also test using configuration database. Daniel On 12/21/18 2:44 PM, Rick van Rein wrote: > Hi Daniel, > >> I guess it relates to a temporary confdb, which is created for storing configuration loaded from >> a config file and removed upon. Could you try calling knotc with explicit socket parameter (knotc -s ...)? > > Yes, that solved it. > > The default socket path is @run_dir@/knot.sock, and the ports tree > configures --with-rundir=/var/run/knot but, according to > https://github.com/freebsd/freebsd-ports/blob/master/dns/knot2/Makefile#L32… > it is under defined variables. I will ask Leo if this might need > correction. > > Thanks! > -Rick >

7 let, 5 měsíců

1
0
0 0

Question on KSK rollover

by Volker Janzen

Hi all, one of my zones made a ZSK rollover yesterday. I had an some recursive resolvers validation errors at different times. This is the log output from knot of the rollover: Dec 6 17:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, ZSK rollover started Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public, active Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T18:16:49 Dec 6 17:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1543943808 -> 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@45727: started, serial 1543943808 -> 1544113009 Dec 6 17:16:50 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@45727: finished, 0.00 seconds, 1 messages, 1329 bytes Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public, active Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T19:16:49 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1544113009 -> 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@53131: started, serial 1544113009 -> 1544116609 Dec 6 18:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@53131: finished, 0.00 seconds, 1 messages, 43889 bytes Dec 6 18:16:50 a knotd[9924]: info: [voja.de.] AXFR, outgoing, 10.10.10.10@59417: started, serial 1544116609 Dec 6 18:16:50 a knotd[9924]: info: [voja.de.] AXFR, outgoing, 10.10.10.10@59417: finished, 0.00 seconds, 1 messages, 28054 bytes Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 15820, algorithm RSASHA256, public, active Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-07T15:16:48 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] zone file updated, serial 1544116609 -> 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] notify, outgoing, 10.10.10.10@53: serial 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@55161: started, serial 1544116609 -> 1544120209 Dec 6 19:16:49 a knotd[9924]: info: [voja.de.] IXFR, outgoing, 10.10.10.10@55161: finished, 0.00 seconds, 1 messages, 1329 bytes 10.10.10.10 is the (anonymized) IP of the distribution server, which is a Bind server. The actual authorative nameservers get the zone from Bind with IFXR or AXFR. AXFR is used for distribution to a anycast nameserver pair. When looking at the ZSK rollover timing, I notice that after two hours Knot stopped signing with the old ZSK. Does this make sense? The last event before the rollover has been this resining: Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing zone Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 53800, algorithm RSASHA256, KSK, public, ready, active Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, key, tag 38188, algorithm RSASHA256, public, active Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, signing started Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, successfully signed Dec 4 18:16:48 a knotd[9924]: info: [voja.de.] DNSSEC, next signing at 2018-12-06T17:16:48 Is it possible that this is an issue with a propagation-delay that is too low (default value applies). Regards Volker

7 let, 5 měsíců

2
3
0 0

Re: [knot-dns-users] Key sizes with ECDSA

by Full Name

OK, thanks. Just making sure I was not missing something obvious. -----Original Message----- From: "libor.peltan" [libor.peltan(a)nic.cz] Date: 11/29/2018 04:33 AM To: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Key sizes with ECDSA Hi Full Name, indeed, this is not possible. The ECC and EDD algorithm families always stick to one key size for any algorithm. You can't have your KSK and ZSK with different algorithms. On the other hand, this is no big deal. Those algorithms are considered safe enough even with small keys, so you can choose just e.g. ECDSA256 and profit from having small signatures. You can also think of using single-type signing scheme. BR, Libor Dne 28.11.18 v 22:58 Full Name napsal(a): > A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct? -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

7 let, 6 měsíců

1
0
0 0

Key sizes with ECDSA

by Full Name

A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct?

7 let, 6 měsíců

2
1
0 0

Re: [knot-dns-users] Problem to import key material of softhsm into knot

by mark.karpilovskij＠nic.cz

Hi Christian, I am glad to hear that. Let us know if you have any other issues. Best regards, Mark On 2018-11-27 14:04, Christian Petrasch wrote: > Hello Mark, > > I was able to sign with Knot and SoftHSM. I switched to an actual > version of gnutls and recompiled Knot. > > Thank you very much for your good support > > best regards > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Datum: 26.11.2018 16:22 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > also, did you build Knot manually or did you use a package? What is > your current GnuTLS version? It should be at least 3.4.6 for the HSM > to work, at least according to our documentation. > > BR, > > Mark > > On 26. 11. 18 16:09, Mark Karpilovskij wrote: > > Hi Christian, > > I have verified that it is indeed necessary for Knot to use full > length key IDs with PKCS #11, so make sure you do that. Other than > that, I am quite puzzled by the "FAILED TO INITIALIZE KASP (NOT > IMPLEMENTED)" error that you are getting and so far I have been unable > to reproduce it. I will spend some more time on it. Which version of > CentOS are you using? Meanwhile, see if both setting correct policy > configuration and using full length key IDs will help you. > > Best regards, > > Mark > > On 26. 11. 18 12:31, Christian Petrasch wrote: > Hi Mark, > > thanks a lot for you help.. > > I added the keystore to my config.. but I_m getting another error > now.. > > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > > # KSK > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > # ZSK > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > keystore: a1b1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > zone: > - domain: example.com > dnssec-signing: on > dnssec-policy: manual > zonefile-load: difference > file: example.com.zone > storage: /etc/knot/ > > log: > - target: syslog > any: debug > > ### > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1b1 algorithm=RSASHA256 size=2048 ksk=no > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Failed to initialize KASP (not implemented) > > I tried with the -d parameter as well.. but i got: > > keymgr -d /var/lib/knot/keys/ example.com. import-pkcs11 a1b1 > algorithm=RSASHA256 size=2048 ksk=no created=20181126090000 > publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > I read from former knot versions about the "keymgr init" command, but > it is not implemented anymore.. > > Do you have another idea whats going wrong.. ? > > Thanks a lot for your great help :) > > best regards > > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Kopie: knot-dns-users(a)lists.nic.cz > Datum: 26.11.2018 11:56 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > I have checked out your Knot configuration, and I suspect that the > issue might be a missing keystore option in the policy section of your > configuration. Try specifying the ID of the PKCS11 keystore in the > policy section as follows: > > keystore: > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > KEYSTORE: A1A1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > Let us know if this helps. > > Best regards, > > Mark > > On 26. 11. 18 9:49, Christian Petrasch wrote: > Hi @ all, > > we are testing with softhsm 2.5 and KNOT 2.7.4... > > I try to import the keys inside softhsm into keymgr to sign with this > a example zone. > > The keymaterial is shown via pkcs11-tool: > > [root@centos-test2 ~]# pkcs11-tool --login --list-objects --module > /usr/local/lib/softhsm/libsofthsm2.so > > Using slot 0 with a present token (0x285d1c08) > Logging in to "testKSK_1". > Please enter User PIN: > Private Key Object; RSA > label: testKSK_1 > ID: a1a1 > Usage: decrypt, sign, unwrap > Public Key Object; RSA 1024 bits > label: testZSK_1 > ID: a1b1 > Usage: encrypt, verify, wrap > Private Key Object; RSA > label: testZSK_1 > ID: a1b1 > Usage: decrypt, sign, unwrap > Public Key Object; RSA 2048 bits > label: testKSK_1 > ID: a1a1 > Usage: encrypt, verify, wrap > > ###### > > The KNOT config is : > > [root@centos-test2 ~]# cat /etc/knot/knot.conf > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > zone: > - domain: example.com > dnssec-signing: on > dnssec-policy: manual > zonefile-load: difference > file: example.com.zone > storage: /etc/knot/ > > log: > - target: syslog > any: debug > > ################### > > And if I try to import the key into keymgr i run the command: > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1a1 algorithm=RSASHA256 size=2048 ksk=yes > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > ### > > I don't know how I can fix this.. maybe anybody can help me ? The > documentation of KNOT is very good.. but at this point it is a little > bit insufficient. Does anybody has examples for this ? > > Thanks a lot in advance for the help.. > > best regards > > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main

7 let, 6 měsíců

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users