A Practical Method for Domain and Infrastructure Recon

Domain and infrastructure reconnaissance becomes noisy very quickly when the method is backwards.

A broad search can return:

• hundreds of hostnames;
• historical IP addresses;
• certificate names;
• internet-facing services;
• technology labels;
• redirects;
• old DNS records;
• third-party scan results.

That volume can look impressive while making the original research question harder to answer.

A stronger workflow starts with a narrow target and widens in layers:

identity → DNS → certificates → HTTP behavior → technology signals → historical context → broader exposure data → corroboration → stop

The objective is not to construct the largest possible asset map.

It is to produce the clearest defensible answer to a defined question.

---

Start by defining the object of research

The word "domain" can refer to several different things in practice.

For example:

example.com
www.example.com
app.example.com
192.0.2.10
https://example.com/login

are related but different research objects.

Before collecting anything, define the target precisely.

Record:

• apex domain;
• hostname;
• URL if the question concerns web behavior;
• organization if relevant;
• timestamp;
• research question.

Example:

Has old.example.com been migrated to a newer public service?

is a much better starting point than:

Investigate example.com.

The first question tells you which evidence matters.

The second encourages uncontrolled expansion.

---

Domain identity is not organizational ownership

A domain name is a technical identifier.

Its existence does not automatically prove:

• which legal entity operates it;
• which company owns the infrastructure behind it;
• who controls every associated hostname;
• whether historical infrastructure is still current;
• whether third-party services belong to the organization.

A useful discipline is to separate:

Technical relationship

Example:

old.example.com redirects to www.example.net.

Organizational interpretation

Example:

Company A migrated its web platform to Company B.

The redirect supports the first statement directly.

The second requires organizational evidence.

This distinction should remain visible throughout infrastructure research.

---

Build the investigation in layers

Each infrastructure source sees a different part of the public surface.

Do not collapse them.

Layer 1 — Current DNS

Question:

What does the domain publish in DNS now?

Layer 2 — Certificate transparency

Question:

Which certificate names have been publicly logged in relation to this namespace?

Layer 3 — HTTP behavior

Question:

What does the public web endpoint do when requested now?

Layer 4 — Technology signals

Question:

Which public delivery, platform or framework signals are observable?

Layer 5 — Historical DNS and web evidence

Question:

How did these signals differ over time?

Layer 6 — Broader internet-facing observations

Question:

Do larger passive datasets provide relevant host or service context?

The layers reinforce one another.

They do not replace one another.

---

Step 1 — Establish the current DNS baseline

DNS is often the cleanest first technical layer.

For a domain, useful records can include:

• A;
• AAAA;
• NS;
• MX;
• TXT;
• CAA.

Depending on the research question, other record types may also matter.

The initial objective is not exhaustive enumeration.

It is to understand the current published baseline.

A and AAAA

These map a hostname toward IPv4 and IPv6 addresses.

Useful observation:

www.example.com resolved to IP X at time Y.

Do not immediately conclude:

IP X belongs to Example Company.

The address may belong to:

• CDN;
• cloud provider;
• shared host;
• reverse proxy;
• managed platform.

Resolution is a technical relationship.

Ownership requires another evidence layer.

NS

Nameserver records can reveal which DNS infrastructure is authoritative for the domain.

This can suggest:

• managed DNS provider;
• hosting relationship;
• migration.

But many unrelated organizations use the same DNS provider.

Do not treat common infrastructure as organizational linkage.

MX

Mail exchangers identify where mail for the domain is directed.

They can reveal:

• hosted email platform;
• mail security gateway;
• outsourced mail infrastructure.

Again:

mail routed through provider X

is not equivalent to:

provider X owns the organization.

TXT

TXT records can expose useful public configuration, including:

• SPF;
• domain-verification tokens;
• service-verification records;
• miscellaneous application metadata.

TXT is flexible.

That means interpretation must be specific to the actual record.

Do not treat every verification token as current proof of a live service.

CAA

CAA records allow domain holders to express which certificate authorities may issue certificates for the domain.

They add useful certificate-policy context.

Absence does not mean certificates are untrusted.

