Maintained by: NLnet Labs

ldns -> unbound migration

Vladimir Levijev
Mon Jun 6 11:39:06 CEST 2016

On 6 June 2016 at 12:05, Roland van Rijswijk - Deij
<roland.vanrijswijk at> wrote:


> Vladimir Levijev via Unbound-users wrote:
>> We are successfully using libldns (C) in our project to perform DNS
>> queries. At some point the requirements for queries per minute went
>> high and in order to fulfill those we had to start fork()-ing the
>> process to perform queries in parallel. This works well but we are
>> concerned now about the amount of processes run in the system.
>> After searching on the net I found out about libunbound and it's
>> ability to perform asynchronous queries. This looks awesome, but the
>> questions are as follows.
>> Given the requirement to perform up to 20-40 DNS queries to different
>> name servers asynchronously in a single task, how well can unbound
>> handle such load (with all the possible timing outs and so on)? What
>> would be the recommended limit of queries in this case?
>> And the second question, perhaps anybody has an idea, how easy is
>> switching from libldns to libunbound? What are the
>> advantages/disadvantages of doing that?
> We currently use a tiered approach for one of our projects, where LDNS
> synthesizes the local queries, whereas a local copy of Unbound does the
> resolving. One thing to bear in mind, should you choose a similar
> approach, is that LDNS does not perform sanity checks on responses that
> it receives on a socket. This can come back to bite you if you have lots
> of open queries and if one or more time out. If your local Unbound
> decides to answer an open query while LDNS has already timed out, the
> answer may get picked up by a freshly opened socket that happens to be
> on the same port. Since LDNS does not check if the QNAME or query ID
> match the query it sent, this will get accepted.
> In other words: if you use a locally running Unbound and LDNS to
> synthesize and send queries, make sure you check QNAME and query ID on
> the returned response.

Thanks for your reply. We actually are not using the Unbound, we are
just querying the Name Servers (IN A) that serve existing domains. So
I guess that means we have nothing to worry about and libunbound would
server well for us?