knot-dns-users August 2020

knot-dns-users@lists.nic.cz

6 participants
6 discussions

Start a nNew thread

dynamic updates (DDNS)

by Thomas

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

5 years, 11 months

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

6 years, 1 month

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

6 years, 1 month

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

6 years, 2 months

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 >

6 years, 2 months

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

6 years, 2 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users August 2020