Module 7 · BGP, DNS, CAs — Internet-Scale Trust Failures

Last updated: April 29, 2026

The internet works because BGP (routing), DNS (naming), and CAs (identity via TLS certs) all extend trust from single actors to global scale. Each layer was designed with minimal cryptographic verification. Each layer has been abused at scale. This module covers the three internet-wide trust failures every defender and pentester should understand — because they’re not going away.

Why this happens

BGP (1989), DNS (1983), and the CA system (1994) were designed to work, not to be secure. The founding assumption was “participants behave honestly.” When participants have turned out to not be fully honest (or compromised, or coerced), the layers have been patched with various cryptographic mitigations (DNSSEC, RPKI, Certificate Transparency) — but deployment is uneven, enforcement is weak, and the fundamental trust model remains “we trust the registered authority.”

The result: a motivated actor (often nation-state, sometimes criminal) can hijack traffic at scale by subverting one of these layers.

BGP hijacking

Every network has an Autonomous System Number (ASN) and advertises which IP prefixes it owns. Other networks accept the advertisements and route accordingly. No built-in verification that the advertising network actually owns the prefix.

# Real BGP hijack example (2018 - MyEtherWallet)
# Attacker advertised routes for Amazon's DNS Route 53 prefixes
# Users trying to reach MyEtherWallet had DNS queries routed to attacker
# Attacker returned DNS pointing to phishing site
# Site used valid TLS cert (obtained via DV challenge from hijacked IP)
# Total cryptocurrency stolen: ~$160,000

# Attacker's ASN temporarily routed around a third of the internet's traffic
# Route was withdrawn after ~2 hours

Technical mechanism

AS path: sequence of ASNs a route traversed. BGP picks shortest AS path by default. Attacker advertises a more-specific prefix (smaller block = more specific = wins). Traffic flows through attacker’s AS. Attacker can drop, inspect, or forward it.

Real incidents

• Pakistan Telecom (2008): Accidentally advertised YouTube prefixes. YouTube globally unreachable for ~2 hours. Pure misconfiguration but showed the protocol’s fragility.
• China Telecom (2010): Leaked routes for ~15% of internet prefixes. Traffic for significant chunks of US+EU government, Dell, IBM, Microsoft, and others transited China for ~18 minutes.
• MyEtherWallet (April 2018): Hijack + DNS manipulation + TLS cert obtained from hijacked IP = full session hijack for cryptocurrency theft.
• KlaySwap (2022): BGP + DNS hijack to steal ~$1.9M from Korean DeFi platform users.
• Various 2023-2025 route leaks: ongoing weekly events, most documented at RIPEstat / Cloudflare Radar.

RPKI defense

Resource Public Key Infrastructure: cryptographically-signed record that “AS X is authorized to originate prefix Y.” Routers validate advertisements against RPKI; reject invalid ones. Deployment ~50% globally as of 2026.

# Operator side: create Route Origin Authorization (ROA) in RIR portal
# RIPE, ARIN, APNIC, etc.
# ROA: Prefix 203.0.113.0/24, Max length /24, Origin AS 64500

# Router side: validate via RPKI cache
router bgp 64500
  rpki server 192.0.2.10 port 3323
  bgp bestpath prefix-validate allow-invalid 0
  ! Rejects RPKI-invalid routes

# Check your RPKI status:
# - bgp.tools
# - ripe.net/analyse/YANG

DNS cache poisoning

Dan Kaminsky (2008) demonstrated that DNS resolvers were trivially poisonable via birthday-attack math on the 16-bit transaction ID. Resolvers were patched to include port randomization. In 2020, SAD DNS (Side-channel AttackeD DNS) showed port randomization could be leaked via ICMP rate-limit side channels.

DNS rebinding is a subtler attack. Malicious website’s DNS responds to the browser first with an attacker-controlled IP, then with an internal RFC1918 IP. Browser’s “same origin” tracks the DNS name, not the IP — so attacker’s JavaScript can now interact with internal services.

