Summary

  • ZMap’s 2013 release made repeatable public IPv4 surveys practical through stateless probes that avoided a conventional connection record for every target.
  • ZMap, ZGrab2, ZDNS and ZLint form a staged measurement pipeline in which each filter changes the population the final analysis can describe.
  • A response records behaviour from one vantage point at one time; ownership, product identity and vulnerability require separate evidence and dated attribution.
  • Identifiable sources, rate limits, public information, monitored abuse contacts and opt-outs reduce harm but do not create universal consent or legal permission.

ZMap made repeatable IPv4 surveys possible

In 2013, Zakir Durumeric, Eric Wustrow, J. Alex Halderman and collaborators at the University of Michigan released ZMap. On suitable hardware and bandwidth, its stateless probe engine could survey the public IPv4 address space in minutes rather than days. The speed made headlines; the more durable change was that a large survey could be repeated often enough to become a measurement method.

Earlier tools could scan broad address ranges, but full-IPv4 exercises were often slow, stateful and expensive. Teams divided targets across machines, waited for connections to time out and spent substantial effort managing the scanner. Smaller samples were easier to operate and could miss patterns visible only at internet scale.

ZMap changed the economics of the first question. It sent a narrowly defined packet across a large target set and validated replies without retaining a conventional per-target connection record. A permutation spread probes through the address space. Reserved ranges could be excluded. Output could feed a later protocol stage rather than forcing the discovery engine to conduct every handshake itself.

That separation made repetition useful. When the same probe is run with documented parameters from a known source, researchers can compare observations over time: certificate adoption, exposed services, protocol changes or the response to a vulnerability disclosure. A one-off fast scan produces a number. A repeatable scan produces an instrument whose assumptions can be inspected.

The instrument still sees only what its design permits. A TCP SYN can show that an address returned behaviour consistent with a listening service. It cannot establish who owns the system, whether a virtual host is configured, whether a middlebox answered or whether the service is exploitable. Silence may reflect filtering, loss, rate limiting or an inactive host.

That uncertainty leaves ZMap with a difficult question: how can researchers measure the public internet at scale without turning a vantage-bound response into a universal claim or making remote operators carry an unreasonable share of the experiment’s cost?

The project’s answer became a staged suite. ZMap discovers responsive endpoints. ZGrab2 conducts protocol handshakes. ZDNS measures naming behaviour. ZLint and cryptographic libraries analyse collected objects. Each stage asks a different question and increases cost, sensitivity and ethical responsibility.

By August 2026, ZMap 4.4.0 was the current stable release under the Apache License 2.0. The lasting achievement is not that the project “mapped the whole internet”. It made a class of public IPv4 observation fast, reproducible and ordinary enough that target selection, probe design, interpretation and abuse handling all had to become part of the method.

Stateless speed puts more pressure on probe design

A conventional scanner can open a connection, track its state and wait for a response. At internet scale, maintaining state for every target consumes memory and makes timeouts expensive. ZMap avoids much of this cost by encoding enough information in the probe and validating replies when they return. Targets can be generated through a permutation so the scan covers the space without storing a list of every address already contacted.

The design shifts complexity rather than eliminating it. The scanner must choose source ports, sequence values or validation fields so replies can be associated with the experiment. It must handle packets arriving out of order. It must distinguish duplicates and unrelated traffic. The receive path has to keep up with the chosen rate or results will be lost locally.

Network capacity is only one limit. The source host needs NIC, CPU and kernel settings suited to high-rate packet generation and capture. Upstream networks may police or filter the traffic. Middleboxes can rewrite fields. Targets may rate-limit replies. The fastest configured rate is not necessarily the rate that produces the best dataset.

A randomized target order reduces concentrated load on one network. It also makes the measurement less intuitive to observe because consecutive packets reach unrelated destinations. Operators should record the permutation seed, target constraints and probe module so the run can be reproduced and audited.

The first-stage probe is deliberately minimal. For TCP, it may establish responsiveness on a selected port without completing a full application exchange. This reduces remote work and makes breadth possible. It leaves important ambiguity. A SYN-ACK can indicate a listener, while a reset, silence or ICMP response has several possible causes. Filtering policies, host load and transient network conditions affect the outcome.

Loss is bidirectional. The probe may never reach the target, or the reply may never reach the scanner. A silent address cannot be labelled “offline” with certainty. It is more accurate to say that it did not produce the expected response during that measurement. This phrasing sounds cautious and preserves the scientific meaning.

The vantage point shapes the population. A service reachable from a university network may be filtered from a residential provider or another country. Anycast can direct probes to different sites. Route changes alter latency and loss. Comparing surveys from different sources without accounting for these factors can turn network policy into a false trend.

