Forem: Aviv Cohen

TLS in Node.js Is a Black Box - Here's an Open One

Aviv Cohen — Thu, 16 Apr 2026 00:30:50 +0000

Every Node.js app you've ever built uses TLS. Every https.createServer(), every fetch() to an external API, every database connection with ssl: true — all of it goes through TLS.

But have you ever actually seen what happens during a TLS handshake? Have you ever tried to control which cipher suite is used for a specific connection? Pinned a certificate? Inspected the key exchange? Read the traffic keys?

Probably not. And it's not because you're not curious — it's because Node.js doesn't let you.

Node's node:tls module is a thin wrapper around OpenSSL, a C library with over 700,000 lines of code. It works, it's fast, and for most use cases it's fine. But it's a black box. You call tls.connect(), something happens in C-land, and you either get a secure connection or an error. What happened in between? Which parameters were negotiated? Could you have made different choices? Good luck finding out.

This article is about LemonTLS — a pure JavaScript implementation of TLS 1.3 and TLS 1.2 for Node.js. Not a wrapper. Not a binding. The actual protocol, implemented in JavaScript, where you can read every line, set a breakpoint on every step, and control things that OpenSSL has no API for.

Why Would Anyone Reimplement TLS?

Fair question. OpenSSL works. It's been battle-tested for decades. Why would you want a JavaScript implementation?

Here are three concrete reasons — and they're not theoretical.

1. You Can't Control What You Can't See

Try to do any of these in Node.js:

Pin a certificate. You want to make sure your app only connects to a server presenting a specific certificate — not just any certificate signed by any CA. This is critical for banking apps, internal services, and anything where a compromised CA could be disastrous. In Node.js, you have to implement this manually by checking the peer certificate after the handshake. There's no built-in option.

Choose a cipher suite per connection. Node.js sets cipher suites globally. If you have one connection to a legacy server that needs AES-128 and another to a modern API where you want ChaCha20, you can't configure them independently without openssl.cnf hacks.

Disable session tickets for a specific server. Session tickets are great for performance, but they carry security trade-offs (forward secrecy during the ticket lifetime). In Node.js, disabling them requires modifying OpenSSL's configuration file — not something you can do per-connection.

Detect bots with JA3 fingerprinting. Every TLS client sends a ClientHello with a unique combination of extensions, cipher suites, and curves. This creates a fingerprint (JA3) that can identify bots, scrapers, and known malicious clients. Node.js gives you no access to the raw ClientHello.

With LemonTLS, all of these are one-liner options:

import tls from 'lemon-tls';

// Certificate pinning
tls.connect(443, 'bank.example.com', {
  pins: ['sha256/YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=']
});

// Per-connection cipher and curve selection
tls.connect(443, 'api.example.com', {
  allowedCipherSuites: [0x1301, 0x1303],  // AES-128-GCM + ChaCha20 only
  groups: [0x001d],                        // X25519 only
  signatureAlgorithms: [0x0804],           // RSA-PSS-SHA256 only
  prioritizeChaCha: true                   // Prefer ChaCha20 over AES
});

// Disable session tickets
tls.createServer({ key, cert, noTickets: true });

// JA3 fingerprinting
server.on('secureConnection', (socket) => {
  const ja3 = socket.getJA3();
  console.log(ja3.hash);  // 'e7d705a3286e19ea42f587b344ee6865'
  if (knownBots.has(ja3.hash)) socket.destroy();
});

None of these require configuration files, environment variables, or OpenSSL rebuilds. They're just options you pass to a function.

2. You Can Actually Debug TLS Problems

Everyone who's worked with TLS has seen this error:

Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE

Or this one:

Error: self signed certificate in certificate chain

When these happen in Node.js, you're stuck. The error comes from deep inside OpenSSL. You can't set a breakpoint, you can't inspect the certificate chain at the point of failure, you can't see which validation step failed and why.

With LemonTLS, TLS is JavaScript. You can:

Set a breakpoint inside the handshake and step through each message
Inspect the raw ClientHello and ServerHello
Watch key exchange happen in real time
See exactly which certificate in the chain failed validation and why

// See every handshake message
socket.on('handshakeMessage', (type, raw, parsed) => {
  console.log('Handshake:', type, parsed);
});

// Wireshark integration — export keys for packet inspection
socket.on('keylog', (line) => {
  fs.appendFileSync('keys.log', line);
});
// Then in Wireshark: TLS → Pre-Master-Secret log filename → keys.log

For development, testing, and debugging — the ability to see what TLS is doing changes everything. Instead of googling cryptic OpenSSL errors, you read JavaScript.

3. Some Protocols Need TLS Internals

This is the reason LemonTLS was originally built. Some protocols need access to TLS internals that OpenSSL simply doesn't expose through Node.js.

QUIC needs the TLS handshake keys at specific points during the connection setup. It needs to encrypt packets with derived keys, not through a socket — because QUIC runs over UDP, not TCP. Node's node:tls gives you a TCP socket and nothing else. You can't extract the keys, you can't encrypt individual records, you can't run TLS without a TCP connection underneath.

LemonTLS solves this with two API levels:

// High-level: drop-in replacement for node:tls (works with TCP)
import tls from 'lemon-tls';
const socket = tls.connect(443, 'example.com');

// Low-level: state machine only — you handle the transport
import { TLSSession } from 'lemon-tls';
const session = new TLSSession({ isServer: false });
session.on('send', (data) => { /* send over UDP, WebSocket, anything */ });
session.on('keys', (keys) => { /* use these for QUIC encryption */ });
session.receive(incomingData);

The TLSSession is a pure state machine. It doesn't know or care what transport you're using. Feed it bytes, it produces handshake messages and keys. This is what makes it possible to build protocols like QUIC, DTLS, or any custom transport that needs TLS security — entirely in JavaScript.

Drop-In Replacement: Same API, More Control

Despite all these advanced capabilities, the basic usage is intentionally boring. LemonTLS implements the same API as node:tls:

import tls from 'lemon-tls';  // just change the import
import fs from 'node:fs';

// Server — same as node:tls
const server = tls.createServer({
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt'),
}, (socket) => {
  console.log('Protocol:', socket.getProtocol());  // 'TLSv1.3'
  console.log('Cipher:', socket.getCipher().name);  // 'TLS_AES_128_GCM_SHA256'
  socket.write('Hello from LemonTLS!\n');
});
server.listen(8443);

// Client — same as node:tls
const socket = tls.connect(8443, 'localhost', {
  rejectUnauthorized: false
}, () => {
  socket.write('Hello from client!\n');
});
socket.on('data', (d) => console.log(d.toString()));

createServer(), connect(), TLSSocket as a Duplex stream, getProtocol(), getCipher(), getPeerCertificate(), alpnProtocol, SNICallback — all the methods and events you know from node:tls work exactly the same way.

The 27 compatibility methods from Node.js have been verified through automated tests. If your code works with node:tls, changing the import to lemon-tls should just work.

Session Resumption: Faster Reconnections

TLS 1.3 introduced a mechanism where, after the first handshake, the server sends the client a "session ticket" — an encrypted blob that lets the client skip the full handshake on the next connection. Instead of exchanging certificates and doing key agreement from scratch, the client presents the ticket and both sides derive keys immediately.

This is especially important for mobile apps and APIs where connections are frequently opened and closed. The difference between a full handshake (1 round-trip) and a resumed handshake (same round-trip, but less computation) adds up.

let savedSession = null;

// First connection — save the ticket
const socket1 = tls.connect(8443, 'example.com');
socket1.on('session', (ticketData) => {
  savedSession = ticketData;
});

// Later — resume with the ticket
const socket2 = tls.connect(8443, 'example.com', {
  session: savedSession
}, () => {
  console.log('Resumed:', socket2.isResumed);  // true
  // No certificate exchange happened — faster connection
});

This works identically to Node.js session resumption, but with one difference: you can actually debug it. If resumption fails, you can inspect the ticket, see the PSK binder validation, and understand exactly why.

Mutual TLS: Both Sides Authenticate

Standard TLS is one-sided — the client verifies the server, but the server doesn't verify the client. For internal services, microservice communication, or zero-trust architectures, you often need both sides to present certificates.

// Server: require client certificate
const server = tls.createServer({
  key: serverKey,
  cert: serverCert,
  requestCert: true,
  ca: [clientCA]  // Only accept clients signed by this CA
});

server.on('secureConnection', (socket) => {
  const peer = socket.getPeerCertificate();
  console.log('Client:', peer.subject.CN);
  console.log('Valid:', socket.authorized);
});

// Client: present certificate
const socket = tls.connect(8443, 'service.internal', {
  cert: fs.readFileSync('client.crt'),
  key: fs.readFileSync('client.key'),
  ca: [serverCA]
});

Same API as node:tls. But if something goes wrong with certificate validation — wrong CA, expired cert, hostname mismatch — you can actually trace through the JavaScript to see where and why it failed.

What's Actually Happening: The TLS 1.3 Handshake

One of the benefits of having TLS in JavaScript is that you can actually understand what the protocol does. Here's what happens when you call tls.connect():

