What this simulation covers
Explore how network and service outages could affect public DNS and incoming email for a selected set of Swedish public bodies and other organizations with a public role. The dataset includes municipalities, regions, agencies, universities, political parties and public service broadcasters. Only the domains in this dataset are included.
What you see first is real
When the page opens, every marking on the map comes from the daily scan of each organization's DNS and inbound email. Yellow and red are real findings: something did not work in the scan. Yellow means one server or path failed while another still worked. Red means no path worked. Grey means the scan could not verify the result. Shared dependencies are real weak points, not outages.
The outage buttons are simulations
When you switch off a network or a service, it only happens in the model. The map then shows what would happen to DNS and inbound email if it failed. Nothing is switched off for real. That part is on some rogue AI agent's roadmap, not ours. The strip above the map always shows whether you are looking at real data or a simulation.
What the sandbox looks for
Several servers can depend on the same network. Those shared points of failure are what the sandbox looks for. The model follows how networks connect at the AS level. Where the fiber runs is not included.
Data in this build
Technical assumptions and sources
Network outages and service failures are separate scenarios. In their service scenarios, Microsoft 365 and Google Workspace are assumed to have a complete email outage. Domains where the data points to the selected platform then lose email, even behind a working gateway. When the backend has not been identified, the model cannot tell whether it depends on the switched-off service. A path that remains in the model is no guarantee of actual availability.
Networks and services share one dependency model. The default dependencies tie Microsoft 365 to AS8075 and Google Workspace to AS15169. A name server's authoritative answer is verified per host and can come from another IP address than the first one exported. Not every alternative IP address, nor the authority of the exported address itself, is verified in this data.
Networks can also fail through cascading effects: when an operator is switched off, the networks that only reach the internet through it fail too, and networks with observed peering may keep partial reachability. Where they are actually reached from is not measured. Dependencies are calculated from transit visible in BGP, so backup links that are only announced during a failure do not show. The Cascading effects setting under Assumptions turns them off.
AS relationships: The CAIDA AS Relationships Dataset, 2026-10 (CAIDA Acceptable Use Agreement). BGP neighbors: RIPEstat, RIPE NCC (RIS), 2026-10-14. IX presence: PeeringDB, 2026-10-12.
Limitations
The model covers observed IPv4 paths to public DNS and inbound email. IPv6, physical location, capacity, client access and internal systems are not included. An AS outage assumes that the whole network becomes unreachable; anycast and large networks can have significant internal redundancy. Unknown paths and possible cascading effects are reported separately.
The failure analysis tests networks within the data. One failure at a time and pairs of network failures describe tolerance to those scenarios, not the likelihood of an outage. DNS caches and email queues can soften short disruptions; their contents, lifetime and the backup capacity are not measured. The origin of the arcs is schematic: an AS has no location on the map.
Map data © OpenStreetMap contributors, ODbL.