[network] interface-aware DNS lookups

[avtolstoy]

Problem

Despite the fact that we store all interface-specific DNS servers (statically configured or over DHCP/PPP etc) the resolver only uses the first and then on failure subsequent servers in this table. There is no API to tell the resolver to use only interface X.

This may have undesired effect even on cloud connectivity. For example, in case of M SoM with eth, wifi and cellular available, but eth and wifi providing bogus DNS responses (app firewall or other reasons), while the connection can still be performed over cellular, it might fail because we are unable to correctly resolve cloud server address.

Solution

1. Introduce an API to perform interface-aware lookups
2. Make sure that when initiating a cloud connection we perform lookups through the ACM-selected network interface
3. Make sure that ACM round-robins interfaces for DNS lookups in case of reachability failures. This is not ideal, but is a trade-off to not perform up to currently 3 blocking DNS lookups per each interface, as that can take a signficant amount of time.

Steps to Test

TODO

References

particle-iot/lwip#17

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[scott-brust]

ill review lwip changes in its PR

[scott-brust]

Will using the iface from the round robin selection above filter out all the other resolved addresses from the other interfaces dns_tables?
Are we relying on there being multiple entries in info in order to implicitly associate a resolved address with a network interface? Do we only test one interface with this change?

[scott-brust]

I guess in situations where lastTestFailed did not fail, we will still test all interfaces. IE iface = NETWORK_INTERFACE_ALL. So in effect, we will round robin test 1 interface at a time with its DNS until it succeeds. Then all subsequent tests will use all available interfaces

[avtolstoy]

Something like that, yes. It's just a trade-off to get out of this weird state:

This may have undesired effect even on cloud connectivity. For example, in case of M SoM with eth, wifi and cellular available, but eth and wifi providing bogus DNS responses (app firewall or other reasons), while the connection can still be performed over cellular, it might fail because we are unable to correctly resolve cloud server address.

Again, ideally during the test we'd resolve X number of times per each iface with its set of servers, but it's a blocking call and might take a while, so as a trade off - normally we use NETWORK_INTERFACE_ALL - so the default prioritization in DNS server list, in case we see a complete reachability failure we'll round robin through all ifaces/their dns servers to try to correctly resolve, yes, this might take several iterations - but we'll recover. And cloud connection layer subsequently will use the same servers/interface to resolve before establishing connection.