It means no CAA restriction was observed at the relevant lookup point.

---

What the OSINT.dev DNS Inspector currently does

OSINT.dev's native DNS / MX / SPF / DMARC Inspector performs direct DNS resolution for a submitted public domain.

The current runner resolves:

• A;
• AAAA;
• MX;
• NS;
• TXT;
• CAA;
• TXT at _dmarc.<domain>.

It also extracts:

• the first SPF record beginning v=spf1;
• the first DMARC record beginning v=DMARC1;
• the DMARC p= policy when present.

The tool is deliberately narrow.

It does not currently provide:

• historical DNS;
• passive DNS at internet scale;
• subdomain enumeration;
• WHOIS history;
• ASN mapping;
• certificate transparency;
• service scanning.

That separation is useful.

Current DNS is one evidence layer.

Historical and broader infrastructure data belong to other tools.

---

Step 2 — Use certificate transparency to widen hostname awareness

Certificate Transparency creates publicly auditable logs of TLS certificate issuance or observation.

RFC 9162 defines Certificate Transparency Version 2.0 as a protocol for publicly logging TLS certificates in a way that allows auditing of certificate-authority activity and suspicious issuance.

For infrastructure research, CT data can reveal names that appeared on certificates.

Examples:

www.example.com
api.example.com
support.example.com
old.example.com

This can generate valuable hostname hypotheses.

What a certificate name supports

A certificate record can support:

This DNS name appeared in publicly logged certificate material.

It does not automatically prove:

• the hostname is currently active;
• the hostname resolves now;
• the organization still operates it;
• the service was publicly reachable;
• the certificate was used in production.

Certificate history is excellent discovery evidence.

It is not a current asset inventory.

---

crt.sh as a certificate-transparency discovery tool

crt.sh is one of the most practical interfaces for searching Certificate Transparency data.

Use it when the question is:

Which certificate names have been publicly associated with this domain namespace?

A good workflow is:

1. query the known domain;
2. extract relevant names;
3. normalize and deduplicate;
4. classify names as candidates;
5. verify only candidates relevant to the research question using current DNS or other passive evidence.

Do not turn:

certificate name

directly into:

confirmed active asset

The state transition should be:

CT observation
→ hostname candidate
→ current verification
→ contextual interpretation

---

Wildcards require careful interpretation

Certificate names can include wildcard forms such as:

*.example.com

A wildcard does not enumerate every actual subdomain.

It indicates certificate coverage for names matching the wildcard rules.

Do not expand:

*.example.com

into an invented list of hostnames.

Certificate evidence should generate questions, not fabricate assets.

---

Step 3 — Verify relevant hostname candidates

Once CT or another source produces hostnames, validate only those relevant to the investigation.

Questions include:

• Does the hostname resolve now?
• Which address does it resolve to?
• Does the target return an HTTP response?
• Does it redirect elsewhere?
• Is the hostname still referenced by the current website?
• Is it present in historical data only?

This is where narrow native tools become useful.

Do not automatically check every possible endpoint.

The research question should control which candidates advance.

---

Step 4 — Read HTTP behavior as a separate layer

A hostname can resolve without serving the public web behavior you expect.

HTTP adds information such as:

• response status;
• redirect chain;
• final hostname;
• selected headers;
• cookies;
• content type.

A redirect can reveal relationships invisible in DNS.

Example:

old.example.com
→ 301
www.example.net

DNS explains how the first hostname resolves.

HTTP explains what the public service tells the client to do.

Those are different observations.

---

Redirects are especially useful during migrations

Common patterns include:

http → https
apex → www
old domain → new domain
legacy path → new path
application → identity provider
campaign link → tracking provider → destination

These can help reconstruct:

• canonicalization;
• rebranding;
• service separation;
• platform migration;
• third-party routing.

But the redirect itself does not reveal motive.

A 301 from an old domain to a new one is evidence of a routing relationship.

It is not a legal merger document.

---

What the OSINT.dev Redirect Inspector currently does

The native Redirect Chain & Response Inspector performs server-side GET requests and follows HTTP redirects manually.

