This is [was; the quote in the parent was edited] incorrect, the response includes `header.ad`, which on Linux is controlled by both what the resolver responds with and `option trust-ad` in /etc/resolv.conf, so the administrator can choose if they trust their resolver via "trust-ad".

Thanks for clarifying, that makes more sense. I was just going by what the person I was replying to was saying.

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).

Yes, I mentioned the AD header. However, I stand by my statement that ssh(1) cannot confirm whether the answer was actually validated because an MITM could have set that flag.

If ssh is using the GNU C Library’s resolv functions, and it isn’t setting RES_TRUSTAD, then glibc will automatically clear the AD bit unless the sysadmin has configured the trustad option in resolv.conf. A competent sysadmin would only do that in cases where MITM is impossible - either a local validating resolver, or DoT/DoH to a remote validating resolver. It is true that ssh has to trust the sysadmin to be competent and not enable that option in cases where MITM is possible, but I think that’s a general assumption for security that the sysadmin is doing the right thing, otherwise there are numerous other possible insecure configurations which might break ssh’s security. To double foolproof it, ssh_config could come with its own trustad setting independent of resolv.conf, so you’d have to set both.