knot-dns-users

knot-dns-users@lists.nic.cz

6 participants
762 discussions

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ů

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

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

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

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

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

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

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

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

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

← Newer
1
...
20
21
22
23
24
25
26
...
77
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users