This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: Andreas Schwab <schwab at suse dot de>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 19 Nov 2015 09:20:46 +0100
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <56429E2A dot 7050208 at panix dot com> <5646BAA9 dot 9000009 at redhat dot com> <564A7D2E dot 4030503 at panix dot com> <564AA295 dot 9000505 at redhat dot com> <564D4694 dot 3080706 at panix dot com>
Zack Weinberg <zackw@panix.com> writes:
> First, I will note that at least one person in this discussion (Paul
> Wouters) wants to be able to outsource DNSSEC to a validating resolver
> that is *not* on 127.0.0.1. This is obviously a terrible idea when
> there is a physical network in between the client and the validating
> resolver, and I *think* he conceded that point to Rich, but he brought
> up the possibility of containers or VMs outsourcing to a validating
> resolver in another container or on the host, via a VLAN. It seems to
> me that even in that case we cannot be *certain* that response forgery
> is impossible (does the kernel actually contract to prevent address
> spoofing? are you *sure* there are no bugs?).
If the admin says so he should be able to assert it. glibc has no
business to second-guessing.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."