[Bug network/34515] resolver applies search path for AAAA queries even though ndots is exceeded

https://sourceware.org/bugzilla/show_bug.cgi?id=34515

--- Comment #9 from Fabian Vogt <[email protected]> ---
(In reply to Florian Weimer from comment #6)
> I believe libcurl has the same behavior as getent here: it makes separate
> getaddrinfo calls with AF_INET and AF_INET6.

Yeah, probably.

> The question is whether we should do search path processing if a lookup
> fails with the equivalent of EAI_NODATA (no matching protocol data, but name
> exists). Changing that behavior could be potentially disruptive, though.

IMO yes, and I do see the potential for trouble there.
The resolv.conf man page says abouts ndots:

> ndots:n
>   Sets a threshold for the number of dots which must appear in a name given to res_query(3)
>   (see resolver(3)) before an initial absolute query will be made. The default for n is 1,
>   meaning that if there are any dots in a name, the name will be tried first as an absolute name
>   before any search list elements are appended to it.

The query for AAAA code.qt.io. succeeds (dig reports NOERROR),
just with no data, so that could be interpreted as success?

> On
> the glibc side, we don't know about the two separate requests being
> submitted, so we cannot reconcile this data. Applications could perhaps
> compare ai_canonname with the original name and prefer the answer that
> matches, but that is fundamentally incompatible with Happy Eyeballs (you
> cannot make a request until you have both DNS responses and consolidated
> them).

IMO the behaviour should not differ based on whether the application makes
an A query, an AAAA query or both in any order. In any of those cases it should
get data for the same domain.

> Unfortunately, ndots only says whether an initial absolute query is
> performed. It does not disable search list processing. Providing an option
> that disables that is necessarily part of bug 25163, I think.

Yes, with ndots, the search list is effectively a fallback only. I'd also
prefer
for consistency, that with ndots:1 all domains containing a . will be treated
as
absolute, but in practice the fallback behaviour probably works well enough and
is more compatible?

(In reply to Andreas Schwab from comment #8)
> No, getaddrinfo didn't change.  It's only that the host using glibc 2.38 has
> nscd running, caching the previous negative answer.

nscd making DNS even more fun, as usual :D

IMO that shows though that treating NODATA as "success" makes it more
consistent
and was due to nscd actually effectively the default already!

Something like this works for me:

diff --git a/resolv/res_query.c b/resolv/res_query.c
index 30ace9d06d..1dea43d4a4 100644
--- a/resolv/res_query.c
+++ b/resolv/res_query.c
@@ -388,6 +388,7 @@ __res_context_search (struct resolv_context *ctx,
                                                 answerp2_malloced);
                if (ret > 0 || trailing_dot
                    /* If the second response is valid then we use that.  */
+                   || (ret < 0 && statp->res_h_errno == NO_DATA)
                    || (ret == 0 && resplen2 != NULL && *resplen2 > 0))
                        return (ret);
                saved_herrno = h_errno;

(maybe TRY_AGAIN should be accepted too, to ensure consistency)

 > getent hosts code.qt.io
 54.247.17.180   code.qt.io
 > getent hosts notcode.qt.io
 2a07:de40:b205:1c:10:144:53:65 gitlab.prg2.suse.org notcode.qt.io.suse.de
gitlab.suse.de

curl is happy too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.