warn if static (unmanaged) key is used

Static key configuration (i.e. without enabling RFC 5011) causes problems with roll-overs. Wild idea: Maybe we should warn if an unmanaged key is configured?

Note that this is the default setup for distros – package read-only TAs managed by the package system.

You are right, it would generate a lot of false positives. What about warning only if the read-only TA differs from relevant DNSKEY?

This should generate warnings only if distro maintainers are late with updates, which sounds like a good reason for some screaming.

Yes, that sounds good. I expect we could extend the 5011 code to also do this, as it's very similar; moreover it's probably not enough to do it on start, so we might as well do it with the whole process usual for 5011 (except that we won't actually updating the TAs).

Good idea. The cost of doing repeated queries from 5011 is usually negligible.

Currently the refresh time for the root zone is 24h, so that is really cheap.

added minor usability labels

Maybe it makes sense to implement this at once with #220 (closed) so we do not need to touch the code repeatedly.

changed milestone to %2017 Q4

assigned to @vkriz

changed milestone to %2019 Q1

Moved for reconsideration.

I don't see the value of this. If a static keyfile is used and unmanaged, it's the packager/distro's responsibility and not our business.

Good diagnostics might still be useful, so that it's easier to see who's at fault. (In bad situations that seem most likely, at least.)

removed milestone

Hmm, @tkrizek is right. Default packages in distros would cause an "unfixable" warnings for everyone so it is not really useful.

It would be more useful to modify ta_update module to compare statically configured keys against keys in zone and warn if there are differences, basically saying "beware, you need to update package with trust anchors before it breaks!".

I thought we have a ticket for that somewhere but I'm not able to find it now.

assigned to @ljezek

@ljezek I'm not sure how complex this would be, the code around TA maintenance is spagethi-style. Please have a look how hard it would be to implement https://gitlab.labs.nic.cz/knot/knot-resolver/issues/251#note_131379 and if it is complex please report back, we might postpone this.

mentioned in merge request !1051 (merged)

closed via commit b8fb66ab

mentioned in commit b8fb66ab