In fact, even if the original domain does support DNSSEC, can a userspace program such as the SSH client actually tell whether the record it just resolved was resolved using a DNSSEC-aware resolver?
There's an "ad" (Authenticated Data) flag in the DNS reply header that a resolver can set to 1 to indicate that it validated the answer, but an MITM can also just set that to 1. The client would have to do its own validation, and ssh(1) doesn't. Therefore, you can only safely use this if you use a DNSSEC-validating resolver, and you trust the resolver (e.g. you administer it yourself), and you have a trusted path between you and it (e.g. it's on your LAN).
Isn’t this a gap in the API? res_query/etc should provide some way to find out if the response is validated or not. That would require either (1) a validating resolver running locally, or (2) a remote validating revolver, accessed over a secure protocol (such as DoT or DoH), which the system administrator has elected to trust. But the system should be able to tell applications, via some API, whether (1) or (2) hold or not
The man pages on my Linux box are too old to mention the trust-ad option, although newer Linux man pages do.
glibc defines a RES_TRUSTAD bit which is equivalent, so applications can choose to request and trust the AD bit even if resolv.conf isn't configured to do so. However, that doesn't appear to be documented anywhere other than the header file and the NEWS file in the glibc distribution. Both RES_TRUSTAD and trust-ad were added in glibc 2.31 (released Feb 2020).
EDIT: I meant for this to be a reply to my sibling comment.
If you're on Ubuntu, you most likely have a local resolver running already.
*: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.
That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.