This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building consensus over DNSSEC enhancements to glibc.


On 11/17/2015 08:39 PM, Paul Wouters wrote:
> On 11/18/2015 04:04 AM, Carlos O'Donell wrote:
> 
>>>> So you'd have:
>>>>
>>>> (a) New synthetic hwcap bit "local-validating-resolver" which forces
>>>>     glibc to only talk to 127.0.0.1 from the very first userspace process.
>>>>
>>>> (b) New options flag "dns-strip-dnssec-ad-bit" which forces glibc to
>>>>     remove AD-bit data.
>>>>
>>>> Mix-and-match.
>>>
>>> That still does not do fail safe.
>>
>> Thanks for bringing that up again.
>>
>> So I am willing to concede flipping the meaning of (b) and defaulting
>> to always stripping AD-bit if that means we have consensus for a way
>> forward.
>>
>> I have background work in the Nuclear industry in Canada and I know
>> what fail safe means and the value it provides. Both from a certification
>> *and* usability perspective.
> 
> That would work for me. Thanks Carlos.
> 
> I don't think we then have a use for a) anymore unless that mechanism
> could somehow be extended to be configured - eg if a user uses NM to
> mark a wifi network as "trusted" that it would then somehow be able
> to add the network's nameservers IP's to the "trusted" set.

The policy for all of these use cases is very complicated.

Dare I say that systemd-resolved might solve some of this already?

http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html

It appears to have per-interface domain names, and could be extended
to have per-interface trust information which could be used to strip AD-bit
data within systemd-resolved before the data makes it to glibc?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]