The internet, explained
Plain-language explanations of the concepts behind every figure on this site — each one drawn rather than described, and each one followed by what we actually measure for it across 363.6M domains.
ASN
An Autonomous System Number identifies a network on the internet — one of the basic units internet routing works with.
The internet is a network of networks.
The internet is made up of independent networks called Autonomous Systems (ASes), each identified by an Autonomous System Number (ASN). Counting ASNs is counting the public networks it is made of. Cloudflare operates AS13335. Google operates AS15169.
Each AS announces the ranges of IP addresses it can reach — its address space. Other networks pass those announcements on, so traffic moves from network to network until it reaches its destination.
An AS decides what it announces and to whom, so any count of networks is a count of what was visible from where it was observed. A company can run more than one — Amazon announces through AS16509 and AS14618 — so an ASN identifies a network, not a company.
The origin AS tells us which network carries a domain's traffic, which is what makes concentration measurable. Not every network carries domains: about a third of those we see announcing address space host none we can attribute, so the figures below are ranked over the smaller population that does.
- 6
- Networks carrying half of all attributable domains
- 232
- Networks carrying ninety per cent of attributable domains
- 79,192
- Networks observed announcing address space
of 52,663 networks observed carrying domains · as of 2026-09-24
of 52,663 networks observed carrying domains
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
IP prefix
An IP prefix is a block of consecutive IP addresses — the unit networks announce when exchanging routes.
Routers work with blocks of addresses, not individual IPs.
Prefixes are written in CIDR notation, such as 203.0.113.0/24. For IPv4, a /24 contains 256 addresses. A /16 contains 65,536. A /25 contains 128. The larger the number after the slash, the smaller and more specific the block.
Prefixes can sit inside one another. A network holding a /16 can announce the whole block, or divide it into smaller prefixes and announce those separately.
Where two announced routes both cover a destination, routers use the more-specific prefix. This is known as longest-prefix matching. It is fundamental to internet routing, and it also explains how a more-specific route can attract traffic away from a legitimate, less-specific one.
Routing activity is observed at the prefix level. Changes in who announces a prefix, how specifically it is announced, and whether that announcement is authorized can reveal routing instability, configuration errors and potential hijacking. The prefix is therefore the unit behind our routing measurements.
- 1.2M
- Distinct IPv4 prefixes observed
· as of 2026-09-24
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
MOAS
A Multi-Origin AS observation occurs when the same IP prefix is announced by more than one Autonomous System.
Two origins do not automatically mean a hijack.
An IP prefix normally has one origin AS. A Multi-Origin AS (MOAS) observation occurs when two or more networks announce the same prefix.
That can look suspicious, but it is often legitimate. An organization may deliberately announce the same address space through multiple networks for resilience, for traffic engineering, or during an infrastructure migration.
The important signal is not that multiple origins exist, but how the relationship behaves over time. A pattern that has held for more than 30 days, the threshold our measurement uses, is more likely to represent an intentional operational arrangement. A new origin that appears unexpectedly and then disappears has a different risk profile.
Treating every MOAS observation as suspicious substantially overstates the number of potential hijacks. Separating persistent multi-origin relationships from sudden changes removes much of that background noise, and leaves the smaller set of announcements that warrant investigation.
- 97.41%
- MOAS prefixes that are stable multi-homing, not hijacks
of 194,872 MOAS prefixes observed · as of 2026-09-24
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
BGP hijacking
Announcing address space you do not hold, so that traffic meant for someone else arrives at you instead.
Routing tells you reachability, not ownership.
Routing runs on assertion. A network tells its neighbors which prefixes it can reach, they pass that on, and nothing in the protocol asks for proof of entitlement.
The usual method is to announce a more-specific prefix. If the rightful holder announces a /24 and an attacker announces a /25 inside it, the /25 is preferred — not because it is trusted, but because it is more specific.
Traffic then arrives at the wrong network, which can read it, discard it, or forward it on so that the diversion goes unnoticed. Some events last minutes and resemble a configuration error. Others are deliberate and target a single prefix.
A hijack shows up in routing data before it shows up anywhere else, but only against a baseline of what normally announces a prefix. We measure the multi-origin events that are not stable multi-homing — the set small enough to investigate.
- 4,592
- Prefixes flagged as hijack candidates
of 1.2M IPv4 prefix announcements in intel.prefix_intel · as of 2026-09-24
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
RPKI
Resource Public Key Infrastructure: signed records stating which Autonomous System is authorized to announce a given IP prefix.
Invalid and not-found mean very different things.
The holder of an IP prefix publishes a Route Origin Authorization (ROA): a signed record naming the AS permitted to announce it, and the longest prefix that AS may announce.
A network operator can then validate an announcement against the published ROAs, and gets one of the three results above. Validation is a choice each network makes; nothing in BGP performs it automatically.
Not-found is not a failed check. It means no ROA was published, which is different from a claim that turned out to be false.
Invalid is the actionable state: proof was published and the announcement contradicts it, which is either a misconfiguration or an attempt to take traffic. Not-found is simply unprotected. We report the three separately, because a figure combining invalid and not-found answers a different question.
- 41.19%
- Prefix announcements with a valid RPKI ROA
- 58.33%
- Prefix announcements with no covering ROA
- 0.48%
- Prefix announcements that are RPKI-invalid
of 1.2M IPv4 prefix announcements in intel.prefix_intel · as of 2026-09-24
of 1.2M IPv4 prefix announcements in intel.prefix_intel
of 1.2M IPv4 prefix announcements in intel.prefix_intel
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
SPF, DMARC and BIMI
DNS records that let a receiving server check whether a message claiming to come from your domain really did.
Published is not the same as enforced.
Anyone can put your domain in the From line of an email. SPF and DKIM give a receiver two ways to test that claim — one checks the sending server, the other checks a signature — and both only produce a result.
DMARC is where the domain owner says what to do with that result. Its policy tag is the whole of the instruction, and it is the only part of the chain that changes what happens to a message.
BIMI sits on top and depends on everything beneath it: a domain cannot reach it without enforcing DMARC first.
Adoption figures count records that exist. A domain at p=none has published DMARC and told the world to ignore every failure, which those figures score as a success. We report presence and policy separately. DKIM is absent deliberately: verifying it needs the selector name, which DNS does not reveal.
- 24.26%
- Domains publishing a DMARC record
- 44.93%
- Domains publishing an SPF record
- 50.31%
- DMARC records set to p=none
- 49.63%
- DMARC records at enforcement (p=quarantine or p=reject)
- 0.06%
- DMARC records with an invalid policy value
- 0.06%
- Domains publishing BIMI
of 363.6M resolving domains · as of 2026-09-24
of 363.6M resolving domains
of 88.2M domains publishing DMARC
of 88.2M domains publishing DMARC
of 88.2M domains publishing DMARC
of 363.6M resolving domains
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
MTA-STS
A published policy telling other mail servers to require encryption when delivering to you, and to fail rather than fall back.
Opportunistic encryption can be downgraded.
Mail between servers is encrypted opportunistically. The receiving server advertises STARTTLS, the sender takes it up, and the message travels encrypted. The advertisement itself is sent in the clear.
Anyone in the path can remove it. The sending server sees no offer of encryption and delivers in plaintext rather than fail. Neither side is alerted.
MTA-STS publishes the requirement in advance. It has two halves and both are required: a DNS TXT record at _mta-sts naming the current policy version, and a policy file served over HTTPS listing your mail servers and a mode. Only enforce refuses delivery; testing asks senders to report failures while still delivering.
A downgraded delivery looks exactly like a normal one, so absence here is silently insecure rather than visibly missing. Publishing the record is not the protection: the figures below separate publishing, holding a policy, and enforcing. Where no mode is recorded, either the file is not served or we did not retrieve it — we cannot tell which.
- 0.09%
- Domains publishing MTA-STS
- 72.76%
- MTA-STS domains with a policy mode on record
- 47.94%
- MTA-STS domains whose policy is set to enforce
of 363.6M resolving domains · as of 2026-09-24
of 319,063 domains publishing MTA-STS
of 319,063 domains publishing MTA-STS
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
CAA
A DNS record naming which certificate authorities are allowed to issue certificates for your domain.
By default, any trusted CA can issue for any domain.
Trust is not partitioned by name. A mistake or a compromise at any one certificate authority produces a certificate for your domain that every browser accepts.
A CAA record is a standing instruction in DNS naming the authorities permitted to issue for you. Since 2017 a CA has been required to check it before issuing, and to refuse where it is not named.
It is checked when a certificate is requested, not when a visitor connects. It does not affect a certificate that already exists; it narrows who could obtain one.
A CA that ignores its own rules is not stopped by a DNS record, so what CAA removes is accidental issuance rather than a determined attacker. That is a narrow benefit for the cost of one DNS record, which makes take-up the question worth measuring.
- 1.54%
- Domains publishing a CAA record
of 363.6M resolving domains · as of 2026-09-24
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
DNSSEC
Signatures that let a resolver verify a DNS answer came from the real zone and was not altered on the way.
Signed is not the same as correctly validating.
DNS answers arrive with nothing to prove where they came from. Anything able to reply before the real server, or to sit in the path, can supply a different address.
DNSSEC signs the records. A signature is only useful if the key behind it can be trusted, so each zone publishes a fingerprint of its child's key: the root vouches for .com, .com vouches for example.com. A validating resolver checks that chain.
Because it is a chain, it fails as a chain. If a signature expires or a key is rotated without updating the parent, the domain does not revert to unsigned — a validating resolver refuses the answer and returns nothing.
The failure mode explains the adoption rate: DNSSEC turns a silent risk into a visible outage, and the outage lands on the domain owner rather than the attacker. Where registries have made it the default, national adoption runs an order of magnitude above .com. Our figure records that a delegation is signed, not that it currently validates.
- 8.01%
- Domains with a signed DNSSEC delegation
of 363.6M resolving domains · as of 2026-09-24
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
Parked domains
Registered, resolving, and run by nobody — a domain delegated to a platform that shows an advert instead of a site.
A DNS record does not necessarily represent an operator decision.
Someone registers a name and builds nothing on it. Rather than leave it dark, they point its nameservers at a parking platform, which serves a placeholder page carrying adverts and often an offer to sell.
The domain is fully alive in DNS. It resolves, it answers queries, and it appears in any count of registered or resolving domains. What it does not have is anyone operating it.
Parked domains often publish more email authentication than real ones. The platform provisions SPF and DMARC from a template across every domain it holds, so the records exist in enormous numbers and say nothing about anyone's security posture.
An adoption figure that does not separate parked domains counts provisioning templates alongside decisions. Millions of identical records, written once by a platform, are scored as millions of operators each choosing something. We measure the parked population, and what it publishes, so every other share on this site can be read against it.
- 8.86%
- Domains parked on a recognised parking platform
- 88.37%
- Parked domains publishing DMARC that set p=none
of 363.6M resolving domains · as of 2026-09-24
of 4.8M parked domains publishing DMARC
Measured, not sampled. Full method and caveats sit with each figure on the page that publishes it, behind “Caveats and method”.
Query these statistics directly
Every figure on this page is served as Parquet. Same format as the corpus itself.
SELECT * FROM read_parquet('https://observatory.datazag.com/observatory_statistics.parquet');