Show HN: Golang DNS server, including DNSSEC and DNS-over-TLS | Hacker News Reader

Show HN: Golang DNS server, including DNSSEC and DNS-over-TLS

github.com

283 pointstenta64 comments

Apart from the difference in programming language, how does this compare to https://github.com/bluejekyll/trust-dns ?

Thanks for linking to the project.

TRust-DNS has been coming along over the last couple of years, there've been a few discussion here about it, these ones had a lot of comments:

https://news.ycombinator.com/item?id=12332876

https://news.ycombinator.com/item?id=13099979

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.

Happy to answer any questions.

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.

> DNS with TLS in a shiny new language

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 :)

AFAIK they both use the same miekg/dns library. I am not sure the assembly optimizations have been merged into the library itself.

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.

Where does that order of magnitude come from? Certainly sounds interesting.

That's very interesting, thanks, I will try this!

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

See also: https://coredns.io/ (also Go)

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.

Sorry, unfortunately you have moved the djb hat from the djb hat rack and so can no longer refer to it as a djb hat.

So Knot is authoritative, like nsd. And this Golang server is more like Unbound.

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.)

What's the valueprop over Linux Fondation backed coredns?

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

BGP integration and nSnitch, both are nice adds.

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.

Is it common in Golang to not write tests?

No, tests are commonly in the same package as the implementation.

I did find this one: https://github.com/tenta-browser/tenta-dns/blob/master/src/t...

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.

Oh lordy, that log.SetLogLevel() has effects outside the test code.

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.

Package-level loggers are an antipattern :(

Certainly it's common to write fewer tests than Python or Ruby projects, where you need tests to verify basic type and existence assertions.

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.

Tests are good! Everything should have tests.

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.

I don't know how many times I've written that kind of test, but I'd bet I can count them in base-10 with just my fingers.

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.

I've tried using the DNS listed in the page and they were very slow resolving new names (I'm in Spain).

DNS Benchmark (https://www.grc.com/dns/benchmark.htm) shows this results: https://ghostbin.com/paste/rr65w

Are they normal? Or are they slow because the servers are located in the US?

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.

I've just tested the nameservers again and ICANN ones seem to be a lot faster than before. OpenNIC ones are down for me right now.

How does it compare to PowerDNS?

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.

Thank you for the kind words! - Peter van Dijk, PowerDNS

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.

What does "BGP support" mean for a DNS resolver? Generally curious, as the internet ran fine for decades without combining the two.

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.

This is a much more interesting feature than DNSSEC and is what you should lead with.

Why not leave that responsibility to something else like bird, quagga, etc? Those have been doing the job just fine for years.

A lot of this sounds like rewriting the wheel in Go because Go is "hip".

Do one thing, and do it well.

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

I did test on tenta.com but couldn't get any result https://imgur.com/a/iK8Yh

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?

I'm using Firefox DE, and yes I'm on VPN and using DNS.WATCH server.

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?

I know DNS over TLS is basically the same, but any plans to integrate dnscrypt too?

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...

How does this stack up against Unbound?

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.

Reply on news.ycombinator.com