Step 1: ClientHello. The client sends a message listing: supported TLS versions, supported cipher suites, supported key exchange groups, a random nonce, and a key share (the client's half of the key exchange). In TLS 1.3, the client optimistically includes its key share in the first message — this is what makes the handshake only one round-trip.

Step 2: ServerHello. The server picks a cipher suite and key exchange group, includes its own key share, and sends it back. At this point, both sides have everything they need to compute the shared secret.

Step 3: Encrypted handshake. Everything after ServerHello is encrypted. The server sends its certificate, proves it has the private key (via a CertificateVerify message), and sends a Finished message. The client verifies everything, sends its own Finished, and the handshake is complete.

Step 4: Application data. Both sides now have traffic keys derived from the shared secret. All application data is encrypted with AES-GCM or ChaCha20-Poly1305.

The entire handshake happens in one round-trip — the client sends ClientHello, and the server responds with everything needed to start sending encrypted data. Compare this to TLS 1.2, which required two round-trips.

With LemonTLS, you can watch this happen in real time:

socket.on('handshakeMessage', (type, raw, parsed) => {
  console.log(`[${type}]`, JSON.stringify(parsed, null, 2));
});

socket.on('secureConnect', () => {
  console.log(socket.getNegotiationResult());
  // { version: 'TLSv1.3', cipher: 'TLS_AES_128_GCM_SHA256',
  //   group: 'X25519', alpn: 'h2', resumed: false,
  //   handshakeDuration: 23 }
});

The Full Negotiation Picture

After the handshake, you have complete visibility into what was negotiated:

socket.on('secureConnect', () => {
  // What version and cipher were agreed on?
  console.log(socket.getProtocol());        // 'TLSv1.3'
  console.log(socket.getCipher());          // { name: 'TLS_AES_128_GCM_SHA256', ... }

  // What key exchange was used?
  console.log(socket.getEphemeralKeyInfo()); // { type: 'X25519', size: 253 }

  // Who is the server?
  const cert = socket.getPeerCertificate();
  console.log(cert.subject.CN);             // 'example.com'
  console.log(cert.fingerprint256);         // 'AB:CD:EF:...'

  // Was this a resumed connection?
  console.log(socket.isResumed);            // false

  // What ALPN protocol was negotiated?
  console.log(socket.alpnProtocol);         // 'h2'

  // Access the raw shared secret (for research)
  console.log(socket.getSharedSecret());    // Buffer<...>

  // Export keying material (RFC 5705)
  const material = socket.exportKeyingMaterial(32, 'my-protocol', Buffer.alloc(0));
});

Every piece of information that was negotiated, exchanged, or derived during the handshake is available to you. Not hidden in a C struct somewhere — accessible as JavaScript values you can log, inspect, and use.

Zero Dependencies, Full Transparency

LemonTLS uses only node:crypto for the raw cryptographic primitives (AES, SHA-256, ECDH). Everything else — the state machine, the handshake logic, the record layer, the key schedule, the certificate parsing — is JavaScript.

The entire library is readable. When something goes wrong, you don't get an opaque error from a C library — you get a JavaScript stack trace that points to the exact line where the issue occurred.

For security-sensitive applications, auditability matters. You can read the key derivation code, verify the HKDF implementation, check the AEAD encryption. With OpenSSL, you're trusting 700,000 lines of C that even most security researchers don't fully understand.

Getting Started

npm install lemon-tls

For most use cases, change one import:

- import tls from 'node:tls';
+ import tls from 'lemon-tls';

Everything else stays the same — and you gain visibility, control, and debuggability that node:tls can't offer.

Resources:

Why This Matters

TLS is the most important security protocol on the internet. Every HTTPS request, every secure WebSocket, every encrypted database connection depends on it. And yet, for most Node.js developers, it's a complete black box.

It doesn't have to be. TLS is a well-documented protocol with clear RFCs. The only reason it's been opaque is because the implementations have been in C, hidden behind abstraction layers that prioritize convenience over understanding.

LemonTLS gives you both: the convenience of a Node.js-compatible API when you just want things to work, and full protocol-level access when you need to understand, debug, or control what's happening. Same API, open box.

Add HTTP/3 to Your Node.js App

Aviv Cohen — Thu, 16 Apr 2026 00:29:07 +0000

Let's start with a question: when was the last time you thought about what protocol your Node.js server actually speaks?

If you're like most developers, the answer is probably "never." You set up Express, called app.listen(), and moved on to building features. And that's totally fine — that's how it should work.

But here's the thing: the internet has moved on, and your server probably hasn't.

Every major browser — Chrome, Firefox, Safari, Edge — already speaks HTTP/3. Google has been serving search results over it since 2020. Cloudflare routes over 30% of its traffic through it. Meta, YouTube, Instagram — all HTTP/3. The biggest companies in the world decided that HTTP/2 over TCP wasn't fast enough, and they built something better.

Meanwhile, most Node.js apps are still serving responses over HTTP/1.1. Some have upgraded to HTTP/2. But almost none speak HTTP/3 — because until now, there was no simple way to do it in Node.js.

That's what this article is about. We'll look at why HTTP/3 exists, what real problems it solves (spoiler: if your users are on WiFi or mobile, this matters a lot), and how to add it to your existing Node.js app without rewriting a single route.

The Problem Nobody Talks About: TCP Is Holding You Back

TCP has been the backbone of the internet for over 40 years. It's reliable, it's battle-tested, and it's everywhere. So what's wrong with it?

Nothing — if you're on a perfect network. But let's be honest: nobody is on a perfect network.

Head-of-Line Blocking: The Silent Performance Killer

Imagine you're loading a web page. Your browser opens an HTTP/2 connection and starts downloading 15 resources simultaneously — CSS, JavaScript, images, fonts — all multiplexed over a single TCP connection. Sounds efficient, right?

Now imagine one single packet gets lost. Maybe the user is on WiFi and walked a bit too far from the router. Maybe they're on a train and the signal hiccupped for a millisecond.

Here's what happens: TCP freezes everything.

Not just the resource that lost a packet — all 15 resources stop. TCP guarantees in-order delivery, so it holds every subsequent packet hostage until that one lost packet is retransmitted and arrives. Your CSS file is ready, your JavaScript is ready, six images are ready — but nothing can be delivered to the browser until that one missing packet shows up.

This is called head-of-line blocking, and it's the dirty secret of HTTP/2. The multiplexing that was supposed to make everything faster actually made this problem worse — because now all your streams share the same TCP bottleneck.

On a clean fiber connection, you'll barely notice. But on WiFi — especially busy coffee shop WiFi, conference WiFi, home WiFi with 12 devices — packet loss happens constantly. On mobile networks — 4G/5G with signal fluctuations — it happens even more.

The result? Your page loads feel janky. Your API calls sometimes take 200ms and sometimes take 2 seconds, and you can't figure out why. Your WebSocket connections drop and reconnect. It's not your code — it's TCP.

The Handshake Tax

Every time a user opens a new connection to your server over HTTPS, they pay a "handshake tax":

TCP handshake — 1 round-trip (SYN → SYN-ACK → ACK)
TLS handshake — 1 to 2 more round-trips (ClientHello → ServerHello → keys)

That's 2–3 round-trips before a single byte of real data flows.

On a fast connection with 20ms latency, that's 40–60ms. Barely noticeable. But on a mobile connection with 150ms latency? That's 300–450ms of pure waiting. Almost half a second, just for the privilege of starting to talk to your server.

And it gets worse. Users don't just connect once — they open new connections to different subdomains, to your CDN, to your API. Each one pays the same tax.

The WiFi-to-Cellular Problem

Here's one that every mobile user has experienced: you're loading a page on WiFi, then you walk out of range. Your phone switches to cellular. What happens?

Every single TCP connection dies.

TCP connections are identified by four things: source IP, source port, destination IP, destination port. When your phone switches networks, your IP changes — and TCP has no mechanism to migrate connections. They all drop, the browser reopens them, pays the handshake tax again, and resends the requests.

If your user was in the middle of uploading a file or streaming data, it's gone. Start over.

Enter QUIC: TCP's Replacement

QUIC isn't an incremental improvement over TCP. It's a complete replacement — a new transport protocol built from scratch by Google, then standardized by the IETF (RFC 9000). And it was specifically designed to solve every problem we just described.

Independent Streams: No More Head-of-Line Blocking

QUIC runs over UDP and implements its own reliability layer. But unlike TCP, QUIC knows about individual streams. If a packet belonging to stream #3 gets lost, only stream #3 waits for the retransmission. Streams #1, #2, #4–15 keep flowing without interruption.

Think about what this means for your users on WiFi. That single lost packet that used to freeze all 15 resources? Now it only affects the one resource it belongs to. The rest of the page continues loading normally.

This is the single biggest performance improvement HTTP/3 brings, and it's most dramatic exactly where your users need it most — on unreliable connections.

Faster Handshakes: 1 Round-Trip (or Zero)

QUIC merges the transport and TLS handshake into a single operation. First connection to a server? One round-trip and you're sending data. That 300–450ms tax on mobile drops to 150ms.

Reconnecting to a server you've visited before? Zero round-trips. QUIC supports 0-RTT resumption — the client can start sending data in the very first packet. For APIs and real-time apps, this is transformative.

Connection Migration: Seamless Network Switches

QUIC connections aren't identified by IP addresses. Instead, each connection has a Connection ID — a random token that both sides remember. When your user walks out of WiFi range and their phone switches to cellular, the Connection ID stays the same. The QUIC connection survives.

No dropped connections. No re-handshakes. No lost uploads. The user doesn't even notice the switch happened.

Built-in Encryption

Every QUIC connection is encrypted by default using TLS 1.3 — the latest and most secure version. There's no option to run unencrypted QUIC. Security isn't an afterthought or an optional layer — it's fundamental to the protocol.

So Why Isn't Everyone Using HTTP/3 in Node.js?

Good question. The browsers are ready. The protocol is standardized. Major servers support it. So what's the holdup?

The problem is that Node.js doesn't have a built-in QUIC implementation.

Unlike HTTP/1.1 and HTTP/2, which have node:http and node:http2, there's no node:http3. It's been discussed for years, there have been experimental branches, but nothing has shipped. The reason is complex: QUIC requires deep integration with TLS internals that Node's existing APIs don't expose, and the QUIC state machine is genuinely complex — packet scheduling, congestion control, key rotation, connection migration.

This left Node.js developers with two options: either proxy through a server like nginx that supports HTTP/3 (adding infrastructure complexity), or use native C++ bindings (adding build complexity and platform-specific pain).

Until now.

QUICO: HTTP/3 for Node.js, Pure JavaScript

QUICO is an open-source library that brings full QUIC and HTTP/3 support to Node.js. And it does it with one key design decision: everything is pure JavaScript. No C++ bindings, no OpenSSL dependency, no node-gyp, no platform-specific builds.

npm install quico

That's all it takes. It works on Linux, macOS, Windows, ARM, Docker, edge devices — anywhere Node.js runs.

But the really nice part is the API. QUICO was designed to be a drop-in replacement for node:https. If you already know how to use https.createServer(), you already know how to use QUICO.

Your First HTTP/3 Server

import quico from 'quico';
import fs from 'node:fs';

const server = quico.createServer({
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt')
}, (req, res) => {
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end('Hello from HTTP/3!');
});

server.listen(4433, () => {
  console.log('HTTP/3 server on https://localhost:4433');
});

Look familiar? It should — it's the same pattern as https.createServer(). Same req, same res, same writeHead(), same end(). The only difference is what's happening underneath: instead of TCP + TLS, you're now running QUIC + HTTP/3.

It Works with Express (and Fastify, and Koa)

Here's where it gets interesting. Because QUICO mirrors the node:https API, your existing frameworks just work:

import express from 'express';
import quico from 'quico';
import fs from 'node:fs';

const app = express();

app.get('/', (req, res) => {
  res.json({
    message: 'Hello!',
    protocol: req.httpVersion  // "3.0" ← this is new
  });
});

app.get('/users', (req, res) => {
  // Your existing routes — nothing changes
  res.json(users);
});

quico.createServer({
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt')
}, app).listen(4433);

All your routes, all your middleware, all your error handlers — everything stays exactly the same. You're just replacing https.createServer with quico.createServer. That's the whole migration.

And your users get: faster connections, no head-of-line blocking, resilient connections on flaky WiFi, and seamless network switches on mobile. Without changing a single line of your application logic.

Making HTTP/3 Requests from Node.js

QUICO also works as a client. Want to make requests to HTTP/3-enabled servers?

import quico from 'quico';

quico.request('https://www.google.com/', (res) => {
  console.log('Status:', res.statusCode);    // 200
  console.log('Protocol:', res.httpVersion); // "3.0"

  res.on('data', (chunk) => process.stdout.write(chunk));
});

The client is smart about protocol negotiation. It uses Alt-Svc headers to discover HTTP/3 support, and if the server doesn't support it, it falls back gracefully to HTTP/2 and then HTTP/1.1. No code changes, no error handling — it just works.

Multi-Domain Hosting with SNI

Running multiple domains on one server? QUICO supports SNICallback, just like node:https:

import quico from 'quico';
import tls from 'lemon-tls';

const server = quico.createServer({
  SNICallback(servername, cb) {
    cb(null, tls.createSecureContext({
      key: fs.readFileSync(`certs/${servername}.key`),
      cert: fs.readFileSync(`certs/${servername}.crt`)
    }));
  }
}, handler);

server.listen(4433);

Same pattern, same mental model. One server, many domains, now over HTTP/3.

WebTransport: The Real Upgrade from WebSocket

If you've ever built a real-time application — chat, gaming, live dashboards, collaborative editing — you've probably used WebSocket. And you've probably struggled with it.

WebSocket has fundamental limitations that no amount of library code can fix:

It runs on TCP, which means it suffers from the same head-of-line blocking we talked about. If one message stalls, every message behind it stalls too. For a chat app, maybe that's acceptable. For a game where you need 60 updates per second, it's painful.

Everything is reliable and ordered, even when you don't want it to be. In a game, you don't care about the player's position from 200ms ago — you want the latest position. But WebSocket will dutifully deliver every single update in order, even the stale ones.

No multiplexing. Want to send different types of data — chat messages on one channel, game state on another, voice data on a third? With WebSocket, it's all one stream. You end up building your own multiplexing layer on top.

WebTransport solves all of this. It's built on top of QUIC and gives you:

Bidirectional streams — like WebSocket, but multiplexed. Open as many independent channels as you need.
Unidirectional streams — when you only need to send data one way.
Unreliable datagrams — fire-and-forget messages with no head-of-line blocking. Perfect for game state, sensor data, or anything where the latest value is all that matters.

And because it runs over QUIC, you get all the benefits: no head-of-line blocking between streams, encrypted by default, and resilient to network changes.

Here's what a WebTransport server looks like with QUICO:

import quico from 'quico';

quico.createServer({ key: KEY, cert: CERT }, (req, res) => {
  if (req.headers[':protocol'] === 'webtransport') {
    // Accept the WebTransport session
    res.writeHead(200);

    // Handle bidirectional streams from the client
    req.on('stream', (stream) => {
      stream.on('data', (chunk) => {
        console.log('Received:', chunk.toString());
        stream.write('Acknowledged');
      });
      stream.on('end', () => stream.end());
    });

    // Handle unreliable datagrams
    req.on('datagram', (data) => {
      // Process real-time data (game state, sensor data, etc.)
      res.sendDatagram(data); // echo back
    });

    // The server can also open streams toward the client
    const push = res.createBidirectionalStream();
    push.write('Welcome! Server-initiated stream.');
    push.end();
  } else {
    // Regular HTTP/3 request
    res.writeHead(200, { 'content-type': 'text/plain' });
    res.end('Hello HTTP/3!');
  }
}).listen(4433);

And on the client side — in the browser — you use the standard WebTransport API:

const wt = new WebTransport('https://yourserver.com:4433/live');
await wt.ready;

// Reliable bidirectional stream (like WebSocket, but multiplexed)
const stream = await wt.createBidirectionalStream();
const writer = stream.writable.getWriter();
await writer.write(new TextEncoder().encode('Hello'));

// Unreliable datagrams (like UDP — latest value wins)
const dgramWriter = wt.datagrams.writable.getWriter();
await dgramWriter.write(new TextEncoder().encode(JSON.stringify({
  x: player.x,
  y: player.y,
  timestamp: Date.now()
})));

Notice that the browser-side code uses the standard WebTransport API — no special client library needed. QUICO on the server, native browser API on the client. That's it.

For testing without a browser, QUICO also includes a Node.js WebTransport client with the same API, so you can write integration tests entirely in Node.

What's Under the Hood

You might be wondering: how does a pure JavaScript library implement a protocol as complex as QUIC?

QUICO implements the full stack from the ground up:

UDP layer — uses Node's built-in dgram module for raw UDP sockets
QUIC transport (RFC 9000) — packet parsing, frame encoding, connection IDs, ACK processing, flow control, and key rotation
TLS 1.3 — handled by LemonTLS, a pure JavaScript TLS implementation that provides the cryptographic layer QUIC requires (AES-128-GCM, AES-256-GCM, X25519, P-256, P-384)
HTTP/3 (RFC 9114) — request/response mapping onto QUIC streams
QPACK (RFC 9204) — header compression with static and dynamic tables
WebTransport (RFC 9297) — bidirectional streams, unidirectional streams, and datagrams

No OpenSSL. No native code. Every packet, every frame, every byte is JavaScript you can step through in a debugger.

The fact that this is all JavaScript means something important for you as a developer: you can actually understand what's happening. If something goes wrong, you can set a breakpoint and trace it. You can't do that with a C++ QUIC library.

Tested Against the Real World

This isn't a spec-only implementation. QUICO has been tested for interoperability against the QUIC implementations powering real production traffic:

Google — the creators of QUIC
Cloudflare — one of the largest HTTP/3 deployments in the world
Facebook / Meta
Microsoft
nginx — the QUIC-enabled branch

When you use QUICO to connect to these servers, it works. When these servers connect to your QUICO server, it works. That level of interoperability matters.

How to Test Locally

QUIC requires TLS 1.3 with ECDSA certificates. Regular self-signed RSA certificates won't work. The easiest way to set up local development is with mkcert:

# Install mkcert (one-time setup)
brew install mkcert   # macOS
# or: choco install mkcert   # Windows
# or: apt install mkcert   # Linux

# Create a local CA and generate certificates
mkcert -install
mkcert localhost 127.0.0.1 ::1

This creates localhost+2.pem and localhost+2-key.pem files that QUICO can use directly.

To test with curl:

curl --http3 https://localhost:4433 --insecure

To test with Chrome:

chrome --enable-quic --quic-version=h3 \
  --origin-to-force-quic-on=localhost:4433 \
  https://localhost:4433

What You Get Today

QUICO gives you a fully working HTTP/3 server and client with QPACK header compression, WebTransport (bidirectional streams, unidirectional streams, and datagrams), automatic H3 → H2 → H1 fallback, and drop-in compatibility with Express, Fastify, and Koa. TLS 1.3 is handled internally with support for multiple cipher suites and key exchange algorithms.

It's been tested for interoperability against Google, Cloudflare, Facebook, Microsoft, and nginx — the same servers handling real production traffic today.

The library is in active development and improving fast. Check the GitHub repo for the latest status and to follow along.

Getting Started

npm install quico

If you have an existing HTTPS server, the migration is one line:

- import https from 'node:https';
+ import quico from 'quico';

- https.createServer({ key, cert }, app).listen(443);
+ quico.createServer({ key, cert }, app).listen(4433);

Everything else stays the same.

Resources:

Why This Matters

We're at an interesting moment in web infrastructure. HTTP/3 and QUIC aren't future technology — they're current technology that most servers haven't adopted yet. The browsers are ready. The protocols are standardized. The big players are already there.

The gap has been tooling. For Node.js developers specifically, there hasn't been a simple path to HTTP/3. QUICO fills that gap.

Your users are already on networks where QUIC makes a real difference — WiFi with interference, cellular with handoffs, VPNs with added latency. The improvements aren't theoretical: faster handshakes, no head-of-line blocking, connections that survive network switches.

And the best part? You don't have to rewrite anything to get there.

WebRTC Works Great in Demos. In Production, It Falls Apart. Here's the Fix.

Aviv Cohen — Thu, 16 Apr 2026 00:27:03 +0000

You've seen the WebRTC demo. Two browsers, a few lines of code, and suddenly there's a video call running peer-to-peer. No server in the middle, no third-party SDK, just the browser's built-in API. Magic.

Then you try to build an actual product with it.

The camera toggle breaks the call. Adding screen share crashes the negotiation. One user switches from WiFi to cellular and disappears. The DataChannel fills up and the app freezes. You spend three days debugging an issue that only happens when both peers add a track at the same time. You Google "WebRTC glare" and find a 40-line code snippet from MDN that still doesn't cover all edge cases.

This is the WebRTC experience for virtually every developer who's tried to build something real with it. The demos work. The products don't. And the gap between "demo" and "product" is enormous.

Why WebRTC Breaks in the Real World

The browser's RTCPeerConnection API is a low-level protocol binding. It gives you access to every knob and lever of the WebRTC protocol — but it also expects you to coordinate them all correctly. And the coordination is where everything goes wrong.

Glare: The Bug Nobody Warns You About

This is the most common and least understood WebRTC failure. Here's what happens:

Both peers want to renegotiate at the same time. Maybe one user turns on their camera while the other starts screen sharing. Both sides call createOffer() and send it. Now each peer receives an offer while it's already in the "have-local-offer" state.

The WebRTC spec calls this glare. The native API doesn't handle it. It just throws an error or silently corrupts the state. The MDN documentation has a "perfect negotiation" pattern that tries to solve this — but it's 40 lines of tricky code, it doesn't handle all edge cases, and it behaves differently across browsers.

In a two-person call, glare happens every time both users change their media simultaneously. In a group call, it happens constantly.

Signals That Arrive Out of Order

The native API assumes that signaling messages — offers, answers, ICE candidates — arrive in exactly the order they were sent. If an ICE candidate arrives before the offer it belongs to, addIceCandidate() silently fails. The connection never establishes, and there's no error message telling you why.

On a perfect WebSocket connection, messages arrive in order. But in the real world, signaling might go through HTTP, through a message queue, through a serverless function, or through any transport that doesn't guarantee ordering. One message taking 10ms longer than another is enough to break everything.

Renegotiation Storms

User turns on camera → negotiation starts. User immediately toggles mic → another negotiation needed. The first negotiation is still in flight. Now the SDP state is confused — the second negotiation is based on a description that hasn't been applied yet.

This happens every time users quickly toggle media, and it's especially bad during the first few seconds of a call when everyone is adjusting their settings. The result: corrupted state, dropped tracks, or a call that just stops working.

The Connection Dropped — Now What?

User walks from one room to another. WiFi signal drops for two seconds, reconnects. In a normal app, this would be seamless. In WebRTC, the ICE candidates expire, the connection state goes to "disconnected" or "failed", and... now what?

The native API gives you iceConnectionState — a string that changes. It doesn't give you disconnect or reconnect events. It doesn't automatically restart ICE. It doesn't tell you whether the connection is recoverable or dead. Building a "reconnecting..." UI requires polling the state, debouncing transitions, and guessing.

SDP: 4KB of Text for a Simple Connection

Every WebRTC offer and answer includes a Session Description Protocol (SDP) blob. For a simple DataChannel-only connection, this is 2-3KB of text. Add video and it's 4KB+. Add simulcast and you're looking at massive text blocks that need to be sent through your signaling server.

This isn't just wasted bandwidth — it's a real problem for transport-constrained signaling. If you're using MQTT, SMS, or any size-limited transport, SDP becomes a bottleneck.

No Telemetry Without Pain

Want to show the user their connection quality? Bitrate? Packet loss? Resolution? The native API gives you getStats() — a function that returns 30+ different report types. You need to poll it manually, iterate through the reports, match them to the correct stream by MID, compute deltas between polls, and correlate inbound and outbound reports.

Every app with a quality indicator reimplements this logic. Every implementation has bugs.

stable-webrtc: All of This, Handled

stable-webrtc is a library that wraps RTCPeerConnection and handles all of the above internally. The API is simple — the hard problems happen behind the scenes.

npm install stable-webrtc

The Simplest WebRTC Connection

var peer1 = new StableWebRTC();
var peer2 = new StableWebRTC();

// Relay signaling (in production: WebSocket, HTTP, MQTT, anything)
peer1.on('signal', data => peer2.signal(data));
peer2.on('signal', data => peer1.signal(data));

// Connected
peer1.on('connect', () => peer1.send('Hello from peer1!'));
peer2.on('data', msg => console.log('Received:', msg.toString()));

No role assignment. No ICE configuration. No state machine management. Just create two peers, connect their signaling, and it works.

Notice what's missing: there's no "who is the initiator?" decision. Both peers embed a random nonce in their signaling messages. The peer with the higher nonce becomes the initiator automatically. Roles are resolved before any SDP is generated — eliminating an entire class of bugs at the source.

A Video Call That Actually Works

var peer = new StableWebRTC();

// Signaling
peer.on('signal', data => ws.send(data));
ws.onmessage = msg => peer.signal(msg.data);

// Send camera
navigator.mediaDevices.getUserMedia({ video: true, audio: true })
  .then(stream => peer.addStream(stream));

// Receive remote video
peer.on('stream', (mediaStream, info) => {
  document.querySelector('video').srcObject = mediaStream;
});

That's a working video call. But the real test isn't whether it connects — it's what happens next:

User toggles camera off and on? Handled. The library serializes all negotiations through a 6-state machine. Only one negotiation happens at a time. If a new track change arrives while one is in flight, it queues and coalesces.

Both users add a track simultaneously? Handled. Glare is resolved via epoch-rotating politeness — one side always yields, and who yields alternates to prevent starvation. No deadlocks, no dropped tracks.

User switches WiFi to cellular? Handled. The library monitors connection state and automatically triggers ICE restart with configurable timeouts and backoff.

Screen share added on top of camera? Handled. The tagged streams API keeps everything organized:

// Camera
navigator.mediaDevices.getUserMedia({ video: true, audio: true })
  .then(stream => {
    peer.stream('camera', {
      video_track: stream.getVideoTracks()[0],
      audio_track: stream.getAudioTracks()[0]
    });
  });

// Screen share
navigator.mediaDevices.getDisplayMedia({ video: true })
  .then(stream => {
    peer.stream('screen', { video_track: stream.getVideoTracks()[0] });
  });

// Stop screen share — just null the track
peer.stream('screen', { video_track: null });

// On the receiving side, you know what each stream is
peer.on('stream', (mediaStream, info) => {
  if (info.tag_id === 'camera') {
    document.getElementById('camera').srcObject = mediaStream;
  } else if (info.tag_id === 'screen') {
    document.getElementById('screen').srcObject = mediaStream;
  }
});

No transceiver management, no m-line ordering bugs, no SDP manipulation. Tag your streams with a name, and the library handles the rest.

Connection Status Without Polling

Building a "reconnecting..." indicator with the native API requires polling iceConnectionState, debouncing rapid transitions, and writing custom logic. With stable-webrtc, it's events:

peer.on('connect', () => {
  showStatus('Connected');
});

peer.on('disconnect', (info) => {
  showStatus('Reconnecting (' + info.reason + ')...');
  // ICE restart happens automatically — nothing to do
});

peer.on('reconnect', () => {
  showStatus('Connected');
});

peer.on('close', () => {
  showStatus('Disconnected');
});

When the connection drops, the library starts an automatic ICE restart sequence: wait 3 seconds (configurable) in case it recovers naturally, then restart ICE, up to 5 retries with backoff. If it recovers, you get a reconnect event. If it doesn't, you get close. Your code just updates the UI.

Per-Stream Quality Metrics — No getStats() Wrestling

Showing bitrate, packet loss, or resolution per stream normally requires polling getStats(), parsing 30+ report types, matching by MID, and computing deltas. With stable-webrtc:

peer.on('streamstats', (tagId, direction, stats) => {
  if (direction === 'receiving') {
    showBitrate(tagId, stats.video.bitrate);
    showFPS(tagId, stats.video.fps);
    showResolution(tagId, stats.video.width + 'x' + stats.video.height);

    if (stats.video.packetLoss > 5) {
      showQualityWarning(tagId);
    }
  }
});

Each streamstats event gives you { bitrate, fps, width, height, codec, packetLoss, jitter } for both video and audio, per tagged stream. The library handles the polling, the delta computation, and the report-to-stream matching internally.

Want to check the connection type and latency?

peer.on('connectioninfo', (info) => {
  console.log(info.type);  // 'direct-udp', 'direct-tcp', 'relayed'
  console.log(info.rtt);   // 12.3 (milliseconds)
});

SDP Compression: 3KB → 50 Bytes

This is a detail that most developers don't think about, but it matters. Every time you renegotiate (add a track, switch camera, start screen share), a new SDP offer is generated and sent through your signaling server. A typical offer is 3-4KB of text.

stable-webrtc compresses every signaling message using four competing strategies — compact binary encoding, diff against previous SDP, deflate compression, and diff+deflate. The smallest payload wins automatically.

The result: a typical renegotiation (adding a video track) goes from 3KB to about 50-100 bytes. That's small enough for a single UDP packet, an MQTT message, or even an SMS.

And once the DataChannel is open, signaling messages automatically route through the peer-to-peer connection itself — bypassing your server entirely. Renegotiation latency drops to the raw round-trip time between peers.

Mesh Networks: N Peers

Building a group call? Each participant maintains a connection to every other participant:

var peers = {};

function connectTo(remoteId) {
  var peer = new StableWebRTC();
  peers[remoteId] = peer;

  peer.on('signal', data => {
    server.send({ to: remoteId, signal: data });
  });

  peer.on('connect', () => {
    peer.send('Hello from ' + myId);
  });

  peer.on('stream', (mediaStream, info) => {
    addVideoElement(remoteId, mediaStream);
  });

  return peer;
}

// When signaling arrives from the server
server.on('signal', (fromId, data) => {
  if (!peers[fromId]) connectTo(fromId);
  peers[fromId].signal(data);
});

Each connection independently handles its own glare resolution, ICE management, and media negotiation. No centralized coordinator needed.

Works in Node.js Too

stable-webrtc isn't browser-only. In Node.js, pass a WebRTC binding:

var wrtc = require('@roamhq/wrtc');
var peer = new StableWebRTC({ wrtc: wrtc });

Same API, same behavior. This is useful for building server-side recording, media processing pipelines, testing infrastructure, or any scenario where you need a WebRTC peer that isn't a browser.

Security: Verifying Who You're Talking To

Every WebRTC connection creates a short-lived DTLS certificate. Normally, you trust that your signaling server hasn't been compromised. But for sensitive applications — messaging, payments, healthcare — you can verify the peer's identity cryptographically:

peer.on('fingerprints', (localFP, remoteFP) => {
  // Both peers see both fingerprints
  // You can sign them with your app's identity key
  // and verify the other side did the same
  // → proof that no MITM tampered with the connection
});

This is optional — connections work without it. But it's there when you need it.

What's Actually Inside

Under the simple API, here's what stable-webrtc is managing for you:

A 6-state negotiation machine that serializes all offer/answer exchanges, preventing concurrent negotiations from corrupting SDP state.

Epoch-rotating glare resolution where which peer yields alternates with each successful negotiation, preventing both starvation and deadlocks.

ICE candidate queueing that holds candidates per-ufrag until the remote description is applied, then drains them in the right order.

Transceiver recycling that reuses inactive transceivers instead of stopping them, keeping m-line ordering stable across renegotiations.

DataChannel backpressure with bounded queues, watermark-based pacing, and drain notifications to prevent memory bloat during high-throughput data transfer.

Automatic ICE restart with configurable timeouts, retry limits, and exponential backoff.

SDP compression with four competing strategies and automatic checksum verification.

Connection telemetry computed from getStats() with proper delta calculation, report matching, and per-stream aggregation.

All of this runs internally. You never see it. You just get a connection that works.

Getting Started

npm install stable-webrtc

var peer = new StableWebRTC();
peer.on('signal', data => sendToRemotePeer(data));
peer.on('connect', () => console.log('Connected!'));
peer.on('data', msg => console.log('Received:', msg));

Resources:

📦 npm — stable-webrtc
💻 GitHub — stable-webrtc

The Point

WebRTC is an incredible technology. Peer-to-peer video, audio, and data in the browser, with no plugins and no intermediary servers. But the native API was designed for protocol implementers, not application developers. The gap between "it connects in a demo" and "it works reliably in production" is measured in months of debugging.

That gap doesn't need to exist. The hard problems — glare, renegotiation, signaling order, ICE management, SDP bloat, telemetry — are solvable. They just need to be solved once, in a library, instead of in every application that touches WebRTC.

That's what stable-webrtc does. All the hard parts, handled. All the simple parts, simple.

Stop Using Certbot. Manage SSL Certificates From Your Node.js Code.

Aviv Cohen — Thu, 16 Apr 2026 00:24:54 +0000

You know the ritual. You spin up a new server, install certbot, run the command, hope it works, set up a cron job for renewal, pray it doesn't silently fail three months later at 3am, and if it does — your users wake up to a scary browser warning and you wake up to a panicked Slack message.

And that's the good scenario. The bad scenario is when you're running Node.js behind nginx just for SSL termination. Your app handles everything — routing, middleware, WebSockets, API logic — but nginx sits in front of it for one reason: HTTPS certificates. An entire reverse proxy, with its own configuration language, its own process, its own failure modes, just to handle TLS.

Or maybe you've gone the cloud route. You pay for AWS Certificate Manager or Cloudflare's managed certificates. They work great — until you need a certificate for something that isn't behind their load balancer. An internal service, a custom protocol, a TURN server, a mail server.

What if your Node.js app could just... get its own certificates? Automatically? Without any external tools?

ACME: The Protocol Behind Let's Encrypt

Before we look at code, it helps to understand what's actually happening when you get a free SSL certificate.

Let's Encrypt (and ZeroSSL, and other free CAs) use a protocol called ACME — Automatic Certificate Management Environment (RFC 8555). It's an API. Your client talks to the CA's server, proves you control a domain, and gets a signed certificate back.

The proof of domain control usually works like this: the CA says "put this specific value in a DNS TXT record for your domain." You do it. The CA checks. If the record is there, you clearly control the domain. Certificate issued.

The protocol itself isn't complicated. But the implementation is: you need to generate keys, create a signed JWT for every request, encode a CSR in DER format with ASN.1, handle nonce rotation, poll for authorization status, and deal with edge cases like badNonce errors and rate limits.

Most developers don't want to learn ASN.1 DER encoding. They just want HTTPS.

cert-manager: HTTPS Certificates in 10 Lines

cert-manager is a zero-dependency ACME client for Node.js. It handles the entire certificate lifecycle — from key generation to renewal — with an event-driven API that hides all the protocol complexity.

npm install cert-manager

Here's a wildcard certificate for your domain:

import ssl from 'cert-manager';

var order = ssl.createOrder({
  domain: 'example.com',
  wildcard: true,
  email: 'admin@example.com',
});

order.on('dns', (records, done) => {
  // Set these DNS TXT records at your provider, then:
  console.log('Set DNS records:', records);
  done();
});

order.on('certificate', (cert) => {
  console.log(cert.cert);       // Server certificate (PEM)
  console.log(cert.ca);         // CA chain (PEM)
  console.log(cert.key);        // Private key (PEM)
  console.log(cert.expiresAt);  // Expiry date
});

order.start();

That's it. No manual account creation. No CSR generation. No JWS signing. No nonce management. Everything — key generation, account registration, order creation, DNS challenge setup, verification polling, challenge completion, and certificate download — happens automatically, step by step.

You subscribe to events. The library handles the protocol.

What Happens When You Call `order.start()`

It's worth understanding the flow, because it shows how much complexity the library absorbs:

1. Key generation. Two ECDSA P-256 keys are generated — one for the ACME account, one for the certificate. If you provide existing keys, they're reused.

2. Account registration. The library creates a signed request to the CA, registers an account with your email, and stores the account URL. Next time, it reuses the same account.

3. CAA preflight. Before even starting the order, the library checks your domain's CAA records to make sure the CA is allowed to issue for it. This catches misconfigurations early instead of failing after DNS setup.

4. Order creation. A new certificate order is created with the CA, requesting the domain (and *.domain if wildcard is enabled).

5. DNS challenge. The CA responds with DNS TXT records that need to be set. The library emits the dns event with the exact records and waits for you to call done().

6. Verification. The library polls DNS (using fallback resolvers 8.8.8.8 and 1.1.1.1) to confirm the records are visible before telling the CA to check. This prevents the common failure mode where the CA checks before DNS has propagated.

7. Challenge completion. The library submits the challenge responses and polls the CA until all authorizations are valid.

8. Finalization. A CSR is generated, signed, DER-encoded, and submitted. The CA signs it and returns the certificate.

9. Certificate event. You get cert.cert, cert.ca, cert.key, and cert.expiresAt. Done.

If anything fails along the way — a badNonce error, a timeout, a DNS propagation delay — the library retries automatically. You get an error event only when it's genuinely unrecoverable.

DNS Provider Integration: Use Whatever You Have

The dns event gives you complete control. The library doesn't assume you use a specific DNS provider — it just tells you what records to set and waits for you to call done(). This means any provider with an API works:

Cloudflare:

order.on('dns', (records, done) => {
  var pending = records.length;
  records.forEach((record) => {
    fetch(`https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records`, {
      method: 'POST',
      headers: { 'Authorization': `Bearer ${CF_TOKEN}`, 'Content-Type': 'application/json' },
      body: JSON.stringify({ type: 'TXT', name: record.name, content: record.value, ttl: 120 }),
    }).then(() => { if (--pending <= 0) done(); });
  });
});

AWS Route 53:

order.on('dns', (records, done) => {
  var changes = records.map((r) => ({
    Action: 'UPSERT',
    ResourceRecordSet: {
      Name: r.name, Type: 'TXT', TTL: 120,
      ResourceRecords: [{ Value: `"${r.value}"` }]
    }
  }));
  route53.changeResourceRecordSets({
    HostedZoneId: ZONE_ID,
    ChangeBatch: { Changes: changes },
  }, () => done());
});

DigitalOcean, GoDaddy, Namecheap, your own DNS server — if it has an API, it works. You could even use it with dnssec-server to manage DNS programmatically and complete the challenge without any external API calls at all.

Automatic Renewal: Set It and Forget It

Getting a certificate once is nice. Making sure it renews every 90 days without you thinking about it is what you actually need.

The manager handles multi-domain certificate management with persistent storage and automatic renewal:

import ssl from 'cert-manager';

var mgr = ssl.manager({
  dir: './certs',
  email: 'admin@example.com',
});

mgr.add('example.com', { wildcard: true });
mgr.add('api.example.com');
mgr.add('other.com');

mgr.on('dns', (domain, records, done) => {
  setDnsRecords(domain, records).then(() => done());
});

mgr.on('certificate', (domain, cert) => {
  console.log(domain, 'certificate ready!');
  reloadServer(cert);
});

mgr.on('renewing', (domain, daysLeft) => {
  console.log(domain, 'renewing,', daysLeft, 'days left');
});

mgr.start();

That's a production certificate manager. It stores certificates and keys to disk, tracks expiry dates, and renews 7 days before expiration. On process restart, mgr.start() reads the stored state and picks up where it left off — no need to call add() again.

The manager includes protections that come from experience with real-world certificate management: domains are processed one at a time (never parallel, to avoid rate limits), failed domains are throttled (minimum 4 hours between retries), each domain has a 10-minute timeout, and domains that have never been attempted are prioritized.

Zero Dependencies — And What That Actually Means

cert-manager uses only Node.js built-in modules. That sounds like a nice-to-have, but for a crypto library it's significant.

The ACME protocol requires several cryptographic operations: ECDSA key generation, JWS (JSON Web Signature) creation, CSR generation with ASN.1 DER encoding, and HMAC signing for External Account Binding. Most Node.js ACME libraries pull in node-forge, jose, or other dependencies for these operations.

cert-manager implements all of it from scratch using node:crypto. The ASN.1 DER encoder, the JWS signer, the CSR builder — all in a few hundred lines of JavaScript. This means:

No supply chain risk from third-party crypto dependencies
No version conflicts with other packages in your project
The code is small enough to audit (the entire src/ directory is seven files)

Works With Let's Encrypt and ZeroSSL

Let's Encrypt is the default provider, but ZeroSSL works too — useful if you need more certificates than Let's Encrypt's rate limits allow, or if you want a different CA for redundancy:

ssl.createOrder({
  domain: 'example.com',
  email: 'admin@example.com',
  provider: 'zerossl',
  eab: {
    kid: 'YOUR_EAB_KID',
    hmacKey: 'YOUR_EAB_HMAC_KEY',
  },
});

Any ACME-compatible CA will work with the same API.

Testing with Staging

Let's Encrypt has strict rate limits on production certificates. While developing your integration, use the staging environment:

ssl.createOrder({
  domain: 'example.com',
  email: 'admin@example.com',
  staging: true,  // Uses Let's Encrypt staging — no rate limits
});

The staging CA issues real certificates signed by a fake root — they'll show browser warnings, but they validate that your entire flow (DNS records, verification, issuance) works correctly before you switch to production.

Putting It All Together: HTTPS Server With Auto-Renewal

Here's what a self-managing HTTPS server looks like:

import ssl from 'cert-manager';
import https from 'node:https';

var currentCert = null;

var mgr = ssl.manager({
  dir: './certs',
  email: 'admin@example.com',
});

mgr.add('myapp.com', { wildcard: true });

mgr.on('dns', (domain, records, done) => {
  setDnsRecords(domain, records).then(() => done());
});

mgr.on('certificate', (domain, cert) => {
  currentCert = cert;
  console.log('Certificate ready, expires:', cert.expiresAt);
});

mgr.start();

// Server uses SNICallback to always serve the latest certificate
var server = https.createServer({
  SNICallback: (servername, cb) => {
    if (currentCert) {
      cb(null, require('tls').createSecureContext({
        key: currentCert.key,
        cert: currentCert.cert + '\n' + currentCert.ca.join('\n'),
      }));
    }
  }
}, app);

server.listen(443);

No certbot. No cron. No nginx. The certificate renews itself, and the server picks up the new certificate automatically through SNICallback.

Getting Started

npm install cert-manager

Start with staging to validate your setup:

import ssl from 'cert-manager';

var order = ssl.createOrder({
  domain: 'yourdomain.com',
  email: 'you@yourdomain.com',
  staging: true,
});

order.on('dns', (records, done) => {
  console.log('Set these DNS records:', records);
  // Set them manually or via API, then:
  done();
});

order.on('certificate', (cert) => {
  console.log('It works! Switch staging to false for production.');
});

order.start();

Resources:

The Bigger Picture

Certificate management shouldn't be a separate system. It shouldn't require a separate tool, a separate configuration language, a separate daemon running on your server. It's a fundamental part of running an HTTPS service — and it belongs in your application code.

When your certificates are managed by the same code that serves your app, everything simplifies. Deployment is one process. Monitoring is one log stream. Renewal is automatic. And when something goes wrong, you debug it the same way you debug everything else — in JavaScript, with the tools you already know.

Your server, your certificates, your code. No middlemen.

Stop Paying for TURN. Run Your Own in Node.js.

Aviv Cohen — Thu, 16 Apr 2026 00:22:42 +0000

If you've ever built a WebRTC application, you've hit this wall: two users try to connect, and it works perfectly in your office. Then you deploy, and 15% of your users can't connect at all.

The problem is NAT. Most devices sit behind a firewall or router that blocks incoming connections. When two users are both behind NATs, neither can reach the other directly. The WebRTC connection fails silently, and your users stare at a spinner that never goes away.

The solution is a TURN server — a relay that both peers can reach, which forwards traffic between them. It's the fallback that makes WebRTC work for everyone, not just people on favorable networks.

The catch? Running a TURN server has traditionally meant either paying a third-party service ($50–500/month depending on usage) or installing coturn — a C daemon with a 3,000-line configuration file, its own database for credentials, and its own deployment and monitoring story.

What if your TURN server was just another part of your Node.js app?

Why Your WebRTC App Needs TURN

Let's be clear about when TURN is needed and when it isn't.

STUN (Session Traversal Utilities for NAT) handles the easy case. A user behind a NAT sends a request to a STUN server, which tells them their public IP and port. Armed with this information, most peers can connect directly. STUN is lightweight, stateless, and free — Google runs public STUN servers that anyone can use.

TURN (Traversal Using Relays around NAT) handles the hard case. When both peers are behind symmetric NATs — common in corporate networks, university WiFi, and some mobile carriers — direct connection is impossible. No amount of STUN magic will help. The only option is to relay traffic through a server that both sides can reach.

How often does this happen? Studies show that 10–20% of WebRTC connections require TURN relay. On corporate and mobile networks, it can be higher. If you don't have a TURN server, those users simply can't use your app.

This is why every production WebRTC application needs TURN — not as a nice-to-have, but as a reliability requirement.

The Current Options Aren't Great

Paying a service: Twilio, Xirsys, and others offer hosted TURN. They work, but they're expensive at scale. Video traffic through TURN can consume significant bandwidth, and you're paying per gigabyte. For a startup with 1,000 daily users, the bill adds up fast.

Running coturn: The standard open-source option. It's written in C, mature, and feature-complete. But it's also a separate daemon with its own configuration language, its own credential database, its own process management, and its own deployment story. If your stack is Node.js, coturn is a foreign body you have to learn, deploy, and maintain separately.

node-turn: The only Node.js option — but it hasn't been updated in 5 years, supports only basic STUN/TURN, and has no TCP support, no TLS, no hooks, and no production features.

turn-server: STUN/TURN as a Node.js Library

turn-server is a complete STUN/TURN implementation — both server and client — built from scratch in JavaScript with zero dependencies. It's not a wrapper around coturn. It's a full implementation of the protocol stack (RFC 8489, RFC 8656, RFC 6062) that you require() into your app.

npm install turn-server

A Working TURN Server

import { createServer } from 'turn-server';

const server = createServer({
  auth: {
    mechanism: 'long-term',
    realm: 'example.com',
    credentials: { alice: 'password123' }
  },
  relay: { ip: '0.0.0.0', externalIp: '203.0.113.5' }
});

server.listen({ port: 3478 });

That's a production-capable TURN server. Point your WebRTC clients at it:

new RTCPeerConnection({
  iceServers: [{
    urls: 'turn:your-server.com:3478',
    username: 'alice',
    credential: 'password123'
  }]
});

Connections that can go direct will go direct (via STUN). Connections that can't will relay through your server (via TURN). Your users don't know the difference — everything just works.

Production Configuration

The minimal example above works, but a production server needs more control:

import { createServer } from 'turn-server';

const server = createServer({
  auth: {
    mechanism: 'long-term',
    realm: 'example.com',
    secret: 'your-shared-secret'  // Time-limited REST API credentials
  },
  relay: { ip: '0.0.0.0', externalIp: '203.0.113.5' },

  maxConnections: 10000,
  userQuota: 10,           // Max allocations per user
  totalQuota: 5000,        // Max total allocations
  maxDataSize: 65535,      // Max packet size
  idleTimeout: 300000,     // Clean up dead clients after 5 min
});

// Dynamic auth — look up credentials from your database
server.on('authenticate', (username, realm, cb) => {
  db.getHmacKey(username, realm).then(key => cb(key));
});

// Graceful shutdown
process.on('SIGTERM', () => {
  server.drain(30000, () => process.exit(0));
});

// Listen on multiple transports
server.listen([
  { port: 3478 },                                          // UDP + TCP
  { port: 5349, transport: 'tls', cert: CERT, key: KEY },  // TLS
]);

Notice the secret option — this enables the TURN REST API, which generates time-limited credentials. Instead of storing usernames and passwords, your backend generates temporary credentials per session. This is the standard approach for production WebRTC.

14 Hooks: Control Every Decision

This is where turn-server really differentiates itself from coturn. Every decision point in the server is exposed as a hook — accept or reject, with full context:

// Control who can connect
server.on('accept', (info, cb) => {
  cb(isAllowed(info.source.ip));
});

// Control who can allocate relay resources
server.on('beforeAllocate', (info, cb) => {
  if (isPremiumUser(info.username)) {
    info.lifetime = 3600;  // Premium users get longer allocations
  }
  cb(true);
});

// Control what gets relayed
server.on('beforeRelay', (info, cb) => {
  cb(info.size < 65535);  // Drop oversized packets
});

// Track usage
server.on('onRelayed', (info) => {
  metrics.trackBandwidth(info.username, info.size, info.direction);
});

There are 14 hooks in total, covering every phase: connection acceptance, authentication, authorization, quota checks, allocation, permissions, channel binding, TCP connect, and data relay. If no hook listener is attached, the action is auto-approved — so you only hook what you care about.

With coturn, this level of control requires writing C plugins or using external databases with custom schemas. Here, it's JavaScript callbacks.

It's Also a Client

Most TURN libraries are server-only. turn-server includes a complete client implementation — useful for testing, for building server-side WebRTC applications, and for NAT diagnostics.

Get your public IP:

import { getPublicIP } from 'turn-server';

getPublicIP((err, info) => {
  console.log('Public IP:', info.ip);    // "203.0.113.42"
  console.log('Mapped port:', info.port); // 54321
});

Detect your NAT type:

import { detectNAT } from 'turn-server';

detectNAT('stun:stun.example.com:3478', (err, result) => {
  console.log(result.type);  // 'full-cone', 'restricted-cone', 'symmetric-or-port-restricted'
});

Allocate a TURN relay programmatically:

import { connect } from 'turn-server';

connect('turn:turn.example.com:3478', {
  username: 'alice',
  password: 'password123',
}, (err, socket) => {
  socket.allocate({ lifetime: 600 });

  socket.on('allocate:success', (msg) => {
    console.log('Relay address ready');
  });

  socket.on('data', (peer, data) => {
    console.log(`Data from ${peer.ip}:${peer.port}`);
  });
});

The client handles auto-refresh of allocations, permissions, and channels, UDP retransmission with exponential backoff, automatic retry on authentication challenges, and DNS SRV resolution.

Performance: Where It Matters

The most common concern with a JavaScript TURN server is performance. Fair question — TURN is a data relay, and relay performance matters.

Here's the key insight: 99% of TURN traffic uses ChannelData — a minimal 4-byte header format that bypasses the full STUN encoding. It's designed for high-throughput relay with near-zero overhead.

turn-server decodes ChannelData at 9.3 million messages per second on a single core using zero-copy Uint8Array.subarray(). The control plane (allocations, permissions, refreshes) uses full STUN encoding at 36K–218K messages per second — but these operations happen a few times per minute, not per packet.

For context: a 720p video call uses roughly 100–200 packets per second. A single-core JavaScript TURN server can handle thousands of simultaneous video calls before becoming a bottleneck.

Interoperability: Tested Against the Real World

turn-server has been tested in both directions:

Its client → coturn server: Connect to an existing coturn installation, allocate relays, send data. Works.

coturn client → its server: Point coturn's turnutils_uclient at the Node.js server. Works.

Chrome/Firefox → its server: Standard RTCPeerConnection with iceServers configuration. Works.

The wire protocol implementation covers all 62 IANA-registered STUN attributes and passes all 22 RFC 5769 test vectors — the standard conformance test for STUN/TURN implementations.

Embed It, Don't Deploy It

The biggest advantage of a Node.js TURN server isn't performance or features — it's operational simplicity.

Instead of deploying and managing a separate coturn daemon alongside your Node.js app, your TURN server is just another module in your application. Same process, same deployment, same monitoring, same logging, same scaling strategy.

Need to authenticate TURN users against your existing user database? It's a callback, not a database schema migration. Need to track bandwidth per user for billing? It's a hook, not a log parser. Need to dynamically adjust quotas? Change a variable, not a configuration file.

Your infrastructure, your code, your rules.

Getting Started

npm install turn-server

Minimum viable TURN server:

import { createServer } from 'turn-server';

createServer({
  auth: { mechanism: 'long-term', realm: 'example.com', credentials: { test: 'test' } },
  relay: { ip: '0.0.0.0', externalIp: 'YOUR_PUBLIC_IP' }
}).listen({ port: 3478 });

Then in your WebRTC client:

new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:your-server.com:3478' },
    { urls: 'turn:your-server.com:3478', username: 'test', credential: 'test' }
  ]
});

