Right, I've also heard about the special interface solution before.
Not sure how exactly it works though.
Can't claim to be an expert on the implementation details either, sorry.
I see. In that case, maybe we could have local resolver listening
on multiple network interfaces. But how would container know which
interface it should connect to? As in, is 169.254.169.254 consistent
across various container solutions(Docker/Rocket/LXC etc.)?
Docker already supports a --dns option on the commandline to pass details for /etc/resolv.conf. For the various container solutions, I'd expect providing a standard consumable location for the resolver would be a good start. A container specific implementation looks like a slippery slope.
-Matt M
On Thu, Jan 15, 2015 at 1:02 PM, P J P <pjp@xxxxxxxxxxxxxxxxx> wrote:
Hello Matt,
On Thursday, 15 January 2015 8:27 PM, Matt Micene wrote:
>One of the on list responses talks about setting up a known
>IP space, taking a page from MS and using a local collision domain.
>AWS does this currently, making a metadata service available from
>all instances on 169.254.169.254.
Right, I've also heard about the special interface solution before.
Not sure how exactly it works though.
>This could be a solution for a Docker environment, where a host
>provides the trusted DNSSEC enabled resolver on known single and
>unchanging IP address. This avoids the special nature of the
>loopback address, but gives consistency for a number of different
>approaches.
I see. In that case, maybe we could have local resolver listening
on multiple network interfaces. But how would container know which
interface it should connect to? As in, is 169.254.169.254 consistent
across various container solutions(Docker/Rocket/LXC etc.)?
Thank you.---
Regards
-Prasad
http://feedmug.com
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
