Nit: Rust doesn't prevent memory leak.
It is unfortunate you're downvoted for making a true statement. It's extremely important that people don't see Rust as a panacea.
A year of Rust and DNS
71–80 of 109 posts
Re: A year of Rust and DNS
#72with erlang you can parse the dns-header like so: ,---- | %% extract dns-header fields from a raw packet. | parse_dns_header(raw_packet) -> | | ID:16, | QR:1, OPCODE:4, AA:1, TC:1, RD:1, RA:1, Z:3, RCODE:4, | QDCOUNT:16, | ANCOUNT:16, | NSCOUNT:16, ARCOUNT:16, | Tail/binary | >> = raw_packet, | | {#dns_header_record { | id = ID, | qr = QR, opcode = OPCODE, aa = AA, tc = TC, rd = RD, ra = RA, z = Z, rcode = RCODE, | q…
You can do something similar with `libpnet` in rust:
#[packet]
struct Dns {
id: u16be,
qr: u1,
opcode: u4,
aa: u1,
tc: u1,
...
#[payload]
data: Vec,
}Re: A year of Rust and DNS
#73Love 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…
You might find this interesting: "However, the closest
in functionality and intent is Dan Bernstein’s djbdns,
which aims to be a minimalist, highly secure DNS
server. The latest release of djbdns, including various
support tools, is about 10,000 lines of C as measured
by sloccount. We expect that it is possible to build a
feature-par version with Nail that is an order of magnitude
smaller and intend to do so."
https://people.csail.mit.edu/nickolai/papers/bangert-nail-la...
Nail, btw is parser written in the spirit of "language theoretic security", which is a poweful new way of looking at security problems.
Re: A year of Rust and DNS
#74Nit: Rust doesn't prevent memory leak.
nit: while rust doesn't prevent all memory leaks, it does prevent some classes of memory leaks; especially when compared to C, since it requires you to annotate the lifetimes of data and automatically manages many types of allocations by scope and lifetime
Re: A year of Rust and DNS
#75Any 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.
I'd love to get some benchmarks going. It's not as high a priority for me right now as getting to feature complete (my definition of that anyway).
The question you pose though is awkward. MirageOS is a unikernel, Trust-DNS is an application, a consumer of the TCP stack.
I have seen Rust apps built into rumprun, but as of right now this isn't something on my list, in theory it's possible.
Re: A year of Rust and DNS
#76Earlier quoted context omitted.
> 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 numb…
> 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 How would one know whether there are any major flaws in a code base?
You don't, for sure. But when half the security bugs seem to be related to memory corruption and buffer overflows, there are options. We've had languages that put more emphasis on being correct and safe than on performance, but people haven't been using them for much. C/C++ have momentum and people that know how to use them, so they are used. I'm not sure that makes them a good choice for security related work, where bugs sometimes counter the entire purpose of the library.
Re: A year of Rust and DNS
#77Any 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.
I'd love to get some benchmarks going. It's not as high a priority for me right now as getting to feature complete (my definition of that anyway). The question you pose though is awkward. MirageOS is a unikernel, Trust-DNS is an application, a consumer of the TCP stack. I have seen Rust apps built into rumprun, but as of right now this isn't something on my list, in theory it's possible.
It is not awkward at all.
You can build a DNS server with MirageOS and it is used like that in the context to the new Docker versions for Mac OS X and Windows, which is one example of being used in production.
Re: A year of Rust and DNS
#78Nit: Rust doesn't prevent memory leak.
It is unfortunate you're downvoted for making a true statement. It's extremely important that people don't see Rust as a panacea.
Fortunately it appears this perfectly legitimate comment has been salvaged. Steve, I was disappointed that this topic[1] received no discussion at all at HN. Has anyone inside Mozilla looked at it? The title is a bit click-baity for academic work, in my opinion, but I do think the points raised are worthy. Much like recent criticism of PostgreSQL by Uber, one hopes the purveyors of Rust are also open and respond well to constructive criticism.
Re: A year of Rust and DNS
#79Earlier quoted context omitted.
It is unfortunate you're downvoted for making a true statement. It's extremely important that people don't see Rust as a panacea.
Fortunately it appears this perfectly legitimate comment has been salvaged. Steve, I was disappointed that this topic[1] received no discussion at all at HN. Has anyone inside Mozilla looked at it? The title is a bit click-baity for academic work, in my opinion, but I do think the points raised are worthy. Much like recent criticism of PostgreSQL by Uber, one hopes the purveyors of Rust are also open and respond well…
It wasn't discussed a lot because it's quite old, and we talked about it a lot when it was published. I actually met (and then became friends with) Amit in real life because of this paper; we're both in New York and got coffee to discuss it.
(It's been a while, but IIRC the issues they had were more about not understanding what exacty was available and how to use them, at the time. The project has been going really well since then; Amit has been giving a number of cool talks about it at various Rust user groups, and they recently started their own "This week in", though it's called "Talking Tock" because that's a better name, ha!)
Re: A year of Rust and DNS
#80with erlang you can parse the dns-header like so: ,---- | %% extract dns-header fields from a raw packet. | parse_dns_header(raw_packet) -> | | ID:16, | QR:1, OPCODE:4, AA:1, TC:1, RD:1, RA:1, Z:3, RCODE:4, | QDCOUNT:16, | ANCOUNT:16, | NSCOUNT:16, ARCOUNT:16, | Tail/binary | >> = raw_packet, | | {#dns_header_record { | id = ID, | qr = QR, opcode = OPCODE, aa = AA, tc = TC, rd = RD, ra = RA, z = Z, rcode = RCODE, | q…
FWIW you can get code-formatting by prefixing lines with a 4-space indent: parse_dns_header(raw_packet) -> > = raw_packet, Also for readers, this does depend on customisable (per-segment/field) defaults: `ID:16` is a shorthand for `ID:16/big-unsigned-integer-unit:1` aka "16-bits wide segment parsed as an unsigned integer in big endian"
> FWIW you can get code-formatting by prefixing lines with a 4-space indent
ah thank you ! that is very good to know.
will it be possible to have some formatting guidelines / examples on the site somewhere ? similar to what we see on reddit ?