[dnssec-deployment] Seeking early users for Unbound.

[Wouter Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Suresh,

Unbound is designed for high performance, and RFC compliance, as well as
robust failure, together with a clean modular architecture. Unbound has
its roots (as Bill pointed out) in a far older Java version. The same
straightforwards design philosophy as was used for NSD has been used to
cope with Unbounds validating resolver needs in C. It provides both a
high performance caching server, and a library interface.

The functionality that results from that architecture is very different
from the functionality that would provide the features needed by the API
in your draft. Implementing all those extra features was certainly not
in scope for our 1.0 release. Besides, some of the functionality needed
by the API -- Like the highly detailed error codes, and detailed
validation status results for every data element encountered that you
describe in your draft --- breaks boundaries in the modular
architecture. E.g. the packet audit trace, that the proposed API, makes
available is only available to the resolver module and its state is not
maintained.

During the development of the C-port of unbound, we focused on correct
functionality and high performance. We choose for a design that would
allow people to turn on DNSSEC without notable performance degradation
with respect to existing recursive nameservers and resolvers. The first
signs are that, with DNSSEC enabled by default, we are at least
comparable, if not faster, than other recursive nameservers.

Besides, there is little experience with respect to how applications
will work with DNSSEC results. We choose for the most practical
approach. The current unbound (0.9) returns a couple of status codes.
One is a library error code, which only signals local operational
failures (out of memory, socket errors, file errors, ...). One is the
DNS rcode(failures from the server). And then it gives the result data
together with a status of secure, bogus, or neither. DNSSEC is very
complicated and we want to (make it possible to) contain this swamp of
trouble away from the application programmer.

This means that application developers will not be intimidated with
DNSSEC complications. In fact, by looking only at the secure status,
application developers can ignore all complications (much like the
positive-only proposal a while ago). It is very easy to check if the
result is secure, and do your e-commerce activity, and fail otherwise.

The bogus state is available as a boolean value. Without a detailed
reason. (The data is available, but marked bogus). Troubleshooting has
to be done with external tools. The library supports troubleshooting
with a debug-level setting and writing (highly detailed) logfiles to a
stream. With a high debug value, the logfile can contain dumps of all
packets encountered and detailed error conditions.

The approach from the unbound library towards validation failure is thus
a lot like the on-the-wire result, AD bit on or off for secure, and
bogus indicated by CD-query success vs non-CD-query success. The high
amount of detail that your libval exposes (and is also documented in
your draft) can be useful for a troubleshooting tool, but the complexity
of providing the functionality in unbound was prohibitive for an
implementation in 1.0. It is not to say that the libval API cannot be of
value, our design choices are just different.

The unbound library API was chosen to be easy, but also to be useful for
implementing other APIs. For implementing old APIs to make it backwards
compatible. But also the API from your draft could be implemented,a
lthough some detail is lost. Libc implementers and application
developers will want to make their own choices for their
getaddrinfo(-alike) functions, and libunbound makes it possible to do
those choices.

The asynchronous feature in libunbound was tough to write, but makes the
library more useful for application developers that need high
performance. It may not be useful (or proper) to include in a standard.

This is not to say that at a later stage we may start adding API
functionality but we first want to wait for folk to start using the
library and learn from the experience of the application developers. If
they want extra features or functionality, we can extend the library
interface of unbound.

So, in closing, the API described in your draft was considered and we
made a conscious choice towards simplicity. The current unbound API is
robust, and by getting more experience with DNSSEC we can find out if it
needs to be extended.

Best regards,
~   Wouter

Suresh Krishnaswamy wrote:
|
|> On Feb 14, 2008, at 8:37 AM, Olaf Kolkman wrote:
|>>
|>> Also we would be interested in seeing people use the library API of
|>> unbound that is specifically targeted to bring DNSSEC  to the
|>> application.
|>>
|>> More information can be found on http://unbound.net/ a mini tutorial
|>> on the library API and other documentation can be
|>> found at http://www.unbound.net/documentation/index.html. A
|>> users mailinglist is available
|>> at http://unbound.net/mailman/listinfo/unbound-users.
|>>
|
| Hi Olaf,
|
| I looked at this a bit, and the immediate question that came to my mind
| is why Unbound exports a different API than the one published in
| draft-hayatnagarkar-dnsext-validator-api-05.
|
|  From a quick look at the Unbound tutorial, it seems that most unbound
| calls have an equivalent in the -05 draft (even the semantics for the
| validator context seem to be similar). I'm not sure how unbound exports
| details of the authentication chain, so those data structures may be
| different. Also, the asynchronous DNS resolution function is not defined
| in the current validator API, but that should not be difficult to add.
|
| I think it will be good to have a single API specification at this time
| for two reasons: (1) it will allow applications that have already been
| instrumented with DNSSEC capability (using libval) to seamlessly support
| other libraries (2) application developers will have clear guidance on
| how to develop additional DNSSEC-capable applications without having to
| choose a validation library upfront.
|
| Thoughts?
|
| Suresh

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHtY8AkDLqNwOhpPgRAiU5AKCbhghlJGF0babRWguyxBT2aOJVKwCeOaMX
FsYi4eyZXb4NPSW2xD7m6Vc=
=q4UJ
-----END PGP SIGNATURE-----