Bug #2415
closed
util::dns::Resolver fails on some platforms
Added by Alex Afanasyev over 9 years ago.
Updated over 9 years ago.
Description
When making DNS resolution query, the current code adds query::all_matching parameter to the query constructor.
With this parameter, the resolver supposed to return all IPv4 and IPv6 matches on a system that does not have a working IPv4 and/or IPv6 address (the default behavior is to return addresses that can potentially work). This addition was made primarily for the sake of unit tests.
At least on FreeBSD and Android platforms it is known that this addition causes DNS resolution failure.
My proposal here is to remove query::all_matching parameter from the query completely. On a working system, the default behavior for the resolution is the correct one. For the test cases we can add a requirement to have both IPv4 and IPv6 configured (there just need to be an interface with non-localhost address). We can also make DNS resolution test cases optional or conditional.
- Subject changed from util::nds::Resolver fails on some platforms to util::dns::Resolver fails on some platforms
I don't understand the issue description.
The hostname to be resolved and the platform configuration can have the following nine combinations:
|
IPv4-only platform |
IPv6-only platform |
IPv4+IPv6 platform |
| hostname has A record only |
|
|
|
| hostname has AAAA record only |
|
|
|
| hostname has A and AAAA records |
|
|
|
For each combination, please answer:
- What's the expected behavior?
- What's the actual behavior with
query::all_matching?
- What's the actual behavior without
query::all_matching?
The documented behavior of query::all_matching
|
IPv4-only platform |
IPv6-only platform |
IPv4+IPv6 platform |
| hostname has A record only |
A |
A |
A |
| hostname has AAAA record only |
AAAA |
AAAA |
AAAA |
| hostname has A and AAAA records |
A, AAAA |
A, AAAA |
A, AAAA |
On FreeBSD and Android platform when query::all_matching is specified, the query always fails, no matter what the local configuration is.
The default behavior (as documented):
|
IPv4-only platform |
IPv6-only platform |
IPv4+IPv6 platform |
| hostname has A record only |
A |
- |
A |
| hostname has AAAA record only |
- |
AAAA |
AAAA |
| hostname has A and AAAA records |
A |
AAAA |
A, AAAA |
Given the tables in note-3, using the default behavior makes sense to me.
I agree with dropping query::all_matching. This shall be a change in utils.
Regarding test cases: a global fixture shall detect whether the platform supports IPv4 and IPv6, and write the results into static boolean flags.
A test case that relies on IPv4 or IPv6 shall be written as:
if (!NetworkConfigureDetector::hasIpv4())
return;
// test with IPv4
NetworkConfigureDetector::hasIpv4() should have BOOST_WARN_MESSAGE("Platform does not support IPv4, skipping test case");, so that this warning isn't repeated in every test case.
- Category changed from Tests to Utils
How are you suggesting to do the network connectivity detection?
How are you suggesting to do the network connectivity detection?
Check whether a non-local IPv4/IPv6 address is configured.
That's not a suggestion. That the effect we want to check. How are you expecting us to do this check?
Would using the DNS resolver itself for this be sufficient? In other words, in the fixture we'll try to resolve a host with A and AAAA and depending on which are available enable or disable IPv4 / IPv6.
- Status changed from New to Code review
- Assignee set to Alex Afanasyev
- % Done changed from 0 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by