Live data from Hacker News

A year of Rust and DNS

bluejekyll.github.io

11–20 of 109 posts

Re: A year of Rust and DNS

#11

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…

I marked the RFC where each RR is defined (https://github.com/spc476/SPCDNS/blob/master/src/dns.h) in my DNS decoding library (in C: https://github.com/spc476/SPCDNS). I've also referenced RFCs (in comments) in the main code (https://github.com/spc476/SPCDNS/blob/master/src/codec.c) so someone going through the code knows where to look.

And just to note: I separated the network portion from the encoder/decoder functions. It's easier to integrate that way.

Re: A year of Rust and DNS

#12
bluejekyll, have you thought about splitting the server into separate crates? (for example the parsing, the dnssec validation, the forwarding/resolving part, etc.) I'm planning to write a purely forwarding/reporting DNS server with white/black-lists and it looks like I could reuse 99% of code from you. But unless I'm missing something, the whole of the server is in one crate/repo. I did see that it's split into one lib and one bin, but haven't looked into how reusable that lib is yet.

Re: A year of Rust and DNS

#13

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…

> which makes it easier to extend without adding security holes on a weekly basis (coughBINDcoughOPENSSLcough)...

Worth remembering that until the real crypto libraries arrive in pure rust, openssl is still being used internally.

Re: A year of Rust and DNS

#14

bluejekyll, have you thought about splitting the server into separate crates? (for example the parsing, the dnssec validation, the forwarding/resolving part, etc.) I'm planning to write a purely forwarding/reporting DNS server with white/black-lists and it looks like I could reuse 99% of code from you. But unless I'm missing something, the whole of the server is in one crate/repo. I did see that it's split into one l…

I have, and specifically for purposes like this. Honestly, it just hasn't been a high priority though.

At least for the client/server code, I think you'd end up with 90% of all the same dependencies, so I don't know exactly how I'd divide it up. If you have ideas, definitely let me know!

Re: A year of Rust and DNS

#15

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…

> which makes it easier to extend without adding security holes on a weekly basis (coughBINDcoughOPENSSLcough)... Worth remembering that until the real crypto libraries arrive in pure rust, openssl is still being used internally.

Yes, though also ring, which is derived from OpenSSL through boringssl.

Re: A year of Rust and DNS

#16
post #11

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…

I marked the RFC where each RR is defined ( https://github.com/spc476/SPCDNS/blob/master/src/dns.h ) in my DNS decoding library (in C: https://github.com/spc476/SPCDNS ). I've also referenced RFCs (in comments) in the main code ( https://github.com/spc476/SPCDNS/blob/master/src/codec.c ) so someone going through the code knows where to look. And just to note: I separated the network portion from the encoder/decoder f…

[deleted]

Re: A year of Rust and DNS

#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?

Re: A year of Rust and DNS

#18

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 error-prone, though often more verbose. It’s a part of the language’s philosophy.

Re: A year of Rust and DNS

#19

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?

[deleted]

Re: A year of Rust and DNS

#20

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…

I thought DJB generally donates his code to the public domain. Hard to be "friendlier" than that.

Public domain code is actually illegal in some places, if I recall correctly
Post reply on HN