No, that was a comprehensive answer that explained why the question of whether the stub resolvers in macOS or iOS “supports” DNSSEC didn’t make sense to begin with.
But I should clarify further: the Unix part of macOS does what all Unix-style operating systems do: the stub resolver forwards the requests to whatever is in /etc/resolv.conf.
But the Foundation Kit part of macOS indeed supports DNSSEC and has for years; I gave the link to the docs that describe how an app can use it. I suspect Apple and various 3rd parties have been using it for years.
Macs are popular in higher ed and government; I’m sure enough of these accounts required macOS to have DNSSEC capability built-in. Same thing for iOS.
Neither higher ed nor government services require DNSSEC. It's understandable why you'd think they do, because for several years the federal government did require it. They rescinded that requirement. CLOUD.GOV doesn't even support DNSSEC.
By the way, .APPLE? New gTLDs are required to be DNSSEC-signed. It's no surprise that ICANN supports DNSSEC.
Apple can do whatever they want. The fact that their TLD is DNSSEC-signed is not an indication of what they will do, despite your claim to the contrary.
We've been talking on HN about mDNSResponder for over 5 years. It has un-baked DNSSEC support that macOS has never used. mDNSResponder was replaced by another service (Yosemite's Discoveryd) which had zero support for DNSSEC, but instability forced them to revert back.
The macOS system resolver does not support DNSSEC, has never supported DNSSEC, and the fact that mDNSResponder has/had DNSSEC code is not an indication that they're embracing it. By the way: I have better sources on this than just my opinion of the source code.
