5 Čen
2024
5 Čen
'24
20:29
Hello
UltraDNS is working on implementations of the multi-signer DNSSEC (RFC 8901)
specification.
It has been our desire to be able to use CDNSKEY records as an indicator to other signers
that a ZSK roll is in process and the other signer should adjust their DNSKEY rrSet to
reflect the new ZSK created by the UltraDNS signing processes.
Our interpretations of RFCs 7344 and 8078 do not prohibit the use of CDNSKEY for this
purpose and we had developed the service to publish CDNSKEY records with a DNSKEY flags
value of 256 to indicate a change in the ZSK for the zone.
Unfortunately, this approach appears to be causing issues for TLDs using FRED as the
cdnskey scanner process does not consider the flags attribute of the rdata and treats
every CDNSKEY record as a KSK key event.
We would like know if FRED could be updated to consider the flags of CDNSKEY records and
only act on those records where the SEP indicator is set - i.e. flags = 257?
Acknowledging that the RFCs are silent on the use of flags=256 in a CDNSKEY record, it
seems to us to be a reasonable use of the CDNSKEY record for signaling and informing other
signers implementing RFC 8901.
Thoughts?
Steve deJong
UltraDNS
11 Čen
11 Čen
11:23
Hi Steve, all,
this topic has been also discussed on the multi-signer mailing-list and OARC Mattermost.
As a reminder, the situation is that DS is being updated (at an already secured delegation
point) as a result of detecting novel CDNSKEY. What I think after those discussions:
1) FRED should not actually care about the Flags field in CDNSKEY (nor in corresponding
DNSKEY). Processing CDNSKEY with Flags 256 (i.e. SEP bit cleared) seems OK. I suspect that
your assumption, that 256-flagged CDNSKEY would be ignored, was incorrect.
2) According to RFC 7344, Section 4.1, Bullet "Continuity", FRED should (it is
actually a MUST) check the delegation, if it works with updated DS. The RFC is pretty
vague about the details here. I suspect that FRED is missing some (or any) such checks and
this can be considered a bug in FRED. There are some viable options what FRED could check,
depending on available codebase (and therefore ease of implementation):
2a) perform an interative validation of the cild zone's DNSKEY with the new DS-to-be
installed as a trust anchor (this might be easy if there is an iterative DNSSEC validation
tool already part of FRED)
2b) the same as 2a) but validate the child zone's SOA (this might avoid updating DS
when the child zone is wrongly signed itself, dunno if better or worse)
2c) only check that the DNSKEY corresponding to the DS-to-be is used to sign DNSKEY in the
child zone (this could be easier to implement as a single-RR validator is only needed,
which is already probably part of FRED due to necessary CDNSKEY-RRSIG validation...)
2d) only check by keytag that the DNSKEY corresponding to the DS-to-be is used to sign
DNSKEY in the child zone (this is the easiest way possible, only compute the keytag of the
accepted CDNSKEY and search for it in the child's DNSKEY-RRSIG)
(All those options would need to be elaborated, e.g. for the case of multiple CDNSKEYs
(and DSs)....)
Any of those possible bugfixes would prevent what you observed -- accepting a ZSK as an
entry point for DS. Note that DNSKEY/CDSNKEY flags don't play any role here.
Nevertheless, the idea of re-purposing apex CDNSKEYs is IMHO not good.
Libor
27 Srp
27 Srp
14:56
Hi Steve,
some internal discussion reminded me that I forgot to answer to this
topic.
When we implemented RFC 7344 and RFC 8078 back in 2017 we intentionally
omitted this kind of checks that are mentioned in RFC. The reason was
that we wanted to have consistency between channels for accepting
DNSKEY records in the registry. If DNSKEY is submitted via EPP we don't
prevent to publish DS that breaks DNSSEC chain. There may be valid
reasons to do so (tests, DNSSEC failure checkers, etc...) When DNSKEY
is updated via other channel (CDNSKEY) we valued more the consistency
with EPP.
I agree that from another point of view it may be considers as bug and
we will evaluate possibilities how to add some kind of checks as Libor
mentioned.
At the same time, I also think that both RFCs (as title suggest) are
meant for synchronization of DNSKEY with parent and DNS operator should
not abuse this intention.
Based on stats from our registry, it is not uncommon that DNS operators
are using keys with flag 256 as KSKs so preventing to accept such keys
via CDNSKEY would probably break updates for other users.
Regards,
Jaromir
On Tue, 2024-06-11 at 09:23 +0000, Libor Peltan wrote:
Hi Steve, all,
this topic has been also discussed on the multi-signer mailing-list
and OARC Mattermost. As a reminder, the situation is that DS is being
updated (at an already secured delegation point) as a result of
detecting novel CDNSKEY. What I think after those discussions:
1) FRED should not actually care about the Flags field in CDNSKEY
(nor in corresponding DNSKEY). Processing CDNSKEY with Flags 256
(i.e. SEP bit cleared) seems OK. I suspect that your assumption, that
256-flagged CDNSKEY would be ignored, was incorrect.
2) According to RFC 7344, Section 4.1, Bullet "Continuity", FRED
should (it is actually a MUST) check the delegation, if it works with
updated DS. The RFC is pretty vague about the details here. I suspect
that FRED is missing some (or any) such checks and this can be
considered a bug in FRED. There are some viable options what FRED
could check, depending on available codebase (and therefore ease of
implementation):
2a) perform an interative validation of the cild zone's DNSKEY with
the new DS-to-be installed as a trust anchor (this might be easy if
there is an iterative DNSSEC validation tool already part of FRED)
2b) the same as 2a) but validate the child zone's SOA (this might
avoid updating DS when the child zone is wrongly signed itself, dunno
if better or worse)
2c) only check that the DNSKEY corresponding to the DS-to-be is used
to sign DNSKEY in the child zone (this could be easier to implement
as a single-RR validator is only needed, which is already probably
part of FRED due to necessary CDNSKEY-RRSIG validation...)
2d) only check by keytag that the DNSKEY corresponding to the DS-to-
be is used to sign DNSKEY in the child zone (this is the easiest way
possible, only compute the keytag of the accepted CDNSKEY and search
for it in the child's DNSKEY-RRSIG)
(All those options would need to be elaborated, e.g. for the case of
multiple CDNSKEYs (and DSs)....)
Any of those possible bugfixes would prevent what you observed --
accepting a ZSK as an entry point for DS. Note that DNSKEY/CDSNKEY
flags don't play any role here. Nevertheless, the idea of re-
purposing apex CDNSKEYs is IMHO not good.
Libor
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
148
days inactive
231
days old
2 comments
3 participants
participants (3)
-
Jaromir Talir -
Libor Peltan -
Steve DeJong