There are some features in name resolution that are quite useful on large systems. I'll refer to them by their POSIX names for lack of better terminology:
AI_V4MAPPED: When using an IPv6 stack that can do IPv4 but hides that from the application (using the dual stack features of IPv6), a stack could return Ok(IpAddr::V6("::ffff:10.0.0.1")) to a request.
AI_ADDRCONFIG: When a stack knows that it has no addresses of a given family, it can suppress sending requests for the corresponding kind of DNS records. Thus, unusable results are filtered out in some situations.
AI_ADDRCONFIG-done-right[^1]: Even when some addresses of a family are available and the host needs to send A and AAAA requests, it may turn out that it has no route to the addresses indicated. With AI_ADDRCONFIG-done-right, the lookup would filter those out (because the stack is in a way better position to do that than the recipient, who would effectively do trial-and-error, espeically with our APIs).
To me, from the docs, it is unclear from the documentation whether or not these are supposed to be done by get_host_by_name / whether support is optional or mandatory / how optional support is signaled.
My suggestions are those:
AI_V4MAPPED is behavior a stack may have. It is recommended that stacks be consistent, i.e. that they only work with ::ffff:v4 addresses, but that's hard to enforce.
AI_ADDRCONFIG and -done-right should IMO be recommended: the stack has the information, the user doesn't need it, and if a user does need to know the answers to DNS requests without the need to interact with them, chances are they're building some DNS program, and want to access a bunch of other details that this API doesn't expose either.
If a stack can not determine whether or not they're routable at all, it may violate that recommendation, but then users of that stack need to be aware that once such software is deployed on v4-only clients that talk to v4+v6 servers, they'll be on their own handling resulting errors. (They can recover by using something like #58, or by retrying and hoping that the one address they get is selected randomly).
Making it mandatory may be the better choice even.
Is that a line you could get behind, and could implement on your implementations of embedded-nal? If so, I can build all of this into a PR on the documentation.
[^1]: I'm aware that (modulo bugs in implementations), ADDRCONFIG is doing what it is supposed to do, but right now I don't have a better name for what I think it should do.
There are some features in name resolution that are quite useful on large systems. I'll refer to them by their POSIX names for lack of better terminology:
Ok(IpAddr::V6("::ffff:10.0.0.1"))to a request.To me, from the docs, it is unclear from the documentation whether or not these are supposed to be done by get_host_by_name / whether support is optional or mandatory / how optional support is signaled.
My suggestions are those:
Is that a line you could get behind, and could implement on your implementations of embedded-nal? If so, I can build all of this into a PR on the documentation.
[^1]: I'm aware that (modulo bugs in implementations), ADDRCONFIG is doing what it is supposed to do, but right now I don't have a better name for what I think it should do.