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: Petr Spacek <pspacek at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 20:11:48 +0100
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <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> <5649D87E dot 6080105 at redhat dot com> <5649D9D9 dot 4040206 at redhat dot com> <5649E193 dot 30903 at redhat dot com> <564A247C dot 9030700 at redhat dot com> <564A2555 dot 706 at redhat dot com>
On 16.11.2015 19:49, Florian Weimer wrote:
> On 11/16/2015 07:46 PM, Petr Spacek wrote:
>
>>> By the way, have you had a chance to review how an AD flag policy should
>>> interact with the search path configured in /etc/resolv.conf?
>>
>> Hmm, I apparently did not send the reply :-) Anyway, in my eyes 'search' is
>> inherently incompatible with domain name-based checks (be it TLS or DNSSEC or
>> whatever else).
>>
>> Speaking about AD bit, theoretically it could be set 1 if *all* intermediate
>> results had the bit set to 1, but I'm worried that applications would not
>> handle it correctly: Application would have to receive back the terminal name
>> which was found & use the name for domain name checks, which is error prone
>> and adds yet another layer which application developer has to take care of.
>>
>> Given that in TLS world search directive and use of short names lead to
>> validation failures (unless the cert contains the short name ...) I would
>> strip the AD bit if search is in use & name returned is not the same as name
>> originally requested by the caller.
>
> We would have to apply this stripping unconditionally, even for trusted
> recursive resolvers, I think. Do you agree?
Yes, in all cases where search was actually *used*.
If the name requested directly by application exists (i.e. search machinery
was not invoked so it could not change the name) the AD bit can be relayed to
application, assuming the AD bit came from trusted resolver.
--
Petr Spacek @ Red Hat