knot-dns-users Říjen 2018

knot-dns-users@lists.nic.cz

13 participants
13 discussions

Re: [knot-dns-users] Best practices for knot inline DNSSEC signing and zone loading

by libor.peltan

Hi Sebastian, 1) that's OK. You don't need to worry about that warning unless you edit the zonefile on the signer manually. You can also consider zonefile-less signer, either completely headless (needs AXFR after each daemon start) or with the zone stored in journal (needs some thoughts regarding journal capacity policies). Check "zonefile-load", "journal-content", "max-journal-db-size" and "max-journal-usage" options in config. 2) No, "discontinuity in changes history" is not expected. Could you please describe what did you do before such warning appeared, with longer snippets of the log? In any case, there is no need to be scared of journal getting full, once you read the documentation ;) https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour BR, Libor Dne 29.10.18 v 13:07 Sebastian Wiesinger napsal(a): > Right now I have two zone types for my knot test setup, one where knot > is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and > one where the knot is the master for the zone and zone data is coming > out of a git repository and gets signed. > > Reading older threads on this ML and browsing the configuration has > led me to the following configuration and I wanted to make sure this > is actually supported or if there is a best practice that is > different. > > > 1) Inline DNSSEC signing for slave zone. > > zone: > - domain: example.com > serial-policy: unixtime > storage: "/var/lib/knot/slave" > file: "%s.zone" > zonefile-load: difference > dnssec-signing: on > dnssec-policy: rsa-de > master: ns1_signer > notify: ns1 > acl: acl_ns1 > > policy: > - id: rsa-de > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > ksk-submission: tld_de > > > This seems to work fine, zone gets transferred from master (with low > serial), signed and with a new unixtime serial transferred out again. > I'm not sure if "zonefile-load: difference " makes any difference for > a slave zone but without it I get warnings about possibly malformed > IXFRs... > > 2) Inline DNSSEC for master zone from git: > > zone: > - domain: dnssec-test.intern > serial-policy: unixtime > storage: "/var/lib/knot/master" > file: "%s.zone" > zonefile-sync: -1 > dnssec-signing: on > dnssec-policy: rsa > acl: acl_ns1 > zonefile-load: difference-no-serial > > policy: > - id: rsa > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > > > This also works but I get warnings like this: > > [dnssec-test.intern.] journal, discontinuity in changes history > (1540307365 -> 28), dropping older changesets > > Is this expected? Also I read in older threads that this might fill > up the journal. Is that still the case? > > > Best Regards > > Sebastian >

6 let, 1 měsíc

(where) is the python control script packaged?

by Rick van Rein

Hi, You/Daniel pointed me to the Python control library, but I cannot find it in the 2.7.3 packages -- is that forgotten, or am I missing it? Thanks, -Rick

6 let, 1 měsíc

Question about obtaining information for parent zone of DNSSEC KSK rollover

by Maximilian Engelhardt

Hi, I'm having a question about DNSSEC KSK rollover and obtaining the relevant information for submission to the parent zone of the new key. I'm currently using these steps: - running "keymgr example.org list" - manually identifying the new key using the parameters "ksk=yes" and having a look at the created, publish, ready and active parameters. The new key always seems to be the one with active=0 and I also check the dates of the other parameters for plausibility. I then note the tag of the identified key. - using "keymgr example.org dnskey <keytag>" or "keymgr example.org ds <keytag>" to get the corresponding information for submission to the parent zone. Is there an easier way of achieving this, especially without the manual key identification step? Ideally would be a single command I can run and specify the zone of interest and it will output the dnskey and/or ds information of the new key. Thanks, Maxi

6 let, 1 měsíc

Best practices for knot inline DNSSEC signing and zone loading

by Sebastian Wiesinger

