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
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
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
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
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
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
Hello,
Is there a way how to force AXFR for certain masters in the
configuration? I have a situation with one of master serveres where IXFR
fails - received response is "Format error". Knot does not fall back to
AFXR in this case and the zone is going to expire. Using zone-retransfer
can fix it. Transferring this zone using kdig is also ok.
I can see this with Knot 2.7.2 and Knot 2.7.3 as well.
BR
Ales
Hi,
Is it possible to restrict DNS64 module only for specific IPv6 subnets
in Knot Resolver? The reasoning behind this is that this would make it
possible to run DNS64 resolver on the same instance with the "normal"
resolver in a way that fake AAAA records are returned only to IPv6-only
clients whereas normal dual-stack or IPv4-only clients are served with
unmodified A records.
I found an issue [1] that seems to be related to the very same thing,
but I was left a little bit uncertain what the current situation is and
how this should/could be configured.
[1] https://gitlab.labs.nic.cz/knot/knot-resolver/issues/368
Cheers,
Antti
Hi folks,
sorry for the spam.. now with the right subject..
Maybe anybody can help me..
Is there any possibility to sign with more than one core ? The
"background-workers" parameter didn't help...
KnotDNS is using only one core for signing..
thanks a lot
best regards
--
Christian Petrasch
Senior System Engineer
DNS/Infrastructure
IT-Services
DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY
E-Mail: petrasch(a)denic.de
Fon: +49 69 27235-429
Fax: +49 69 27235-239
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
