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.
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.
My goals with TRust-DNS are a little more than just shiny new language. I really want to leverage Rust's safety guarantees, especially in regards building high performance implementations for core tools like this. I believe that with Rust we can produce more hardened software and deliver at a faster pace than other more traditional low level languages.
I haven't yet had a chance to really optimize the library. In my measurements for example, BIND responds to queries in 100 micro-seconds, whereas TRust-DNS is now down to 250 (on my local system, YMMV). There are a couple of low-hanging fruit things that I hope to get to soon, that should bring that down significantly.
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.
Servers are located in Amsterdam, Miami, Seattle and Singapore. Since the resolvers are new, there's a lot of global cache to fill up.
In addition, if you'd be willing to share, visit https://nstoro.com/api/v1/geolookup and shoot us the results to hello@tenta.com. That API will pull your IP and the physical location of the box you connected to. If that location isn't Amsterdam, then we'll need to take a look at our routing.
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.
I'll put on my djb hat here, I'd avoid combining authoritative and recursive resolving servers in the same process. That is, unless you want to end up like bind.
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.
thanks! also vs coreDNS, we support actually running as a recursive or authoritative resolver. CoreDNS is appropriate (excellent, in fact) for running for service discovery, but not suitable for running as a public resolver.
Tenta browser business model is the opposite of most browsers. We don't care about ads. It's simply based on protecting data. We have a built-in VPN that's always free to use in-browser only, but if you want to expand VPN coverage to other apps then we charge a monthly subscription
