Methodology

How OpsCheck Tools Work

This page describes how OpsCheck tools process data, where computation happens, and what limits apply to results.

Tool Types: Browser-Side vs Server-Side

OpsCheck runs two classes of diagnostic tools:

Server-side tools — DNS lookups, SSL/TLS checks, WHOIS queries, port scans, email authentication checks, HTTP header analysis, and similar network diagnostics run entirely on the OpsCheck server. Your browser sends a request; the server performs the check against the target and returns results. Server-side processing ensures consistent results independent of your local network conditions.
Browser-side tools — Base64 encoding/decoding, hash generation, JSON formatting, URL encoding, timestamp conversion, and similar data-transform tools process input directly in your browser using JavaScript. Input never leaves your machine for these tools.

The tool page indicates the processing method. Server-side tools show a loading state while waiting for the backend response; browser-side tools produce results instantly.

Data Handling

How user input is processed depends on the tool type:

Browser-side tools: Input stays on your device. Nothing is transmitted to OpsCheck servers. No logs are created from these tools.
Server-side tools: The target domain, hostname, or IP you submit is sent to the OpsCheck server for processing. The server performs the diagnostic check against external infrastructure (DNS resolvers, target servers, WHOIS registries) and returns results.

OpsCheck does not store or log the specific inputs or results of individual diagnostic checks beyond what is needed for abuse prevention and rate limiting. Access logs are retained for a limited period per standard server practice.

Rate Limiting and Caching

Rate limits apply to server-side tools to prevent abuse and ensure fair access. Typical limits are 30 requests per minute per tool. Some tools use stricter limits depending on the cost of the external queries involved.

Results from some server-side tools may be cached for a short duration (typically 60-300 seconds, depending on the tool and the data source). Caching reduces load on external services and improves response times for repeated queries. Cache TTL values are documented on individual tool pages where caching applies.

Data Sources

OpsCheck tools rely on several external data sources:

DNS records: Queried in real time against public DNS resolvers using PHP native DNS functions. No third-party DNS API is used.
SSL/TLS certificates: Retrieved by opening a TLS connection to the target server using PHP streams (OpenSSL). Certificate chains are parsed from the connection handshake.
WHOIS data: Queried against IANA-registered WHOIS servers via port 43. Results reflect the current state of the registry and registrar databases.
IP geolocation: Uses a local GeoIP database. Accuracy depends on the database freshness and the nature of the IP range.
Blacklist checks: Queried against public DNS-based blacklists (DNSBL) in real time.
Vulnerability data (CVE/NVD): Retrieved from the National Vulnerability Database API. Results reflect NVD data availability and may have a delay from CVE publication.
Certificate Transparency logs: Queried via crt.sh API for certificate search functionality.
Email authentication (SPF/DKIM/DMARC): DNS TXT records are queried in real time. SMTP tests connect to the target mail server directly.

Result Limitations

Diagnostic results are subject to several limitations:

Cache TTL: Cached results may not reflect changes made in the last few minutes. If a DNS record or SSL certificate was just updated, wait for the cache to expire or check on a tool page with a lower cache TTL.
DNS propagation: DNS changes take time to propagate across the internet. OpsCheck queries from a single geographic location, so results may differ from what users in other regions see.
Network reachability: Firewalls, CDNs, geo-blocking, and network filtering between the OpsCheck server and the target may affect results. A port showing as closed from the OpsCheck server may be open from other locations.
Rate limiting by targets: Some target servers or DNS resolvers may rate-limit or throttle repeated queries from a single source IP.
Service availability: External data sources (WHOIS servers, NVD API) may be temporarily unavailable. The tool will report the failure rather than return stale data.
No security guarantee: Passing a check does not mean a system is secure. A valid SSL certificate does not guarantee the site is safe. A clean blacklist check does not confirm the IP has never been used maliciously. OpsCheck tools provide diagnostic signals, not security certifications.

Reporting Incorrect Results

If you receive results that appear incorrect, check the following before reporting:

Verify the input was entered correctly (domain spelling, IP format, port number).
Confirm the result using a different tool or method (command-line dig, openssl s_client, whois CLI).
Wait for caches to expire and try again — cached results may be stale.
Consider regional differences — DNS and network paths differ by location.

If the result still appears wrong after these checks, report it via the contact page. Include the exact input used, the expected result, and the result you received.

Article Review Process

Blog articles on OpsCheck are written by Nemanja Jeremić based on professional experience in Linux system administration and hosting infrastructure. Articles are technically reviewed before publication:

Command examples and configuration snippets are tested on real Linux systems.
DNS and networking examples are verified against live infrastructure where practical.
Security recommendations reflect current best practices and are reviewed against authoritative sources (RFCs, vendor documentation, OWASP guidelines).
Articles are updated when underlying technologies or practices change.

Article publication dates reflect the original publish date. Significant updates are noted in the article body. If you find an error in an article, report it via the contact page.