[nsd-users] (no subject)

[Ask Bjørn Hansen]

> On Jun 6, 2021, at 17:43, Kaulkwappe via nsd-users <nsd-users at lists.nlnetlabs.nl> wrote:
> 
> Dear Anand,
> 
> unfortunately I cannot agree. I had multiple problems with PowerDNS, while I had not a single problem with NSD. It only required a small amount of time for me to setup two servers which are already running fine for years and it serves a lot (not tons of, but a lot) of zones. I even created an own API and I still plan to release it under the same license as NSD when I am happy with it.
> 
> NSD in my opinion is very different from PowerDNS. Its design is consistent and logical. This, in my opinion does not apply to PowerDNS. What I encountered was:

PowerDNS is excellent software. For the set of features it provides in my experience it’s likely the most coherently designed of the various alternatives.

> a) PowerDNS refused to offer a TLS protected API. First it sounded like a bad joke for me, but they are serious: "Indeed. We are not doing this. Closing ticket, sorry!" (Add SSL support to the API #6521). This alone makes PowerDNS useless for me. TLS is a common standard and their is no room to argue that.

There are many ways to implement what you need. The TLS termination doesn’t have to be in the same process; just as you’ve discovered for the “NSD API” you described the API doesn’t have to be in the same process as the DNS servers.

> b) They refused to fix bugs, if you are not providing **absolutely unredacted** logs, even and especially for cases, where the sensitive data is obviously not required at all. No unredacted logs? No bug.

If the data is “obviously not required”, surely you could reproduce the problem on another data set and provide logs for that.

The NSD and Bind developers are great, too, but my experience with the PowerDNS developers have been one of extreme helpfulness.

> c) Design problems where it seems they moved program logic into the database. Even if it uses a relational database such like MySQL, for a DNS server, it is (in my opion) absolutey not the databases responsibilty to prevent duplicate entries. The DNS server itself needs to prevent that. It is simply a sensitive piece of software.

That doesn’t make any sense. If you have duplicate data, what is the DNS software supposed to do? Pick at random. And that’s putting aside that “duplicate” is a tricky term in DNS. For the database backends PowerDNS provides facilities for you to specify a query that does this for you (in the way you want the data de-duplicated).

Having the data correctly in the database makes much more sense though.

> Thus, if you say my statement is not true, that may be true for hosters which handled these problems *or* just do not care about these problems. About missing TLS, about misleading error logs, about authoritative developers which refuse to fix bugs which are evident. But from my perspective, this is not a project I would ever use in a setup where I am required to rely on a consistent and logical build software. NSD met these requirements easily and the developers were never unhelpful or authoritative.

NSD is indeed great, too, when the features and design fits the needs.


Ask (happy operator of NSD and Bind currently for “standard” authoritative servers; and PowerDNS and much other DNS software as well in the past).