Hi Libor,
thanks for coming back.
Yes, this is mainly what we have done. Two notes:
- We have not cold started Knot, instead we used "knotc reload"
- "parent DS query" is "not scheduled" (instead of "not planned" as you
wrote)
Thanḱs,
Thomas
Am 19.03.19 um 10:57 schrieb libor.peltan:
Hi Thomas,
just to make sure, with 2.8.0, it works like following?
Configuration: zone has a policy assigned with submission configured
with some remotes. (The configuration might have been different before
and changed since in any way.)
Cold start of Knot 2.8.0. It shows the line "KSK submission, waiting for
confirmation" in the log.
Still, there is no sign of DS checking activity and "parent DS query" is
still "not planned" in "zone-status".
...right?
I need to ensure because now it seems like a different malfunction, even
though it might look the same for you ;)
Thanks for clarification,
Libor
Dne 13.03.19 v 12:54 Thomas E. napsal(a):
Hi Daniel,
we upgraded to 2.8.0 in the meantime. All I can say is that the
behavior is exactly the same.
The only difference we can see is that there is now one additional Log
Entry:
"DNSSEC, KSK submission, waiting for confirmation"
Best regards,
Thomas
Am 08.03.19 um 13:47 schrieb Daniel Salzman:
Hi Thomas,
Please, are you able to test Knot DNS 2.8.0? I think that this issue
could already be fixed along
with the improvement "DS check event is re-planned according to KASP
even when purged timers".
Thanks,
Daniel
On 3/7/19 5:09 PM, Thomas E. wrote:
Hi Libor,
sorry for taking so long to come back to you, but we tried our best
to trace down our previous steps to make this issue reproducible.
We found out, that the described behavior does not affect all of the
domains that we wanted to sign. We made this assumption based on a
small set of domains that we used to test real-world DNSSEC
integration with and that we frequently enabled and disabled signing
for over and over again, while we were figuring out how we can use
knot.
To clarify this point: New domains, that have not been signed
previously are not affected by this!
The steps to reproduce the described problem are:
1. Set up a knot 2.7.6 using a config without (!) a submission section
2. Add an unsigned zone to the config file and reload knot
3. Set the template of the zone to "signed" and reload knot
4. Execute "knotc zone-status" for the domain, and you should be
able to observe the following state: "parent DS query: not scheduled"
5. Set the template of the zone to make it unsigned again and reload
knot
6. Add the submission section to the knot.conf and reload knot
7. Set the template of the zone to "signed" and reload knot
8. Execute "knotc zone-status" for the domain, and you should be
able to still observe the following state: "parent DS query: not
scheduled"
This seems to indicate that there is some persistent state, that
remains for the zones that have been removed from the signed
template, and that this state actually prevents the parent DS query
from being scheduled (ever?) again.
I hope that this description gives you enough insight to evaluate
the behavior.
Best regards,
Thomas
Am 06.03.19 um 18:03 schrieb libor.peltan:
Hi Thomas,
I'm still not sure what goes wrong in your case. The setup looks
good and when I try something similar, it works for me - the DS
check is planned whenever I add a zone to "signed" policy.
Could you please send us the logs of Knot? (Also shuffle with the
configured log verbosity first, e.g. like:
log:
- target: "stdout"
any: "info"
). Thanks much!
Libor
Dne 06.03.19 v 16:47 Daniel Salzman napsal(a):
Hi,
On 3/5/19 10:14 PM, Thomas wrote:
Hi Daniel,
we add the new zones configured with the "default" template. When a
customer is requesting DNSSEC we move the zone to the "signed"
template.
Could that be the problem?
It shouldn't be. But as you use shared key, it's possible there is
a bug in the code.
We will investigate your setup...
Daniel
Best regards,
Thomas
On 05.03.19 19:32, [email protected] wrote:
Hello Thomas,
On 2019-03-05 18:31, Thomas E. wrote:
Hello Daniel,
we tried the described approach, and it worked fine for zones,
that we
already executed "knotc zone-ksk-submitted xx.tld" for.
For freshly added zones however the "knotc zone-status xx.tld"
returns
a status that indicates that the parent DS query has not been
scheduled:
Are the freshly added zones configured with template 'signed'?
Daniel
[xx.tld.] role: master | serial: 1551549547 | transaction: none |
freeze: no | load: not scheduled | refresh: not scheduled |
update:
not scheduled | expiration: not scheduled | journal flush: not
scheduled | notify: not scheduled | DNSSEC re-sign: +19h26m42s
| NSEC3
resalt: +27D2h42m39s | parent DS query: not scheduled
Also our logs do not show any attempts of parent DS queries for
the
affected zone, only for the zones that we previously executed
"zone-ksk-submitted" for.
Right now we add the zone using a default template (which does not
make use of DNSSEC), because not all of our zones should be signed
right away and switch the template to a signed template for
specific
zones, that we actually want to sign.
Here's an excerpt from our current config:
remote:
- id: local-resolver
address: 192.168.1.2
submission:
- id: resolver
parent: local-resolver
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
template:
- id: default
storage: "/var/lib/knot"
semantic-checks: on
global-module: mod-stats
master: primary
notify: secondaries
acl: [primary, secondaries]
- id: signed
dnssec-signing: on
dnssec-policy: shared
acl: [primary, secondaries]
notify: secondaries
Maybe we get something fundamentally wrong, but from our
experience
there is no DS scheduling without an initial manual
intervention via
"knotc zone-ksk-submitted xx.tld".
Any hint would be appreciated!
Thank a lot,
Thomas
Am 05.03.19 um 11:49 schrieb Daniel Stirnimann:
Hello Thomas,
On 05.03.19 11:24, Thomas E. wrote:
Will the "knotc zone-ksk-submitted" command still be
necessary for the
initial DS lookup when signing a new zone? Or is the
"ksk-submission"
statement sufficient in any case?
The use of "ksk-submission" is sufficient.
From the knot documentation:
"At this point new KSK has to be submitted to the parent zone.
Knot
detects the updated parent’s DS record automatically (and
waits for
additional period of the DS’s TTL before retiring the old key)
if parent
DS check is configured, otherwise the operator must confirm it
manually
with knotc zone-ksk-submitted"
https://www.knot-dns.cz/docs/2.7/singlehtml/
I've never used "knotc zone-ksk-submitted". Maybe it's useful
if you
have a broken trust chain to your zone and in some scenario
you might
want to tell knot to go ahead...
Daniel
--
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
