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

fweimer at redhat dot com via Glibc-bugs <[email protected]>
Newsgroups gmane.comp.lib.glibc.bugs
Message-ID <[email protected]/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=34515

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=25163
              Flags|                            |security-

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
I believe libcurl has the same behavior as getent here: it makes separate
getaddrinfo calls with AF_INET and AF_INET6.

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. 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).

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.