Technical Evidence Guide
Read DNS and TLS evidence without overclaiming.
DNS and certificate data are valuable relationship signals, but neither source should be treated as permanent proof of ownership or current exposure.
What a DNS answer tells you
DNS maps names to records through a distributed, cached system. An A or AAAA record connects a hostname to an address at the time of the answer. A CNAME points one name to another. MX and NS records describe mail routing and authoritative name service. TXT records carry purpose-specific text, including some domain-verification and email-policy values.
The answer is time-bound. Resolver cache, time to live values, split-horizon configurations and propagation delays can cause observers to receive different answers. Record the queried name, type, answer, resolver context and observation time together.
- An IP relationship does not by itself prove that one organization owns the address.
- A CNAME target can identify a service dependency without establishing account ownership.
- An absent record may be a temporary or observer-specific result.
- Historical DNS is evidence of a past relationship, not a permanent one.
What certificate evidence tells you
A certificate can show which names were covered, who issued it and the period for which it was intended to be valid. Certificate transparency can make issuance events publicly auditable. These facts help discover related hostnames and review change over time.
Certificate issuance does not prove that a service is currently reachable, that the certificate is currently deployed or that every listed name remains controlled by the same party. A certificate's validity dates also do not prove that a client will accept the complete TLS configuration.
- Keep the subject alternative names and issuer with the observation time.
- Separate certificate validity from live deployment status.
- Treat wildcard coverage as a naming scope, not a list of active hosts.
- Use current, authorized TLS validation before making remediation claims.
Correlate independent signals
Confidence improves when independent observations agree. A DNS answer, a matching certificate name and a consistent HTTP response may support the conclusion that a hostname served a particular application at a particular time. The conclusion should still remain bounded by those timestamps.
Conflicting signals are useful. They may indicate a migration, a shared service, a stale record or collection from different network locations. Preserve the conflict instead of forcing every source into one narrative.
A practical validation checklist
Before acting on DNS or TLS evidence, confirm that the activity is authorized and that the current target is the intended asset. Re-resolve the exact hostname, review the complete answer chain, check the active certificate and compare the result with the stored observation.
Document material differences. A changed IP, certificate or service response can close an old lead or reveal a transition that needs an owner.
- Use the exact hostname and record type.
- Capture UTC timestamps for every validation step.
- Record redirects and intermediary services.
- Avoid probing addresses that are outside the authorized scope.
- Recheck after DNS time to live and deployment windows have elapsed.