DEV Community: BlackNeuron

Your CDN says it is protecting you. I checked, and 0% of the traffic was cached.

BlackNeuron — Tue, 14 Jul 2026 15:27:52 +0000

You put your site behind a CDN, watched the dashboard turn green, and moved on. The edge will soak up the floods now. Right?

Mostly. Its network still eats volumetric floods and its edge can filter and rate-limit. But one layer quietly depends on you, and the availability dashboard stays green while it fails: your responses are not actually being cached.

The problem in one sentence

Cache absorption is the layer that depends on your own config: a CDN serves what it can from its own cache, and those requests never reach your origin. Every response it cannot cache is one your origin has to generate itself. So under a flood of uncacheable requests, the edge forwards them through, and unless another edge control catches them, your origin answers every one.

The math is blunt:

At a 0% hit-ratio your origin sees the entire flood. At 95% it sees a twentieth of it. A CDN does not move you along that curve by being installed. It moves you by actually caching, and that is a property of your response headers, not the vendor's marketing.

Why the edge quietly caches less than you think

None of these require a misconfigured CDN. They are ordinary application defaults:

Cache-Control: private or no-store. Frameworks slap these on by default for anything that looks dynamic. Perfectly correct for a logged-in page. Also means the edge forwards every hit to origin.
A Set-Cookie on the response. By default, a session cookie on your HTML (or worse, on your static assets) tells shared caches not to store it. One analytics or CSRF cookie can make your whole site uncacheable.
max-age=0 / no-cache. The object revalidates with origin on every request, so the origin is in the loop every time anyway.
cf-cache-status: DYNAMIC. Cloudflare caches common static extensions by default, but HTML and anything off that list comes back DYNAMIC and is not cached until you add a Cache Rule. Most sites never add it.

Any one of these, sitting on the paths a flood targets, and your expensive edge is a very fast reverse proxy to the thing you were trying to protect.

So I wrote a small tool to measure it

I wanted a one-command answer to "what fraction of my own traffic does the edge actually absorb, right now?" So I built edge-cache-check in Rust. It is deliberately boring on the network: it fetches your own pages and reads the cache headers. No flooding, no attacks, single binary, no config.

The flow:

Fetch the landing page and fingerprint the edge from its headers (cf-cache-status, x-cache, x-vercel-cache, via, server).
Read the HTML and build a representative sample of your own URLs: the static assets it references plus a few internal pages.
Request each URL twice. The first request warms the edge; the second is the one scored.
Classify each warmed response as EDGE (served from cache), CACHE (cacheable but missed), or ORIGIN (cannot be cached), with the reason.
Report an absorption score for the static assets, whether the landing page is cached, and the top reasons anything falls through.

The interesting part: deciding "did the origin see this?"

Every CDN spells "cache hit" differently, so the load-bearing logic is normalising them into one honest answer. A hit is a hit whether it is Cloudflare's cf-cache-status: HIT, CloudFront's x-cache: Hit from cloudfront, Vercel's x-vercel-cache: HIT, or simply an Age header greater than zero (if the object has been sitting in cache for 12 seconds, it came from cache):

let hit = h.cf_cache.as_deref()
        .map(|s| matches!(s.to_uppercase().as_str(),
             "HIT" | "UPDATING" | "STALE"))
        .unwrap_or(false)
    || h.x_cache.as_deref().map(|s| s.to_lowercase().contains("hit")).unwrap_or(false)
    || h.x_vercel.as_deref().map(|s| { let u = s.to_uppercase(); u == "HIT" || u == "STALE" }).unwrap_or(false)
    || h.age.map(|a| a > 0).unwrap_or(false);

if hit {
    return (Class::Absorbed, "served from edge cache".into());
}

If it was not a hit, the useful output is not "MISS", it is why. That is what turns the result into a fix instead of a shrug:

if !has_vendor {
    return (Class::Origin, "no CDN edge detected - request reaches origin".into());
}
if cc.contains("no-store")  { return (Class::Origin, "Cache-Control: no-store".into()); }
if cc.contains("private")   { return (Class::Origin, "Cache-Control: private".into()); }
if cc.contains("no-cache")  { return (Class::Origin, "Cache-Control: no-cache (revalidate every time)".into()); }
if h.set_cookie && !cc.contains("public") {
    return (Class::Origin, "Set-Cookie on the response defeats shared caching".into());
}

The two-fetch design matters here too. A single request to a cold object on a large multi-PoP edge is a MISS even when the object is perfectly cacheable, so a naive checker would cry wolf. Warming first, then scoring the second response, separates "cannot be cached" from "just was not cached yet." The tool reports those as two different buckets on purpose.

Running it

cargo run --release -- example.com
# or build once, then:
./target/release/edge-cache-check example.com

