在持续的事件中：Network Solutions 向我确认，他们在其系统中并未看到与该域名关联的任何 DNSSEC 记录……所以……难道是前任注册商留下的“机器幽灵”？
无论如何，既然他们无法删除不存在的内容，我们正尝试添加新记录，希望这些记录能够覆盖那些幻影记录，并将一切恢复至应有的状态。
这绝对是我见过的最奇怪的 DNS 问题。
我完全同意 
那是一个 .org 的域名服务器。
DNSSEC 控制必须在您的注册商处进行，因为与粘合记录（glue records）类似，您域名的 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=
;; Received 252 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 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 记录。
因此，目前我已确认：注册商 Network Solutions 已正确配置了来自 Cloudflare（名称服务器）的新 DS 记录，而前注册商 Argeweb 也已移除了其记录。
希望全球范围内所有相关记录都能随之更新。NetSol 和 Cloudflare 的确认是在周三晚间完成的，而 Argeweb 的确认则是在今天早上。也许到了本周末，所有问题都会得到解决。祈祷
这应该不会超过一天。
这一切中充斥着太多的“应该”……Argeweb 本应在首次转移域名之前就禁用 DNSSEC。Network Solutions 本应在接收转移时能够看到并禁用它。
“应该”是整个项目的祸根。
我不确切知道注册商和根区域运营商背后的接口是什么；他们是发送增量更新还是每日完整更新。但他们应该了解该流程并采取了正确的措施。
同样，Network Solutions 在您将区域转移进来时，应该已将之前的 DS 记录导入到其界面中。据推测，他们也转入了 NS 记录，但也许您需要自行提供这些记录？
DNS 很难配置正确；DNSSEC 更是如此。
本该/本可以/本会
至少你知道问题所在以及如何修复它。
供应商几乎都会互相推卸责任。
我看到今天 pidforum.org 的 DS 粘合记录没有变化。
您是否已在 Network Solutions 界面中添加了正确的记录？
是的，上周晚些时候已在 Network Solutions 添加了正确的记录，但等待了整个周末……没有任何变化。错误的 DS 记录 30311 仍然隐藏在某个地方，似乎无人能够更改它。
您可以在该页面中看到正确和错误的记录。
正确的记录在 .org 层级并不存在，而该层级才是关键所在。
您需要敦促 Network Solutions 发布正确的记录。
您是否有域名配置中该部分的截图？
Network Solutions 未提供 DNSSEC 任何方面的公开管理界面。仅有一个支持小组负责处理此事，您必须通过电子邮件与他们联系。
不，我并非开玩笑。
今天我确实联系到了某一级别的支持人员，他们似乎对此有所了解，并告知我将在 24 至 48 小时内给予答复。
这仍然没有解决。哎哟，我理解你的痛苦 @griffey
我在 这里 运行了一次检查。您可以在结果中看到 KeyTag 30311 的位置。
错误：DNSKEY 2371 对 DNSKEY RRset 进行签名，但在父区域中未找到确认的 DS RR。未创建信任链。
致命错误：父区域包含已签名的 DS RR（算法 8，KeyTag 30311，DigestType 2，摘要 p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=），但目标 DNSKEY 不存在或无法验证 DNSKEY RR 集。未创建信任链。
仍未解决。可以说，Network Solutions 在处理 DNSSEC 和复杂的域名问题时完全无用。问题确实出在 DNSSEC 上，有一个 DSKEY（30311）似乎卡在某个地方，没人认为能够将其移除。
将您的域名迁移至 Google Cloud。
随后，您可以自行控制 DNSSEC 设置。
关于此问题的最终更新：虽然令人不太满意，但某些问题已得到解决，域名开始传播。目前尚不清楚具体发生了什么变化，因为我仍然可以看到 30311 DSKEY 条目。但无论注册商方面发生了什么，现在它已正常运行。
感谢您的更新