dns cache: support per interface dns resolution

[junr03]

Description: there exist certain environments where it is important for DNS resolution to be different per available network interface, e.g., mobile devices where a resolved address for a home wi-fi network might not be valid on a cellular network.

This feature request covers two parts:

1. Allow for interface specification on dns resolver queries:
   • Apple:
   • This thread discusses a similar use case.
   • This is possible by using the interface index param in DNSServiceGetAddrInfo, and is assertable in the returned interface param in the reply. The interface index is stable
   • c-ares:
   • It is less straightforward to create queries on a specific interface in c-ares. However, there are at least a couple options:
     • ares_set_local_dev causes all future sockets to be bound to a particular interface. This will allow for populating the cache sequentially as there are triggers to query on given interfaces. Note that: This option is only supported on Linux, and root privileges are required for the option to work
     • Potentially getting an address list of available DNS servers per interface to the device and set them via resolvers configuration.
2. Allow the DNS cache to specify interfaces on cache look ups. This might be implemented in one of two ways:
   • DNS Cache per interface: with independent host lists. Rough sketch of this implementation option via @mattklein123:
   • Allow the proxy filter to attach to more than 1 DNS cache (names must be unique).
   • Allow the DFP cluster to attach to more than 1 DNS cache (names must be unique). Cluster must maintain parallel host sets for each attached cache since the host names will be the same.
   • Allow the cache to be selected using metadataMatchCriteria(), since this can be supplied in stream info (and set via the interface selection filter). It is also supplied via LbContext, so can be used by the cluster.
   • The retry options predicate will also need to be able to change the match criteria, but that is pretty simple.
   • One cache with ability to tag and query hosts by hostname,interface pairs.
   • I sketched a rough draft of this idea and the code lend itself naturally to it.
   • (+) the information about a hosts particular interface lives naturally in it, and would allow for concurrent queries to all available interfaces without handling several caches.
   • (+) this option would allow for doing the same for port number, if desired.
   • (-) there is a lot of plumbing to be done which would be avoided with the former solution where there would be different caches per interface.

[mattklein123]

cc @alyssawilk @RyanTheOptimist

[junr03]

Had an interesting discussion with the folks over at google (@alyssawilk @RyanTheOptimist @DavidSchinazi).

• There is a general hypothesis that utilizing https://github.com/envoyproxy/envoy/pull/18165 will bring most of the benefits we might be able to get with having per interface entries. The only slight difference might be that with this feature, relevant entries would be in the cache already when a network change occurs resulting in slight performance improvement.
• This feature would be novel in the sense that chrome does not do this today. It only flushes the cache on network changes