lbd (Load Balancer Detector): Mapping Out Hidden Infrastructure Before You Test

Load balancers are everywhere in modern infrastructure, and they can quietly complicate a security assessment. If a target is sitting behind multiple backend servers, a vulnerability that appears on one request might vanish on the next simply because you hit a different node. lbd, short for Load Balancer Detector, is a small shell-script-based tool built specifically to identify whether DNS or HTTP-based load balancing is in play before you dive deeper.

I like lbd because it’s unapologetically simple — it doesn’t try to do everything, it does one recon task well and gets out of the way.

How lbd Works

lbd uses two main detection techniques:

1. DNS-based load balancing detection — it queries the target’s DNS records repeatedly and checks whether multiple A records (or the same record returned in different order/multiple IPs) indicate round-robin DNS load balancing across several backend servers.
2. HTTP-based load balancing detection — it sends multiple HTTP requests to the target and inspects subtle differences in response headers (like Server, Date drift, or slight variations in response timing and content-length) that can reveal multiple backend web servers answering behind a single load balancer or reverse proxy.

By combining both checks, lbd can often tell you not just that load balancing is happening, but roughly how it’s implemented — which matters because DNS round robin and HTTP-layer load balancing (like an actual F5, HAProxy, or nginx upstream config) have very different security implications for testing consistency.

Installation

Kali Linux ships with lbd pre-installed as part of its tools collection, but if you need to install manually:

sudo apt update
sudo apt install lbd -y

From source (it’s a bash script, so this is straightforward):

git clone https://github.com/stealth/lbd.git
cd lbd
chmod +x lbd.sh

Verify:

lbd

Running it with no arguments should print usage instructions.

Basic Syntax

lbd <domain>

Core Command Examples

Basic load balancer check against a domain:

lbd example.com

Output:

lbd - load balancing detector 0.4 - Check for (DNS/HTTP) Load-Balancing

Checking for DNS-Loadbalancing: example.com
   ...
DNS-LB: NOT FOUND

Checking for HTTP-Loadbalancing: example.com
   ...
HTTP-LB: FOUND, Server: nginx/1.18.0, Server: nginx/1.19.2

This output tells you DNS round-robin isn’t happening, but the HTTP layer is answering from at least two different backend server versions — a strong sign of an active load-balanced or clustered setup.

Running against a subdomain used in an authorized assessment:

lbd app.example.com

Redirecting output to a file for later reporting:

lbd example.com | tee lbd_results.txt

Configuration Notes

lbd doesn’t have an extensive flag system like many other tools — it’s designed to be run directly against a target with minimal configuration. Its behavior is largely automatic:

• It performs several DNS lookups in sequence, comparing returned IP sets.
• It fires a handful of HTTP requests and diff-checks the headers and timing.
• Results are printed directly to stdout, making it trivial to pipe into tee, grep, or a reporting script.

If you need custom DNS resolvers or specific behavior, you can edit the script directly since it’s plain bash — a quick way to point it at an internal resolver during an internal assessment.

Real-World Use Cases

1. Pre-testing infrastructure mapping. Before running any vulnerability scanner, I run lbd to understand whether I’m dealing with a single server or a load-balanced cluster — this changes how I interpret inconsistent scan results later.

2. Confirming CDN/reverse proxy architecture. In authorized assessments, lbd helps distinguish between a simple reverse proxy setup and genuine multi-backend load balancing, which affects how a discovered vulnerability might be scoped (does it affect all nodes, or just one?).

3. Validating infrastructure changes post-migration. After a client migrates to a new load-balanced architecture, running lbd confirms the new setup is actually distributing traffic as expected from an external, real-world testing perspective.

4. Supporting DDoS resilience assessments. Knowing whether a target uses DNS round robin or HTTP-layer load balancing informs how a resilience test should be structured, since each has different failure characteristics under load.

Workflow and Tool Integration

lbd fits naturally at the start of a recon chain:

# Step 1: Basic DNS enumeration
dnsenum example.com

# Step 2: Load balancer / architecture check
lbd example.com

# Step 3: Deeper HTTP-layer testing, aware of multiple backend servers
nikto -h https://example.com

Knowing load balancing is present before running something like Nikto or a manual injection test helps explain inconsistent results (a payload working on one request but not the next) rather than mistakenly concluding a vulnerability doesn’t exist.

Performance Optimization

• lbd’s checks are lightweight and quick by design — there’s little to optimize, but running it over a stable connection avoids false negatives from dropped DNS queries.
• If testing internal infrastructure, ensure your resolver is set correctly so DNS-based detection reflects the real internal record set rather than a public-facing one.

Troubleshooting

• If lbd reports “DNS-LB: NOT FOUND” but you know load balancing exists, the balancing may be happening purely at Layer 4/7 behind a single public IP (common with cloud load balancers), which lbd’s HTTP check should still catch — check that output section carefully.
• Inconsistent results between runs can happen on CDNs with aggressive caching; try adding cache-busting query strings if your version of the script supports custom requests.
• If the script errors out on newer systems, check that dig and curl (its main dependencies) are installed and in your PATH.

Common Mistakes

• Treating “NOT FOUND” as proof of a single-server architecture — some setups hide load balancing well enough that lbd’s basic checks won’t catch it; treat results as indicative, not definitive.
• Running lbd against a target without authorization — it still generates DNS and HTTP traffic that gets logged.
• Ignoring HTTP-LB results because DNS-LB came back negative — the two checks test genuinely different layers and should both be reviewed.

Best Practices

• Run lbd early, before any deeper vulnerability scanning, so you can correctly interpret inconsistent results later in the engagement.
• Cross-reference lbd’s findings with dig manually and curl -I header comparisons to build confidence in the result.
• Document findings clearly in your report — client teams often don’t realize how their own infrastructure is distributing traffic until it’s laid out for them.

Mini Lab Example

Set up two simple web servers behind an nginx load balancer in a lab (Docker Compose is convenient here):

# docker-compose.yml (lab only)
services:
  web1:
    image: nginx
  web2:
    image: nginx
  lb:
    image: nginx
    ports:
      - "8080:80"
    depends_on:
      - web1
      - web2

Then run:

lbd localhost:8080

You should see the HTTP-LB check pick up on subtle differences between the two backend nginx instances if they’re configured with slightly different response headers or content.

FAQ

Is lbd still actively maintained? It’s a mature, stable tool with infrequent updates since its core functionality (DNS and HTTP diffing) hasn’t needed major changes, though it’s worth checking the GitHub repo for the latest state.

Can lbd detect cloud load balancers like AWS ELB or Azure Load Balancer? Often yes, through the HTTP-layer detection, since these typically distribute traffic across multiple backend instances that may respond with slightly different headers or timing.

Does lbd tell you which backend server responded to a specific request? Not directly — it identifies that load balancing is occurring and gives supporting evidence, but pinpointing exact backend routing usually requires additional manual testing.

Is DNS round robin the same as a “real” load balancer? Not exactly — DNS round robin is a simple traffic distribution method at the DNS resolution level, while dedicated load balancers (hardware or software) operate at Layer 4/7 with health checks, session persistence, and more intelligent routing.

Summary

lbd fills a small but genuinely useful gap in the recon phase of a security assessment: figuring out whether a target’s traffic is being spread across multiple backend systems. That single piece of information changes how you interpret everything that follows, from inconsistent scan results to how a discovered vulnerability might actually be scoped across an infrastructure. It’s quick, simple, and worth running before anything else.

References

• GitHub repository: https://github.com/stealth/lbd
• Kali Linux tool page: https://www.kali.org/tools/lbd/