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: Paul Wouters <pwouters at redhat dot com>
- To: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Cc: Simo Sorce <simo at redhat dot com>
- Date: Sat, 7 Nov 2015 08:19:22 +0900
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <20151105012328 dot GU8645 at brightrain dot aerifal dot cx> <563C760E dot 4060107 at redhat dot com>
On 11/06/2015 06:42 PM, Petr Spacek wrote:
> Hopefully this explains the role of Glibc: It is *the* provider of canonical
> DNS API, so it is a natural place where the signal 'AD bit can be trusted'
> could be exposed to applications.
Note that I talked to the getdns/verisign people at IETF94, and I told them what
our requirements would be as well. They are now thinking of a "get_addr_info2"
that could be a dropin replacement but has some more information available. But
they are also focusing on the "rather unsafe then broken" premise. I pushed back
on that saying that would not be usable for us.
> Other proposals which fail safe are more than welcome, but anything which does
> not fail safe will do more harm than good.
Although getdns people are thinking about allowing different policies for different
RRTYPEs, so that for instance an A record that would not resolve with dnssec but would
resolve without dnssec, would still be returned to the application. But not SSHFP or
TLSA records.
While it seems that could work for most things, it runs into issues with indirection,
like CNAME's or MX records. If you can spoof the MX record to mx.yourdomain.example
and you run TLSA on those servers, it would all still look secure while you did get
lured to the wrong server.
Paul