[dnssec-deployment] Seeking early users for Unbound.
Suresh Krishnaswamy
suresh at sparta.com
Fri Feb 15 12:10:22 EST 2008
Hi Wouter,
Thanks for the detailed explaination! The performance results for
unbound are impressive and I'd love to try out the library sometime.
Let me focus on just the API for now, since I think a lot of design
choices for the libraries are implementation-specific and can be
abstracted away in the API. Note that the goals for the proposed API
are very similar to what you've stated as your design goals for
Unbound. We wanted to make it easy for applications that did not care
for detailed results of validation to be able to simply check if
validation succeeeded; but we also wanted to allow some specialized
applications to see detailed authentication chain results if they
wished to. There's also the VAL_NOT_IMPLEMENTED error code that a
validation library can return to indicate that it does not implement
a particular feature (and this could be the function that returns
detailed authentication chain results, depending on how the library
was compiled).
1. Context handling
a) Unbound has
struct ub_ctx *ctx;
ctx = ub_ctx_create();
...
ub_ctx_delete(ctx);
b) The proposed validator API has
struct val_context_t * ctx;
int ret = val_create_context(NULL, &ctx);
...
val_free_context(ctx);
2. Resolve name to IP
a) Unbound has
retval = ub_resolve(ctx, "www.nlnetlabs.nl",
1 /* TYPE A (IPv4 address) */,
1 /* CLASS IN (internet) */, &result);
ub_resolve_free(result);
b) The proposed validator API has
/* this mirrors the existing getaddrinfo() function */
val_status_t status;
struct val_addrinfo ainfo; /* same as struct addrinfo, but with
validation
status information */
retval = val_getaddrinfo(NULL, "www.nlnetlabs.nl", service,
&hints, &ainfo, &status);
val_freeaddrinfo(ainfo);
3. Read DNS proxy settings (from DHCP)
a) Unbound has
ub_ctx_resolvconf(ctx, "/etc/resolv.conf");
ub_ctx_set_option(ctx, "root-hints:", "my-hints.root")
ub_ctx_hosts(ctx, "/etc/hosts");
b)
The resolv.conf file can be specified during context creation,
but val_create_context_with_conf() is not described in -05
val_create_context_with_conf(NULL, NULL, "/etc/resolv.conf",
"my-hints.root", &ctx);
We haven't specified a way to dynamically provide the /etc/hosts
file in the proposed validator API.
4. Examine the results
a) Unbound has
ub_result* result;
...
if(result->nxdomain)
...
if(result->secure)
...
if(result->bogus)
b) The proposed validator API has
val_status_t status;
...
if (val_does_not_exist(status))
...
if (val_isvalidated(status)) /* validated through chain of trust */
...
if (val_istrusted(status)) /* either validated or trusted by local
policy configuration */
..
if (!val_istrusted(status)) /* treat as bogus */
I've only focused on some of the similarities above, not the
differences (of which there are a few).
I think implementation details aside, it really makes sense to have a
single API that an application developer can use to write library-
agnostic DNSSEC-capable applications. Even if there is a small set of
functions that most applications will use to test DNSSEC results
(with other more heavy-weight validation functions compiled away to
return VAL_NOT_IMPLEMENTED), it would be much more efficient if these
functions were commonly agreed upon. At least we should try to make
this possible. Agree?
Best regards,
Suresh
On Feb 15, 2008, at 8:09 AM, Wouter Wijngaards wrote:
> -----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-----
More information about the Dnssec-deployment
mailing list