3 ms·

I never imagined someone would write a recursive DNS sever in javascript. Have they explained why they chose javascript? It can't perform well nor scale and the

by _wldu 7y ago

I never imagined someone would write a recursive DNS sever in javascript. Have they explained why they chose javascript? It can't perform well nor scale and they even sort of admit that: https://github.com/handshake-org/hsd#unbound-support https://github.com/handshake-org/hsd#unbound-support

acdha 7y ago
It’s a blockchain: JavaScript is the least of their worries.
QuicksilverJohn 7y ago
Basically, only the root record parsing is done in JS and then passed to unbound for resolution. Though it is possible to run a pure JS resolver, it's not really recommended. There's also a more portable authoritative & recursive [resolver in C](https://github.com/handshake-org/hnsd https://github.com/handshake-org/hnsd). Plus, the whole protocol for node communication and name resolution & proofs is so simple, that it's pretty easy to reimplement in any language.
- w8rbt 7y ago
  Right, thanks. And I hope my question does not sound too critical. I was just genuinely curious why JS was used. I think JS is fine for small to mid-sized tasks, prototyping and testing ideas. However, for real DNS servers, used by a lot of clients, I believe C, C++, Go or Rust would be an absolute requirement.
  - troquerre 7y ago
    This is separate from the DNS resolver being written in JS, but the team behind Handshake also created bcoin, which is the only javascript fullnode (and non-core fullnode IIRC) that has mined a Bitcoin block. https://github.com/bcoin-org/bcoin https://github.com/bcoin-org/bcoin
  - tynes 7y ago
    The JS implemention is a fork of bcoin, the JS Bitcoin full node and production backend. It binds to libunbound but you are right that you would want a lower level language for it to be more scalable. There is a rust implemention work in progress here: https://github.com/UrkelLabs/rsd https://github.com/UrkelLabs/rsd There is also a C light client here: https://github.com/handshake-org/hnsd https://github.com/handshake-org/hnsd For the consensus, there are C bindings for the cryptography and a workerpool that really speeds things up. It could also be possible to dump the Handshake zone into a zone file and serve from behind unbound.

by _wldu 7y ago

acdha 7y ago

It’s a blockchain: JavaScript is the least of their worries.

QuicksilverJohn 7y ago

Basically, only the root record parsing is done in JS and then passed to unbound for resolution. Though it is possible to run a pure JS resolver, it's not really recommended. There's also a more portable authoritative & recursive [resolver in C](https://github.com/handshake-org/hnsd https://github.com/handshake-org/hnsd). Plus, the whole protocol for node communication and name resolution & proofs is so simple, that it's pretty easy to reimplement in any language.

w8rbt 7y ago
Right, thanks. And I hope my question does not sound too critical. I was just genuinely curious why JS was used. I think JS is fine for small to mid-sized tasks, prototyping and testing ideas. However, for real DNS servers, used by a lot of clients, I believe C, C++, Go or Rust would be an absolute requirement.
- troquerre 7y ago
  This is separate from the DNS resolver being written in JS, but the team behind Handshake also created bcoin, which is the only javascript fullnode (and non-core fullnode IIRC) that has mined a Bitcoin block. https://github.com/bcoin-org/bcoin https://github.com/bcoin-org/bcoin
- tynes 7y ago
  The JS implemention is a fork of bcoin, the JS Bitcoin full node and production backend. It binds to libunbound but you are right that you would want a lower level language for it to be more scalable. There is a rust implemention work in progress here: https://github.com/UrkelLabs/rsd https://github.com/UrkelLabs/rsd There is also a C light client here: https://github.com/handshake-org/hnsd https://github.com/handshake-org/hnsd For the consensus, there are C bindings for the cryptography and a workerpool that really speeds things up. It could also be possible to dump the Handshake zone into a zone file and serve from behind unbound.