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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Simo Sorce <simo at redhat dot com>, Paul Wouters <pwouters at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 19 Nov 2015 01:19:30 -0500
- 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> <5649A3F3 dot 2060309 at redhat dot com> <20151116161642 dot GQ3818 at brightrain dot aerifal dot cx> <564A0FED dot 9010408 at redhat dot com> <20151116181740 dot GS3818 at brightrain dot aerifal dot cx> <564A1E3E dot 5090703 at redhat dot com> <20151116182322 dot GU3818 at brightrain dot aerifal dot cx> <564AB3F9 dot 4020404 at redhat dot com> <564AC146 dot 1040305 at redhat dot com> <564AD51D dot 4040100 at redhat dot com> <564B3FA7 dot 8010100 at redhat dot com>
On 11/17/2015 09:54 AM, Simo Sorce wrote:
> I would prefer if glibc (and all other libraries) gave this
> information to applications themselves, as it would be more
> efficient. The "out of libc" method causes resolv.conf to be re-read
> 3 times which is a burden for short lived processes but is better
> than not trusting glibc and having applications implement their own
> crypto or have a dozen different methods to "configure" DNSSEC.
I believe the following answers all of the questions in your email,
and resolves the use cases you brought forward. If I missed one, please
provide it again and I'll see what I can do.
I think that defaulting to stripping the AD-bit *and* providing a way
for an application to know which resolv.conf option was set at
startup would allow the application to know the following:
* Assume DNSSEC AD-bit untrusted by default in glibc.
- Modern glibc will strip AD-bit by default without `options: dnssec-enforced`
specified in /etc/resolv.conf
- Old glibc will not strip AD-bit.
- Applications that want to read /etc/resolv.conf as a heuristic
can look for `dnssec-enforced` option. Not the recommended way.
* Is the system enforcing DNSSEC (to use an SELinux term)?
- Use up a res._options bit for RES_DNSSEC_ENFORCED, meaning the
admin has secured the system and DNS results follow DNSSEC rules.
e.g.
diff --git a/resolv/resolv.h b/resolv/resolv.h
index 53c3bba..e886610 100644
--- a/resolv/resolv.h
+++ b/resolv/resolv.h
@@ -221,6 +221,7 @@ struct res_sym {
#define RES_USE_DNSSEC 0x00800000 /* use DNSSEC using OK bit in OPT */
#define RES_NOTLDQUERY 0x01000000 /* Do not look up unqualified name
as a TLD. */
+#define RES_DNSSEC_ENFORCED 0x02000000 /* System is enforcing DNSSEC. */
#define RES_DEFAULT (RES_RECURSE|RES_DEFNAMES|RES_DNSRCH|RES_NOIP6DOTINT)
---
- res._options has RES_DNSSEC_ENFORCED set (indicates /etc/resolv.conf
had the `options: dnssec-enforced`. So yes we are enforcing
DNSSEC and AD-bit is not stripped, and all listed servers are trusted.
- Use all the normal APIs knowing the results are secure or indeterminate.
- Connected validating resolvers are trusted and drop insecure
and bogus results.
- res._options does not have RES_DNSSEC_ENFORCED set. So no.
- Only APIs that have explicity trust information can be used.
- Use getdns API.
- Use new glibc APIs with DNSSEC flags per Petr's suggestions.
Regardless of the mode the application can use the extended APIs with
DNSSEC flags to receive perhaps all the results of a query along with
trust information so it can decide which results to use and which to
discard. Likewise the extended APIs with flags that request only secure
results are also a valid option.
You must still lock down /etc/resolv.conf to prevent someone from marking
the system as secure when it is not.
Higher level policy frameworks have to decide what to do about multiple
connected interfaces, mixtures of trusted and untrusted networks, etc.
etc. and route that information to the validating resolver whose results
go to the stub resolver which is part of the running application process.
How does that sound?
Cheers,
Carlos.