Statelessness also limits what can be asked in one stage. Protocols that require negotiation, authentication or application data need follow-up. The ZMap ecosystem’s answer was modular enrichment rather than making the first scanner stateful and complex. This separation keeps the discovery stage efficient and gives researchers control over the cost and intrusiveness of deeper questions.

The architecture is elegant because it makes a constraint explicit. Internet-wide measurement cannot afford to treat every address as a long conversation. It must decide which evidence is worth collecting and in what order. ZMap made that decision programmable.

ZGrab2 turns a response into a deeper and costlier conversation

A port response says little about the application behind it. ZGrab2 follows the discovery stage with protocol-aware handshakes. It can connect to services such as TLS, HTTP, SSH or SMTP and record structured metadata. At that stage, a survey begins to identify software, certificates, protocol versions and configuration.

The enrichment is analytically powerful. A TLS exchange can collect a certificate chain and negotiated parameters. An HTTP request can reveal a status code, server header or page. An SSH banner can indicate software. Repeating these interactions across many hosts can show ecosystem changes that are invisible from routing or DNS data alone.

The same interaction consumes more resources at the target. A full handshake requires state, cryptographic work and application processing. An HTTP request may reach a virtual host that behaves differently depending on the name. An SMTP exchange can trigger logging or security controls. Rate, payload and timing therefore need stricter justification than a minimal discovery probe.

Virtual hosting introduces a major interpretation problem. Many domains can share one IP address, and the default response may not represent any of them. A scan by address can retrieve a generic certificate or page while real users send a name through Server Name Indication and an HTTP Host header. The measured endpoint is real and may not be the service the researcher intends to describe.

Middleboxes create another ambiguity. A content-delivery network, firewall or load balancer can terminate the handshake. The response reveals the fronting infrastructure, not necessarily the origin server. This may be exactly the object of a study, but it must be named correctly.

Protocol modules also age. Specifications evolve, extensions appear and servers implement unusual behaviour. A parser that assumes one encoding can fail or misclassify. Malformed remote input can expose bugs in the scanner itself. Project maintenance therefore includes security, parser resilience and more than the addition of new protocols.

Structured output helps researchers preserve evidence. Rather than storing only a human-readable banner, ZGrab2 can record fields that can be filtered and compared. The schema becomes part of the method. A change in parser or output format can affect longitudinal analysis, so version information belongs with the dataset.

Deep scans should be designed from the research question backward. If the goal is to measure TLS version support, an HTTP request may be unnecessary. If the goal is certificate linting, only responsive TLS endpoints need further processing. The pipeline’s modularity allows restraint.

The ethical threshold is not one universal packet count. It depends on the protocol, target population, expected server cost, rate, jurisdiction and public interest. ZGrab2 gives researchers capability; it does not issue permission. Responsible users need review, contact procedures and a plan for stopping when harm is reported.

The progression from ZMap to ZGrab2 captures the project’s central discipline: breadth first, depth where justified. It is a way to make internet-wide research feasible without pretending every possible handshake should be performed against every address.

ZDNS measures naming at scale without making one answer definitive

DNS is both a directory and a distributed policy system. A record can identify an address, delegation, mail route or service. Caches, resolvers, authoritative servers and content platforms all affect what an observer receives. ZDNS provides a measurement-oriented way to issue large volumes of DNS queries and record structured replies.

Bulk DNS measurement supports several kinds of study. Researchers can examine delegation, record adoption, DNSSEC behaviour, certificate-related names or the infrastructure used by a population of domains. The tool fits the ZMap model: make one stage efficient, store machine-readable evidence and keep the question explicit.

The target population is often harder than the query. Domain lists can come from zone files, certificate transparency, passive observations or rankings. Each source includes and excludes different names. A study of “the web” built from a popularity list measures a curated sample, not all domains. A certificate-derived list reflects issuance and may contain names that are not publicly reachable.

Wildcard DNS can make nonexistent names appear valid. Caching can return stale data within permitted time. Anycast can direct queries to different authoritative instances. Resolver-based measurements may reflect the resolver’s cache and policy rather than the authority. Direct authoritative queries have their own rate and operational impact.

A DNS answer also does not prove service. An A or AAAA record can point to an unused address. A name can resolve differently by geography or client network. A CNAME chain can hide a provider relationship that changes over time. The data becomes useful when joined with explicit timing, vantage and follow-up measurements.

Bulk queries can burden authoritative infrastructure. Randomizing names or sending malformed traffic is more intrusive than asking for existing records. Rate limits and opt-out procedures matter. Researchers should avoid making a small authoritative server pay for the convenience of a massive dataset.