Resources:

Building Your Own Load Balancer in Node.js

Aviv Cohen — Wed, 17 Sep 2025 18:57:20 +0000

Why you need a load balancer

Imagine your website suddenly becomes popular. Hundreds or thousands of users are visiting at the same time.

If all of them land on one server, that server will slow down, maybe even crash.

The natural solution is to run more than one server — maybe two, three, or ten — and spread the traffic between them.

The missing piece is a “traffic director” that decides who goes where. That’s what a load balancer is: it makes sure no single server carries all the weight.

Different approaches to load balancing

There are several ways to share traffic. Each approach works differently and comes with its own pros and cons:

1) Reverse Proxy

How it works: All traffic first goes through one main server — the reverse proxy. It accepts every request and forwards it to another backend server. This can be done at the transport layer or the application layer.

Example: A network load balancer forwarding TCP packets to different machines; or Nginx acting as a reverse proxy for HTTP requests.

✅ Pros:
- Simple to configure.
- Works with any application.
- Easy to add features like TLS termination, WebSockets, or header manipulation.
⚠️ Cons:
- Everything passes through one “gatekeeper.”
- If that proxy server gets overloaded or is physically far from the user, performance suffers.
- It can become a single point of failure.

2) Redirector Server

How it works: Instead of proxying every request forever, the main server can redirect the client to a more specific server or subdomain. For example, the proxy receives the first request, decides that this user should go to eu.example.com, and responds with a redirect. From then on, the client talks directly to that server.

