Florian Weimer:
> * 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.
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.
> > 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 messed up. My complaint was about prior email that had a proper
reply-to header.
> I've dropped everything but the list for this reply.
And as expected, i receive only copy from the list.
Wietse