Right now I have two zone types for my knot test setup, one where knot is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and one where the knot is the master for the zone and zone data is coming out of a git repository and gets signed. Reading older threads on this ML and browsing the configuration has led me to the following configuration and I wanted to make sure this is actually supported or if there is a best practice that is different. 1) Inline DNSSEC signing for slave zone. zone: - domain: example.com serial-policy: unixtime storage: "/var/lib/knot/slave" file: "%s.zone" zonefile-load: difference dnssec-signing: on dnssec-policy: rsa-de master: ns1_signer notify: ns1 acl: acl_ns1 policy: - id: rsa-de algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 ksk-submission: tld_de This seems to work fine, zone gets transferred from master (with low serial), signed and with a new unixtime serial transferred out again. I'm not sure if "zonefile-load: difference " makes any difference for a slave zone but without it I get warnings about possibly malformed IXFRs... 2) Inline DNSSEC for master zone from git: zone: - domain: dnssec-test.intern serial-policy: unixtime storage: "/var/lib/knot/master" file: "%s.zone" zonefile-sync: -1 dnssec-signing: on dnssec-policy: rsa acl: acl_ns1 zonefile-load: difference-no-serial policy: - id: rsa algorithm: RSASHA256 ksk-size: 2048 zsk-size: 1024 This also works but I get warnings like this: [dnssec-test.intern.] journal, discontinuity in changes history (1540307365 -> 28), dropping older changesets Is this expected? Also I read in older threads that this might fill up the journal. Is that still the case? 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

6 let, 1 měsíc

KSK Algorithm Rollover Question

by Sebastian Wiesinger

Hi, I'm currently testing a KSK algorithm rollover with my zone. I changed the signature scheme from RSA to ECDSA. Knot started adding new RRSIGs and new keys and now waits for the new DS to be published at the parent zone. One thing strikes me as odd though: http://dnsviz.net/d/6v6.de/W9AmtA/dnssec/ Looking at the graph the new KSK (54879) is not signing anything right now. Shouldn't it sign the DNSKEY records of the ZSKs so that the chain stays intact when the DS record changed at the parent zone? Kind 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

6 let, 2 měsíce

geoip secondary DNS with DNSSEC

by Mark Karpilovskij

Dear Volker, it is true that the method for creating a CSK is not explicitly mentioned in the documentation, we shall fix that. You can create a CSK using our keymgr utility by specifying both 'ksk=yes' and 'zsk=yes' parameters of the 'generate' command. E.g. $ keymgr -c /path/to/knot.conf example.com. generate ksk=yes zsk=yes remove=+1y creates an immediately active CSK with a 1 year lifetime. You can check out all possible timestamp settings in the docs <https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#generate-arguments>. Please note that the geoip module is currently not very well integrated into Knot's DNSSEC workflow. For instance, the only way to refresh RRSIGs precomputed by the module is to reload it (knotc zone-reload). One approach for now could be to create a CSK with a strong algorithm (e.g. the default ECDSAP256SHA256) and a long lifetime, e.g. 1 year, and to set the same lifetime for the RRSIGs. The policy configuration could look like this: policy: - id: manual manual: on algorithm: ECDSAP256SHA256 rrsig-lifetime: 365d zone: - domain: example.com. dnssec-signing: on dnssec-policy: manual Then you would only have to perform a manual key rollover while reloading the zone so that the module computes the new signatures. We will update the documentation to include this information. In addition, you can sync the key from one server to others by copying the KASP lmdb database e.g. using the mdb_dump and mdb_load tools. If you have any further questions, let us know! Best regards, Mark On 19.10.2018 10:13, Volker Janzen wrote: > Hi all, > > I'd like to test the geoip module with a signed zone. The > documentation recommends using manual mode for signing. As far as I > know, the geoip information is not transferred via AXFR. That would > mean, that I've to transfer the signing key to the secondary servers > along with the geoip (and zone) configuration. To reduce caveats with > ZSKs, I'd like to use CSK. As a result I just need to sync one key per > zone to secondary servers. I checked the Knot documentation on how to > use a CSK for a zone, but the CSK is only mentioned twice in the > documentation with no example on how to actually use it. Can someone > point me to a configuration example for setting up a CSK? > > > Kind regards, > Volker

6 let, 2 měsíce

geoip secondary DNS with DNSSEC

by Volker Janzen

