BIND_8_COMPAT appears to be required to be set by configure, and when it is the ssh client is ignoring the ad bit set in the dns response, resulting in a host key verification failure. "debug1: found 1 insecure fingerprints in DNS" Verified with a packet sniffer that the ad bit was indeed set in the response.
UPDATE: Managed to get this to compile and work, but it's rough. BIND_8_COMPAT undefined in config.h All files dependent on resolv.h, updated also to include nameser_compat.h. config.h #define HAVE_HEADER_AD Compiles and works properly.
This was tested on Leopard (10.5), by the way. openbsd-compat/getrrsetbyname.c uses a struct called HEADER to check the flags for the AD bit, in particular, this bit of code from around line 275: #ifdef HAVE_HEADER_AD /* check for authenticated data */ if (response->header.ad == 1) rrset->rri_flags |= RRSET_VALIDATED; #endif Openssh is using not the new enum __ns_flag from /usr/include/arpa/nameser.h, but the compatability code usually in /usr/include/arpa/nameser_compat.h. It's there on my NetBSD system, and with BIND_4_COMPAT defined, arpa/nameser.h will include arpa/nameser_compat.h. MacOS has a similar BIND_8_COMPAT flag, which when defined makes arpa/nameser.h include arpa/nameser8_compat.h. Unfortunately, that's an older version of the file which has the AD bit in that structure marked as "unused." The way to fix this is to make sure that BIND_8_COMPAT is *not* defined, and instead bring in the newer version that MacOS also has, arpa/nameser_compat.h (note the lack of an "8" in the name). This needs to be done for both openbsd-compat/getrrsetbyname.h and for the code in the configure.ac script used to determine whether to define HAVE_HEADER_AD. This should probably also be done for openbsd-compat/inet_ntop.c, though it doesn't use the AD bit. It would be good if we could set up some sort of test suite that could test that this is working, as it seems to break on a regular basis, probably because for whatever reason almost nobody uses this extremely useful feature. (Maybe nobody likes to set up secure DNS.)