For each hop it records selected fields including:

• status;
• Location;
• next URL;
• Server;
• Cache-Control;
• Content-Type;
• approximate Set-Cookie count.

The current runner:

• validates public URLs;
• re-validates each redirect destination against public-address safety controls;
• detects redirect loops;
• stops on malformed Location;
• uses a configurable hop limit;
• performs GET-only tracing.

It does not execute JavaScript.

So:

no HTTP redirect observed

does not prove:

a browser cannot navigate elsewhere after JavaScript execution.

The scope of the observation should remain explicit.

---

Step 5 — Fingerprint the public delivery layer conservatively

Technology fingerprints can help answer questions such as:

• Did the public frontend change?
• Is a CDN visible?
• Does the page expose framework-specific assets?
• Is the current delivery path consistent with historical observations?

Useful signals include:

• response headers;
• generator metadata;
• asset paths;
• page-source patterns.

The key is confidence.

A technology fingerprint is a hypothesis supported by public signals.

It is not a guaranteed inventory of hidden backend components.

---

BuiltWith: current and historical technology context

BuiltWith provides current and historical website technology information and related metadata through its products and APIs.

This makes it useful when the question concerns:

• technology migration;
• analytics or platform adoption;
• historical integration changes;
• corroboration of a current fingerprint.

BuiltWith also offers technology change data over time.

That can help compare:

technology detected now

with:

technology previously detected.

Treat BuiltWith as an observation dataset with its own collection methodology.

A BuiltWith label is not the same evidence as a directly observed response header.

Agreement across different channels increases confidence.

---

What the OSINT.dev Tech Stack Snapshot currently does

OSINT.dev's native Tech Stack Snapshot performs a conservative single-response fingerprint.

The current runner:

• validates a public HTTP/HTTPS URL;
• performs a server-side GET;
• does not automatically follow redirects;
• limits response-body size;
• inspects selected response headers;
• parses meta name="generator";
• checks selected framework and CMS patterns;
• returns confidence levels for each signal.

Current recognizable patterns include selected signals associated with:

• Cloudflare;
• Vercel;
• CloudFront;
• Fastly;
• Akamai;
• Next.js;
• Nuxt;
• WordPress;
• Ghost;
• Shopify;
• Wix;
• Squarespace;
• Astro;
• SvelteKit;
• React;
• Vue.

It does not currently identify:

• databases;
• private APIs;
• hidden origin infrastructure;
• package vulnerabilities;
• complete JavaScript runtime behavior.

Use it as a small explainable fingerprint, not an omniscient scanner.

---

Step 6 — Add historical DNS context

Current DNS tells you about now.

Historical DNS can help answer:

• Did the domain previously resolve elsewhere?
• Did MX providers change?
• Did nameservers change?
• Did a hostname move between address ranges?
• Does a migration hypothesis have a timeline?

SecurityTrails currently exposes APIs for DNS history and broader domain-related information.

A historical record should be described with time.

Prefer:

SecurityTrails records show A record X during period Y.

over:

The domain uses X.

Historical observation and present state are not interchangeable.

---

SecurityTrails: history is context, not current truth

A historical dataset can contain records that are no longer operational.

This is precisely why it is useful.

It helps reconstruct change.

But it also creates a common failure mode:

old IP → analyst treats it as current origin.

Avoid that.

Use state labels such as:

current
historical
candidate
unverified

A good infrastructure timeline preserves those distinctions.

---

Step 7 — Use broader internet datasets only when the question justifies it

At some point, the investigation may require a wider view.

Examples:

• Is a host exposing other internet-facing services?
• Does an IP have service observations relevant to this case?
• Is the infrastructure clue isolated or part of a larger public pattern?
• Which observed service fields provide corroborating context?

This is where Censys can become useful.

The Censys Platform maintains structured records of internet-facing hosts and services and supports search across its current dataset.

The important word is:

observed.

A Censys result is an observation from Censys' collection system.

It is not the same thing as a live measurement you personally just performed.

---

Censys: broader exposure context

Censys is strongest when you already know why you need broader internet-facing context.

Useful evidence can include:

• host observations;
• service fields;
• DNS names;
• certificates;
• software-related context;
• protocol information.

Do not start with:

Search the whole internet for everything related to this company.

Start with:

I have candidate IP X from evidence Y. Does Censys contain relevant observations that help answer question Z?

This keeps the dataset subordinate to the investigation.

---

Current record does not mean permanent state

Censys' current Platform host dataset represents current internet-facing host records according to its collection system.

That still does not mean:

• every service is reachable at the exact moment you read the record;
• every field is complete;
• the organization owns the IP;
• every service belongs to the same application.

Attach the observation time and collection source to the finding.

---

Step 8 — Use urlscan.io as a web-observation dataset

urlscan.io provides current and historical web-scan results.

Its result data can include:

• requests;
• responses;
• page metadata;
• domains;
• IP addresses;
• redirects;
• cookies;
• derived fields.

This can provide a useful third-party view of a page at another point in time.

It is especially valuable when:

• current behavior changed;
• you need to corroborate a technology clue;
• you want to inspect previous public requests;
• a historical scan captured third-party domains.

But scan visibility matters.

urlscan supports:

• public;
• unlisted;
• private

visibility modes.

Do not submit sensitive investigation URLs publicly without understanding those settings.

---

urlscan observation is not organizational ownership

A scan may show requests to:

analytics.vendor.com
cdn.vendor.net
api.thirdparty.example

Those domains can represent:

• analytics;
• advertising;
• content delivery;
• embedded widgets;
• authentication;
• customer support.

A request relationship is not automatically corporate ownership.

The safe statement is:

The scanned page requested resource X from domain Y.

The organizational meaning requires another evidence layer.

---

Step 9 — Add historical web context

Wayback Machine can help answer:

• Did the hostname previously contain content?
• Did branding change?
• Did the legal footer change?
• Did the URL structure change?
• Was a redirect destination previously different?
• Did the site once expose technology clues no longer present?

Historical captures can be powerful when combined with:

• DNS history;
• CT history;
• current redirects;
• current technology fingerprints.

They are not complete archives.

A missing capture does not prove the page did not exist.

---

Build a timeline instead of a flat asset list

Infrastructure analysis improves dramatically when time becomes a first-class field.

Instead of:

example.com
IP A
IP B
Vercel
WordPress
Next.js
old.example.com

build:

Now the data tells a story.

It can support a migration hypothesis.

A flat list cannot.

---

Evidence states prevent accidental overclaiming

Use explicit state labels.

Observed

Directly present in the source.

Example:

api.example.com appears in CT record X.

Candidate

Worth checking, not yet validated.

Example:

CT name may represent a historical or current hostname.

Current

Confirmed through a current relevant source.

Example:

hostname resolves today.

Historical

Supported only for a previous period.

Example:

historical A record from 2024.

Inferred

Analytical interpretation.

Example:

pattern is consistent with platform migration.

Rejected

Candidate investigated and found irrelevant.

Example:

similarly named domain belongs to unrelated organization.

This state model makes automation and collaboration safer.

---

Independence of sources matters

Three tools returning the same fact are not necessarily three independent confirmations.

Example:

• Tool A reads CT logs.
• Tool B also reads CT logs.
• Tool C republishes Tool A's dataset.

All three return:

api.example.com

You have repeated one evidence source.

Not three independent observations.

Stronger corroboration might be:

1. CT record;
2. current DNS resolution;
3. current HTTP response;
4. historical web capture.

Different layers reduce shared-source dependence.

---

Distinguish discovery from attribution

Infrastructure research often finds things.

Attribution is the harder step.

Discovery:

IP X appears in historical DNS for hostname Y.

Attribution:

IP X was controlled by Organization Z.

The first may be well supported.

The second may require:

• provider records;
• official documentation;
• legal ownership data;
• ASN context;
• historical evidence.

Do not let a discovery graph silently become an ownership graph.

---

Shared infrastructure creates false relationships

Many domains share:

• CDNs;
• cloud hosts;
• nameservers;
• analytics providers;
• hosting IPs;
• certificate authorities.