Example: A Node.js server that checks the client’s IP location, then replies: “302 Redirect → us1.example.com” or “eu2.example.com.”

✅ Pros:
- After the first step, traffic no longer flows through the main proxy — reducing load on it.
⚠️ Cons:
- Users still depend on that central server for the first connection.
- If it’s busy or goes down, new sessions can’t be routed correctly.

3) Anycast / IP‑level routing (used by Cloudflare, Google, etc.)

How it works: The same IP address is announced from multiple geographic locations using BGP. Internet routing automatically directs users to the nearest announcement.

Example: 1.2.3.4 is announced from Amsterdam and New York; BGP delivers client traffic to the closest point.

✅ Pros:
- Very fast.
- Automatic.
- Resilient.
⚠️ Cons:
- Requires BGP announcements and AS management.
- Only available to large providers.
- Not realistic for small companies or developers.

4) DNS-based Routing

How it works: Your authoritative DNS server returns different IP answers depending on the query (by looking at client subnet via ECS, resolver IP, or other decision inputs). This effectively routes clients to different data centers before any TCP connection happens.

Example: For example.com, US users get 192.0.2.10, EU users get 198.51.100.20.

✅ Pros:
- Lightweight.
- Scalable.
- Avoids a single choke point.
⚠️ Cons:
- Changes are not instant.
- Some delay because of caching and resolver behavior.

