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 366.2M 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.
- Networks carrying half of all attributable domains
- 6
- of 51,933 networks observed carrying domains · as of 2026-11-05
- Networks carrying ninety per cent of attributable domains
- 231
- of 51,933 networks observed carrying domains
- Networks observed announcing address space
- 80,395
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.
- Distinct IPv4 prefixes observed
- 1.2M
- · as of 2026-11-05
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.
- MOAS prefixes that are stable multi-homing, not hijacks
- 96.49%
- of 206,770 MOAS prefixes observed · as of 2026-11-05
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.
- Prefixes flagged as hijack candidates
- 6,619
- of 1.2M IPv4 prefix announcements in the Datazag BGP collection · as of 2026-11-05
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.
- Prefix announcements with a valid RPKI ROA
- 41.69%
- of 1.2M IPv4 prefix announcements in the Datazag BGP collection · as of 2026-11-05
- Prefix announcements with no covering ROA
- 57.68%
- of 1.2M IPv4 prefix announcements in the Datazag BGP collection
- Prefix announcements that are RPKI-invalid
- 0.63%
- of 1.2M IPv4 prefix announcements in the Datazag BGP collection
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.
- Domains publishing a DMARC record
- 25.16%
- of 366.2M resolving domains · as of 2026-11-05
- Domains publishing an SPF record
- 45.94%
- of 366.2M resolving domains
- DMARC records set to p=none
- 50.66%
- of 92.1M domains publishing DMARC
- DMARC records at enforcement (p=quarantine or p=reject)
- 49.28%
- of 92.1M domains publishing DMARC
- DMARC records with an invalid policy value
- 0.06%
- of 92.1M domains publishing DMARC
- Domains publishing BIMI
- 0.05%
- of 366.2M 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.
- Domains publishing MTA-STS
- 0.09%
- of 366.2M resolving domains · as of 2026-11-05
- MTA-STS domains with a policy mode on record
- 71.18%
- of 330,078 domains publishing MTA-STS
- MTA-STS domains whose policy is set to enforce
- 45.94%
- of 330,078 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.
- Domains publishing a CAA record
- 1.77%
- of 366.2M resolving domains · as of 2026-11-05
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.
- Domains with a signed DNSSEC delegation
- 8.19%
- of 366.2M resolving domains · as of 2026-11-05
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.
- Domains parked on a recognised parking platform
- 9.7%
- of 366.2M resolving domains · as of 2026-11-05
- Parked domains publishing DMARC that set p=none
- 88.89%
- of 5.1M 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');