While it is generally not common for Arch Linux to change an option to something different than that of the upstream, I believe there to be multiple compelling reasons to do so. I also hope that Arch Linux’s adoption of this change can be used to convince the upstream that this is the proper thing to do by default.

The OpenSSH client option VerifyHostKeyDNS causes SSH to perform a DNS lookup for SSHFP records when connecting to a server at a domain. An SSHFP record can contain a SSH host authenticity key fingerprint. With VerifyHostKeyDNS set to ask, this can be used as an additional layer of security.

Upon connecting for the first time, the SSH client will notify the user if the host key supplied by the SSH server is the same as one from the SSHFP records. If a fingerprint is present in the known_hosts file, it will automatically verify that it is the same as the one from the SSHFP record. If there is no record present, the client will simply warn the user on the initial connect and then continue to work normally thereafter.

VerifyHostKeyDNS should be set to ask, not yes. By setting VerifyHostKeyDNS to yes, the SSH client will trust the DNS SSHFP record implicitly if DNSSEC is present and valid for the domain. This is not secure as it is delegating security to DNSSEC and assuming that DNSSEC is secure. By setting VerifyHostKeyDNS to ask, the client never trusts the DNS SSHFP record implicitly. This is the best choice as it is building security in layers; it is using multiple potentially secure methods of verification in conjunction, thus increasing the security of the system as a whole.

There were numerous attempts to get the default setting for the VerifyHostKeyDNS option changed from no to ask about a decade ago, the only valid argument against it being that there would be a delay of a few milliseconds for the DNS lookup. I feel that this almost insignificant additional delay is more than worth it for the additional security that it provides.

The reasons why I suggesting that Arch Linux make this change before suggesting it to the upstream is multifold:

Firstly, it would be much easier to convince the upstream to make this change if a major distribution already has. Meaning that it would be much easier to increase the security of almost all new SSH installations.

Secondly, I am trying to convince the AUR 4 to adopt SSHFP records. I already submitted another bug report for this. Other than the obvious multiple layers of security that it would provide, there is another very important reason to do so.

Prior to 2015-06-14, the AUR 4 was affected by this issue: https://bugs.archlinux.org/task/45322
The AUR 4 SSH host authenticity key fingerprints were not posted in an easily visible and secure location. Because of this, the maintainers and users of over 11000 PKGBUILDs blindly accepted the SSH key fingerprints presented to them on their initial connect. This means that, potentially, the vast majority of the AUR 4 user and maintainer base could have, and still might, be the victim to a man-in-the-middle attack. Due to the fact that this incredible number of people accepted the fingerprints with no sort of verification at all, it leads me to doubt that these users would have verified them after they were published to the front page of the AUR 4. It also leads me to doubt that new users are actually checking if the fingerprints are valid at all.

If this setting was enabled, it would alert users of keys that do not match the ones that they already accepted, effectively mitigating this issue. DNSSEC should be enabled for the archlinux.org domain to provide even more security.

This issue is not limited to the AUR, but rather any service that provides SSH access. If such a large number of users and maintainers would accept the AUR’s SSH fingerprints without verification, who says that they will for other services? For example, GitHub, which already provides SSHFP records.

Obviously, without DNSSEC, against a sophisticated attacker, this change would have no effect. But it would make it more difficult for someone to pull off an attack and would pave the path for services to be more secure as DNSSEC gets deployed.

I sincerely hope that Arch Linux maintainers reading this will make the proposed change due to the potential major impact it could have on SSH security. Hopefully, after implementing this, we can convince the upstream to do so as well.