FedRAMP is designed to provide reusable cybersecurity work against the NIST security controls that your Federal agency's Authorizing Official deems your Federal IT system must implement.
Those security controls come from a document NIST SP 800-53, 2 of which (that Slack linked to in the linked post-mortem), SC-20 and SC-21, effectively seem to me to conspire to require DNSSEC. Both of these are included as part of the "Low" baseline of security controls, so they are effectively required for all Federal IT systems unless your Agency Authorizing Official wants to walk on the wild side.
So even if you get a FedRAMP certification, if you do it without fully implementing SC-20 and SC-21, that just means your customer needs to either convince their Agency Authorizing Official to sign off on an ATO despite the missing SC-20 and SC-21 security control, convince them to sign off on some sort of Plan of Action and Milestones where Slack will commit to fix this in the future (which is just kicking the can down the road), or somehow manage to implement the same effect completely within the customer end without help from Slack. All you would have done is to spend a lot of money on FedRAMP paperwork without making it appreciably easier for potential customers who have to deal with compliance regimes to buy your product.
Cloud.gov's argument is valid but all they posted is that they don't implement SC-20 or SC-21 for their government customers, and that the OMB M-08-23 mandate for DNSSEC is no longer operative (not that no other DNSSEC mandate applies). Indeed they even give explanation for how their customers should work to enable it (presumably by refusing to use the non-DNSSEC compliant .app.cloud.gov services and instead using only their DNSSEC-compliant custom domains).
FWIW I fully agree with tptacek's arguments against DNSSEC, and will note that I recently stopped being able to navigate to literally the entire .mil on my Linux host until I disabled DNSSEC in systemd, for reasons that are still unclear to me even now.
Not everyone agrees with the linked argument. For example, I disagree that browsers can't take advantage of DNSSEC, since many are using DoH, and the rest of the article reads like someone complaining that we need to wait for the perfect protocol or nothing at all.
That's the thing about a debate... it's got arguments on both sides.
I mean, I agree with you and don't find the language disingenuous (I felt like it was more of a tell that the people working on this cursed project weren't super read into DNSSEC and DNS security in general, which isn't a knock; it's a boring thing to keep up with, especially when the best-practice answer is so simple --- just don't bother with DNSSEC).
But I'd also say that DoH (1) largely obviates any need for DNSSEC (the last-mile DNS problem is the only on-the-wire DNS security problem that needs solving) and (2) doesn't enable DANE in browsers, which is what people are talking about when they talk about DNSSEC intersecting with browsers in any way other than randomly making sites fall off the Internet.
It's fine to disagree with the linked argument, but you actually have to do so. This is them presupposing that "securing Slack for [their] customers" requires DNSSEC -- it's not engaging with the argument at all.
> While we are aware of the debate around the utility of DNSSEC among the DNS community, we are still committed to securing Slack for our customers.
The argument is specifically that it doesn't provide that security. At least it's neat to see actual begging the question in the wild, I guess.