ssh: default VerifyHostKeyDNS to no, following upstream

[emaste]

Summary

Revert to upstream's default.  Using VerifyHostKeyDNS may depend on a
trusted nameserver and network path.

This reverts commit 83c6a5242c80160fff76fb85454938761645b0c4.

Reported by:    David Leadbeater, G-Research
Relnotes:       Yes
Sponsored by:   The FreeBSD Foundation

[emaste]

Reference: https://blog.des.no/2013/10/verifyhostkeydns/

[zlei]

In D38648#880933, @emaste wrote:

Reference: https://blog.des.no/2013/10/verifyhostkeydns/

3. If an SSHFP record was found:
     1. If it matches the server’s key:
         1. If it has a valid DNSSEC signature and VerifyHostKeyDNS is “yes”, continue connecting
         2. Otherwise, set a flag to indicate that a matching SSHFP record was found
     2. Otherwise, warn about the mismatch

I've not looked into OpenSSH's source code, but the logic seems not right.

IMO a SSHFP record should be used only when its DNSSEC signature is validated and valid, otherwise the record is not trusted and should be not be used and ignored.
So the step 3 should be If an SSHFP record was found and has a valid DNSSEC signature.

A landscape:

3. If an SSHFP record was found and has a valid DNSSEC signature:
     1. If it matches the server’s key:
         1. If VerifyHostKeyDNS is “yes”, continue connecting
         2. Otherwise, set a flag to indicate that a matching SSHFP record was found
     2. Otherwise, warn about the mismatch

Back to this topic, any chance that the logic could not be fixed ? Or this is only a temporary fix ?

[gordon]

Looks good to me.

[emaste]

Back to this topic, any chance that the logic could not be fixed ?

Yes, we should fix OpenSSH's host key handling, and also improve the resolver.