Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

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].

Resolvers are just a 'pipe' which does not really understand what kinds of
data are flowing through it, and IMHO it should stay like that.

My hope is that security-sensitive DNS records will be consumed by specialized
libraries (imagine GnuTLS consuming TLSA records) so the code will be
centralized in some sense, just not in the validating resolver.


A compromise could be an API flag 'require secure answer' which can filter out
responses with AD = 0 on the API level. It should be quite obvious to
application developer calling the API that 'require secure answer' is the
thing he wants to turn on when writing a security-sensitive code ...

The problem is that current res_ interface does not seem as extensible, so I
do not know where to put the flag.

-- 
Petr Spacek  @  Red Hat