Forem: Aviv Cohen

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