DEV Community

BlackNeuron
BlackNeuron

Posted on

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

#rust #security #devops #dns

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.

  1. How many authoritative nameservers you run (one is a SPOF).
  2. Whether those nameservers actually sit in different networks, not just different hostnames on the same provider.
  3. Whether DNSSEC is on.
  4. 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()
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

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.

Top comments (0)