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

[Phillip Hallam-Baker]

On Wed, Jan 30, 2013 at 1:30 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:

> Ahem. This is a thread about how *this API* should be designed, not how
> DNSSEC should be designed. You two have had this discussion on the DNSEXT
> WG mailing list, if I remember correctly. The result was no changes in the
> protocol, I believe.
>

There are two separate issues. One is what capabilities the API should
support, the other is which ones an implementation of the library must
implement to be useful.

A full DNS API should support the whole range of DNS capabilities including
being a server, generating and parsing presentation format etc.

A client side implementation might be nothing more than a stub resolver
that handles arbitrary records.


An argument can be made for almost any point between those extremes. But
that comes at the expense of code complexity.

The way to decide whether an API is well designed or not is whether it
makes it easy to move from a library with a limited feature set to one that
is full feature or vice versa.


Choosing to force recursive or sub resolution or DNSSEC validation should
be an easily changeable class attribute or context member. If the library
does not support the requested access mode it should throw a compile time
error, a run time error or both.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130130/87d488bf/attachment.html>