Trusted path could also be DoH or DoT as well, but yeah, not just 53/udp in the clear over the internet.

An example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today.

If you're on Ubuntu, you most likely have a local resolver running already.

On Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*.

*: 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.

Perhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.

There should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there?

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.

I believe that is DNSSEC=allow-downgrade which is also the default.

I thought “allow-downgrade” meant it would return unsigned data, but not invalidly signed data? I was talking about the latter case not the former.

You could be right. I guess the documentation isn't terribly clear...

> and no, ssh(1) can't confirm if the answer was actually validated or not.

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

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.