[Unbound-users] python module example documentation bug and crasher

[Paul Wouters]

On Mon, 20 Jan 2014, W.C.A. Wijngaards wrote:

>> We would also still like to have something better than running
>> dns.resolver() that more natively goes back into the unbound code.
>
> Use module_env, send_query() or attach_sub().  Send query sends a udp
> packet (with fallback to TCP and EDNS detection).  attach_sub creates
> a recursive lookup that is facilitated by unbound (fully validated
> result at the end, can recurse further to lookup the nameservers and
> dnssec chain of trust for it).  In both cases an event is triggered
> when the result arrives.  The result for the recursion case should not
> perform heavy processing - it should especially refrain from making
> other recursion calls and not write to UDP buffers - it should instead
> stash the data in an internal structure and set it up so that an
> upcoming event (module_run) to continue processing outside of the
> 'interrupt-style' result event can be used for the actual processing.

I'm not sure I fully understand if this can be used.

unbound receives a lookup for an A record. We let unbound continue
until it calls operate() with MODULE_EVENT_MODDONE. Then we want to
launch a lookup for IPSECKEY. You say we should send_query(). This
requires us to create a new qstate to pass with send_query. Then this
operate() should return with MODULE_WAIT_MODULE?

Then we have two lookups in flight. If the send_query has something for
us, I assume we would catch it again in operate(). But that is a
different qstate, the one we created. I don't think we have access to
the previous qstate? How does this information transfer back to the
other qstate handling? How do we ever get back into the first query
to return the A record? Do we just return MODULE_FINISHED in the
IPSECKEY lookup and will that trigger a new operate() for the first
query? And if so, how do we grab the IPSECKEY data from that query?
Is it somewhere reachable in the cache?

Paul