ZDNS’s value is that it treats DNS as a source of structured observations rather than an opaque lookup command. It can be integrated into reproducible pipelines and compared across runs. The limits need to travel with the output: query type, resolver mode, retry policy, response code and timestamp.

The naming layer also connects ZMap’s tools. DNS results can identify virtual-host names for ZGrab2. Certificates collected from endpoints can supply additional names. Reverse DNS can help explain addresses. These joins increase analytical value and can magnify bias from each source.

A responsible project keeps the layers separate enough that a researcher can see which claim comes from which observation. A name in a certificate is not the same as a live DNS record. A live record is not the same as a service response. A service response is not proof of ownership or vulnerability.

ZDNS helps make those transitions explicit. Its contribution is not that it makes DNS simple, but that it gives large-scale studies a tool designed for the complexity rather than forcing general-purpose resolver software into an undocumented batch experiment.

ZLint can test certificate rules without declaring a system secure

Internet-wide TLS studies produce millions of certificates and related objects. Collecting them is only the first step. Researchers want to know whether fields comply with standards, whether names are encoded correctly, which algorithms are used and how issuance practices change. ZLint and cryptographic parsing libraries provide this analysis layer.

A linter evaluates objects against defined rules. It can identify a certificate whose validity period, extensions or name constraints conflict with a requirement. At scale, these checks can reveal recurring errors and help certificate authorities improve issuance. They can also support ecosystem governance by showing whether new rules are being followed.

A lint result has a precise scope. Passing every implemented check does not prove that a certificate is trustworthy, correctly issued or safe to use. The tool may not implement every policy. A relying party may apply a different root store, date or algorithm policy. The private key can be compromised even when the certificate is syntactically perfect.

Failure also needs interpretation. Some rules are errors, others warnings or notices. A certificate can violate a current requirement because it was issued under an older policy. A study that treats every lint finding as an active security flaw can exaggerate risk.

Cryptographic parsing has its own hazards. ASN.1 and certificate structures are complex, and remote data can be malformed deliberately. A parser needs strict bounds handling and clear error reporting. At internet scale, one unusual object can stop a pipeline or contaminate a dataset if failures are not isolated.

Chain building is particularly easy to overstate. A collected server chain is what the endpoint presented. A browser may construct a different path using cached intermediates and its own trust store. An analysis library can parse the chain without reproducing every client’s validation decision. Claims about browser trust require the relevant policy and date.

The ZMap ecosystem’s separation of collection and linting improves reproducibility. Researchers can preserve raw objects, apply a versioned rule set and rerun analysis as policies change. A published dataset should record the ZLint version and rule configuration so later readers can understand the result.

The tools also show why a modular project is easier to govern than one giant scanner. Certificate experts can maintain lint rules. Protocol developers can maintain handshakes. Core scanning can remain focused. The repositories have separate release rhythms and contributor communities, which means the umbrella project’s current status cannot be reduced to one version number.

These analysis components made ZMap relevant to public-key infrastructure beyond host discovery. They allowed researchers and industry teams to observe issuance patterns at a scale unavailable from anecdotes. The correct conclusion remains bounded: the tools make certain properties measurable. They do not turn a certificate corpus into a complete security assessment of the systems that presented it.

Every stage of the pipeline changes the population being measured

The mature ZMap workflow can include target selection, ZMap discovery, ZGrab2 handshakes, ZDNS enrichment, certificate parsing, linting, storage and publication. Each stage filters the population. The final dataset is the result of all those choices.

Suppose a study begins with the public IPv4 space and scans a common TLS port. Addresses that do not reply are removed. ZGrab2 then completes TLS with responders. Hosts that require a different handshake or drop the second-stage connection are removed. Certificates that fail parsing may be removed or counted separately. The final analysis describes the systems that survived the pipeline, not every TLS deployment.

This is not a defect if the method is documented. It becomes a defect when the final count is described as a census without the attrition. Researchers should publish denominators at each stage and reasons for exclusion. Versioned code and configurations allow others to reproduce or challenge the result.

Time is another filter. A full scan can be fast, yet the internet changes during and after it. Cloud instances start and stop. Certificates renew. Anycast routes shift. A dataset is a dated snapshot assembled over an interval. Joining it with another source collected days later can create mismatches.

Storage and deduplication change meaning. The same certificate may appear on many hosts. Counting hosts, certificates and organisations answers different questions. One IP can host many services; one service can use many IPs. Entity resolution is an analytical layer with uncertainty.

Publication creates a new risk. A dataset can help defenders understand exposure and help attackers identify targets. Redaction, aggregation and access controls may be appropriate for sensitive fields. Open science does not require publishing every address and banner without considering harm.

