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.

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 [email protected]. 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.

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.

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

ah, in some cases VPN providers push DNS options too, in which case your system DNS will be overridden. Can you check whether that's the case?

thanks! We appreciate it. Yeah mainly not open source and AFAIK, it's authoritative only.

PowerDNS provides the standard by which other DNS resolvers are judged. It's an amazing, stable product. Our biggest features compared to PowerDNS are that we provide DNS-over-TLS, we're written in memory safe golang (which is also highly concurrent, although so is PowerDNS), and we support BGP natively, making "internet wide" deployments a breeze.

All of these things could be done with PowerDNS, but it would also require a number of other programs "helping" in order to get TLS and BGP, and the configuration would be a mess. With TentaDNS it's all in one convenient, easy to run place, with a single set of config, running multiple (even 10s or hundreds) of resolver configs all in one place.

That having been said, our Authoritative support (e.g. being the main nameserver for a domain) still lacks a lot of features, while our recursive support (e.g. being the resolver you use for your browser) is top notch.

We support full recursion, including DNSSEC validation and chaining up to the roots. CoreDNS is an awesome product, but it's much more focused on service discovery

Can you let me know which browser you're using? Also I'm assuming you're running the test site with our DNS settings or another DNS? Also do you have a VPN running?

We've just open sourced the API that powers our Browser Privacy Test Tool, written in Golang: https://github.com/tenta-browser/nsnitch.

As you know, many of the best VPNs today offer a secure DNS solution, but just testing for IP, ISP, hostname and geolocation isn't enough. For example, the Nsnitch API checks if DNS over TLS is enabled. This is a relatively new protocol, but an increasingly important setting that actually keeps your DNS requests encrypted/private. You can also see if DNSSEC is enabled or "Checking Disabled" is on or off. Overall, these results give you a more complete picture of your DNS privacy and security settings.

After beta, we'll allow direct downloads of the apk. During this test phase, it's just easier for us to manage the tester feedback with the Play store admin tools.

We're starting with Android first (we'll make that clear on the site) and iOS second. Then we'll decide what platforms to prioritize next.

Regarding the second question, the short answer is that we plan to support this. It's just a matter of our time and what to focus on for the initial v1.0 launch. Long answer is that we do agree this is something that’s best solved by an ecosystem of providers (like the ones you listed) where users can easily block ads as they desire. So we'll take this approach rather than the browser unilaterally determining which features websites are allowed to have. Even major browsers with built-in ad blockers have false positives and break websites inadvertently. Take our own website for example. We have zero ads on it. It displays properly in Chrome, but completely ruined in Opera Mini which has built-in ad blocker.

I just answered this question above. check out my response to user niij. If you have further questions though, let me know.

On the UA string, thats a good suggestion. We can look how much device info we need to send and add some settings for that. On the privacy question, it sounds like the zone you used was connected to a local connection instead over the VPN connection. In the next build we're going to make this more obvious. Tap on the flag or blue pin icon in the top right corner to open Zone settings and you can see a drop down of locations to choose from.

Btw, it's not added yet, but we will make the default selection "Fastest Connection".

As far as trusting us to run the VPN edge for you, we will work on variety of ways to earn that trust as I've mentioned throughout my comments. But this is also why we're working on a way to let people run their own edges.

Thanks for the feedback, we'll make sure to clarify this all on the site!

Mainly because we're still getting beta feedback and in development. We're on version 0.99.5 and working toward 1.0, so depending on what beta testers tell us, there could potentially be sections of the app that change completely and some features are simply not complete. We want to get it out of beta and into 1.0 first, otherwise it will be a distraction for our small team. ..so yeah tab-indenting and lack of code comments. :)