* Wietse Venema: > Florian Weimer: >> * Wietse Venema: >> >> > Florian Weimer: >> >> * Wietse Venema: >> >> >> >> > Florian Weimer: >> >> >> * Rich Felker: >> >> >> >> >> >> > A solution that would work with existing and future versions of musl >> >> >> > as well as glibc, and would (I think) avoid the need to poke at _res >> >> >> > to set the glibc trustad flag, would be replacing the call to >> >> >> > res_query with res_mkquery, |='ing the AD bit into place, then >> >> >> > res_send. >> >> >> >> >> >> This will not give the result that Postfix programmers want on newer >> >> >> glibc versions (not without the trust-ad flag in /etc/resolv.conf). >> >> > >> >> > The problem with using low-level res_*mkquery() is that Postfix >> >> > would have to re-implement all the high-level res_search() features >> >> > such as RES_DEFNAMES, RES_DNSRCH, retries over TCP after receiving >> >> > a truncated response, and so on. >> >> >> >> I don't think this is actually an issue: TCP fallback is still >> >> performed with res_send. If you care about DNSSEC validation, you >> >> cannot really use search list processing anyway because you might not >> >> get back the name you wanted after an unauthenticated query failure, >> >> so the lack thereof with res_send actually avoids the cumbersome flags >> >> manipulation. >> > >> > Fine, so res_*send() does retry. >> > >> > As for RES_DEFNAMES and RES_DNSRCH, these might be needed for lookups >> > other than DNSSEC, so I can't simply drop support for them. >> >> I think the way you manipulate the flags essentially turns res_search >> into res_query, so why not call res_query directly? > > Did you mean that res_search with BOTH flags off == res_query? Why > would I want to add extra code for the case that BOTH flags are off?
I looked at the Postfix history behind this, and it seems that as part of the fix for unexpected search list processing, the (more or less) internal resolver flags were exposed via the Postfix configuration, instead a new flag to choose between res_search and res_query. 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. > If I may ask a stupid question: my post says Reply-to: postfix-users, > Please do not send me an extra copy of your resoponse. Hmm. I see this: Reply-To: i...@porcupine.org, res_qu...@porcupine.org I've dropped everything but the list for this reply.