# DNS rebinding basic chain:
# 1. User visits attacker.com
# 2. DNS returns attacker's IP; page loads, JS runs
# 3. JS makes XHR to attacker.com (same-origin, allowed)
# 4. Meanwhile, attacker.com DNS TTL expires
# 5. Next query for attacker.com returns 192.168.1.1 (victim's router)
# 6. JS makes next XHR to attacker.com — but DNS resolves to 192.168.1.1
# 7. Browser treats it as same-origin because DNS name unchanged
# 8. JS interacts with 192.168.1.1's admin interface as if authenticated

# Tool: https://github.com/brannondorsey/whonow
# Attack: internal routers, printers, IoT devices, Kubernetes APIs accessible via rebinding

DNSSEC

Cryptographic signing of DNS records. Detects tampering. Deployment is partial (largely TLD and ccTLD operators; most enterprise domains don’t sign). Doesn’t solve rebinding. Does solve cache poisoning.

TLS certificate abuse

Anyone can get a TLS cert for any domain they control (even temporarily). DV (Domain Validation) certs from Let’s Encrypt, ZeroSSL, etc. check only that the requester controls the domain’s DNS or HTTP. If an attacker temporarily hijacks DNS or BGP, they can prove “control” and issue a valid cert.

# Hijacker workflow for TLS cert via BGP+DNS hijack:
# 1. Hijack BGP for victim's IP range (or DNS for victim's domain)
# 2. ACME HTTP-01 challenge: Let's Encrypt GETs http://target.com/.well-known/...
#    Since you own the IP temporarily, you serve the challenge value
# 3. Cert issued to you, valid for 90 days
# 4. Unhijack. Now you have a valid cert for target.com you can use later

# Certificate Transparency (CT) logs reveal the issuance to monitoring
# If victim subscribes to CT alerts, they see: "someone just issued cert for our domain"
# But action requires someone to be watching

Certificate Transparency

Every publicly-trusted cert must be logged to CT logs (Chrome requirement since April 2018). Anyone can monitor logs for their domain. Crt.sh provides search interface. Mature defenders subscribe to CT alerts on their own domains — catch rogue issuance within hours.

CAA records

DNS records that limit which CAs can issue certs for a domain. ringsafe.in. CAA 0 issue "letsencrypt.org" means only Let’s Encrypt may issue. CAs check CAA before issuing; reject if not authorized. Inexpensive defense; deployment uneven.

The SAD DNS hole (2020-2023)

University researchers showed that Linux kernel’s ICMP rate-limiting creates a side-channel: an attacker can determine which port a DNS resolver used for a query by sending probe packets and observing rate-limit responses. Given the port, standard cache poisoning works again. Multiple kernel patches landed; implementation varies.

What we find

• Organizations without RPKI ROAs for their own prefixes (hijacking easier)
• Recursive DNS servers without DNSSEC validation
• No CT log monitoring for the organization’s domains
• No CAA records in DNS
• Internal services reachable only via browser-rebinding paths (unauthenticated internal admin panels)
• VPN / API endpoints with DV certs (easier to hijack via DNS than OV/EV)

Defense summary

1. Publish ROAs for all prefixes you own (RIPE/ARIN/APNIC portals)
2. Drop RPKI-invalid routes on your BGP (talk to your transit provider)
3. DNSSEC-validate on recursive resolvers
4. CAA records scoping your domain to specific CAs
5. CT monitoring for your domains (crt.sh subscriptions, commercial services)
6. Internal services authenticated (rebinding defenses: Host header validation, private IPs blocked in browser via DNS allow-list at corporate resolver)
7. TLS pinning for mobile apps connecting to your APIs (defeats DV-cert-via-hijack)
8. Modern clients check CT / Expect-CT

Mindset takeaway

Trust on the internet is distributed across multiple layers, each of which can be subverted individually. A motivated adversary with resources can abuse BGP for hours, DNS for hours, and CAs for months if unnoticed. The mitigations (RPKI, DNSSEC, CAA, CT monitoring) are individually simple and collectively effective but require actual deployment.

For pentesters: external recon should include “could BGP or DNS hijack work here?” — mostly a Yes/No based on your CAA + CT monitoring + VPN cert verification answers. For defenders: the eight-item checklist above is most of the cost; the payoff is substantial if your organization is a target.