The Best Approach: DNS‑based routing

The most practical way to balance traffic without expensive hardware or complex BGP setups is to use DNS itself.

Every connection on the internet starts with a DNS lookup — so if you control the DNS answers, you control where users connect.

Think of DNS as a super‑lightweight version of HTTP:

The client asks: “What’s the IP of example.com?”
Your authoritative server replies: “Connect to 203.0.113.10.”

One tiny request, one tiny response — no heavy proxy in the middle.

By taking advantage of this mechanism, you can decide on the fly:

🌍 Which server is closest to the user (geo-routing).
❤️ Which servers are healthy and ready (health-aware routing).
⚖️ How to split traffic between servers (weighted or canary testing).

This makes DNS a traffic director built into the internet itself — fast, lightweight, and surprisingly flexible.

Most traditional DNS software only gives static answers from a zone file. But if you want dynamic answers — logic that changes per user, per query, per moment — that’s where Node.js shines. With a few lines of JavaScript you can program the authoritative server itself and take full control.

Implementing a DNS‑Based Load Balancer with Node.js

To actually build a DNS‑based load balancer, you need a library that can act as an authoritative DNS server. And in the Node.js ecosystem there’s one library that really makes this possible: dnssec-server.

Unlike traditional DNS software, which mostly relies on static zone files, dnssec-server lets you generate answers programmatically — with the same simplicity as Node’s built‑in HTTP module. That means your application can decide, in real time, what IPs to return. It’s the only Node.js library that brings this level of dynamic control and DNSSEC support out of the box.