Hi all, I'd like to test the geoip module with a signed zone. The documentation recommends using manual mode for signing. As far as I know, the geoip information is not transferred via AXFR. That would mean, that I've to transfer the signing key to the secondary servers along with the geoip (and zone) configuration. To reduce caveats with ZSKs, I'd like to use CSK. As a result I just need to sync one key per zone to secondary servers. I checked the Knot documentation on how to use a CSK for a zone, but the CSK is only mentioned twice in the documentation with no example on how to actually use it. Can someone point me to a configuration example for setting up a CSK? Kind regards, Volker

6 let, 2 měsíce

DDNS with DNSSEC, is this expected behavior or a bug

by Maximilian Engelhardt

Hi, I'm using a zone with DNSSEC signing enabled that is updated using DDNS. The update procedure is very simple and looks like this: ==> test_ddns.sh <== #! /bin/sh ZONE="example.org." cat << EOF | nsupdate server localhost zone ${ZONE} update delete ${ZONE} A update add ${ZONE} 60 IN A 127.0.0.1 send quit EOF And the corresponding output in the knot log is this: Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, successfully signed Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 2018-10-24T22:58:46 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, update finished, serial 1539809849 -> 1539809926, 0.02 seconds Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, processing 1 updates Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, zone is up-to-date Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DNSSEC, next signing at 1970-01-01T01:00:00 Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] DDNS, finished, no changes to the zone were made Okt 17 22:58:46 backroad knotd[14134]: info: [example.org.] zone file updated, serial 1539809849 -> 1539809926 I'm wondering if the "next signing at 1970-01-01T01:00:00" output is correct as this seems suspicious to me. Running "knotc zone-status example.org" gives the following output: [example.org.] role: master | serial: 1539809926 | transaction: none | freeze: no | refresh: not scheduled | update: not scheduled | expiration: not scheduled | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: +29D23h53m28s | parent DS query: not scheduled Is this expected behavior or a bug in knot? I can give more information or create a proper bugreport if needed. I also recently had the problem that knot didn't respond to ddns updates until it was restarted. I don't know if this is related or a different problem, however I currently don't have more information about this. Thanks, Maxi

6 let, 2 měsíce

Re: [knot-dns-users] Correct way to turn off dnssec-signing

by libor.peltan

Hi Oliver, > Ah, the mistake was that changing the dnssec-policy *and* dnssec-signing > in one go does not insert the delete-CDS/CDNSKEY records since knot > immediately stops all dnssec related actions. Thanks! You at least want to have the special CDNSKEY record -signed- anyway ;) > Am I right that, unlike the signing process (KSK submission attempts), > there is no built-in functionality in knot, that takes care about the > right time to remove the key material from the zone? Yes. We didn't care much for this usecase, sorry. I guess it's not so difficult to achieve this manually. We need to have automated just those processes, that start automatically (e.g. KSK rollover). > So, basically I should wait > [propagation-delay] + [max TTL seen in zone/knot_soa_minimum] > seconds until I manually remove the material. No, you first need to check when your parent zone removed the DS record. Afterwards wait for its TTL + propagation_delay. BR, Libor

6 let, 2 měsíce

Correct way to turn off dnssec-signing

by Oliver Peter

Hi, I am experimenting with latest knot and its wonderful dnssec autosigner functionality. It works pretty nice but I am a bit lost in the unsign process, my zone looks basically like this: zone: - domain: "domain.tld." storage: "/home/oliver/knot/zones" file: "sign.local" zonefile-load: "difference" dnssec-signing: "on" dnssec-policy: "dnssec-policy" serial-policy: "unixtime" policy: - id: "dnssec-policy" zsk-lifetime: "2592000" ksk-lifetime: "31536000" propagation-delay: "0" nsec3: "off" ksk-submission: "local" cds-cdnskey-publish: "always" What is the safe way to turn off dnssec once the DS has been seen by the resolver/knot? I tried to do dnssec-signing: "off" but that did not change anything; I also created a second policy called "unsign-policy" where I switched cds-cdnskey-publish to "cds-cdnskey-publish". I expected the CDNSKEY/CDS immediately turn into "0 3 0 AA==" and so on since my propagation-delay is 0 (for faster test results...) Thanks for any hints! -- Oliver PETER oliver(a)gfuzz.de 0x456D688F

6 let, 2 měsíce

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users Říjen 2018