Knot DNS: A high-performance, authoritative DNS server

I'm the author of gdnsd and noticed this sub-thread here recently. Knot DNS is pretty neat, and I'm glad that there's healthy competition in open source authserver software these days :) In response to your comments about gdnsd and standards:

The DNS is defined by a plethora of RFCs of varying legitimacy, utility, and age; it's hard to argue there's a single set of absolutely-required features and behaviors that define the "DNS standard." Modulo any difference we might have about the points outlined below, I feel that gdnsd is a standards-complaint DNS authdns server. In the pragmatic sense, it is being used to serve the public authdns needs of some fairly large sites (e.g. Wikipedia), and that alone argues for its legitimacy.

* Lack of [AI]XFR: This is an intentional design choice. Not necessary for a pure authserver of limited feature scope (gdnsd doesn't intend to support DDNS updates from client-level machines), and frankly there are many superior methods for transferring data between cooperative authservers these days.
* Limited subset of RR types: I think the subset that gdnsd implements is valid. It covers all of the core RR types defined by the older RFCs, minus the ones that have fallen completely out of legitimate, modern use (e.g. MINFO, MAILA, etc). Of the newer RR-types: SPF was initially supported and then later removed (as it has been deprecated by the standards process for new implementations, so gdnsd took advantage of a major-version bump to drop it for 2.x). NAPTR is implemented because it does see broad-enough usage that it seemed prudent. As a catchall, RFC3597 generic TYPEXXX is implemented, which can be used to define data for RR types gdnsd knows nothing about. I have yet to receive a feature request for any other esoteric types (e.g. SSHFP, etc), but I'd be happy to add them if there was a legitimate demand from users.
* Lack of DNSSEC: If your definition of standards-compliant includes some (specific?) level of DNSSEC feature support, then gdnsd definitely doesn't comply there. This has been an intentional design choice from day one, as I've been rather unimpressed with both the process and results of the DNSSEC effort.
Given where the world is at today (that DNSSEC seems to be winning in spite of itself), gdnsd will probably eventually have some form of DNSSEC implementation that's appropriate to how it operates. It's on the back-burner radar for 3.x. For the time being, however, I think it's a legitimate design choice. It's definitely possible that lack of DNSSEC in the design confers an "unfair" advantage in non-DNSSEC benchmarks, but I think if anything that's an interesting thing to highlight about DNSSEC itself and how it affects simplicity of implementation.

I do take some issue with your statement "Knot DNS outperforms any other open-source DNS server available". I honestly don't know if it outperforms gdnsd (all other things being equal), as I really don't currently have the mental bandwidth to set up such a rigorous comparison environment. I'm inclined to believe it would be difficult (but not impossible!) for Knot to exceed gdnsd's performance, especially in the areas of UDP query rate, latency, and jitter. Neither of us knows that if you're not benchmarking it, though, so it seems a bit imprudent to make such a sweeping claim.