The pipeline also needs operational controls. Logs should record rates and errors. Abuse messages should be linked to the run. Data should be protected because it can contain infrastructure details. Credentials used for cloud storage or analysis are separate attack surfaces.

Reproducibility is not the same as permanent validity. A protocol module can change, a target list can become unavailable and network policy can shift. A ten-year retrospective is valuable because it can identify which methods remained comparable and which required reinterpretation.

ZMap’s infrastructure contribution lies partly in normalising this pipeline thinking. The scanner is one component. Serious use requires treating the study as a data system with provenance, lifecycle and ethical review. That is how an internet-wide observation becomes evidence rather than a collection of packets.

A response becomes misleading when it is promoted to ownership or vulnerability

The public often encounters internet scanning through claims about exposed cameras, databases or industrial systems. These stories can be important and are vulnerable to categorical error. An IP address is not an organisation. A banner is not a verified product inventory. A version string is not proof that a vulnerability is exploitable.

Addresses change hands and can be shared. Cloud providers host many customers. Carrier-grade network address translation can complicate interpretation. Anycast presents one service through many locations. Reverse DNS may be stale or generic. Attribution requires additional evidence and sometimes cooperation from the operator.

Service fingerprints can be deceptive. Administrators can change banners. Proxies and gateways terminate connections on behalf of backends. Honeypots imitate services. A scanner can identify behaviour consistent with a product and should not convert that into certainty without validation.

Vulnerability claims add another inference. A product version may be associated with a public advisory. The deployment may include a backported fix without changing the banner. The vulnerable feature may be disabled. A mitigation may block exploitation. Conversely, a generic banner can hide an affected system.

The accurate language is specific: an endpoint responded, presented a value or exhibited behaviour during a dated scan. Researchers can estimate exposure under stated assumptions. They should distinguish confirmed vulnerable systems from potentially affected versions.

This discipline is not pedantry. Public accusations can affect companies and critical infrastructure. Defenders need accurate prioritisation. Exaggerated counts can produce alert fatigue and make operators less willing to cooperate with researchers.

Longitudinal comparisons require consistent definitions. If a later scanner recognises more variants, an apparent increase may reflect improved detection. If a cloud provider blocks probes, an apparent decline may reflect visibility. Changes in the tool and network need to be separated from changes in the population.

ZMap’s tools enable stronger evidence because the pipeline can collect protocol detail and preserve raw records. They do not remove the burden of attribution. The highest-quality studies are often those that state what they cannot know and invite affected operators to validate findings.

Its central lesson is that speed magnifies both insight and error. A mistaken interpretation applied to one host is a support ticket. Applied to the IPv4 space, it becomes a misleading global statistic.

Accountability has to be designed before the first packet leaves

Internet-wide scanning reaches systems whose operators did not request the measurement. That fact cannot be removed by good intentions. Responsible practice aims to minimise harm, make the source identifiable and give operators a workable route to object.

The ZMap documentation and research tradition emphasise several controls. Scans should originate from dedicated addresses with informative reverse DNS. A public web page should explain the project, probe and contact details. Abuse mail must be monitored. Targets that request exclusion should be blocked promptly. Rates and payloads should be chosen to limit remote work.

These measures are operational, not ceremonial. A reverse-DNS label is useful only if it resolves to a current explanation. An abuse address is useful only if someone responds. A blocklist is useful only if it is applied to future runs and shared across the team. A researcher should be able to stop a scan quickly when an unexpected effect appears.

Probe content can reduce confusion. A clear HTTP user agent or request path can identify research traffic. A minimal valid handshake is generally preferable to malformed packets unless malformed behaviour is the explicit, reviewed subject. Authentication attempts and exploit payloads cross a much higher ethical and legal threshold than service discovery.

Rate limiting should consider the receiver, not only the scanner’s uplink. A randomized scan spreads load across the address space, while a network with a large block can still receive many probes. Per-prefix limits and exclusion of known sensitive ranges may be appropriate. Repeated measurements should account for cumulative burden.

Opt-out is not consent. It offers recourse after or during unsolicited contact. Some operators will still regard scanning as hostile. Law varies by jurisdiction, protocol and purpose. Institutional review and legal advice may be needed. The existence of open-source software does not authorise its use.

Transparency can improve data quality as well as ethics. Operators who understand a scan may report middleboxes, honeypots or measurement artefacts. An explanation page can document changes across runs. Abuse feedback becomes part of the method, revealing probes that trigger unexpected behaviour.

The controls also protect the project. A poorly managed scan can damage the reputation of the research institution, cause upstream providers to block traffic and reduce willingness to cooperate with future studies. Ethical architecture is therefore part of sustainability.

