[getdns-api] Stub vs. recursive, DNSSEC, and design goals for this API

[Phil Pennock]

On 2013-01-25 at 19:30 -0800, Paul Hoffman wrote:
> - The extensions for DNSSEC apply only to an API in recursive mode; an
> DNS system that validates through the helper function does not feed
> into the extensions because the API did not do the validations
> 
> Does anyone see any problems with this proposal? To me, it is the
> right balance of letting applications be sure that DNSSEC is being
> done correctly, and it allows access to DNS parts that might be useful
> to DNS systems.

What happens when there's an out-of-process resolver which is being
talked to over an inherently trusted path?

Eg, bind lwres with verification enabled.  Or, for a system which
actually does anti-spoof packet filtering (or follows the strong
end-system model) such that "localhost" is trustworthy, just talking to
a verifying resolver on localhost?

>From the API point of view, it's a stub, but it's a stub talking over a
trusted path.

Yes, I know that the lwres approach is pretty much defunct through lack
of client support, but it's still the right approach to have a separate
service which does things "right" and can maintain trust associations;
the client support issue came about because the two approaches to use it
are "system configuration" and "app using API"; for the app, the
existing API was more portable, and for system configuration, it's
simpler to normally just tell clients that the resolver is on localhost.

Frankly, DNS logic inside each application is more attack surface than
is sane: we have tools run as root which accept UDP packets and try to
process them sanely, with no auth layer practical.  Given the number of
systems that _don't_ run a local resolver, this is scary.

If the new API can result in applications transparently using a trusted
path to a local cache and _trusting_ it, so that all the crypto is
isolated and the exposed surface area is constrained to an environment
which can be heavily monitored for anomalies via OS sandboxing, then we
can have more secure systems.

Your first point, "The API definition requires an implementation to be
able to be a recursive resolver" is maintained, since the use of the
local resolver becomes an implementation detail of the API instance.

I'm not asking for this in your implementation, but am asking for the
API to support DNSSEC in non-resolver mode, since there are sane,
supportable and, for some of us, desirable approaches which give
trustworthy DNSSEC responses in stub mode.

How about:

  All API implementations will support DNSSEC in their default context,
  but are not required to support DNSSEC in stub mode because some
  common architectures do not produce trustworthy results in that mode.

  Applications are advised to either accept the default context's
  resolver mode, or if they require DNSSEC *and* override the defaults,
  then those applications should query the API capabilities and only
  choose stub mode if this is indicated by a capability key.

?

I hadn't noticed: the API doesn't have a capability or version query
interface.  It probably should.  Something which returns a dict of named
capabilities, such as "dnssec_stub".

    getdns_return_t getdns_api_details(struct _dict **dpp);
    // if successfull, allocates a struct _dict per getdns_dict_create
    // and assigns the pointer parameter to reference it.  Caller is
    // responsible for calling getdns_dict_destroy(*dpp);

    results:

    {
      "software_name": "frobozz",
      "software_vendor": "Yoyodyne, Inc",
      "software_version": "1.2.4p6-foopatch7",
      "capabilities": [
        "dnssec_stub",
        "external_caching",
        "ipv6_rewrite_to_nat46"
      ]
    }

Does that look sane?

I, for one, as an app maintainer try to make sure that debug output
shows version numbers of libraries, both at compile time and run-time,
so that mismatches are visible.  This has proven useful for far too many
APIs.  Given this, and some compile-time constants in the API, I'd be
sure to query it and report back.

"Oh, that's your problem; frobozz screwed up ABI compatibility across
the 1.2.2 to 1.2.4 boundary, you built Exim against 1.2.1 but are
running against 1.2.4p6-foopatch7, so those queries will sometimes get
false negatives.  You need to recompile; the API is unchanged, so no
code changes are needed, just recompile."

That is *NOT* contrived.  :-(

-Phil