Re: [dane] An AD bit discussion

[Viktor Dukhovni <[e-mail]>]

On Thu, Feb 27, 2014 at 03:17:53PM +1100, Mark Andrews wrote:

> I walk into a coffee shop.  I get a address.  I manage to get IPsec
> running between the server and myself because both ends are configured
> for opportunistic IPsec.  This does not mean I should trust the AD
> bit.

We are starting to veer off-track.  The original discussion is
about stub resolver policy choices, which I read to be broadly:

    - Sensible defaults absent any configuration to the contrary?

    - Where should non-default configuration be specified?

	* System configuration files?

	* Application?

	* Both?

    - What mechanisms are appropriate for stub-resolver users to
      express the application security requirements (AD only,
      AD + RRSIGs for in-application validation)?

It sounds like there is no strong objection to defaulting to no
trust.

Either there is a default white-list of trusted nameservers (127.1,
::1) or the administrator has to explicitly bless the full list in
/etc/resolv.conf.  I've not heard many clear preferences from others
in one direction or the other.  I personally, prefer a global "trust
the nameserver list" predicate over a white-list.

I am hoping that folks here agree that generally the person or
program that writes /etc/resolv.conf is in a better position to
set the default policy than most applications, and so the stub
resolver should takes its cues from /etc/resolv.conf first.

Naturally, given appropriate APIs, applications may be able to
override this.  Thus an application that sets the nameserver
list explicitly and then asks for the AD bit, should reasonably
expect that its chosen list will not be second-guessed by the
stub resolver library.

Beyond that are API design issues, for specifying the application's
desire for AD only, AD + RRSIGs.  It would be best in libresolv to
include support for res_ninit(), res_nsearch(), res_setservers()
and so on.  Support for "getdns" would be nice if deemed ready to
be a libresolv replacement or alternative.

So likely RedHat should proceed with extensions to resolv.conf to
express the trust status of the nameserver list, and improvements
to libresolv.  The default stub-resolver policy can reasonably be
non-trust of all nameservers (typically from DHCP).

Applications should be aware that mixing DNSSEC with RES_DNSRCH is
likely non-deterministic and unsafe.  While RES_DEFNAMES may be
less problematic, it still should be avoided.  Applications that
need to process the security status of particular RRsets, should
be particular about those RRsets and specify then precisely.  It
may be more prudent to use res_[n]query() rather than res_search().

-- 
	Viktor.