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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>, libc-alpha at sourceware dot org
- Date: Tue, 17 Nov 2015 00:14:51 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <20151109180310 dot GO3818 at brightrain dot aerifal dot cx> <5641C454 dot 3030309 at redhat dot com> <20151110174923 dot GS3818 at brightrain dot aerifal dot cx> <56433969 dot 10405 at redhat dot com> <20151111154525 dot GW3818 at brightrain dot aerifal dot cx> <56436FB2 dot 2010302 at redhat dot com> <20151111170706 dot GY3818 at brightrain dot aerifal dot cx> <5649BB13 dot 6040907 at redhat dot com> <20151116162328 dot GR3818 at brightrain dot aerifal dot cx> <564A1CB0 dot 7080508 at redhat dot com> <20151116182146 dot GT3818 at brightrain dot aerifal dot cx> <564A2968 dot 70003 at redhat dot com> <564A8535 dot 4070904 at panix dot com>
On 11/16/2015 08:39 PM, Zack Weinberg wrote:
> On 11/16/2015 02:07 PM, Petr Spacek wrote:
>> Please note that necessary level of trust is different for different DNS
>> record types. For A/AAAA records it is widely accepted that results may be
>> forget and applications are counting with that. For other purposes like TLS
>> certificate validation it is necessary to have full confidence in the data, so
>> validation results has to be properly communicated to the application. The
>> list of "must be secure" record types is changing over time, so it is not
>> feasible to hardcode list to resolver libraries.
>
> Again, applications cannot be trusted to process AD correctly. The
> correct approach is for the resolver to hardcode a list of records that
> *should* be passed through even if received from an unsigned zone: A,
> AAAA, PTR, MX, SRV, TXT. I think that's it.
I agree that applications should not see the AD-bit unless processing the
DNS queries and responses themselves (like my example of openssh does in
my other on-thread response).
In the case of the glibc APIs my preferred solution for policy-based
whitelist/blacklist of records as you suggest is for the validating
resolver to make those decisions (relaying them back to the application
via the secured channel).
Cheers,
Carlos.