Shared infrastructure is often low-specificity evidence.

Example:

Domain A
Domain B
→ same Cloudflare IP

does not imply:

Domain A and Domain B are operated by the same organization.

That inference would be especially weak on highly shared edge networks.

Ask how discriminating the signal is.

---

ASN evidence has limits too

An IP can belong to an ASN operated by a cloud or transit provider.

That tells you about routing and network ownership.

It does not necessarily identify the application owner.

Useful statement:

IP X is announced by ASN Y.

Unsafe statement:

Organization Y operates the website's business application.

Network ownership and service ownership are different layers.

---

A worked example: reconstructing a web migration

Research question:

Did oldbrand.example migrate its public website to newbrand.example, and what changed technically?

Phase 1 — current HTTP

Request:

https://oldbrand.example

Observation:

301 → https://newbrand.example/

Finding:

The old domain currently advertises the new domain as a permanent redirect destination.

Phase 2 — current DNS

Old domain:

A → CDN address

New domain:

A → managed hosting platform

This suggests different delivery infrastructure.

It does not prove the old backend no longer exists.

Phase 3 — certificate transparency

CT records show:

www.oldbrand.example
portal.oldbrand.example

historically.

Those become candidate historical hostnames.

Do not automatically probe all of them.

Check only what is relevant to the migration question.

Phase 4 — historical DNS

SecurityTrails shows the old domain previously resolving to another provider.

Now there is a timeline:

old provider
→ CDN
→ redirect to new domain

Phase 5 — technology context

BuiltWith historical data suggests WordPress-oriented technology in an earlier period.

Current OSINT.dev Tech Stack Snapshot sees:

Next.js
Vercel

with current public signals.

Phase 6 — web archive

Wayback captures show old branding and old URL structure.

Current page uses new branding and route structure.

Calibrated conclusion

A defensible summary is:

Current HTTP behavior, historical DNS, certificate records, archived pages and current technology signals are consistent with a migration from the legacy oldbrand.example web presence to newbrand.example, accompanied by a change in the publicly visible delivery/frontend stack.

Avoid:

The company moved every internal system from WordPress to Vercel.

The evidence describes the public web surface.

---

A second worked example: a suspicious hostname

Suppose CT reveals:

admin.example.com

Do not assume:

exposed admin panel.

Use a disciplined sequence.

Observation

Hostname appeared in certificate data.

Question

Is this hostname relevant to the current public surface?

Passive verification

Check current DNS.

Possible result:

NXDOMAIN

Now the finding is:

Historical certificate evidence exists, but the hostname did not resolve during the current check.

That may already answer the question.

Do not escalate simply because the word admin is interesting.

---

A third worked example: IP reuse

Historical DNS shows:

example.com → 203.0.113.10

years ago.

Current research shows another unrelated domain on the same IP today.

Do not infer:

the two organizations are linked.

Hosting IPs are reused.

Time matters.

The correct finding is:

The historical DNS record connected example.com to IP X during period Y. Current observations of IP X describe a later state and should not be treated as evidence of a contemporaneous relationship.

This is why infrastructure analysis should always carry timestamps.

---

Common mistakes

Mistake 1 — Starting with the broadest platform

You collect data before defining relevance.

Mistake 2 — Treating CT as a current asset inventory

Certificate names can be historical or inactive.

Mistake 3 — Treating historical DNS as current truth

State changes.

Mistake 4 — Treating current DNS as ownership proof

CDNs and cloud services create indirect relationships.

Mistake 5 — Treating shared infrastructure as organizational linkage

Common providers are weak discriminators.

Mistake 6 — Treating a technology label as backend proof

Public fingerprints describe visible layers.

Mistake 7 — Treating third-party scan data as live measurement

Record source and timestamp.

Mistake 8 — Ignoring source dependence

Three tools may repeat one underlying dataset.

Mistake 9 — Expanding every discovered hostname

Discovery does not create analytical necessity.

Mistake 10 — Mixing historical and current data in one flat list

Build a timeline.

Mistake 11 — Converting candidate assets into confirmed assets automatically

Use explicit state transitions.

