Connection Types

EMITS_TLS_FINGERPRINT, DMARC_REPORTS_TO, and DKIM_SIGNED_BY are seed-stage: the edge types are live but coverage is still small, so treat an empty result as no data rather than a negative finding.

Edge types come in two kinds, and the distinction changes how you write the query.

Physical edges are materialized on disk: the DNS, geo, and SPF sets, the WHOIS set except SAME_ORG_AS, and BELONGS_TO. An unanchored MATCH ()-[r:RESOLVES_TO]->() returns rows.

Virtual edges are synthesized at query time: everything else, including the routing set (ANNOUNCED_BY, ROUTES, HAS_NAME, BGP_NEIGHBOR, CONFLICTS_WITH, the ROA_* pair), the whole threat and attribution set, the DMARC/DKIM/TLS-fingerprint edges, SEEN_IN_CT, and the physical-infrastructure set. Two rules follow:

• Anchor the source node. An unanchored MATCH ()-[:LISTED_IN]->() returns zero rows. Anchor with a labeled {name: "..."} lookup and traverse in the documented direction.
• Write them as explicit single hops. A virtual edge inside a variable-length [*1..N] pattern silently returns nothing. Split multi-stage traversals with WITH.

A few virtual edges are real and traversable but do not appear in db.relationshipTypes(), because they are synthesized only when you anchor on one end: ROUTES (ASN → ANNOUNCED_PREFIX), HAS_NAME (ASN → ASN_NAME), and the taxonomy hop BELONGS_TO (FEED_SOURCE → CATEGORY). Anchor them and they work; count them globally and you get zero.

CALL db.schema() reports a traversalHints entry for each virtual edge type. See Best Practices for the full set of query rules.

CALL db.relationshipTypes() YIELD type, sourceLabels, targetLabels
RETURN type, sourceLabels, targetLabels ORDER BY type

db.relationshipTypes() lists every edge type with the source and target labels observed on it, and does not count against your quota. Checking it first — alongside db.labels() — is the fastest cure for silent empty results from a mistyped edge name.