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

[Paul Hoffman]

Greetings again. I'm a great fan of succinct thread topics and labeling threads correctly. This thread has the latter but, inherently, not the former. Having said that, I want to emphasize that this is about the design goals for *this* DNS API, whose primary purpose is to be easy to use for applications.

A few people brought up earlier about stub resolvers and DNSSEC. I have now dived into RFC 4033-4035 again, but this time thinking in terms of applications, not DNS systems. 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.

A normal application has no idea about which recursive resolver it wants to use and have exchanged keying material. So, that application cannot rely on the API for DNSSEC if the API is a stub resolver. We lose.

I want this API to be useful to DNS systems that do not use port 53 directly, but that is a secondary goal only. The primary goal is that the API just work and be understandable to applications.

Given that, I propose the following changes:

- 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

- A DNS system using the API can put the API into stub mode for a context

- I add context support for SIG(0) and TSIG to a resolver, and also add a function for "set the CD bit on requests in this context"

- I add a helper function for "validate this record given this pile of records"

- Given that there is not a lot of consistent experience with this, an API implementations do not need to support the previous three additions, but an implementation will be able to determine that before it tries

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

--Paul Hoffman