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

31–40 of 109 posts

Re: A year of Rust and DNS

#31

Post by bluejekyll »

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 not a fan of loop unrolling, I think that's a thing for the compiler to optimize personally.

Anyway, in researching before starting this project, I was very aware of DJBDNS and all of the tools that make up that suite of tools. It is solid, like a rock. But like a rock, it is also inflexible. If you want to read an interesting post from DJB, this is excellent one on AXFR/IXFR: http://cr.yp.to/djbdns/axfr-notes.html

In reading this I realized that we have different goals for DNS. I want DNS to be flexible and secure, he clearly wants DNS to be secure and hardened. We have different goals, this is not to say my goals are better or worse, but I do think they differ fundamentally from that of DJB's.

You can't exploit something that you can't change.

Re: A year of Rust and DNS

#33

Post by kbenson »

jmspring wrote: post #28
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 generalizations about the quality of C code is interesting...It is easy to criticize code that has been developed over years, multiple hands, etc. C code doesn't have to be terrible. And "terrible" often is in the eye of the beholder. I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms. Some claim the architec…

> I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms.

That... really depends on what you consider "worked well". Being a cryptography library, I think I could make a strong argument that working well includes a very good track record with regard to exploits. I don't believe OpenSSL exhibits that[1]. Note the number of items that include overflows and memory corruption in that reference. Also note that the first page (50 items, but some just DoS) only takes us back to mid 2014.

> A new and hot language does not make a new implementation any more secure (maybe it has different issues) than one that has been around awhile, had multiple eyes, etc.

That's true. Unfortunately, OpenSSL has proven itself to be a poor choice for a cryptography library for those that value security over performance. We used it because it's what we had that was free and supported what we needed, but we need more competition (which we are finally getting) so people can make decisions based on their priorities, not just the small pool of what's available.

New implementations (by knowledgeable security professionals) are what we need. Whether those are done in C/C++ using more modern techniques, or some other language that can eliminate certain classes of error in some other way is somewhat irrelevant, as long as it works as a library. I suspect that the vast majority of people would take a 50% performance hit if it yielded a library that had only half as many major flaws as we've seen. That we might be able to approach that with much smaller performance loss is exciting.

1: https://www.cvedetails.com/vulnerability-list/vendor_id-217/...

Re: A year of Rust and DNS

#34

Post by johncolanduoni »

killbrad wrote: post #9

Isn't trying to write a secure implementation of DNS as it is today, like adding a chain to your door? Mostly for show?

Security of DNS the protocol (and the way it's deployed) is different from not exposing the computer running your DNS server to attacks. This is trying to solve the latter, which seems like a good idea.

Re: A year of Rust and DNS

#36

Post by captn3m0 »

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

Found the official statement: https://cr.yp.to/distributors.html

>2007.12.28: I hereby place the djbdns package (in particular, djbdns-1.05.tar.gz, with MD5 checksum 3147c5cd56832aa3b41955c7a51cbeb2) into the public domain. The package is no longer copyrighted.

Re: A year of Rust and DNS

#37

Post by pjmlp »

Any benchmarks against the MirageOS TCP/IP stack?

It would be interesting to see how the way Rust manages memory and its current optimizer match against OCaml in a production TCP/IP stack.

Re: A year of Rust and DNS

#38

Post by pjmlp »

jmspring wrote: post #28
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 generalizations about the quality of C code is interesting...It is easy to criticize code that has been developed over years, multiple hands, etc. C code doesn't have to be terrible. And "terrible" often is in the eye of the beholder. I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms. Some claim the architec…

> C code doesn't have to be terrible.

True, but I hardly have seen any codebase at enterprise level that isn't so.

C doesn't scale when you have projects where modules are written all the time by different people that got hired to work just on piece A and then leave.

They hardly can keep on their head all the nuances of memory management and UB of the company's codebase they have been asked to develop the feature A for in a month.

Languages with more strict type safety help keep people on the right path, even though they still stumble every now and then.

Re: A year of Rust and DNS

#40

Post by cpeterso »

chrismorgan wrote: post #18
DigitalJack wrote: post #17

Just curious. Is this the normal way: let recursion_available = (0b1000_0000 & r_z_ad_cd_rcod) == 0b1000_0000 That just seems redundant. If you declared the var as a Boolean, would the == 0bxxxx part have been necessary?

If r_z_ad_cd_rcod is of type u8, then 0b1000_0000 & r_z_ad_cd_rcod is also of type u8, containing the value 0 or 128. It is (by design) not possible to simply cast a number to a bool in Rust; comparing it with some value is the way you are required to do this. You can do this with `== 0b1000_0000` if you want, or `!= 0` would do just as well. Rust is deliberately explicit about conversions between types; it’s less er…

This seems like a good use case for a bit mask query function. I see Rust has a bitflags crate:

https://doc.rust-lang.org/bitflags/bitflags/index.html

Post reply on HN