TRust-DNS consists of essentially 3 components. The Server supports on-line DNSSec signing of all the current DNSSec standard algorithms, and some additional RFCs around limiting the response of those to what the client connection supports. It supports DNS over TLS as well. Recently I added support for TLSA and CAA records as well. There are definitely some more than can be supported.
The Client, which is for managing the server and performing raw connections to DNS servers for things like dynamic update, etc. It supports DNS over TLS, with three variant TLS impls for different combinations based on toolchain requirements. It also can perform DNSSec validation.
The Resolver, which is what I anticipate most people will use going into the future. This currently doesn't support DNS over TLS. I have plans to do that, but I haven't figured out the configuraton side of it yet. This also is capable of DNSSec validation. It has some neat features around DNS server selection specifically for ranking DNS servers and using the most responsive. I have some plans at some point to try and implement a caching resolver for the three major platforms, but haven't gotten there yet.
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.
I like your octocat-gopher logo, very cool. Looks like an interesting project also. How does it compare to the Cloudflare dns server in Go? (I guess being open source is the most important). They did some interesting optimizations of TLS with assembly
I'm working on RRDNS, but am a new member of the team.
The big difference is that RRDNS contains all of our business logic to enable things like Orange clouding, and other DNS based features. Those depend a lot on how our infrastructure works, and are not useful to others. It's also a much older codebase (it probably started before 1.4?) and therefore goes out of its way to avoid putting pressure on the GC and had other funny bits in it. Finally, RRDNS has seen a lot of abuse and by now is pretty well hardened :)
If you want something faster than github.com/miekg/dns, there is golang.org/x/net/dns. I am the author, but I promise it is a lot faster. It is about an order of magnitude faster in my benchmarks.
CoreDNS has some fun issues at times. The documentation around it is rather sparse and the last time I tried it, CoreDNS refused to reply with authorative responses to any query and also refused to properly resolve any recursive queries (delivering intermediate! results)
If we're already at it comparing different implementations, how's your story versus Knot (https://www.knot-dns.cz/)? Probably a different focus: Knot is authoritative-only, while your implementation mostly seems to focus on the recursive resolver, correct? Are there any reasons to use Tenta DNS over Knot as authoritative nameserver with DNSSEC support?
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.
Does Tenta handle automatic zone signing? can tenta handle ECC param files for hardening elliptic implementations? Why the JSON logging if this is only a recursive unless you planned to run this in a container and stream log data to ELK perhaps?
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.)
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
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.
That's an internal test, meaning it has access to the package internals. A better test would test from outside the boundaries of the package to only interact with exposed symbols.
This is starting to change, perhaps not in Ruby but JS and Python now have commonly-used pre-compile typecheckers with typesystems fancier than your typical typed C-descendant language, annotation stubs for the standard or popular libraries, etc. I wouldn't be surprised that if in a couple of years, the default for a new Javascript project would be more typechecked than Go, strange as it is to say.
Sure! I think that's especially true of Javascript.
I would just caution people against doing direct comparisons of unit test suites between Ruby/Python and Go projects, because a lot of Ruby/Python testing really just mitigates deficiencies in those languages, and those deficiencies have created a sort of culture of exuberant, creative testing that isn't present in other languages.
I know only of Flow for JS, but are there signs that it's commonly used, or are there other JS typecheckers with a more optimistic trajectory?
It looks to me more like compile-to-JS languages are winning this race. Which is good, as it enables sthings like ClojureScript and Elm. Also many of us think the lack of static types is the least of the problems in JS.
Flow and TypeScript are used a fair bit and both have adoption in big organizations that make big, commonly used tools. I don't think any of the compile-to-JS languages have ever really got quite that far and I'm somewhat skeptical they will.
Ah. I guess due to the superset-of-JS property you might kinda sorta see it as annotated JS, though it has its own syntax and has to go through a compiler to produce runnable JS.
edit: Seems the TS tools also have JS linting functionality, where you put JSDoc annotations in comments and use the new --checkJs options, I guess you may have meant this too.
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.
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.
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.
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 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.
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.
For me the authoritative support would be relevant. Can you please elaborate on what important thing is missing?
What's a recommended way of using your product in a redundant way? PowerDNS for example has multiple backends, what I am missing is a bind style backend that is based on JSON files and is able to reload on the fly, so that I don't have to deal with a SQL database. Is this something that could be achieved with Tenta?
Hello, PowerDNS developer here! Not trying to steal Tenta's thunder here, but you should know that the PowerDNS GeoIP backend can be used without a GeoIP database, in which case it might better be called the 'YAML backend'.
Additionally, if you file a feature request for JSON support in the bindbackend, we might consider it!
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 mentioned that the hosted recursive resolver is free to use along with api access in exchange for a backlink, and I checked out the parent project which is Tenta browser and it's currently in beta for Android, so how do make money? Do you sell any upgrades/support to businesses?
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
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?
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.
Out of curiosity, what do you see as the advantages of dnscrypt vs. DNS over TLS?
I looked at dnscrypt myself, it's implementation is much more complex than using standard TLS support libraries that already exist. TLS and dnscrypt seem to cover similar use cases...
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.
