Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of Rust and DNS

bluejekyll.github.io

Post reply on HN
Print view View original

101–109 of 109 posts

Re: A year of Rust and DNS

#101

Post by e12e »

bluejekyll wrote: post #4
nickpsecurity wrote: post #2

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 per…

> 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 walkt…

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

Literate programming (in the Knuth sense): yay!

> (Though that's probably as much work, if not more, as writing the software ;)

Yep. Hence one of the few big projects I'm aware of that use lp (apart from Knuth) is:

Axiom:

http://axiom.axiom-developer.org/axiom-website/books.html

Ed: from the post: > (And writing this post helped uncover a bug, so even if no one reads this, it was worth it).

Literate programming: yay!

Or perhaps narrative-driven design: ndd, to go with tdd and bdd...

Re: A year of Rust and DNS

#102

Post by nickpsecurity »

kbenson wrote: post #94
nickpsecurity wrote: post #86

Earlier quoted context omitted.

That's a real risk. That plus incompatibilities with real-world software that ignore the specs or get creative with any gaps in it. Those have to be tested. Ideally, if it's a critical protocol, it will be formally specified and verified to ensure the code does exactly what it's supposed to. At the least, formally specified with DbyC annotations and/or tests checking each part of the specs plus restricted, coding sty…

It would be wonderful if we could get some standardized language for defining test cases, and some tooling for converting to working (or mostly working) code for your language and implementation (at the API level, at least). If publicly developed per protocol/library, I think it would yield a substantial benefit for robustness of common protocols we have. Want to develop a DNS library or server? Read the RFCs and dow…

I agree it would be useful to have. There's all kinds of stuff like that in academia. So many different forms and tools that the problem would likely be the time available to assess them. On top of nobody using or replicating them as usual. :)

Note: sklogic did mention doing something like that by making sure all the programs' had a scriptable API then using basic, shell input and output to test them. There were acceptance, testing tools I used a long time ago that did something similar using XML. Not sure the efficiency of this method but it should work.

Re: A year of Rust and DNS

#103

Post by nickpsecurity »

api wrote: post #88
nickpsecurity wrote: post #87

Earlier quoted context omitted.

Can't you do a reference implementation in a language with great static checks like Rust with an equivalent one in C/C++ side-by-side? From Orange Book A1 to modern seL4, they always did something like that where high-level problem is expressed in analyzable way with equivalent, low-level code. Always found problems testing missed. In your case, SPARK would prevent all kinds of problems with Rust's discipline possibl…

What we do right now in our project is write thin C++ but use C++'s features (class types, exceptions, catch all, etc.) to implement bounds checking in parsers, etc., in a relatively safe way and with near-zero cost. If we need to go to plain C later we can "minus minus" this thin C++ code base relatively easily. We could in theory do the same with Rust but it would be more work since it's not as syntactically close.…

"write thin C++ but use C++'s features "

Well, that's good given I previously told you that your best approach to memory safety... given C++ use... was to convert it to C to run through Softbound+CETS or something similar. Alternatively, a C++ to C compiler then that. I wonder what the state of C++-to-C compilers is these days in terms of what they take in and quality of output.

Re: A year of Rust and DNS

#104

Post by SomeCallMeTim »

kilburn wrote: post #8
SomeCallMeTim wrote: post #6

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 g…

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

Great news! Very cool, thanks for the update.

It's obviously been a while since I've run my own Qmail or DNS server. :)

Re: A year of Rust and DNS

#105

Post by SomeCallMeTim »

bluejekyll wrote: post #31
SomeCallMeTim wrote: post #6

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 g…

> The article makes a brief reference to DJBDNS, which is written in C About 14 years ago I worked on a project that was a fork of qmail. I got to know DJB's code quite well, to say the least it is awe-inspiring. The level of understanding and craftsmanship he has in C is honestly something I am certain I will never achieve. At the same time, it is some of (for me) the most dense and obtuse code I've had to read. I'm…

I did mention that flexibility to change is a benefit to a Rust rewrite. Especially to changes made by people with <10 years of experience writing hardened code. :)

Re: A year of Rust and DNS

#106

Post by fanf2 »

PandaPedantic wrote: post #59
SomeCallMeTim wrote: post #6

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 g…

Well, djb's dns has bugs (zone corruption, lack of duplicate outbound surpression leading to trivial poisoning, query pool flushing) and missing essentials (IPv6, and most DNS since 2007). Some of these bugs were paid out in fact. There are patches, but not everything is fixed, and not all the patches play well together. The lack of maintenance and an upstream has caused some distros to consider dropping for security…

There are not many macros in BIND: mostly assertions, debug log abbreviation, and BSD style linked lists.

Re: A year of Rust and DNS

#108

Post by detaro »

arunmu wrote: post #107

Would love to repeat this sometime using pure modern C++.

It would be really interesting to have a set of extremely similar programs in, let's say, "matured C", modern C++ and Rust for comparison purposes.

Re: A year of Rust and DNS

#109

Post by arunmu »

detaro wrote: post #108
arunmu wrote: post #107

Would love to repeat this sometime using pure modern C++.

It would be really interesting to have a set of extremely similar programs in, let's say, "matured C", modern C++ and Rust for comparison purposes.

Yeah. That would be really nice as these languages are competing for the same ground. Go beats all in ease of programming but something is not quite satisfying with it(my personal opinion). I really like having control of my memory. But that doesn't matter usually for most of the application processes.
Post reply on HN