No checklist can guarantee zero harm. A fragile device may fail under a valid request. A security system may generate work. A scan can expose a configuration the operator considered private. Responsible researchers acknowledge these limits and weigh public value against burden.

ZMap’s legacy includes making this discussion unavoidable. Once internet-wide scanning became cheap, restraint could no longer rely on cost. The project’s mature practice treats accountability as a first-class feature of the measurement system.

A source network’s reputation is a finite research asset

A university, company or measurement lab can lose the practical ability to scan if upstream providers, peers and remote operators no longer trust its conduct. Complaints can lead to filtering, contract disputes or broad blocklists that affect unrelated research. The source address is therefore more than a technical resource; it carries institutional reputation.

Dedicated prefixes and clear reverse DNS help separate measurement from ordinary users. Internal approval prevents another team from launching an overlapping experiment with different contact details. A central registry of scans, rates and exclusion requests lets the institution answer an operator without reconstructing history from individual researchers.

Reputation also improves science. An operator who receives a useful explanation may report an artefact or confirm a finding. One who receives no response is more likely to block the source. Transparency can reduce raw reach and increase the quality of the remaining relationships.

Leadership should treat abuse handling as funded infrastructure. Students and short-term projects change; opt-out commitments need to persist. The organisation should know who can stop traffic immediately and who owns the exclusion list after a paper is published.

ZMap made large experiments inexpensive enough that institutions can run them regularly. The scarce resource became permission in the broad social sense: not universal consent, but a record of conduct that makes future observation possible.

IPv6 replaces enumeration with constructed and biased target lists

ZMap’s original power is inseparable from IPv4’s finite, enumerable public address space. Even after excluding reserved ranges, the target population is large but tractable. IPv6 changes the scale by many orders of magnitude. Sending one probe to every possible address is not a meaningful strategy.

This does not make active measurement impossible. It changes target discovery. Researchers can use DNS, certificate transparency, routing data, observed traffic, hit lists and patterns in address assignment to identify likely active IPv6 addresses. Each source introduces selection bias.

A DNS-derived list favours named services. A certificate list favours TLS and public issuance. Routing data identifies prefixes rather than hosts. Heuristics can find addresses with common interface patterns and miss privacy addresses or unusual allocation. There is no one list equivalent to the public IPv4 space.

The shift has analytical consequences. An IPv6 scan is usually a survey of a constructed target set, not the protocol population. Coverage must be described through the source and generation method. Comparing counts across studies with different hit lists can be meaningless.

Privacy features and address rotation make longitudinal tracking harder. A device can appear under a new address without changing service. Conversely, stable server addresses may be easier to measure than client populations. The visible IPv6 internet is shaped by operational conventions.

ZMap’s stateless engine can still send probes to large IPv6 target lists where supported by the chosen tooling and method. The project’s broader contribution—fast discovery followed by modular enrichment—remains relevant. The census claim does not.

This limitation is healthy because it forces internet measurement to confront sampling directly. IPv4-wide scanning sometimes encouraged the belief that completeness was available. It was never complete in terms of services, vantage or filtering. IPv6 makes the gap impossible to ignore.

The future of the project may therefore rely less on scanning every address and more on constructing transparent target populations. Tooling for provenance, deduplication and bias analysis becomes as important as packet rate. Collaboration with DNS, routing and passive-measurement communities can improve coverage without pretending to eliminate uncertainty.

IPv6 does not make ZMap obsolete. It reveals which part of ZMap’s legacy is durable: an architecture for asking narrow questions at scale and recording the limits of the sample.

Longitudinal evidence depends on a stable method, not maximum speed

One of ZMap’s largest contributions is the ability to repeat an observation. Repetition becomes scientifically useful only when the method remains comparable. A faster scanner version, different source network or revised protocol module can change results even when the internet population does not.

A longitudinal programme should freeze more than the command line. It should record the target-generation method, exclusions, permutation seed, source addresses, probe payload, rate, retries and response validation. Follow-up modules need their own versions and schemas. The storage pipeline should preserve enough raw evidence to reclassify records later.

Protocol evolution can force a break. A TLS study conducted before widespread Server Name Indication cannot be reproduced exactly in a virtual-hosted environment by adding a modern name list and calling the series continuous. The newer method may be better and should be labelled as a new measurement regime with an overlap period.

Scanner improvements create another discontinuity. A parser that recognises more services can make prevalence appear to rise. Stricter reply validation can make counts fall. Researchers should run old and new methods in parallel on a sample to estimate the effect of the tool change.

Vantage stability matters as much as software. An upstream provider can alter filtering. A university can change routes. Peering can move the source closer to some networks. A second vantage can help identify whether an apparent trend is global or path-specific, and it changes the population rather than simply adding confidence.

