Hostnames and IP Addresses

A hostname in Stairwell is not a string inside a file. It is an entity with a history, a population, and links back to every file that mentions it -- the same shape as an object or an asset. So is an IP address.

That distinction is the whole point. Most tools can tell you a binary contained update-cdn.example.net. The questions that make that fact useful are all questions the string cannot answer: where did it point, when did it move, what else lived at those addresses, how many other files mention it, and which of my machines had any of them.

What is ActiveDNS?

ActiveDNS is Stairwell's longitudinal record of what hostnames resolved to over time. It is the system behind everything on this page, and it is broader than the files you have collected.

It holds more than 1.3 trillion resolutions, and it is indexed in both directions: forward, from a hostname to everything it has ever resolved to, and in reverse, from an address back to every hostname that has pointed at it. Both directions matter, and most of the work on this page is pivoting between them.

Every day, Stairwell resolves hundreds of millions of registered domains -- broadly, the registered domain space rather than a sample of it -- and records what came back. That daily sweep is the base layer, and it runs whether or not anybody has ever asked about a given name.

Layered on top of it are two narrower streams that go deeper than a domain's front door:

• Hostnames extracted from files. Stairwell's scanner pulls the hostnames written inside the executables, scripts, and documents it collects, and those specific names are resolved too. This is what puts evil-c2.example.com in the record, not just example.com.
• Curated threat intelligence, which contributes names that indicator feeds have flagged.

Two consequences fall out of the base layer, and they are the reason it exists.

A domain has a history even if it never appeared in one of your files. You are not restricted to names Stairwell happened to collect from your environment. Somebody forwards you a domain from a phishing email that never touched your fleet, and there is a resolution history waiting for it.

The history predates the question. By the time a domain is published as an indicator, it has usually been resolving -- or deliberately not resolving -- for months. That record already exists, because the sweep did not wait to be asked.

None of it is your network. Passive DNS observes traffic and records the resolutions it happens to see. ActiveDNS resolves names deliberately, on Stairwell's own infrastructure. There is no sensor, no packet capture, and no netflow anywhere in it, so it carries none of the deployment, privacy, or legal weight of network monitoring.

Resolution history

Every answer ActiveDNS has ever recorded for a hostname is a point in a timeline: the record type, the answer, and when it was seen.

Each distinct answer carries a first seen and a last seen, so a domain that moved shows both where it used to point and roughly when it stopped. Answers no longer returned are marked inactive rather than dropped, which is what makes an abandoned address readable months later.

Failed lookups are kept, not discarded. A name that answered NXDOMAIN for a year and then began resolving is a name somebody switched on, and the date of that transition is frequently the most useful fact available about it. A timeline that only recorded successes would silently delete it.

Two consequences worth internalising, because they are why history beats a live lookup:

• A domain that is dead today has a perfectly readable past. By the time an indicator is published, the infrastructure is often already gone. The current answer is nothing; the answer during the campaign is what your proxy and firewall logs need to be searched against.
• Abandoned addresses are indicators nobody wrote down. A report lists what its author saw. The addresses the domain used before that are usually absent from the report and frequently still hosting the rest of the operation.

The reverse index

ActiveDNS also maintains the inverse: given an IP address, which hostnames have resolved to it. That reverse index is what makes the corpus navigable rather than merely large -- a trillion forward answers you can only read one hostname at a time is a lookup table, not an investigative tool.

This is the pivot that turns one indicator into a footprint. Operators reuse infrastructure, so the other names parked on an address are often the rest of the campaign -- including names from earlier activity that was written up under a different label.

It is also how you avoid the most common false lead in infrastructure work. An address answering for a large number of unrelated domains is shared hosting, a parking service, or a sinkhole, and an indicator pointing there deserves far less weight than one pointing at an address answering for two names. Stairwell folds the names at an address to their registrable domain before counting, so a hundred subdomains of one company read as one tenant rather than a hundred. See What Is a Public Suffix? for why that fold is the right unit.

Hostnames are also indexed so that everything beneath a domain can be enumerated as a range. That is what lets a single hostname open out into the shape of the whole domain rather than just the one name you started with.

📘

Reverse lookups are IPv4 today, with IPv6 coming

Forward resolution already covers IPv6 in full -- AAAA answers are recorded and kept like any other, so IPv6 addresses appear in a hostname's history. The reverse direction currently indexes IPv4, so pivoting from an IPv6 address back to the names that have used it is not available yet. An empty result there is a coverage boundary rather than a quiet address.

Reverse IPv6 is on the way. If it matters to your work, talk to your customer success manager about the use cases you have in mind -- that feedback is what shapes the order this lands in.

The link back to files

This is the part that does not exist in a standalone passive DNS product, and it runs in both directions.

From a file to its infrastructure. The Embedded Data section of the object panel lists the hostnames and addresses found inside a file. Most infrastructure investigations start here.

From a hostname to the files that contain it. Every hostname carries the set of objects that reference it. That is the link from a published indicator back into your own environment: the report names a domain, and Stairwell already knows which files in your history mention it -- files you collected long before anyone said the domain was bad.

And a rarity count on top of it. Stairwell maintains how many objects reference a given hostname, and how many reference any name under its registrable domain. That is prevalence applied to infrastructure, and it does the same job: a domain appearing in three files is a lead, a domain appearing in three million is something the whole internet touches. Without it, an analyst pivoting from a file to its embedded hostnames drowns in microsoft.com before reaching anything interesting.

Chain the three and a single indicator becomes an exposure answer with dates: report names a domain → files in your environment that reference it → the sightings of those files → which assets had them, and when.

What this is not

It is not a record of what your machines connected to. ActiveDNS tells you where a name pointed and when it moved. It does not tell you that a host in your fleet talked to it. That distinction matters when you are writing up a finding: the evidence supports "this machine held a file referencing infrastructure that was live on these dates", not "this machine contacted it". For contact, you need your own network logs -- and the dates from here are what you search them for.

Resolution history is not attribution. Shared infrastructure, hosting providers, and CDNs put unrelated parties at the same address constantly. The reverse index is a lead generator, and the crowding at an address is the first thing to read before treating co-residency as a relationship.

What should I read next?

• Network Intelligence, for working with all of this in the product, including the API.
• What Is a Public Suffix?, for why the registrable domain is the unit that matters.
• Prevalence, for the same rarity logic applied to files.
• Objects, for the entity the hostnames are extracted from.