Here’s how it works at a high level:

📩 A DNS query arrives (for example, example.com type A).
⚙️ Your handler function runs, where you can inspect the query, check GeoIP, consult a health map, or apply custom logic.
📤 You return one or more answers (A for IPv4, AAAA for IPv6), each with its own TTL.

Let’s see it in practice.

Example 1 — Geo‑based answer (A/AAAA), annotated

// Import the library and GeoIP helper
const dns_server = require('dnssec-server');
const geoip = require('geoip-lite');

// 🌍 Region → IP mapping for both IPv4 (A) and IPv6 (AAAA)
const EDGES = {
  us: { A: '192.0.2.10',    AAAA: '2001:db8:10::10' },
  eu: { A: '198.51.100.20', AAAA: '2001:db8:20::20' }
};

// 🔍 Simple region picker by country code
function pickRegion(ip){
  const looked = geoip.lookup(ip) || {};
  const cc = looked.country || 'US';
  const EU = { DE:1, FR:1, NL:1, IT:1, ES:1, PL:1, SE:1 };
  return EU[cc] ? 'eu' : 'us';
}

// 🚀 Create the DNS server
const server = dns_server.createServer((req, res) => {
  // Only handle queries for our domain
  if (req.name == 'example.com.'){
    const region = pickRegion(req.remoteAddress);

    // 📡 Add IPv4 answer if requested
    if (req.type === 'A' || req.type === 'ANY') {
      res.answers.push({
        name: req.name,
        type: 'A', 
        ttl: 30, 
        data: {
          address: EDGES[region].A 
        }
      });
    }

    // 📡 Add IPv6 answer if requested
    if (req.type === 'AAAA' || req.type === 'ANY') {
      res.answers.push({
        name: req.name, 
        type: 'AAAA', 
        ttl: 30, 
        data: {
          address: EDGES[region].AAAA 
        }
      });
    }

    res.send();
  }

});

