On 22 Aug 2016, at 21:15, Alex wrote:
Is it a full-fledged nameserver, suitable enough for MX, A, TXT, queries, etc for this purpose?
Nope. rbldnsd is only an authoritative server and does not do any resolution via other servers or caching of records for which it is not authoritative.
If you have some solid reason to believe that the problem is BIND (which seems unlikely to me...) it might be a good idea to analyze exactly what the mechanics of the problem are and pick alternative software which is designed to be a caching recursive resolver AND which won't have exactly the same problem(s).
One example of a pure caching recursive resolver is Unbound. It might meet your needs and it definitely is simpler to configure than BIND because it (like rbldnsd) is focused on a narrow subset of the broad range of functions done by things we call nameservers, whereas BIND is designed to do anything anyone might reasonably want a nameserver to do. I run mail systems using a mix of Unbound and BIND for local caching, and I can't see any reason to believe that BIND performs objectively worse than Unbound in that role. One nice thing about BIND is that you can make it log profusely so that you can figure out whee the delays are in doing a particular query. My bet would be that what you're seeing isn't BIND being slow, but rather an external issue. 2 common problems:
1. Live IPv6 interfaces on a machine with no or very poor IPv6 connectivity. In this circumstance, BIND running without the "-4" option (or Unbound with its default do-ip6=yes) will sometimes try to query an IPv6 authoritative nameserver for a name, eventually time out and then try an IPv4 nameserver. This is particularly pernicious in circumstances where you have one hop of IPv6 connectivity but your provider doesn't really have robust IPv6 connectivity and so you can't get to some places, often intermittently and variably.
2. Many cable providers these days hijack DNS queries by default for mostly sleazy but perfectly legal reasons, often justifying the practice with hand-waving about security (i.e. saving users from themselves by not resolving the names of miscreant domains.) This causes direct intentional breakage that often manifests as queries that time out (they should 'SERVFAIL' "bad" names but some do not.) It also can cause bottlenecks at the provider's hijacking routers and/or DNS servers (particularly during peak times) exacerbated by UDP being unreliable by design.
Could BIND itself be the culprit? Sure, it COULD, but it's not a good default scapegoat for sporadic timeouts in a local caching resolver.
