Ostif.org Unbound DNS Audit Results – 1 Crit – 5 High – 5 Med | Hacker News Reader

Ostif.org Unbound DNS Audit Results – 1 Crit – 5 High – 5 Med

ostif.org

32 pointsProbablyDerekZ23 comments

Open articleView on HN

It's baffling to me that we're still running DNS servers written in C. DNS is not that hard to provide!

Unbound was prototyped in Java, they moved to C for speed [0].

Genuine question: Which languages would you rather DNS servers/resolvers be written in?

Consequently, if you do not mind, which DNS server and resolver do you use?

[0] https://en.wikipedia.org/wiki/Unbound_(DNS_server)#History

They rewrote in 2006. The JVM was not where it is today in 2006.

You could always use Rust if bare-metal speed is important to you. But, as I'm sure tptacek will point out (and which I agree with), Go or Java or most other high-performance memory safe languages would be perfectly reasonable as well.

What amazes me about this, and I'm prepared to be wrong but my confidence level is sort of high, is that you could implement most DNS servers, and, I believe, virtually any authority server in any language at all and it'd be fine. Forget Rust and Go; you could do it in Perl.

I've contributed to unbound, and I wrote a lot of the DNS server that we use at Amazon. The main security risk in DNS is DDOS; it's by far the biggest concern and day to day pain, and a big part of a strategy for dealing with it having really high performance. 100s of thousands of QPS per core kind of performance.

A lot of this boils down to using direct networking plumbing tricks and optimizing query handling into very fast flat memory lookups. A garbage collected language would be a terrible choice.

C is still the most common solution, but if I were writing a DNS server today, I'd go with rust.

To be clear, I don't think you could write Route53's DNS servers in Perl. It'd rather be my contention that most people running their own DNS servers don't need the kind of resilience that Route53 has (if they did, they'd be using Route53).

* https://metacpan.org/pod/Net::DNSServer

* https://metacpan.org/pod/Net::DNS::Nameserver

Something with safe memory handling.

Rust seems like a good candidate.

One of the key things that makes unbound amazing is how tiny and fast it is - this enables use-cases like running it on every node of a giant deployment to provide better dns failover and other things, without wasting too many fleet resources on dns-on-every-node overhead. It's not impossible to do the same in safer languages, but there aren't a lot of great options.

Java - which others have suggested - definitely wouldn't work - no way you could make it anywhere near as tiny. Go is a bit better but you're still paying costs over C that add up if you're running hundreds of thousands of instances. Rust simply didn't exist when this was written. D? maaaybe, but then you just annihilated your pool of contributors. I'm not sure what the best choice would be, honestly.

Is there a mature DNS implementation in Rust? If not, do Go implementations meet all the performance requirements?

Oh yea, instead lets write it in an interpreted language who's VM is written in C....

Java isn't interpreted, and several of these vulnerability classes empirically happen far less in Java programs than in C programs.

There's Ironsides, written in Ada and SPARK for formal verification: https://ironsides.martincarlisle.com/

So?

DNS is a pile of edge cases on a top of other edge cases. There are hundreds of million if not billions of devices that have been deployed that cannot be easily updated, hence implementations need to be not protocol compatible but bug compatible.

Unless you can provide specific examples of the necessity for bug-compatibility with BIND in DNS servers, I'm totally unconvinced by this. DNS is a gross, creaky old protocol, but it's just not that complicated.

You should ask people from Dyn. They wrote their own DNS service and learned it the hard way. I only have peripheral knowledge of it.

Does it count if I've implemented DNS servers several times in my career without running into any problems like this? Mine were limited-purpose --- global traffic management redirectors and, earlier, security testing --- but still, I didn't run into any crazy bug-ness.

I think the question is very much of scope/purpose. I expect that narrow-use one-offs and internal services are easy. I don't have the experience to back this up, but I wouldn't be surprised if it is much harder to write a general-purpose server for use on the open internet by arbitrary clients (and of course <10% of clients will be responsible for 90% of "interesting" behavior).

Links to commits:

https://github.com/NLnetLabs/unbound/commit/09845779d5f2c96e... Shell Injection in IPSECMOD

https://github.com/NLnetLabs/unbound/commit/b60c4a472c856f0a... Uninitialized Memory in worker_handle_request()

https://github.com/NLnetLabs/unbound/commit/f887552763477a60... Config Injection in create_unbound_ad_servers.sh

https://github.com/NLnetLabs/unbound/commit/226298bbd36f1f0f... Integer Overflow in Regional Allocator

https://github.com/NLnetLabs/unbound/commit/a3545867fcdec503... Integer Overflow in sldns_str2wire_dname_buf_origin()

https://github.com/NLnetLabs/unbound/commit/fa23ee8f31ba9a01... Out of Bounds Write in sldns_bget_token_par()

https://github.com/NLnetLabs/unbound/commit/f5e06689d193619c... Assert Causing DoS in synth_cname()

https://github.com/NLnetLabs/unbound/commit/d2eb78e871153f22... Assert Causing DoS in dname_pkt_copy()

https://github.com/NLnetLabs/unbound/commit/02080f6b180232f4... Integer Overflows in Size Calculations

https://github.com/NLnetLabs/unbound/commit/2d444a5037acff60... Insufficient Handling of Compressed Names in dname_pkt_copy()

https://github.com/NLnetLabs/unbound/commit/6c3a0b54ed8ace93... Out of Bound Write Compressed Names in rdata_copy()

The first one is truly terrible, everyone who commits to a project like this should understand that passing network data to a shell is a recipe for disaster. The proper fix is not to validate the arguments, the proper fix is not to use the shell at all. Luckily this appears to be an optional plugin.

Party like it’s 1975 indeed.

Using execve() and friends should be preferred, unless you have a really good reason for spawning a shell.

Reply on news.ycombinator.com