Target ownership also changes. IPv4 blocks are transferred, cloud services recycle addresses and devices appear briefly. A repeated response from one address is not necessarily one persistent machine. Longitudinal analysis needs an entity model appropriate to the question or should remain at address-level observation.

Publication should expose missingness. If one scan lost receiver packets or a provider blocked traffic, the run should not be quietly normalised to earlier results. Confidence intervals and stage-by-stage completion can make the limits understandable without pretending internet measurement behaves like a laboratory instrument.

The ten-year retrospective around ZMap is valuable because it treats method history as part of the result. The project’s speed made repeated surveys practical. Its deeper maturity lies in recognising when repeated numbers are not comparable.

A correct observation can become operationally false as it ages

A scan record can be correct at the time it was collected and misleading later. Certificates renew, addresses are reassigned and services disappear. Historical data are useful for research and dangerous when imported into a current exposure product without a freshness model.

Different fields decay at different rates. A routing origin may remain stable for years. A cloud virtual machine can last minutes. A certificate has explicit validity dates and can be replaced early. A banner can change after an update. A dataset should carry collection time at the finest level needed for the claim.

Revalidation is not always cheap. A product may monitor millions of endpoints and need to decide how often to rescan. Frequent contact increases burden and cost. Infrequent contact increases stale findings. Risk-based schedules can prioritise critical services and recent change, while leaving low-value history clearly marked.

Address reassignment creates harm when old findings follow the new holder. A public IP once hosting an exposed database may later belong to an unrelated customer. Entity-resolution systems should separate historical observation from current attribution and expire links that cannot be confirmed.

Certificate data can create a similar trap. A name appearing in an old certificate does not prove that the same organisation operates the endpoint today. Certificate transparency and scan data need issue and collection dates. A chain that was invalid under one root programme may be treated differently later.

Raw datasets are valuable because analysts can revisit them with new questions. They are sensitive because they preserve details no longer public. Retention should be justified, access controlled and publication designed around the continuing public interest. “It was once reachable” does not make indefinite address-level distribution harmless.

Commercial intelligence products face the same problem at a larger scale. A polished interface can make an old observation look current unless freshness is prominent. Customers may act against a supplier or asset based on stale data. Method transparency should include rescan cadence and confidence.

ZMap’s pipeline encourages date-stamped evidence, and the surrounding ecosystem needs an expiry discipline. Measurement is not complete when data are written. The result has a lifecycle: collect, interpret, publish, refresh and eventually retire.

Honeypots show that the measured internet can answer strategically

A scanner often assumes the remote response is an incidental property of a service. Security systems can recognise probes and answer deliberately. Honeypots emulate vulnerable protocols to attract reconnaissance. Firewalls send synthetic resets. Tarpits accept connections and slow the scanner. Deception platforms return banners designed to confuse classification.

These systems are not noise in every study. They are part of the public internet and can be the subject of measurement. They complicate claims about product prevalence and exposure because the observed behaviour may be an intentional performance rather than the underlying asset.

A single IP can also represent a scanning trap operated across many ports. Counting every apparent service as a separate deployment exaggerates the population. Cross-port consistency, timing and known deception signatures can help, while sophisticated systems adapt.

Content-delivery and security providers can intercept probes at scale. Their edge response may be genuine for the domain and generic for address-only scans. A study of server software can end up measuring the protective layer. This is not a scanner error if the object is named correctly.

Defenders may block a known research source after repeated scans. The resulting decline in observed services can look like remediation. Transparency and stable source identities make blocking more likely and make ethical operation possible. Measurement quality and accountability can pull in opposite directions; rotating covert sources may improve reach and undermine legitimacy.

Researchers should not try to defeat every defensive control automatically. Evasion changes the interaction and ethical posture. If a study requires understanding censorship or blocking, the method should be explicit and reviewed. Routine service surveys should accept that some networks choose not to answer.

Deception also has a strategic purpose: increase an attacker’s uncertainty and gather intelligence. Publishing exact methods for distinguishing honeypots can reduce defensive value. Researchers may need aggregate reporting or coordination with operators.

The lesson is broader than honeypots. Internet measurement is not passive observation of a fixed object. The object can recognise and respond to the instrument. ZMap’s repeatable probes make that interaction analysable, provided the resulting behaviour is not mistaken for an unstrategic fact about the endpoint.

Entity resolution is where a packet record becomes a market claim

ZMap records addresses and protocol responses. Public reporting and commercial products often need organisations, products and assets. The translation is not a simple database join. Registration records can name a network operator rather than the customer using an address. Cloud providers own prefixes that host thousands of unrelated tenants. Reverse DNS can be stale, generic or controlled by a reseller.

