Besides the fact that there is no real "propagation" in the DNS even if everyone says so (because the flow of changes is not applied top to bottom, but things are fetched from "bottom" recursive nameservers), whatever happens in that area should mostly be orthogonal to the case of using DNSSEC or not.
Changing nameservers (which can happen even without changing registrars) for a DNSSEC signed domain is indeed currently still a problem. It has various helpers but no generic solution, and is specifically hard if the current (old) operator of nameservers is unwilling to cooperate.
You have to remember that DNS records have TTLs (which is what often people hints at when speaking about propagation), and then DNSSEC introduces
RRSIG records which encodes both a start time and end time for each specific signature.
Your question lacks actionable details but what may be happening is that recursive caches around the world or at least the one you test did cache the previous DNSKEY, DS and RRSIG records, with various TTLs. TTLs are controlled by different entities: the TTLs on the nameservers itself are set by the registry, same for DS records that live only in the parent, where TTLs on previous DNSKEY/RRSIG records are set by previous operator of nameservers as they live in the child zone.
Note that DNS related problems in changes will be different from DNSSEC related problems: if for example you do not see new content (because caches still have old values), you will get
NXDOMAIN replies (record does not exist), or the previous old record with some TTL. But if you have DNSSEC related problems, you will get
is there something I can do to fix the issue?
Honestly, at that stage you do not describe your issue in sufficient details to really help you. Depending on which stage you are exactly, how things are cached, and what fails exactly, the best course of action may be different. If the domain is not life-critical, waiting for things to settle is probably the sanest/simplest course of actions.
Other possible help (which could also create even more problems, so it all depends on details we do not know):
- switch back to old nameservers for now (so that you have time later to properly handle the change, including potentially to remove DNSSEC before changing things even if it is to reapply it later. A sad way to do things, but sometimes the only practical one)
- have the new nameservers serve the same
RRSIG records, at least until the current entries expire from all caches
- make sure the
DS record is removed from registry side (not clear enough from the description if you are in this case or not)
This page may give you some hints on how to deal with signed transfer: https://help.dyn.com/transfer-a-dnssec-signed-zone/
And there is also this IETF draft that compiles a lot of wisdom on the subject:
quoting its abstract:
Changing the DNS delegation for a DNS zone is quite involved if done
by the books, but most often handled pragmatically in today's
operational practice at the top level with registries and registrars.
This document describes a delegation change procedure that maintains
consistency and validation under DNSSEC.
Note also that some registries may give specific instructions for cases like that, so it depends on the TLD:
- in some registries, registrars have to be specifically DNSSEC accredited, and you can not transfer a DNSSEC enabled domain to a non DNSSEC accredited registrar
- in some registries (like
.FR), during a transfer you have to specify if
DS records are to be kept or dumped
- in some registries (like
.NL) you have specific EPP extension (
keyRelay) to help cooperating registrars exchange keys needed for proper transfer of DNSSEC enabled domains (but do remember that the problem is not the change of registrars, but the change of nameservers which can happen even when not changing registrars).