An attacker floods your origin's own address directly, ignoring your twelve-site footprint — how did they find it?

## The footprint defends an address, not a service Announcing one address from a dozen sites protects traffic sent to *that address*. It does nothing for any other way of reaching the same servers. In almost every real estate there is another way, because the origin existed first: it was the service, it had its own address, and when the footprint went live in front of it nobody changed that address or stopped it answering. It is now a single-homed box with one uplink standing behind twelve sites of absorption capacity that it cannot use. ## How the address gets found None of this requires access to your systems. **Historical and passive DNS.** Resolver operators and research projects record what names resolved to over time. Your name's old `A` record — the origin — is in those datasets permanently. Migrating the record forward does not remove the history. **Certificate Transparency.** Every publicly trusted certificate is submitted to append-only public logs, and each entry carries the certificate's subject and subject alternative names. Note precisely what this discloses: **names, not addresses**. If a certificate was ever issued covering `origin.example.com`, `legacy.example.com` or a management hostname, that name is now public, and an attacker resolves it in one step. This is why CT is the first place a competent adversary looks and why it surprises defenders — nobody ever published that hostname anywhere. **Records that never moved.** Mail exchangers, an FTP or SFTP name, a monitoring endpoint, a staging host on the same network. Any of them may point at the origin's address or one beside it. **Leaks from the application itself.** An error page or header echoing an internal hostname or address, an email whose `Received` chain shows the sending host, a redirect that reveals the direct name. **Internet-wide scanning.** Scanning the address space for hosts presenting a certificate whose name matches your domain finds an origin directly, without any history at all. ## What your footprint saw: nothing This is the part interviews probe, and it is the specific cost of spreading thin. The sites are instrumented, baselined and alerted on the announced prefix. Traffic aimed at the origin's address is routed to the origin, not to any site, so no site's flow exporter generates a record, no site's counter moves, and no threshold is evaluated. The dashboards say a quiet day, honestly and correctly. The estate's monitoring is not degraded during this attack — it is *absent*, and the absence looks identical to calm. What you have instead is whatever the origin and its provider recorded: interface counters on one uplink, whatever flow the origin's own edge exported before it congested, and the upstream provider's view. That last one matters, because once the uplink saturates your own records stop being a measure of what arrived — they measure what fitted through. ## Detecting it at all Since the footprint cannot see it, the detection has to be built elsewhere: - **Watch the origin's own link independently**, with its own thresholds, and treat any meaningful volume there as an anomaly — because in a healthy design the origin should be receiving traffic only from your sites, so anything else is by definition unexpected. - **Compare requests seen at the sites against requests served by the origin.** A gap is traffic that skipped the footprint. - **Monitor Certificate Transparency for your own domains.** It is a free feed telling you which of your hostnames have been published, and it is one of the few defensive uses of an attacker's own reconnaissance source. - **Audit passive DNS for your names** to know what history already exposes, so you at least know which addresses to consider burned. ## Fixing it, and the part you cannot fix The direction is that the origin stops being reachable as itself: it should not answer for your service on an address any third party can reach, and traffic that did not come from your own sites should not be accepted. That is the durable control, and the detail of enforcing it belongs to whoever operates the origin's network. The part you cannot fix is the disclosure. A CT entry cannot be withdrawn, and passive DNS history cannot be deleted. If an address has been published, it stays published, so any real remediation includes **re-addressing the origin** — otherwise you have merely asked the internet not to use a number it already knows. Re-addressing costs a change window, coordination with anyone who allowlisted the old address, and a period where both are live. ## The answer to give Say the three things in order: the origin is a second front door because it predates the footprint; its address is public through history and Certificate Transparency rather than through any breach; and the footprint's monitoring cannot see the attack at all, so the detection has to be built at the origin and by reconciling what the sites served against what the origin served.