Several clues can improve attribution. Autonomous-system origin identifies the network announcing a prefix. WHOIS or registration data identify the resource holder under a registry’s current records. TLS certificates can supply names. DNS and HTTP responses can reveal a service brand. None alone proves legal ownership or operational responsibility.

The clues can conflict for legitimate reasons. A bank can use a cloud provider and a content-delivery network. A managed-security company can terminate traffic for a customer. An address can be leased. A certificate can contain a former name. Entity resolution needs dated evidence and a rule for uncertainty.

Product identification has a similar chain. A banner can name software. A handshake can match a fingerprint. A web page can be a decoy. The product may be embedded inside another appliance. Version information can be hidden or deliberately modified. A study should separate observed string, inferred product and confirmed implementation.

Large datasets encourage deterministic labels because they are easier to count. An “unknown” category is methodologically honest and commercially unsatisfying. Systems should preserve confidence and competing hypotheses instead of collapsing them. A user deciding whether to contact an operator needs to see why the attribution was made.

Reassignment makes the process temporal. An IP can move from one customer to another after the scan. A report sent weeks later may reach the wrong party. Sensitive findings should be rechecked close to disclosure. Historical products should prevent old attribution from appearing as current exposure.

Aggregation can reduce error and hide distribution. Reporting that a cloud network contains a class of exposed service may be accurate without naming every tenant. Naming the provider as the operator of all services can be unfair. Researchers should choose the level that matches the evidence and public interest.

Commercial asset-intelligence companies invest heavily in this layer because customers pay for ownership and context, not raw packets. The value is real and separate from ZMap’s open scanner. A high-quality product should disclose collection time, confidence and correction mechanisms.

For academic work, entity resolution should be documented as a method with validation samples. Manual checks, operator feedback and independent sources can estimate error. The absence of ground truth should not be hidden behind a precise chart.

ZMap made collection scalable. It also made it possible to scale an attribution mistake. The responsible boundary is to stop the claim at the best available evidence: address response, service behaviour, product hypothesis or verified entity. Each step needs its own proof.

Censys shares ZMap’s lineage, not ownership of the open project

ZMap’s academic work helped create the conditions for Censys, a commercial internet-intelligence company. The relationship is important and often collapsed into a false identity. Censys is a separate company with products, customers and its own data operations. The ZMap Project is an open-source tool suite and research ecosystem.

The commercial lineage demonstrates that repeatable internet measurement has market value. Security teams want current information about exposed services, certificates and assets. A company can operate continuous scanning, maintain datasets, resolve entities and provide search and monitoring. These activities require infrastructure and support beyond publishing a scanner.

Commercial operation also changes the accountability model. A company has customers, contracts and a persistent scanning footprint. It may use ZMap-related technology while developing proprietary systems and enrichment. Its dataset should not be treated as the output of an unmodified public tool.

The separation protects attribution. University researchers and open-source maintainers should not be credited with every commercial product decision. Censys should not be described as owning every ZMap repository or dataset produced by others. Shared founders and history do not erase institutional boundaries.

The relationship also illustrates open-source economics. A public research tool can create a commercial category without receiving the revenue of every company that uses it. Commercial firms can fund contributors or return improvements, but the project has no automatic claim on their income. Sustainability depends on grants, institutional support, contributor time and whatever companies choose to invest upstream.

For users, the open tool and managed service offer different bargains. Running ZMap gives control over the question, rate and raw data. It requires network capacity, engineering, ethics processes and storage. A commercial platform provides maintained data and interfaces at a price, while the customer depends on its collection methods and coverage.

The existence of Censys does not prove that the open project has been commercialised away. It shows that the measurement method became infrastructure valuable enough to support a company. The project’s continued release activity, including ZMap 4.4.0 in 2026, indicates an independent technical life.

The commercial story explains impact without establishing ownership. ZMap helped make internet-wide measurement reproducible. Censys built a business in related intelligence. The two share lineage and operate under different authorities.

The scanner is open; the measurement programme is still expensive

The ZMap scanner can be downloaded without a proprietary licence fee. Operating a serious programme requires far more. The organisation needs bandwidth, hosts, capture capacity, data storage, analysts, security controls, abuse response and legal or institutional review. Deep protocol scans add CPU and remote interaction. Longitudinal studies create a permanent data-management obligation.

Cloud infrastructure can make compute available quickly and complicate scanning policy. Providers may restrict high-rate probing or receive complaints. Source addresses can change. Egress charges and packet-rate limits affect design. A university network may have appropriate bandwidth and face reputational risk if the programme is not coordinated.

