* Wietse Venema: >> This is an interesting data point because the interaction between >> RES_DEFNAMES, RES_DNSRCH, and the ndots and no-tld-query options are >> far from obvious. Even the exact impact of RES_DEFNAMES and >> RES_DNSRCH probably varies between code written from scratch and the >> BIND stub resolver codebase, which seems to have gone from one search >> list entry to multiple entries at one point (I wasn't around back >> then). It's not merely of historic interest because with the current >> set of flags we expose in the glibc /etc/resolv.conf parser, it is not >> possible to adhere to the ICANN recommendations for search list >> processing. I will take the Postfix use case into account when >> changing this. Thanks. > > I exposed these two options in Postfix configuration using the > existing names and semantics, so that users would not need to learn > different names with different semantics. Humans have better things > to do than riding bikes with a reversed steering mechanism.
Except that these flags have never been exposed as /etc/resolv.conf options in any implementation, as far as I know. They were targeted at application programmers only. So whether they were familiar to mail administrators at the time is debatable. (I don't even know what the semantics should be if one sets just one flag and not the other.) But all that matters now only insofar as I have try to avoid breaking existing Postfix configurations needlessly.
