ldns -> unbound migration

[Roland van Rijswijk - Deij]

Hi Vladimir,

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.

Best regards,

Roland

-- 
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surf.nl/en/about-surf/subsidiaries/surfnet
-- e: roland.vanrijswijk at surfnet.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3592 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20160606/dc1173ae/attachment.bin>