Sergey Matveychuk wrote: > Hi. > > I'm traversing through code. But it's still unclean for me how modules > work. Can you give a short description of the design? Is it easy to add > an own one? > > Hi Sergey, Modules process the queries from the clients, the results are cached. There are two modules now, they are run from the 'mesh' called by the 'worker'. A module is a state machine, and is activated by events such as the initial query event, and subsequent authority-server-reply events, or subquery-done events. A module has access to the module environment (module.h) as the thread-specific and global resources it can access (the caches and some function callbacks to accomplish tasks such as create new queries and send packets to servers). The design makes modules separate from the rest of the code, but unbound as now has been specifically written for the modules it has now. What sort of module do you want to write? Basically a new module sits best at the start of the module list; it sees new queries; passes them to the next module for handling; and can then post process the results when the next module is done and provides an answer. For example the validator module sits in front of the iterator module. The validator sees the initial query that needs processing, but does nothing with queries but pass them to the iterator. Then when the iterator is done, and has a reply, the validator is woken up again. The validator then starts to validate the response (possibly creating sub-queries for additional information). The results from the validator are stored in the cache (it updates the 'security' variable of the result that the iterator already stored in the cache). Then the validator returns its answer. Since it is the first module; the module runner mesh takes this as a clue to send that reply to the DNS clients waiting for this query result. The code for modules is now cleanly in the validator/ and iterator/ directories. The worker/ knows about what modules exist and loads the modules into the query runner mesh. Does this answer your question? There is plenty of doxygen documentation as well, and also I can recommend running unbound in very high verbosity on a simple query and reading through the logs. Best regards, Wouter