in the continuing saga: Network Solutions confirmed to me that they did not see any DNSSEC records associated with the domain on their side…so…ghost in the machine from the previous registrar?
In any case, since they can’t delete what isn’t there, we’re trying to add new records and hope that those overwrite the phantom ones and kick everything back to where it should be.
This is by far the strangest DNS issue I’ve ever seen.
I have to agree 
That is a .org nameserver
DNSSEC controls must be done at your registrar since, like glue records, the DS records for your domain must be present at the TLD nameservers. Your DNS provider will have no control over that.
I still see the records present there:
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
and the analyser still shows an error:
You need to bother them until they get someone on their side to fix this - this is the registrar’s responsibility to get correct.
You might also get somewhere by talking to the previous registrar and asking them to stop submitting glue and DS records for your zone.
EDIT:
At the moment, your published .org zone records are:
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=
I did get confirmation this morning that the previous registrar (argeweb in the netherlands) did confirm that they finally removed the DS records for this domain from their system.
So at this point i have Network Solutions (registrar) that has confirmed they have correct (new) DS records in place from Cloudflare (nameserver) and that the previous registrar (Argeweb) has removed their records.
Hopefully, I just have to wait for all of that to shake out across the globe. NetSol and Cloudflare confirmation happened late on wed, and Argeweb confirmation happened this morning. Maybe over the weekend this will all reconcile. crossed fingers
It should take no longer than a day.
There’s a lot of Should going on in all this…Argeweb should have disabled DNSSEC before transferring a domain in the first place. Network Solutions should have been able to see and disable it on their end when transferred in.
Should is the bane of this whole project. 
I don’t know exactly the interface behind the registrar and the root zone operators; whether they send deltas or daily complete updates. But they should know the process and have done the right thing.
Likewise, Network Solutions should have imported the previous DS records to their intrerface as you transferred the zone in. Presumably they also transferred in the NS records, but maybe you had to supply those?
DNS is tricky to get right; DNSSEC even more so.
Should have / could have / would have
Atleast you know what the issue is and how to get it fix.
Suppliers will almost blame the other person.
I see today the pidforum.org DS glue has not changed.
Have you added the correct records to the Network Solutions interface?
Yep, added correct records late last week to Network Solutions, waited over the weekend…no change. The rogue DS record 30311 is still hiding somewhere, and no one seems to be able to change it.
https://dnsviz.net/d/pidforum.org/dnssec/
you can see both the correct and the incorrect records in that…
The correct record is not present at the .org level, which is where it matters.
You need to hound Network Solutions to publish the correct record.
Do you have a screenshot of that portion of your domain configuration?
Network Solutions doesn’t present a public admin for any aspect of DNSSEC. There’s only one group in the support group that deals with it, and you have to interact with them via email.
No, I’m not joking.
I did managed to get to some Tier of support today that maybe had a clue, and told me they would have an answer to me in another 24-48 hours.
this is still not sorted. ouch. i feel your pain @griffey
I ran a check here. You can see where the KeyTag 30311 is in the results.
Error: DNSKEY 2371 signs DNSKEY RRset, but no confirming DS RR in the parent zone found. No chain of trust created.
Fatal error: Parent zone has a signed DS RR (Algorithm 8, KeyTag 30311, DigestType 2, Digest p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=), but the destination DNSKEY doesn't exist or doesn't validate the DNSKEY RR set. No chain of trust created.
Still not solved. Let’s say that Network Solutions is absolutely useless when it comes to DNSSEC and complicated domain issues. It’s definitely DNSSEC and there’s one dSKEY (30311) that’s stuck somewhere in the ether that no one seems to think they can remove.
move your domain to google cloud.
you can then control dnssec settings yourself
As a final update on this…Unsatisfying, but something cleared out and the domain began to propagate. It isn’t clear what exactly changed, as I can still see the 30311 DSKEY entry. But whatever happened on the registrar front, it is now working.
Thank you for the update