Re: ai_flags in calls to getaddrinfo, broader call for reproducibility check

[Robin Tarsiger]

Eli Zaretskii wrote:
> Is it possible to check this via network-interface-list, and avoid the
> test with IPv6 if that is bound to fail?

The relevant part of the tests should, generally, be about DNS _lookups_
of IPv6 addresses. This is not "truly" related to whether your local host
has IPv6 connectivity at the network layer. I have no IPv6 routing at
home currently, but getaddrinfo will still give me all the IPv6 results
I want; I just won't be able to connect there. I expect that case to be
common. The opposite case, where I could have IPv6 networking available
but have restrictive upstream DNS resolvers blocking queries for or results
containing IPv6 addresses, is also theoretically possible, though I would
expect it to be rare.

So basically you'd be testing the wrong thing. You could try to err on the
side of caution, but then you'd be excluding the test in a lot of cases
that really should work.

If your upstream resolvers default to mangling or blocking AAAA queries, as
my current best hypothesis suggests, this is not something an application
can reasonably take responsibility for fixing up, and we'd want to go the
route of "skip network-environment-dependent tests when on hosts that are
in strange/broken network environments". I don't know whether there's an
existing toggle for that; if not, then that would be the thing to put in
(at whatever granularity seems appropriate).

There is no _reliable_ way I know of to determine this programmatically,
certainly not without sending some probe queries with a high level of
specific control over them, and I expect that would be a rather hairy
thing to do just for a few tests, and not reasonably maintainable.

Another perspective on above is that when you mention "behind firewalls up
the kazoo", what my intuition imagines is something like: corporate DNS
filtering which only allows specific request types and either was never
updated to think of AAAA queries as valid, or is operated in a way assuming
that users will never have a legitimate need for them (because they "won't
be able to use" the results), or does this as a workaround for some broken
behavior elsewhere (such as some other device used in the organization
which will prefer an IPv6 address response even when it's not reachable,
and fail to fall back to IPv4?) or... any number of things like that.

The main thing that hypothesis doesn't explain is the discrepancy in the
any-family results, but that could easily be by accident depending on how
the specifics of the filtering interact with the specifics of the pattern
of queries Windows generates under those circumstances, which is why I was
originally thinking of finding out the latter; or it could be some local
filtering that Windows does depending on local connectivity for similar
reasons to the above, which is why I wanted to see whether those flags
made any difference for Windows machines on more "conventional" networks.

-RTT