Local DNSSEC resolver and Docker(containers)

Matt Micene nzwulfin at gmail.com
Thu Jan 15 18:17:16 UTC 2015


>
> 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 at fedoraproject.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20150115/0576d328/attachment.html>


More information about the cloud mailing list