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

[Paul Hoffman]

On Jan 28, 2013, at 3:22 PM, Phil Pennock <getdns-api-phil at spodhuis.org> wrote:

> 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?

My proposal allows for that: "- A DNS system using the API can put the API into stub mode for a context"

>> 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.

Given that this is an edge case today, I don't think it is wise to wire that into the API as a likely case in the future. An implementation of the API cannot just assume that there will be a secure way to reach the upstream, even if that upstream 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.

Agreed; that's why it is allowed.

> 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.

And that's why it is allowed.

--Paul Hoffman