tenta

Some parts have unit tests. In addition, the "stresser" component, runs a resolve on the top million domain names, and we run this on every push on our development fork. This provides a real workout. We certainly need to produce a library of example wire data and expected responses. This would be a great contribution that we'd love to incorporate.

Setting the log level has effects, but only on an internal wrapper package that neatly zips up the nitty gritty of setting up the logger.

Well, we didn't rewrite BGP in go, we used the excellent OSRG library for that. We played with several of the open source BGP libraries, but these inevitably result in a giant mess of configs and scripts holding things together, and furthermore, it's hard to signal network condition back and forth between the different parts of the process. One of the great powers of go lies in the ability to pull in fully functional components via the package manager. Rather than having to provide a long list of other dependencies to install along with Tenta DNS, we simply provide a single binary that has all the parts rolled in.

Not currently no. First of all, there's sort of two parts to "DNSCrypt", the typical DNSCrypt, which is Client<->Recurosor, and DNSCurve, which is Recursor<->Authority. The implementation is complex, and not well supported. I know that a number of people in the OpenNIC community to support DNSCrypt.

We've decided to go with TLS instead of DNSCrypt, since it's a well understood (and now RFC standardized protocol). While we're the first to support this publicly, we expect others to follow soon, which, combined with DNSSEC, will provide true security for DNS.

This appears to be in the same universe (DNS with TLS in a shiny new language).

It looks like Tenta DNS currently supports more features around scaling and production use, while Trust DNS includes a client component.

Largely the same as vs PowerDNS. We've designed this to be an all-in-one for running a performant and secure server with BGP. However, we use the excellent miekg/dns library for the DNS wire protocol, which is related to (sponsored by) NLNetLab, which also produces Unbound.

And thank you for PowerDNS. We got to the point with this where we wanted the convenience and easy parallelism of go, but we've used powerdns many times over the years, and it's been a great contribution to the net.

We've previously used a redis-replicated backend to powerdns. The fact that it was pluggable was awesome. We'd love to support something like that one day. For now, however, our eye is firmly on recursion. If a golang DNS server designed for anycast is something people want, we'll keep developing authoritative features. If not, we'll stick to recursion.

You can certainly make two configs, an authoritative only and a recursive only and just run two copies. However, while we cannot strictly control how goroutines are allocated, each module (recursor, resolver, nsnitch) run as their own little kingdom and primarily communicate with shared plumbing (geoip, for instance) through channels.

We natively work a BGP, making it easy and practical to do things like "anycast" (announcing the same IP address from multiple datacenters), or using BGP for load balancing or failover. Looking at large and successful DNS providers (Google, Amazon, Dyn, Neustar, etc), all are running BGP as part of their DNS offering. We've combined it into one piece of software.

authoritative features we don't support yet. We have a slack webhook to help us know when it's running and when it's not. It lets us know if we have server errors. All anonymous of course. The only other place we use json is saving test data, which only happens when you have an nsnitch module running and visit the test site (Also, this data automatically expires.)

Knot DNS is authoritative only. Our main focus has been recursive support and full security support. We haven't used knot dns, but it has an excellent reputation. At the moment, knot dns is more suitable for authoritative hosting (our authoritative features are still very minimal). Although in certain circumstances, like dns leak testing, we have built in support for that.