Re: Building consensus over DNSSEC enhancements to glibc.

["Carlos O'Donell" <carlos 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.