A healthy run is calm: your assets come back [EDGE ], the score is high, and the verdict is STRONG. An unhealthy one is specific about the damage:

    static assets:   2/14 served from edge (14%), 21% cacheable in total
    landing page:    NOT cached - every hit reaches origin
    why not cached:
      11x  Set-Cookie on the response defeats shared caching
       3x  Cache-Control: private

[!] WEAK: an edge is present but is absorbing very little.

That is a two-line fix (drop the cookie from static asset responses, add a cache rule), and a real change in how much of a flood your origin ever sees.

The remediation

Make static assets genuinely cacheable: a long max-age, immutable, and no Set-Cookie on asset responses.
Add an explicit cache/edge rule on the paths that can tolerate it, rather than assuming the CDN's default covers everything (Cloudflare caches static extensions by default, but not HTML).
For the dynamic paths that legitimately cannot be cached, stop relying on the origin as the only line of defence. That is what edge rate-limiting and a WAF are for.

Absorption is not the whole of DDoS resilience, but it is the pillar people assume they have for free the moment they install a CDN, and most do not.

One rule

Run it only against domains and infrastructure you own or are explicitly authorized to test. It only reads your own public responses, but point it at your own stuff.

Code

Tool (MIT, Rust): https://github.com/blackneuron-ai/edge-cache-check (a star helps if it is useful to you ⭐)
More on edge absorption and DDoS resilience: https://blackneuron.ai/blog

If you run it on your own site and the number surprises you, the reason column is usually the interesting part. I would like to hear what caught you out.

*Written while building defensive tooling at BlackNeuron

You hardened your origin and your CDN. Your DNS is still one provider away from going dark.

BlackNeuron — Sun, 05 Jul 2026 17:12:13 +0000

You put the site behind a CDN, locked the origin firewall to the edge ranges, tuned rate limits, and slept better. Then someone floods your DNS instead, and none of that matters, because nobody can resolve your name to reach any of it.

DNS is the piece almost nobody load-checks for resilience. And the most common failure is boring: every authoritative nameserver sitting with one provider.

Why one provider is the whole risk

If all your NS records point at a single DNS host, that host is a single point of failure for your entire domain. A DDoS against it, or just a bad day in their control plane, and every name under you goes dark at once. The blast radius is total, and it happens upstream of everything you spent time hardening.

The fix is old and well known: run authoritative DNS across two providers on different networks. The problem is that almost nobody checks whether they actually did, because it is invisible until the day it isn't.

So I wrote a small tool to check my own

dns-resilience-check points at a domain you own and answers one question: is your DNS a single point of failure? It looks at what a resilience review would look at.

How many authoritative nameservers you run (one is a SPOF).
Whether those nameservers actually sit in different networks, not just different hostnames on the same provider.
Whether DNSSEC is on.
Whether the NS TTLs are sane.

It reads only public DNS data over DNS-over-HTTPS. No zone transfers, no traffic at anyone, nothing to install beyond Rust.

The part I liked building

"Different provider" is the finding that matters, and the honest way to check it is by network, not by name. ns1 and ns2 on the same host tell you nothing. So the tool resolves each nameserver to its IPs and maps each IP to the network (ASN) that owns it. If every nameserver lands in one ASN, that is your single point of failure, no matter how many NS records you have.

The neat trick is that you can get IP-to-ASN over plain DNS, via Team Cymru's public zone. Reverse the octets, ask for a TXT record, and you get the ASN back:

// 1.2.3.4 -> "4.3.2.1.origin.asn.cymru.com" TXT -> "AS64500 | 1.2.0.0/16 | ..."
fn asn_of(ip: &str) -> Vec<String> {
    let o: Vec<&str> = ip.split('.').collect();
    if o.len() != 4 { return Vec::new(); }
    let name = format!("{}.{}.{}.{}.origin.asn.cymru.com", o[3], o[2], o[1], o[0]);
    // doh() is one DNS-over-HTTPS query; parse the TXT and take the ASN field
    let txt = doh(&name, "TXT")?;                 // "AS64500 | prefix | CC | ..."
    txt.split('|').next().unwrap().split_whitespace().map(|s| format!("AS{s}")).collect()
}

Collect the ASNs across all the nameservers, and if the set has one element, the tool flags it and tells you to add a second provider on a different network.

Running it

cargo run --release -- example.com

CONTAINED means nothing obvious is wrong. Each [FAIL] is a gap with the fix printed next to it. On a domain sitting entirely with one DNS host it will say so plainly, which is usually the moment people go add a secondary.

One rule

Run it against domains you own or are allowed to test. It only reads public data, but point it at your own stuff.

Code + the longer write-up

Tool (MIT, Rust): https://github.com/BlackNeuron-ai/dns-resilience-check (a star helps if it is useful to you)
The deeper piece on DNS under DDoS: https://blackneuron.ai/blog/dns-ddos-testing

