TDengine: 3,216 title matches, no application fingerprint, and an empty port check

Time-series databases are the layer that holds measurements: sensor readings, metrics, device telemetry. TDengine is a purpose-built option for that workload, and its online profile illustrates a measurement problem that repeats across database products. The most useful result is one of the zeros.

The counts

ZoomEye queries on 23 October 2026, sub_type=all, page size one, matched totals:

• title="TDengine": 3,216
• app="TDengine": 0
• title="TDengine" && port="6041": 0
• title="TDengine" && port="6030": 0
  Two of those lines returned zero, and both deserve interpretation rather than dismissal.

Why a zero fingerprint is not an absent product

The app field matches ZoomEye's own application fingerprints, which are derived from protocol and banner evidence the crawler has learned to recognise. A product with a REST interface that returns a generic JSON error before an application-specific banner, or a product that speaks a binary protocol with no identifying handshake, may simply have no fingerprint.
Three thousand two hundred and sixteen title matches establish that the product is deployed and reachable. Zero fingerprint matches establish that ZoomEye's recognition layer does not identify it as TDengine. The two statements are compatible, and the second one is the more useful insight for anyone building a query.

Why the port checks returned nothing

TDengine's default ports differ by protocol: a native connection port and a REST port, plus configuration that operators routinely change and container orchestrators remap. A deployment behind a reverse proxy may present the title on 443 and never expose the default port at all.
A zero on a specific port combination tells you that no crawled asset presented both the title and that port at the same moment. It says nothing about whether TDengine runs on 3,216 hosts, some of which may well be listening on those ports behind a different presentation.

What is at stake in a time-series database

The content of a metrics store is a description of an operational environment. Device identifiers, location fields, measurement names, tag values and timestamps are all present. In industrial deployments those tags describe physical assets; in application monitoring they describe services and sometimes users.
The access model matters more than the data volume. Many time-series deployments were designed for an internal network where every client is trusted, with authentication added later or delegated to the network layer. A reachable instance may answer queries without a credential because that was the assumption it was built under.
The write path deserves equal attention. A store that accepts writes from an unauthenticated source can be polluted. For a monitoring system that triggers alerts, injected measurements are a way to suppress a real incident or manufacture a false one.

Reading the 3,216 correctly

A title match is a strong signal and a weak description. It confirms the crawler saw a page that names the product. It does not distinguish an administrative UI from a documentation mirror, a demo instance, or an error page that echoes a product name.
Applied to an inventory, that means the count is useful for the question "is this product visible on the public internet at a scale that warrants attention", and not for "how many of our instances are exposed". The second question requires internal records and a network map.

What to check internally

• List every TDengine deployment and the network path to each. Container orchestration makes this harder than a server inventory, because a service name may resolve to a load balancer with a public address.
• Verify authentication is enforced at the database, not only at the network boundary. A security group is a good control and a poor substitute for credentials.
• Separate read from write. Where the platform supports role separation, giving a reporting tool read-only credentials reduces the value of a leaked connection string and the risk of a polluted dataset.
• Check the retention and replication configuration. A store with no replication loses data on failure, and a store with wide replication spreads the impact of a compromised node.

Detection notes

Query patterns are observable. A reporting client issues regular, predictable queries; an unfamiliar client enumerating measurement names and tag values looks different. Where the deployment writes query logs, that distinction is worth a rule.
Ingest anomalies are the second signal. A sudden change in the cardinality of tag values, or writes from an address that is not one of the collection agents, is both an availability risk and, in industrial contexts, a data integrity question.

Measurement summary

The value of the ZoomEye numbers here is the demonstration that a product can be widely reachable and poorly fingerprinted at the same time. An index that recognises the product by name finds it; an index that looks for a protocol signature finds nothing, and an index that assumes a default port finds nothing either. Building an inventory on any single one of those queries would produce a false sense of coverage.

References

• TDengine documentation: https://docs.taosdata.com/
• TDengine project repository: https://github.com/taosdata/TDengine
• ZoomEye queries executed 23 October 2026 with sub_type=all: title="TDengine" 3,216; app="TDengine" 0; title="TDengine" && port="6041" 0; title="TDengine" && port="6030" 0