Mistake 12 — Forgetting the original question

Infrastructure graphs can grow indefinitely.

---

A repeatable domain and infrastructure workflow

Use this sequence.

1. Define the research question

One sentence.

2. Record the exact starting target

Apex domain, hostname or URL.

3. Establish current DNS

Capture relevant records and timestamp.

4. Use CT for hostname discovery

Classify names as candidates.

5. Verify only relevant candidates

Use current DNS and ordinary public behavior.

6. Trace HTTP behavior

Capture redirects and final destination when relevant.

7. Collect conservative technology signals

Keep layer and confidence explicit.

8. Add historical DNS

Separate historical from current state.

9. Add broader host/service context only when justified

Use Censys or similar datasets with a clear question.

10. Add urlscan or archive observations

Use dated third-party web evidence for corroboration.

11. Build a timeline

Do not maintain a timeless asset pile.

12. Label evidence state

Observed, candidate, current, historical, inferred, rejected.

13. Corroborate important relationships through independent layers

Avoid false confidence from duplicated data sources.

14. Preserve the evidence that supports the conclusion

Record source, time and interpretation.

15. Stop

When the research question is answered, stop expanding.

---

Related OSINT.dev tools

crt.sh

Use for certificate-transparency discovery.

Best for:

• public certificate names;
• historical certificate context;
• hostname candidates.

Do not treat CT names as current assets automatically.

SecurityTrails

Use for:

• DNS history;
• domain context;
• change over time.

Keep historical state separate from current state.

Censys

Use for broader internet-facing host and service observations when the research question needs them.

Treat records as Censys observations, not universal current truth.

BuiltWith

Use for current and historical web-technology context.

Corroborate technology claims through independent signals.

urlscan.io

Use for current or historical third-party web-scan context.

Review scan visibility before submitting URLs.

DNS / MX / SPF / DMARC Inspector

Use OSINT.dev's native runner for the current DNS baseline.

Redirect Chain & Response Inspector

Use it to document current HTTP redirect behavior hop by hop.

Tech Stack Snapshot

Use it for a small explainable fingerprint of the current public response.

Wayback Machine

Use historical public captures to add page and branding context to infrastructure changes.

---

The core principle

Infrastructure reconnaissance is strongest when every widening step has a reason.

Use this progression:

known target → current DNS → certificate candidates → current verification → HTTP behavior → public technology signals → historical context → broader exposure data → corroboration → timeline → conclusion

Each source should answer a specific question.

Each candidate should have a state.

Each relationship should have provenance.

Each historical observation should have time.

The goal is not to discover everything connected to a domain.

The goal is to understand the smallest relevant public infrastructure story that the evidence can actually support.

---

References

Primary standards and official product documentation used in this guide:

• RFC 1034 — Domain Names: Concepts and Facilities
  https://www.rfc-editor.org/rfc/rfc1034.html

• RFC 1035 — Domain Names: Implementation and Specification
  https://www.rfc-editor.org/rfc/rfc1035.html

• RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record
  https://www.rfc-editor.org/rfc/rfc8659.html

• RFC 9162 — Certificate Transparency Version 2.0
  https://www.rfc-editor.org/rfc/rfc9162.html

• RFC 9110 — HTTP Semantics
  https://www.rfc-editor.org/rfc/rfc9110.html

• Censys — Platform API and documentation
  https://docs.censys.com/

• Censys — Platform Quick Start Guide
  https://docs.censys.com/docs/platform-quickstart-guide

• SecurityTrails — API Overview
  https://docs.securitytrails.com/docs/overview

• SecurityTrails — DNS History by Record Type
  https://docs.securitytrails.com/reference/dns-history-by-record-type-old-1

• BuiltWith API — current and historical technology information
  https://api.builtwith.com/

• BuiltWith Change API — detected technology changes over time
  https://api.builtwith.com/change-api

• urlscan.io — Result API
  https://docs.urlscan.io/pages/result-api-reference

• urlscan.io — Scan Visibility Levels
  https://docs.urlscan.io/pages/visibility

• Internet Archive — Wayback Machine
  https://web.archive.org/