A year of Rust and DNS

With Ironsides, that makes at least two of you using safest languages you can find to try to improve DNS. Good goal and tool to pick. :)

http://ironsides.martincarlisle.com/

"Take a look at the full list sometime, I think roughly 50% of those could have been avoided by using (safe) Rust."

This is true for most vulnerabilities I see in C-related apps. We also know there's techniques to prevent that with acceptable performance. So, outside hobbyist or non-critical stuff, I tell people to use a different language to get the baseline of quality/security up. DNS is kind of example that makes it more true.

Now, I haven't learned Rust yet, so I won't be able to fully appreciate the article or spot coding ideas until I do. What I did spot was that you slogged through all the RFC's implementing and testing what you thought should be in the DNS system. Aside from a DNS server/client, I think one of most valuable things you could do in this project is create a single specification of various things in DNS that cites parts of RFC's or advice from real-world implementations to justify each part. Kind of a walkthrough for other people creating DNS's that gives them high-level view and/or drill-down into details of something.

"While in the pit of dispair" "Then I climbed saviors peak"

Haha. Good job getting through all the work as most people quit that I can tell.

"It’s currently not used in production (as far as I know). I’ve put a lot of work into validating correctness of what is going on"

It's good you have gone through the specs and have plenty of features. You did hit on a risk area that might need to be in this section: difference between the specs and real-world implementations that you have to work with. The differences could cause your server to fail. If those exist in DNS, too, there might already be write-ups on common ones out there. Biggest way to find them, though, is running combo's of popular clients and servers against each other in testing. So, that's a possible consideration for the future.

> With Ironsides, that makes at least two of you using safest languages you can find to try to improve DNS

I looked at that a while ago, I should take another. Thanks for pointing that out.

> I think one of most valuable things you could do in this project is create a single specification of various things in DNS that cites parts of RFC's or advice from real-world implementations to justify each part. Kind of a walkthrough for other people creating DNS's that gives them high-level view and/or drill-down into details of something.

I was thinking of doing something like this, but you have an even better idea here. Actual references back to the code. I might start trying to do that. (Though that's probably as much work, if not more, as writing the software ;)

> Biggest way to find them, though, is running combo's of popular clients and servers against each other in testing. So, that's a possible consideration for the future.

Yeah, I've wanted to stand up some automated tests with the most popular systems out there, but there's a time issue here. If others are inspired and want to join the project, I'd love help in this area!

Love the idea of reimplementing DNS in Rust. Would love to see more efforts like this so that we have secure-by-design language implementation of core security services.

But BIND isn't just failing because "it's written in C", it's failing because it's written in terrible C. That said, "terrible C" is probably most every C routine written by someone with less than 10 years of solid low level experience, so "writing good C code" is not very scalable. There are active, solid projects with very few security exploits that are written entirely in C. Nginx comes to mind.

The article makes a brief reference to DJBDNS, which is written in C, but has suffered zero security exploits [1], and is extremely performant. And it is being used in production, so presumably if it had any exploits they would have been exposed by now.

But...DJB's code is (usually?) released under a rather unfriendly (though mostly open) license, and DJBDNS hasn't been updated in some time, so a more modern project isn't a bad idea. And Rust developers can probably write solid code with only a few years of programming experience, which makes it easier to extend without adding security holes on a weekly basis (coughBINDcoughOPENSSLcough)...

[1] http://cr.yp.to/djbdns/guarantee.html

Bernstein used to release all his code under a weird license, by which modified versions could not be redistributed.

This changed in 2007 when he decided to release ALL his software under a public domain license (that includes djbdns obviously)

I'm on a mobile now so I won't lookup the sources for this statement, but I'm sure it's not hard to google...