Each query for example.com is checked against the user’s IP. We decide if the user is closer to us or eu, then send back both A (IPv4) and AAAA (IPv6) records with a 30s TTL.

Example 2 — Health‑aware answer (skip unhealthy regions), annotated

// Import the library
const dns_server = require('dnssec-server');

// 🩺 Track health of each region (updated by background checks)
let health = { us:true, eu:true };

// 🌍 Region → IP mapping
const EDGES = {
  us: { A: '192.0.2.10',    AAAA: '2001:db8:10::10' },
  eu: { A: '198.51.100.20', AAAA: '2001:db8:20::20' }
};

// ⚙️ Function to choose the best healthy region
function bestRegion(){
  if (health.eu) return 'eu';
  if (health.us) return 'us';
  return 'us'; // fallback
}

// 🚀 Create the DNS server
const server = dns_server.createServer((req, res) => {

  // Only handle queries for our domain
  if (req.name == 'example.com.'){
    const region = bestRegion();

    // 📡 Add IPv4 answer if requested
    if (req.type === 'A' || req.type === 'ANY') {
      req.answers.push({ 
        name: req.name,
        type: 'A',
        ttl: 30,
        data: {
          address: EDGES[region].A 
        }
      });
    }

    // 📡 Add IPv6 answer if requested
    if (req.type === 'AAAA' || req.type === 'ANY') {
      res.answers.push({ 
        name: req.name, 
        type: 'AAAA',
        ttl: 30,
        data: {
          address: EDGES[region].AAAA 
        }
      });
    }

    res.send();
  }

});

We maintain a small health map that tells us which regions are alive. If EU is healthy we send users there, otherwise they go to US. The logic is simple, but powerful enough to keep traffic flowing smoothly.

Pointing your Domain to Your Node.js Server

The DNS server that answers is not necessarily the same server that hosts your site files. In many cases, you may be using DNS services from your domain registrar (e.g. Namecheap, GoDaddy), a cloud provider (e.g. AWS Route 53, Cloudflare DNS), or traditional DNS software like BIND running on a separate server.

If you haven’t explicitly set up your own authoritative DNS server, then by default your DNS is being served by one of those services.

Here is how to set your domain’s NS (Name Server) records to point to your machine:

Everyone who has ever configured a domain has seen something like this:

ns1.example.com → points to IP of your Node.js DNS server.
ns2.example.com → secondary server for redundancy.

For example, in Namecheap’s dashboard you would:

Go to Domain List.
Select your domain, click Manage.
Under Nameservers, choose Custom DNS.
Enter ns1.example.com and ns2.example.com and IP address for each of them.

Once saved and propagated, queries for your domain will start hitting your Node.js server. From there you have full programmatic control over the answers you return, and that means your DNS layer becomes part of your application logic — agile and reactive, adapting to your needs without relying on third‑party services.

Join the discussion

💬 Have questions? Ideas for improvements? Or maybe you’ve tried building your own DNS‑based load balancer and want to share your experience?

Feel free to leave a comment or start a discussion — your feedback helps improve the tools and guides for everyone.

Enable DNSSEC Support in Your Node.js Application

Aviv Cohen — Thu, 11 Sep 2025 04:37:12 +0000

The Internet Relies on DNS – and That’s Where the Problem Begins

Every visit to a website, every time an app communicates with a server – it all starts with a simple but critical step: translating a domain name into an IP address. The DNS system is the phone book of the Internet. Without DNS, we’d be stuck typing long IP numbers instead of easy-to-remember names like example.com.

But DNS was born in a different era. In the 1980s, the Internet was still a small academic network. Nobody imagined it would become a global infrastructure supporting banks, governments, e-commerce, and billions of users. As a result, DNS was designed without cryptographic security. In simple terms: when you get an answer from DNS – who guarantees it’s really correct?

