Building consensus over DNSSEC enhancements to glibc.

[Zack Weinberg]

On 11/18/2015 10:40 AM, Petr Spacek wrote:
> On 17.11.2015 06:14, Carlos O'Donell wrote:
>> 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).
> 
> Uh, I do not think that any hardcoded list would work. DNS is being extended
> all the time and often in an unexpected ways so hardcoded lists will cause
> problems sooner or later, and most probably conflict with RFC 3597 [Handling
> of Unknown DNS Resource Record Types].

This does not have to be as difficult as you are making it.

Unsigned zones are allowed for compatibility only.  New record types do
not have to work in unsigned zones.  In fact, new record types SHOULD
NOT[rfc2119] work in unsigned zones, because if they only work in signed
zones the security considerations become simpler.

Therefore, glibc can and should hardcode a whitelist of record types
that are allowed to work in unsigned zones, and we're done.

zw