Introduction
An exposed service is not just an open port. It is an internet-reachable system that gives outsiders something to connect to, identify, fingerprint, authenticate against, or exploit.
That can be a database port, SSH, RDP, Kubernetes API, Elasticsearch, Jenkins, Grafana, Prometheus, VPN gateway, cloud console, development server, or old admin panel. The hard part is not only finding it once. The hard part is knowing whether it belongs to you, whether it should be public, whether it is authenticated, and whether it came back after a change.
This comparison looks at the best tools to find exposed services on the internet in 2026. It separates internet-wide search engines, misconfiguration indexes, open-source scanners, and EASM workflows because they solve different jobs.
Use active scanners only on assets you own or have explicit permission to assess. Internet indexes can be queried for research, but they are not permission to scan third-party systems.
The rankings are practical and qualitative, not a lab benchmark. Index freshness, query limits, API access, region, target size, network conditions, and validation workflow can change the result.
TL;DR — exposed service discovery tools compared
Use this table as the quick shortlist. The best tool depends on whether you need internet-wide search, owned-asset validation, misconfiguration discovery, or ongoing monitoring.
| Rank | Tool | Best fit | Discovery style | Validation depth | Main limitation |
|---|---|---|---|---|---|
| 1 | Shodan | Fast internet-wide lookup of exposed services and host banners | Indexed internet service search | Host, port, banner, tags, and vulnerability enrichment depending on plan/API | Indexed data may lag live state; findings still need ownership and exposure validation |
| 2 | Censys Search | Certificate, host, service, and web-property pivots | Indexed internet host and certificate search | Strong host, service, TLS, certificate, and web context | Search, Platform, and ASM access can differ; confirm current API behavior before building workflows |
| 3 | Netlas | OSINT-heavy exposed service research and API-driven investigation | Indexed internet scan data with query language and API | Service, protocol, DNS, WHOIS, certificate, and response-content context | Coverage, query language, rate limits, and plan details must be verified for your workflow |
| 4 | ExternalSight | Defensive teams that need exposed-service discovery tied to EASM remediation and monitoring | Owned-domain external attack surface monitoring | Ports, exposed services, admin panels, login surfaces, HTTP/TLS context, classification, remediation, history, alerts | Not a global internet search engine or raw CLI port scanner |
| 5 | LeakIX | Finding exposed misconfigurations, leaks, and vulnerable services already indexed online | Misconfiguration and vulnerability search index | Useful service and leak-oriented evidence | Not a complete asset inventory or replacement for scoped validation |
| 6 | FOFA | Cyberspace asset search, host/service queries, and API-driven research | Indexed cyberspace mapping platform | Host, service, fingerprint, query, aggregation, and API workflows | Requires syntax and API/plan verification; results still need validation |
| 7 | ZoomEye | Internet asset discovery and OSINT research | Cyber asset search engine | Host, port, service, and fingerprint-oriented research depending on query and plan | Coverage and API behavior should be verified before operational dependency |
| 8 | BinaryEdge | Internet-wide scan data, service exposure research, and data feeds | Internet scan and data platform | Open ports, exposed services, protocol metadata, and service indicators | Current API access, support model, and licensing should be verified before adoption |
| 9 | ProjectDiscovery Naabu, httpx, and Nuclei | Open-source validation pipeline for assets you own | Active scanning and template-based validation | Open ports, HTTP services, technologies, misconfigurations, and known exposure patterns | Only for authorized scope; not an internet-wide search index |
| 10 | Nmap | Deep service and version validation on scoped IPs and hosts | Active network scanning | Port state, protocol, service, version, OS hints, and scriptable checks | Not designed as a continuous internet exposure monitoring platform |
How we compared these tools
Exposed-service discovery has three separate jobs: finding candidates, validating live exposure, and turning findings into fixes.
Internet search engines are strong at candidate discovery because they already index public services. Active scanners are strong at validation because they test your scoped assets directly. EASM tools are strong when you need ownership, remediation, monitoring, history, and alerts.
For this comparison, we looked at practical coverage profile, freshness profile, service fingerprinting, vulnerability or misconfiguration context, API support, pricing model, reporting workflow, and whether the tool fits defensive monitoring.
No tool should be treated as complete. A clean result from one index does not prove that nothing is exposed.
What exposed-service discovery actually requires
Finding exposed services is not the same as running one port scan.
A useful workflow starts with the assets you own, checks internet-wide indexes, validates live reachability, fingerprints services, classifies what should not be public, and tracks whether the issue comes back.
The most useful findings usually answer five questions: what is exposed, where is it hosted, who owns it, why is it public, and what could happen if it stays public.
The service name alone is not enough. A public SSH listener, unauthenticated Elasticsearch node, Grafana login page, exposed Prometheus endpoint, and Kubernetes API do not carry the same consequence.
| Signal | Why it matters | Example |
|---|---|---|
| IP and hostname | Maps the service to an owned asset or provider | api.example.com -> 203.0.113.20 |
| Port and protocol | Shows what outsiders can connect to | 9200/tcp Elasticsearch, 5432/tcp PostgreSQL, 22/tcp SSH |
| Service banner | Helps identify technology, version, and product family | OpenSSH, nginx, Kubernetes API, Jenkins |
| Authentication state | Separates normal exposure from urgent exposure | Login required, no authentication, default page, public API |
| Business owner | Determines who can approve or remove exposure | Platform, data, DevOps, support, vendor owner |
| Exposure reason | Prevents accidental public services from becoming permanent | Customer API, vendor callback, temporary migration, unknown |
| Impact path | Connects the service to actual consequence | Credential attack, data exposure, admin workflow abuse, cloud access |
| Fix validation | Proves the exposure is removed or restricted | Port closed externally, authentication enforced, allowlist active |
What each tool actually does
The tools below are ranked by practical workflow fit, not by universal coverage. Use them together when the job requires both discovery and validation.
- 1. Shodan — Shodan is the default starting point for many exposed-service investigations. It indexes internet-connected devices and services, and its API can return service data for a host IP. Shodan Monitor also focuses on tracking devices exposed to the internet and sending notifications. Use Shodan when you need quick visibility into public ports, banners, hostnames, tags, and known service context. It is especially useful for checking whether a service is already visible in a public index. Treat results as evidence to validate, not final proof of current live state.
- 2. Censys Search — Censys Search is strong for host, service, certificate, and web-property pivots. It helps security teams search internet-facing infrastructure and connect services to certificates, TLS configuration, hosts, and web properties. Use Censys when exposed-service discovery needs strong TLS, certificate, and host context. It is a better research and enrichment source than a simple port list. Pair it with scoped validation before opening tickets. Confirm whether your workflow uses Censys Search, Censys Platform, or Censys ASM because access, API behavior, and buying motion can differ.
- 3. Netlas — Netlas is useful for OSINT-heavy internet service research. Its public materials describe an IoT search engine with data on publicly available services and filtering by IP address, domain, port, protocol, and response content. Use Netlas when you want rich query-driven search across indexed internet scan data. It is a good fit for researchers who need service context, protocol details, and API workflows. Verify rate limits, plan limits, and coverage before making it a production dependency.
- 4. ExternalSight — ExternalSight is not a global internet search engine. It is a domain-focused external attack surface monitoring platform for internet-facing domains. Use ExternalSight when the goal is to find and manage exposed services across assets you own. Its scanner workflow includes ports, exposed services, admin panels, login surfaces, DNS, subdomains, TLS, HTTP configuration, infrastructure, cloud exposure, passive DNS, Shodan, Wayback, OTX, WHOIS, and attack-chain evaluation. Findings can be classified, enriched with remediation planning, compared historically, alerted on, and exported. Some external-source checks may report unavailable when API keys or upstream services are not configured, so scan coverage should be reviewed.
- 5. LeakIX — LeakIX is a search engine focused on online misconfigurations, vulnerabilities, and leaks. Its documentation describes search across service and leak scope, along with API access. Use LeakIX when you care about exposed services that already look misconfigured, vulnerable, or leak-prone. It is especially useful as an exposure signal, but it should not be the only asset inventory source.
- 6. FOFA — FOFA is a cyberspace mapping and asset search platform with API workflows, query interfaces, and aggregation features. It is useful for researchers who want query-driven discovery across internet assets. Use FOFA when your workflow needs another indexed view of public hosts, services, fingerprints, and web assets. Like other indexes, FOFA findings should be validated against owned scope before remediation.
- 7. ZoomEye — ZoomEye is an internet asset discovery and cyber asset search engine. It is commonly used for OSINT and exposed-service research. Use ZoomEye as an additional indexed source when you need cross-checking beyond Shodan, Censys, FOFA, or Netlas. Before relying on it operationally, verify current API behavior, query syntax, pricing, and coverage for your target geography and service types.
- 8. BinaryEdge — BinaryEdge has historically provided internet-wide scan data and API documentation around continuous worldwide scans, ports, and service data. Coalition documentation also describes BinaryEdge scanning as looking for internet-exposed systems, open ports, exposed services, protocols, and service metadata. Use BinaryEdge when you need another internet-scan data source or data-feed-style workflow. Because some public BinaryEdge API documentation is older and Coalition’s current documentation focuses on its scan engine, verify current commercial access, API behavior, support model, and licensing before making it a core dependency.
- 9. ProjectDiscovery Naabu, httpx, and Nuclei — Naabu is a fast port scanner for enumerating valid ports on hosts. httpx is commonly used to probe HTTP services and gather titles, technologies, and response details. Nuclei adds template-based checks for vulnerabilities, misconfigurations, and exposure patterns. Use this stack for scoped validation on assets you own or have permission to test. It is a strong open-source pipeline, but it is not a public internet index and should not be pointed at third-party infrastructure without authorization.
- 10. Nmap — Nmap is still the best-known tool for deep service validation. Official documentation covers port scanning, version detection, OS detection, and scriptable checks through NSE. Use Nmap when you need precise service and version evidence on a limited set of scoped hosts. It is slower than lookup-based discovery and is not a SaaS monitoring workflow, but it remains valuable for confirming what is actually listening.
Who should use which tools to find exposed services
The best tool changes when the workflow changes.
A threat researcher may want internet-index breadth. A platform engineer may need direct validation. A small security team may need ownership and remediation workflow more than another query interface.
| Workflow | Best starting point | Why |
|---|---|---|
| Fast public lookup for an IP or hostname | Shodan | Quick host, port, banner, and service context from indexed internet data. |
| Certificate and service pivoting | Censys Search | Strong host, service, TLS, certificate, and web-property relationships. |
| OSINT-heavy service research | Netlas | Rich query model across IPs, domains, ports, protocols, and response content. |
| Owned-domain exposed-service monitoring | ExternalSight | Connects service discovery to classification, remediation, history, alerts, exports, and verified-domain monitoring. |
| Misconfiguration and leak discovery | LeakIX | Focuses on online misconfigurations, leaks, and vulnerable service evidence. |
| Additional internet asset index | FOFA or ZoomEye | Useful as secondary indexed views for public host and service discovery. |
| Alternative scan data source or feed | BinaryEdge | Useful for internet-wide scan data and exposed service metadata when current access fits the workflow. |
| Open-source validation at scale | Naabu plus httpx plus Nuclei | Finds open ports, probes HTTP services, and checks known exposure patterns on authorized assets. |
| Deep service confirmation | Nmap | Strong version detection and scriptable validation for scoped hosts. |
| Lightweight IP enrichment | Shodan InternetDB | Useful for quick IP triage, but it returns less data than the regular Shodan API, does not include banners, and should not replace live validation. |
Coverage profile comparison
Coverage is not only how many hosts a tool knows about.
For exposed services, useful coverage means source diversity, service detail, freshness, validation path, and whether the result can be connected to an owner and fix.
| Tool | Internet-wide index | Live validation | Service fingerprinting | Misconfiguration context | Monitoring workflow |
|---|---|---|---|---|---|
| Shodan | Yes | No, indexed data needs validation | Strong banner and host context | Some vulnerability and tag context depending on data/API | Shodan Monitor available |
| Censys Search | Yes | No, indexed data needs validation | Strong host, service, TLS, certificate, and web context | Useful enrichment and exposure context | Product dependent |
| Netlas | Yes | No, indexed data needs validation | Strong protocol, port, response, DNS, and certificate context | Useful query-driven exposure context | Product/API dependent |
| ExternalSight | No global search engine | Scanner workflow for owned internet-facing domains | Ports, exposed services, HTTP/TLS, admin panels, login surfaces, and related scanners | Issue classification, remediation planning, scan coverage, and attack-chain evaluation | Yes, for verified domains on supported plans |
| LeakIX | Yes, focused on misconfigurations and leaks | No, indexed data needs validation | Service and leak-oriented evidence | Strong misconfiguration and leak focus | Product/API dependent |
| FOFA | Yes | No, indexed data needs validation | Host, fingerprint, asset, and service query context | Query and aggregation dependent | Product/API dependent |
| ZoomEye | Yes | No, indexed data needs validation | Cyber asset and service search context | Query and plan dependent | Product/API dependent |
| BinaryEdge | Yes | No, indexed data needs validation | Open ports, services, protocols, and metadata | Service metadata and exposure context | Commercial access dependent |
| Naabu + httpx + Nuclei | No | Yes, for authorized scope | Ports, HTTP services, technologies, templates | Strong with Nuclei templates | Requires your own automation |
| Nmap | No | Yes, for authorized scope | Strong service and version detection | Strong with NSE and manual review | Requires your own automation |
Speed and freshness profile comparison
Search-backed tools feel fast because the scanning already happened before your query. Active scanners can be slower because they test the target now.
That tradeoff matters. Indexed data is fast, but it may be stale. Active validation is current, but it must be scoped and rate-controlled.
| Tool type | Typical speed profile | Freshness profile | Best use |
|---|---|---|---|
| Internet search engines | Fast query response | Depends on index update cycle | Candidate discovery and enrichment |
| Misconfiguration indexes | Fast query response | Depends on crawl and detection schedule | Finding already-indexed risky exposures |
| EASM monitoring platforms | Workflow-oriented scan time | Fresh when scans and monitoring run | Owned-domain posture management and drift detection |
| Fast port scanners | Fast on scoped assets | Current at scan time | Validating owned hosts and IP ranges |
| Deep scanners | Slower on scoped assets | Current at scan time | Confirming service versions, scripts, and vulnerability signals |
| Lightweight enrichment APIs | Very fast lookup | Depends on provider update cadence | Quick triage when full banner data is not needed |
Pricing and access comparison
Avoid comparing these tools only by monthly price.
The important pricing unit is different for each category: query credits, API rate limits, monitored assets, users, retained history, scans, data exports, commercial rights, and support level.
Verify pricing and access on the official vendor site before procurement because plans and limits change.
| Tool | Pricing/access model | What to verify |
|---|---|---|
| Shodan | Account and API-key based, with paid and enterprise options | Query credits, monitored assets, API access, scan capabilities, data access, InternetDB limitations, and export needs. |
| Censys Search | Search/API plans and commercial options | Confirm whether your workflow uses Censys Search, Censys Platform, or Censys ASM because access, API behavior, rate limits, and buying motion can differ. |
| Netlas | Product/API plans with documented API limits | Search quotas, certificate-search limits, API rate limits, exports, team access, and commercial usage. |
| ExternalSight | Plan-based: Recon, Sentinel, Fortress | Domain limits, monitoring interval, scan quota, JSON export, webhook access, DAST quota, and verified-domain requirements. |
| LeakIX | API access is documented; researcher access and commercial usage should be verified on current LeakIX pricing/API pages | API key access, search limits, reporting workflow, leak scope, service scope, and team usage. |
| FOFA | Product/API access with plan-dependent limits | API quota, query syntax, aggregation needs, export access, commercial usage, and team access. |
| ZoomEye | Product/API access with plan-dependent behavior | Query limits, API availability, export access, commercial use, and coverage for target regions and services. |
| BinaryEdge | Commercial/data access dependent | Current API availability, data-feed access, support model, rate limits, and licensing. |
| ProjectDiscovery tools | Open-source CLI tools; ProjectDiscovery platform has separate commercial workflows | Infrastructure cost, scan authorization, rate limits, template management, and platform needs. |
| Nmap | Open source | Operational cost, authorization, rate limits, scan windows, and storage/reporting automation. |
How to validate exposed service findings safely
A public search result is a lead, not a closed finding.
Before opening a critical ticket, confirm ownership, current reachability, service identity, authentication state, and whether the exposure is approved.
Only validate assets you own or have explicit permission to test. Do not run active scans against third-party systems because an internet index showed a result.
- Step 1 — confirm ownership — Map the IP, hostname, certificate, cloud account, DNS record, or provider to your organization before testing.
- Step 2 — check current reachability — Use a small, scoped check to see whether the port or service is still reachable from the internet.
- Step 3 — identify the service — Confirm protocol, banner, HTTP title, certificate, response headers, and application behavior.
- Step 4 — check authentication state — Separate normal public services from unauthenticated databases, dashboards, admin panels, or APIs.
- Step 5 — assign an owner — Every exposed service needs a team or person who can approve, restrict, patch, or remove it.
- Step 6 — validate the fix — Confirm the service is closed, restricted, authenticated, patched, or moved behind approved access controls.
Example workflow for owned assets
Run these examples only against assets you own or have explicit permission to assess.
Start with a candidate list:
```text api.example.com admin.example.com 203.0.113.10 203.0.113.20 ```
Validate open ports with Naabu:
```bash naabu -list targets.txt -p 1-65535 -rate 1000 -o open-ports.txt ```
Probe HTTP services with httpx:
```bash httpx -l targets.txt -title -tech-detect -status-code -location -o http-services.txt ```
Run targeted Nmap version detection on confirmed ports:
```bash nmap -sV -Pn -p 22,80,443,8080,8443,9200,5432,6379 203.0.113.10 ```
Check exposure-oriented templates with Nuclei:
```bash nuclei -l http-services.txt -tags exposure,misconfig -o exposure-checks.txt ```
Avoid templates that perform credential testing, brute-force checks, destructive probes, or unsafe actions unless you have explicit written authorization and a controlled test window.
Create a remediation worksheet:
```csv asset,ip,port,service,evidence,owner,public_reason,action,status admin.example.com,203.0.113.10,443,admin panel,"HTTP 200 /admin",platform,unknown,move behind SSO and allowlist,open 203.0.113.20,203.0.113.20,9200,Elasticsearch,"nmap service detection",data,none,remove public listener,open api.example.com,203.0.113.30,22,SSH,"open port",platform,break-glass access,restrict by VPN or allowlist,review ```
A useful finding should contain enough evidence for the owner to reproduce and enough context for leadership to understand consequence.
Where ExternalSight fits
ExternalSight fits the defensive monitoring side of exposed-service discovery.
It is useful when a team wants to scan internet-facing domains, identify exposed services, classify findings, produce remediation planning, track scan history, receive alerts, export reports, and monitor verified domains on supported plans.
The relevant scanner coverage includes ports, exposed services, admin panels, login surface, HTTP configuration, infrastructure, cloud exposure, DNS, certificate transparency, subdomains, SSL/TLS, TLS configuration, headers, passive DNS, Shodan, OTX, WHOIS, Wayback, and attack-chain evaluation.
Some external-source checks may return unavailable when API keys or upstream services are not configured. That means teams should review scan coverage before treating a clean scan as a clean surface.
ExternalSight should not be treated as a replacement for Nmap, Shodan, Censys, a SIEM, a SOC, a WAF, cloud security controls, or manual penetration testing. Its role here is to make exposed-service discovery operational for verified internet-facing domains.
Common mistakes when finding exposed services
The most common mistake is confusing indexed visibility with confirmed live exposure.
The second mistake is treating every open port as equally important. A public HTTPS service with expected authentication is different from an unauthenticated database or admin dashboard.
The third mistake is opening findings with no owner, no exposure reason, and no validation path.
| Mistake | What goes wrong | Better approach |
|---|---|---|
| Trusting one index | A service missed by one source may appear in another or may only be visible through live validation | Use multiple sources and validate owned assets directly |
| Ignoring stale data | An old search result becomes a false ticket | Check current reachability before assigning severity |
| Skipping ownership | Nobody fixes the exposure because nobody owns the asset | Map every finding to a domain, IP, cloud account, or service owner |
| Counting ports instead of risk | A large list of ports hides the few services that matter | Prioritize unauthenticated, sensitive, admin, database, remote access, and production-connected services |
| Scanning third-party systems | The team creates legal and operational risk | Only actively scan owned or authorized assets |
| Missing recurrence | A closed port reappears after a cloud, firewall, or vendor change | Use monitoring and compare scan history |
| No remediation validation | The ticket closes without proving the service is restricted | Validate externally after the fix |
Final verdict
For fast public lookup, start with Shodan. For stronger certificate, host, and service pivots, add Censys. For OSINT-heavy search, add Netlas, FOFA, or ZoomEye depending on your access and target needs.
For misconfiguration-focused discovery, use LeakIX as an additional exposure signal. For alternative internet scan data, consider BinaryEdge after verifying current product access.
For live validation on owned assets, use Naabu, httpx, Nuclei, and Nmap. These tools confirm what is reachable now, but they require authorization and your own reporting workflow.
For defensive teams that need exposed-service findings tied to remediation, history, alerts, exports, and verified-domain monitoring, ExternalSight is the better workflow fit. It is not a global search engine, but it helps turn exposed-service discovery into repeatable external attack surface management.
Frequently asked questions
- What are the best tools to find exposed services on the internet?
- The best starting points are Shodan for fast public service lookup, Censys for host and certificate pivots, Netlas for OSINT-heavy indexed search, LeakIX for misconfiguration signals, and Naabu, httpx, Nuclei, or Nmap for validating assets you own. ExternalSight fits teams that need exposed-service discovery connected to EASM monitoring and remediation.
- Is Shodan enough to find exposed services?
- No. Shodan is useful, but no single internet index is complete or always current. Use Shodan as a candidate source, then validate owned assets with scoped scanning or an EASM workflow. Shodan InternetDB can help with quick IP triage, but it returns less data than the full Shodan API and does not replace live validation.
- What is the difference between Shodan and Censys?
- Shodan is often used for fast host, port, and banner lookup across internet-connected services. Censys is strong for host, service, TLS, certificate, and web-property pivots. Both are useful, but both still require validation before remediation.
- Should I use Nmap or Naabu to find exposed services?
- Use Naabu when you need fast port enumeration across scoped assets. Use Nmap when you need deeper service and version detection on a smaller set of confirmed hosts. Many teams use Naabu for discovery and Nmap for targeted confirmation.
- How do I know if an exposed service is actually risky?
- Check whether the service is internet reachable, unauthenticated, sensitive, outdated, admin-facing, connected to production data, reachable from unknown networks, or unnecessary. A public database, dashboard, remote access service, or admin panel usually deserves faster review than expected HTTPS on a customer-facing app.
- How does ExternalSight help find exposed services?
- ExternalSight scans internet-facing domains and includes ports, exposed services, admin panels, login surfaces, infrastructure, HTTP/TLS context, DNS, subdomains, Shodan, OTX, Wayback, passive DNS, and attack-chain evaluation. It can classify findings, generate remediation planning, compare scan history, alert on changes, export reports, and monitor verified domains on supported plans.
References and further reading
- Shodan search engine — https://www.shodan.io/
- Shodan REST API documentation — https://developer.shodan.io/api
- Shodan Monitor — https://monitor.shodan.io/
- Shodan InternetDB API — https://internetdb.shodan.io/
- Censys Search — https://search.censys.io/
- Censys Search API — https://search.censys.io/api
- Censys certificates documentation — https://docs.censys.com/docs/ls-certificates
- Netlas IoT Search Engine — https://netlas.io/features/iot_search_engine/
- Netlas API reference — https://docs.netlas.io/api-reference/
- Netlas query language — https://docs.netlas.io/knowledge-base/query-language/
- LeakIX documentation — https://docs.leakix.net/
- LeakIX search API — https://docs.leakix.net/docs/api/search/
- FOFA API introduction — https://en.fofa.info/api/introd
- FOFA API documentation — https://en.fofa.info/api
- ZoomEye — https://www.zoomeye.ai/
- BinaryEdge public API documentation — https://github.com/binaryedge/api-publicdoc
- BinaryEdge scanner overview by Coalition — https://help.coalitioninc.com/hc/en-us/articles/48928737389979-What-the-BinaryEdge-scanner-does-and-why-Coalition-may-scan-your-internet-facing-systems
- ProjectDiscovery Naabu documentation — https://docs.projectdiscovery.io/opensource/naabu/overview
- ProjectDiscovery Nuclei documentation — https://docs.projectdiscovery.io/opensource/nuclei/overview
- Nmap service and version detection — https://nmap.org/book/man-version-detection.html
Turn exposed-service discovery into monitored exposure management
ExternalSight helps teams scan internet-facing domains, identify exposed services, classify findings, generate remediation plans, compare scan history, receive alerts, export reports, and monitor verified domains on supported plans. Use it when exposed-service discovery needs to become a repeatable workflow instead of a one-time search.