Here lies the problem: an attacker can intercept your query or inject a fake answer, tricking you into visiting a malicious site. This isn’t theoretical – such attacks, known as DNS Spoofing or Cache Poisoning, have happened many times. A user thinks they are visiting bank.com, but in reality ends up on a fraudulent server.

“But I Have SSL – Isn’t That Enough?”

This is a common misconception. For years the world has moved to HTTPS with SSL/TLS certificates. Shouldn’t that guarantee security?

The truth is more nuanced:

SSL/TLS protects communication between the user and the server – but only after the user has reached the correct server.
DNSSEC protects the step before that – ensuring the user even gets to the right server in the first place.

In other words:

DNSSEC makes sure the phone book isn’t lying.
TLS ensures the conversation with the right number is encrypted.

In reality, there have been cases where Certificate Authorities (CAs) were compromised, issuing fraudulent certificates. If the user reached the wrong server in the first place, TLS couldn’t save them. That’s where DNSSEC comes in – preventing that initial deception.

The Challenges and Developments in DNSSEC

Although DNSSEC has existed for two decades, adoption is still limited. There are several reasons: existing tools are complex and require deep expertise (like BIND or PowerDNS), awareness among developers is low, support from some TLDs and registrars is incomplete, and business pressure is often lacking – even major sites and banks sometimes don’t implement DNSSEC.

That said, the tide is shifting. Services like Google Public DNS and Cloudflare 1.1.1.1 validate DNSSEC by default. Governments around the world are beginning to require public-sector domains to be signed. Organizations like ICANN and the IETF continue to push new policies and standards. Research shows steady growth in the number of signed domains, though not yet at a sufficient pace.

The importance of DNSSEC in 2025 is clear: threats are increasing – from attacks on databases, to widespread use of insecure public WiFi, to society’s total dependence on the Internet. DNSSEC has gone from a “nice-to-have” to a critical layer of defense. It doesn’t replace SSL – it complements it. SSL secures communication with the server, while DNSSEC ensures the user actually reached the right server. Together, they complete the trust chain.

Business and Reputational Benefits of DNSSEC

Beyond the technical advantages, DNSSEC also has reputational and business value:

✅ Message to customers: A DNSSEC-signed site signals seriousness and responsibility.
✅ Competitive advantage: Few sites adopt it, so those who do stand out.
✅ Potential SEO impact: In the past, Google gradually removed non-SSL sites from search results. It’s possible the same could happen with DNSSEC in the future. The more security measures your site implements, the more you signal – both to people and to algorithms – that you’re authoritative and trustworthy.
✅ Regulatory readiness: Many governments are beginning to mandate DNSSEC for public institutions. Businesses that adopt it early will be prepared.

A New Open-Source Library for DNSSEC in Node.js

When I looked for a way to run DNSSEC in a Node.js project, I found no simple tools. Existing libraries like dns-packet can only parse DNS messages – not sign them. Serious solutions exist in other languages, but they require heavy installations.

And this is no small issue: Node.js has become a critical foundation for countless Internet services, applications, and websites. When managing a large app with dozens of services, it’s far more convenient and efficient to keep everything inside Node.js – rather than adding external servers just for DNSSEC. The lack of a native Node.js solution is one reason adoption has been so slow.

By the way, since this library runs directly on Node.js, you can also manage complementary DevOps services in the same codebase you already use to build and maintain your systems. This centralizes management and reduces reliance on external tools that require extra learning and maintenance – something most developers don’t have the time or attention for.

A new open-source project called dnssec-server was released to fill this gap:

📦 An open-source Node.js library with a simple API.
🔐 Real-time signing of every DNS record.
⚡ Lightweight and fast – run it as a script without external daemons.
🌍 Supports multiple domains and dynamic zones.
🛠 Designed for developers – run locally, test, and integrate into your projects.

Dynamic DNS Responses with Node.js

An important point is that this library isn’t just about DNSSEC. It also allows you to generate dynamic responses based on the incoming query. In traditional setups, most DNS servers behave like static HTML websites: they always return the same answer for the same record. With dnssec-server, you can behave more like a dynamic PHP site – adjusting responses on the fly depending on context, logic, or external data sources.

This opens the door to advanced use cases: geo‑based answers, load balancing logic, conditional records, or even integrating with other Node.js services in real time – all with DNSSEC signing included.

Basic Usage Example

const fs = require('fs');
const tls = require('tls');
const DNSServer = require('dnssec-server');

DNSServer.createServer({
  tls: { // enable DNS over TLS (DoT) on port 853 by default
    SNICallback: function (servername, cb) {
      cb(null, tls.createSecureContext({
        key: fs.readFileSync('key.pem'),
        cert: fs.readFileSync('cert.pem')
      }));
    }
  }
}, function (req, res) {
  console.log(`[${req.transport}] from ${req.remoteAddress}:${req.remotePort}  q=${req.name} ${req.type} ${req.class}  DO=${req.flag_do}  ECS=${req.ecsAddress||'-'}/${req.ecsSourcePrefixLength||'-'}`);

  if (req.name === 'example.com.' && req.type === 'A') {
    res.answers.push({
      name: 'example.com.',
      type: 'A',
      class: 'IN',
      ttl: 300,
      data: { address: '200.10.10.1' }
    });
    res.send();
  } else {
    res.header.rcode = 3; // NXDOMAIN
    res.authority.push({
      name: 'example.com.',
      type: 'SOA',
      class: 'IN',
      ttl: 300,
      data: {
        mname: 'ns1.example.com.',
        rname: 'hostmaster.example.com.',
        serial: 2025081001,
        refresh: 3600,
        retry: 600,
        expire: 604800,
        minimum: 300
      }
    });
    res.send();
  }
});

Check with a DNS client (depending on transport):

Classic UDP/TCP on port 53:

 dig @127.0.0.1 example.com +dnssec

DNS over TLS (DoT) on port 853 (e.g., with kdig):

 kdig +tls @127.0.0.1 -p 853 example.com A +dnssec

You’ll get a response with an RRSIG signature when DNSSEC is enabled, proving the data is authentic and hasn’t been altered.

Feels Like Handling HTTP Requests

Notice how similar this is to returning responses for HTTP requests:

req carries details about the incoming DNS query (name, type, class, transport, EDNS flags).
res is your response builder: you push answers/authority/additional sections and call res.send().
You can plug in your own logic, read from databases/APIs, implement georouting or A/B switching, and emit different records dynamically — with DNSSEC signing layered on top.
DoT via tls + SNICallback mirrors the familiar TLS setup developers already use in web servers.

This programming model lowers the barrier for Node.js teams: the same patterns you use for HTTP services apply to DNS — in code you control, alongside the rest of your stack.

Conclusion

The Internet can’t keep relying on unsigned DNS. More and more organizations – including global DNS providers and governments – are pushing DNSSEC adoption. Yet most websites, even those handling sensitive financial data, still don’t use it.

The lack of easy Node.js tools has been a major barrier. dnssec-server was built to address this gap and let developers integrate DNSSEC naturally into the Node.js systems they already manage.

🔗 GitHub – dnssec-server

Forem: Aviv Cohen

TLS in Node.js Is a Black Box - Here's an Open One

Why Would Anyone Reimplement TLS?

1. You Can't Control What You Can't See

2. You Can Actually Debug TLS Problems

3. Some Protocols Need TLS Internals

Drop-In Replacement: Same API, More Control

Session Resumption: Faster Reconnections

Mutual TLS: Both Sides Authenticate

What's Actually Happening: The TLS 1.3 Handshake

The Full Negotiation Picture

Zero Dependencies, Full Transparency

Getting Started

Why This Matters

Add HTTP/3 to Your Node.js App

The Problem Nobody Talks About: TCP Is Holding You Back

Head-of-Line Blocking: The Silent Performance Killer

The Handshake Tax

The WiFi-to-Cellular Problem

Enter QUIC: TCP's Replacement

Independent Streams: No More Head-of-Line Blocking

Faster Handshakes: 1 Round-Trip (or Zero)

Connection Migration: Seamless Network Switches

Built-in Encryption

So Why Isn't Everyone Using HTTP/3 in Node.js?

QUICO: HTTP/3 for Node.js, Pure JavaScript

Your First HTTP/3 Server

It Works with Express (and Fastify, and Koa)

Making HTTP/3 Requests from Node.js

Multi-Domain Hosting with SNI

WebTransport: The Real Upgrade from WebSocket

What's Under the Hood

Tested Against the Real World

How to Test Locally

What You Get Today

Getting Started

Why This Matters

WebRTC Works Great in Demos. In Production, It Falls Apart. Here's the Fix.

Why WebRTC Breaks in the Real World

Glare: The Bug Nobody Warns You About

Signals That Arrive Out of Order

Renegotiation Storms

The Connection Dropped — Now What?

SDP: 4KB of Text for a Simple Connection

No Telemetry Without Pain

stable-webrtc: All of This, Handled

The Simplest WebRTC Connection

A Video Call That Actually Works

Connection Status Without Polling

Per-Stream Quality Metrics — No getStats() Wrestling

SDP Compression: 3KB → 50 Bytes

Mesh Networks: N Peers

Works in Node.js Too

Security: Verifying Who You're Talking To

What's Actually Inside

Getting Started

The Point

Stop Using Certbot. Manage SSL Certificates From Your Node.js Code.

ACME: The Protocol Behind Let's Encrypt

cert-manager: HTTPS Certificates in 10 Lines

What Happens When You Call order.start()

DNS Provider Integration: Use Whatever You Have

Automatic Renewal: Set It and Forget It

Zero Dependencies — And What That Actually Means

Works With Let's Encrypt and ZeroSSL

Testing with Staging

Putting It All Together: HTTPS Server With Auto-Renewal

Getting Started

The Bigger Picture

Stop Paying for TURN. Run Your Own in Node.js.

Why Your WebRTC App Needs TURN

The Current Options Aren't Great

turn-server: STUN/TURN as a Node.js Library

A Working TURN Server

Production Configuration

14 Hooks: Control Every Decision

It's Also a Client

Performance: Where It Matters

Interoperability: Tested Against the Real World

Embed It, Don't Deploy It

What Happens When You Call `order.start()`