If you run it and find a surprise (a "second" provider that turns out to be the same ASN is a common one), I would like to hear it.

Written while building defensive tooling at BlackNeuron.

I put Cloudflare in front of my site, then found my origin one DNS record away from undoing it

BlackNeuron — Sun, 28 Jun 2026 16:50:50 +0000

You move your site behind Cloudflare (or CloudFront, or any CDN/WAF), watch the dashboard light up green, and feel safe. The edge will soak up the floods now. Right?

Mostly. But there is a quiet failure mode that undoes the whole thing in one step, and almost nobody tests for it: origin IP exposure.

The problem in one sentence

A CDN only filters the traffic that actually passes through it. If your origin server still answers on its own public IP, an attacker who learns that IP just connects straight to it, and every layer of DDoS and WAF protection you are paying for is bypassed.

The edge is protecting a secret (your origin IP), not a wall. And secrets leak.

How the secret leaks

You do not need to breach anything to find an origin. The data is usually already public:

Certificate Transparency logs. Every TLS certificate ever issued is logged publicly. Search crt.sh for a domain and you get a tidy list of its subdomains, including the dev, staging, and mail hosts nobody remembered to put behind the CDN.
Boring subdomains. mail., smtp., vpn., cpanel. and friends are hard to proxy through a web CDN, so they frequently resolve straight to the origin, on the same IP as the "protected" site.
DNS history. The A record from before you switched to the CDN is often still sitting in historical DNS datasets.

Find one of those, confirm the IP serves the real site, and the CDN is now optional.

So I built a small tool to check my own

I wanted a one-command answer to "is my origin reachable past my CDN, right now?" So I wrote origin-exposure-check in Rust. It does exactly the discovery an attacker would, against a domain you own, so you find the leak first.

It is deliberately boring on the network: a few DNS lookups, one crt.sh query, and a handful of normal GET requests. No flooding, no attacks. Single binary, no config.

Here is the whole flow:

Pull the published edge ranges (Cloudflare, CloudFront) so we can exclude the legitimate edge IPs.
Fetch a baseline of the site through the CDN, and fingerprint the response.
Enumerate candidate hosts from common subdomains + Certificate Transparency (crt.sh).
For every candidate IP that is not an edge IP and not the front door, make a direct request to that IP while presenting the real hostname, deliberately bypassing DNS and the CDN.
If the origin answers with your site, that is EXPOSED. If it refuses, CONTAINED.

The interesting part is step 4. To test reachability you force a TLS connection to a specific IP but set the SNI/Host to the real domain, so the origin thinks it is a normal request:

// Force TLS to a specific IP while presenting the real hostname (SNI),
// i.e. deliberately bypass DNS/CDN. Cert validity is ignored on purpose:
// we are probing reachability, not trust.
let connector = native_tls::TlsConnector::builder()
    .danger_accept_invalid_certs(true)
    .danger_accept_invalid_hostnames(true)
    .build()?;

let stream = TcpStream::connect((ip, 443))?;
let mut tls = connector.connect(domain, stream)?; // domain = SNI, ip = where we actually connect
tls.write_all(
    format!("GET / HTTP/1.1\r\nHost: {domain}\r\nConnection: close\r\n\r\n").as_bytes(),
)?;

If the bytes that come back match the baseline fingerprint, that IP is serving your real site directly. Caught.

It also handles the obvious false positive: if every candidate IP returns byte-identical content, you are on an anycast host platform (Vercel, Netlify, Cloudflare Pages) where the host is the edge, there is no separate origin to expose, and it says so instead of crying wolf.

Running it

cargo run --release -- example.com
# or build once, then:
./target/release/origin-exposure-check example.com

A CONTAINED run looks calm. An EXPOSED run hands you the IPs and the fix:

Fix: restrict the origin firewall to the CDN's published ranges (or use a private tunnel so there is no public origin IP), then re-run this check.

That is the actual remediation: your origin should only accept connections from your CDN's IP ranges, or have no public inbound listener at all (a tunnel). Allow the world, and the CDN is decoration.

One important rule

Run it only against domains and infrastructure you own or are explicitly authorized to test. It is a self-audit, and it only consumes already-public data, but point it at your own stuff.

Code + the deeper write-up

Tool (MIT, Rust): https://github.com/blackneuron-security/origin-exposure-check (a star is appreciated if it is useful to you ⭐)
The longer write-up on the mechanism and the fixes: https://blackneuron.ai/blog/origin-ip-exposure-cdn-bypass

If you run it on your own site and get a surprising EXPOSED, I would genuinely like to hear how the IP leaked. That is usually the interesting part.

Written while building defensive tooling at BlackNeuron.