This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING] Re: DNSSEC support in stub-resolver
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Petr Spacek <pspacek at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 15 May 2014 23:32:46 +0200
- Subject: Re: [PING] Re: DNSSEC support in stub-resolver
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com> <20140428133201 dot GB24365 at domone dot podge> <5360BBBD dot 30901 at redhat dot com> <53737979 dot 9060006 at redhat dot com>
On Wed, May 14, 2014 at 04:11:05PM +0200, Petr Spacek wrote:
> ping
>
> On 30.4.2014 11:00, Petr Spacek wrote:
> >I don't think that glibc is the right place to add dependency on
> >SSH/SSL/IPSec/TSIG-CGA/any other particular "secure transport" technology.
> >
> >Also, this doesn't allow you to handle cases where admin is sure that plain IP
> >transport is secure (i.e. VM/container). Consider use case with one physical
> >machine running hundreds of containers with Apache inside...
> >
> >Reconfiguration can be handled by external tool/daemon. The daemon can detect
> >presence of trusted channel and reconfigure the list of trusted resolvers as
> >needed.
> >
> >I hope this explains the intent. Have a nice day!
I would start with simpler steps first, a huge patch for What about adding configure
option/env variable to only trust localhost resolvers.
Then you could use iptables port forwarding when ip is trusted or ssh
etc and this could be maintained without needing to reconfigure.
Does that handle all use cases or do you have a corner case?