Storage grows through enrichment. A minimal response record is small. Certificates, protocol transcripts and HTTP bodies are not. Keeping raw data supports reproducibility and increases sensitivity. Researchers need retention rules, access controls and a plan for deletion.

Personnel is the largest hidden cost. Someone must update modules, interpret errors and respond to operators. Ethical practice requires timely human attention. An automated scan that sends millions of probes cannot have an unmonitored mailbox as its only accountability mechanism.

Funding is distributed across universities, grants, companies and contributors. The project does not publish one consolidated budget or employee count. Repository activity shows maintenance, not the economic value of all downstream use. This is common in research infrastructure and creates succession risk.

The modular suite can reduce duplicated engineering. Researchers do not need to build a scanner, TLS collector and linter from scratch for every paper. Shared code improves comparability and concentrates maintenance. The benefit is public and the cost can fall on a small group of maintainers.

Institutions using the tools should contribute according to their dependence. Contributions can include code, testing, documentation, funding or responsible-scanning infrastructure. A commercial user that maintains a private fork may gain short-term advantage and increase the cost of keeping the public tool compatible with current protocols.

The total-cost comparison with a managed dataset depends on frequency and control. A team conducting one study may be better served by an existing data source. A research group developing a new protocol question may need to run its own measurement. Open source creates the option; it does not make every exercise economically sensible.

ZMap occupies one stage beside scanners and commercial data services

ZMap is often compared with other scanners, and the comparison needs a purpose. Nmap is designed for flexible discovery and detailed examination, with rich scan types, fingerprint databases and a scripting engine. Masscan is known for high-rate scanning. Commercial asset-intelligence platforms operate continuous collection and entity enrichment. Vulnerability scanners add authenticated checks and remediation workflows.

ZMap’s strength is a research-oriented stateless first stage and a modular measurement suite. It is well suited to repeated broad surveys with controlled probes and structured output. It is not a complete vulnerability-management product or an interactive administrator’s universal scanner.

Nmap can perform deep examination of a smaller target set and is widely used in network operations. Its stateful logic and scripting flexibility serve a different workflow. A researcher may use ZMap to find responsive endpoints and another tool for detailed follow-up. The categories overlap without requiring one winner.

Masscan’s speed can suit asset discovery and security work. Differences in validation, output and surrounding research practices matter more than a headline packets-per-second number. The choice should follow the evidence required and the organisation’s ability to operate responsibly.

Commercial platforms offer a maintained view without requiring the customer to scan. They may combine several collection methods, DNS, registration data and historical context. The user trades control and transparency for convenience and service. Coverage and entity resolution remain methodological claims to evaluate.

Passive measurement avoids contacting targets and sees only traffic available at the observation point. It can reveal active use that an external scan misses and cannot provide a global public view. Routing and DNS datasets add context without proving service.

The most credible measurement programmes combine sources. A scan can validate a DNS hypothesis. Passive evidence can show real traffic to a service. Operator disclosure can resolve attribution. Tool competition is less useful than methodological triangulation.

ZMap’s influence is visible in the expectation that internet-wide studies should be reproducible, rate-aware and modular. Even researchers who choose another scanner work in a field changed by the demonstration that breadth could be an ordinary part of measurement design.

Maturity means maintained methods, not harmless or complete scanning

More than a decade after its release, ZMap remained active at version 4.4.0, and the surrounding suite covered application handshakes, DNS and public-key infrastructure analysis. A systematic retrospective and continuing research discussion show that the project has become durable measurement infrastructure.

That maturity is a maintenance achievement. It does not settle the ethical questions, guarantee equal health across repositories or create a complete view of the internet. Protocols evolve, IPv6 changes target construction and defensive systems adapt to known probes. Open-source availability also means the maintainers cannot police every scan conducted with the software.

The evidence is clearest on architecture, release status and documented practice. It is weaker on a global user census, consolidated funding and the consequences of every downstream deployment. Misuse by an independent operator should not be attributed automatically to the project, while responsible-scanning guidance should not be treated as proof that every user follows it.

The project’s durable method is narrower than a claim to universal visibility. Ask a limited question, record the source and target population, preserve the probe and tool versions, separate observation from attribution, and design a route for operators to object. On IPv6, the method also requires an explicit account of how the target list was constructed and what it excludes.

The next test is a current study that can be reproduced independently across the full pipeline, including target provenance, stage-by-stage attrition, responsible operation and dated interpretation. That evidence would show that the public measurement commons can survive the move beyond enumerable IPv4 space.

ZMap reduced the technical cost of seeing part of the public internet. Its value now depends on keeping the epistemic and institutional costs visible: who was asked, from where, with which packet, under which definition and with what recourse when the measurement caused harm.