続編のご報告です：Network Solutions 社に確認したところ、自社の側ではドメインに関連する DNSSEC レコードは一切確認されなかったとのことでした。つまり、前のレジistrar に由来する「機械の亡霊」でしょうか？
いずれにせよ、存在しないものを削除することはできないため、新しいレコードを追加して、それらが幻影のようなレコードを上書きし、すべてが本来あるべき状態に戻ることを期待して対応を進めています。
これまでに経験した中で、これほど奇妙な DNS 問題は初めてです。
私も同感です 
あれは .org のネームサーバーです。
DNSSEC の制御は、あなたのレジストラで行う必要があります。グルーレコードと同様に、ドメインの DS レコードは TLD ネームサーバーに存在している必要があるからです。あなたの DNS プロバイダーには、それに対する制御権はありません。
まだそこにレコードが存在しているのが確認できます：
pidforum.org. 86400 IN DS 30311 8 2 A75DEB1CF7CE3EE94899941C7E92B72A7E83A7B5DCD3717D6731804B 4D851E46
pidforum.org. 86400 IN RRSIG DS 8 2 86400 20211008152857 20210917142857 39681 org. goYqP/QgI0+8jN/pL3yVhZfeWAGXoibV/DHDduL+DWj47b9U18nRKctf OJB+TNznVcQeEtG67UM5O+nr5FmrfzowCHvgRsUaanVlo1nCXjlOg9eV KqZmkVcN2no1oklqbQBtN7GDqtX+G1BYmQCaIWbZ38PGBAnc2aQ0Ftr8 cAg=
;; 199.19.53.1#53(c0.org.afilias-nst.info) から 252 バイトを受信、93 ms
しかし、アナライザー はまだエラーを表示しています：
彼らを付きまとい、自社側でこれを修正できる担当者に連絡してもらうまで諦めないでください。これは正しく修正する レジストラの責任 です。
また、前のレジストラに連絡し、あなたのゾーンに対するグルーレコードと DS レコードの送信を停止するよう依頼することで、進展するかもしれません。
編集：
現時点で、公開されている .org ゾーンレコードは以下の通りです：
pidforum.org. 86400 in ns lee.ns.cloudflare.com.
pidforum.org. 86400 in ns jillian.ns.cloudflare.com.
pidforum.org. 86400 in ds 30311 8 2 (a75deb1cf7ce3ee94899941c7e92b72a7e83a7b5dcd3717d6731804b4d851e46 )
pidforum.org. 86400 in rrsig ds 8 2 86400 20211005151127 20210914141127 39681 org. bDTwz7kYTRJXb7LuN1qj1mCBtiq0DMUM9dNzppGgR/+pTX6b0cWuMhFngI1zMk870aJU6BozFxwuv/AhUHl3y3/PHrjDOsSVA1SubPZM/tC/ylWSUexcVxVhQkQRLkpKPUlL61sZTX8VNca3MBWXx/kFSt7uThR0IYeW+2fQXqQ=
今朝、以前のレジストラ（オランダの Argeweb）が、このドメインの DS レコードを自システムから最終的に削除したことを確認したとの連絡を受けました。
したがって、現時点では、Cloudflare（ネームサーバー）から提供された新しい DS レコードが正しく設定されていることを Network Solutions（レジストラ）が確認しており、かつ以前のレジストラである Argeweb が自社のレコードを削除したことも確認されています。
あとは、これらの変更が世界中で反映されるのを待つだけです。NetSol と Cloudflare からの確認は水曜日の遅くにあり、Argeweb からの確認は今朝でした。週末にはすべてが正常に整合するかもしれません。指を組んで待っています
通常、1 日以内で完了するはずです。
これらすべてに「〜すべきだった」という話がたくさん出てきますね……Argeweb はそもそもドメインを移管する前に DNSSEC を無効にするべきでした。Network Solutions も、移管時に自側でそれを確認し、無効にできたはずです。
「〜すべきだった」という考え方が、このプロジェクト全体の悩みの種です。
レジストラとルートゾーン運用者の間のインターフェースが、差分更新を送信するのか、それとも毎日完全な更新を送信するのか、正確にはわかりません。しかし、彼らはそのプロセスを理解しており、適切な対応をしたはずです。
同様に、ゾーンを移行する際、Network Solutions は以前の DS レコードをインターフェースにインポートすべきでした。おそらく NS レコードも転送されたと思いますが、もしかするとそれらはあなたが提供する必要があったのでしょうか？
DNS は正しく設定するのが難しく、DNSSEC はさらに困難です。
Should have / could have / would have
少なくとも、問題が何で、どうすれば解決できるかは分かっています。
供給業者は、ほぼ必ず他者を責任転嫁します。
本日、pidforum.org の DS グルーが変更されていないことを確認しました。
Network Solutions のインターフェースに正しいレコードを追加しましたか？
はい、先週後半に Network Solutions に正しいレコードを追加しましたが、週末を待っても変化はありません。不正な DS レコード 30311 がどこかに隠れたままとなっており、誰もそれを修正できないようです。
このページで、正しいレコードと不正なレコードの両方が確認できます。
正しいレコードは、問題となる .org レベルに存在していません。
Network Solutions に正しいレコードの公開を強く要請してください。
ドメイン設定の該当部分のスクリーンショットはありますか？
Network Solutions は、DNSSEC のどの側面についても公開された管理画面を提供していません。サポートグループにはそれを取り扱う部署が 1 つだけあり、メールでのやり取りしかできません。
はい、冗談ではありません。
今日は、少しは事情をわかっているかもしれないサポートのティアにたどり着くことができました。彼らは、24〜48 時間以内に回答すると伝えてくれました。
まだ整理されていません。痛いほどお気持ちわかります、@griffey さん。
こちらでチェックを実行しました。結果の中に KeyTag 30311 がどこにあるか確認できます。
エラー: DNSKEY 2371 が DNSKEY RRset に署名していますが、親ゾーンで確認用の DS RR が見つかりません。信頼チェーンが作成されませんでした。
致命的なエラー: 親ゾーンには署名済みの DS RR（アルゴリズム 8、KeyTag 30311、DigestType 2、Digest p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=）が存在しますが、宛先の DNSKEY が存在しないか、DNSKEY RRset の検証に失敗しています。信頼チェーンが作成されませんでした。
まだ解決していません。Network Solutions は DNSSEC や複雑なドメイン問題に関しては全く役に立たないと言えます。これは間違いなく DNSSEC の問題であり、dsKey (30311) がどこか虚空に引っかかっており、誰もそれを削除できるとは思っていないようです。
ドメインを Google Cloud へ移行してください。
その後、DNSSEC 設定を自分で管理できるようになります。
最終更新情報です。……正直、納得できるものではありませんが、何かがクリアされ、ドメインの伝搬が始まりました。何が正確に変わったのかは不明です。30311 DSKEY エントリは依然として確認できます。レジストラー側で何らかの変化があったようですが、現在は正常に動作しています。
アップデートありがとうございます