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

[Tony Finch]

Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>
> The big hangup here is that if an application that wants DNSSEC is
> reliant on a stub resolver, it is simply hosed. A stub resolver that is
> DNSSEC-aware can send queries to an upstream recursive, but those
> queries have to be integrity protected and message authentication.
> Currently, the only methods to do that that are in use (and even then,
> very thin use) are SIG(0) and TSIG, both of which require out-of-band
> agreement between the stub and the recursive.

SIG(0) and TSIG are useful when the client and server have some kind
of trust relationship. But the client doesn't need to trust its recursor
very much if it is doing its own DNSSEC validation.

> - The API definition requires an implementation to be able to be a
> recursive resolver in addition to the existing requirement that it be
> DNSSEC-validating

I don't believe it is necessary for a validator to be a recursor: a stub
can validate replies from a minimally-trusted recursor (received via a
minimally-trusted network) provided the recursor is at least
security-aware.

It probably is necessary for a validator to have a cache.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.