Five Days of Validin, Day 1: Where has your domain actually pointed?

I spend most of my time looking at organizations from the outside in. Before sending a single packet to one of my client’s systems, I want to know what the internet already knows about them. Where their domain has pointed. What subdomains exist that nobody remembers creating. What certificates have been issued in their name.

Validin is where I get most of that. It collects passive DNS, certificate transparency logs, WHOIS and RDAP records, and the responses web servers give when they are crawled. Then it lets you search and pivot across all of it. Passive is the important word. You are querying what has already been observed.

Nonprofits have real and often large attack surfaces. Websites built by volunteers. Vendors who came and went. A donation page stood up for a 2019 gala that is still online and still unpatched. Validin shows me all of it in an afternoon, without touching a single system.

The part that makes it useful to you and not just to me is the price. Community Edition is free. Fifty queries a month, over four years of DNS history, full certificate transparency, subdomain enumeration. That is enough to do real work.

Over the next five days I am publishing one command a day. Every one runs on the free tier, and the whole series costs about six of your fifty monthly queries.

The domain I am using, and why

Every example in this series runs against symbolics.com.

On 15 March 1985, symbolics.com became the first .com domain name ever registered. Symbolics Inc. was a spinout from the MIT Artificial Intelligence Lab that built Lisp machines, specialised computers for the artificial intelligence work of that era. The company went bankrupt in 1993. In 2009 the domain was sold to an investor who bought it specifically to preserve it rather than resell it, and it remains online today as a deliberate piece of internet history.

I picked it for four reasons.

Demonstrating on a real domain is far more useful than example.org, but pointing reconnaissance tools at a working nonprofit and publishing the results is not something I am willing to do. A preserved museum piece carries none of that problem.

It has forty years of accumulated history, so if these commands surface anything interesting, they will surface it here.

It changed owners, which makes it a live demonstration of a lesson I will come back to: when you acquire a domain, its history comes with it.

And its infrastructure genuinely resembles a small nonprofit’s. Self-hosted mail, a handful of subdomains, one modest hosting provider. Not a corporation with a security team.

To be clear about what follows: nothing I show you here is a criticism of that domain or its owner. Everything visible is ordinary for a small, long-lived, self-hosted setup. I am reading it the way I would read any domain, and the point is to teach you to read yours.

Setup, about ten minutes

Create the account. Go to app.validin.com/register. Name, organization, work email, password, and one sentence on how you plan to use it. Verify the email they send, then log in.

Create an API key. Click your name in the upper right, select Profile, then Manage Your API Keys. Click Add New Key. Give it a name and a description, because in four months you will not remember what it was for. Set validity to 180 days, the maximum. None of these can be changed after creation.

Copy the key into a password manager. Not a sticky note, not a shared spreadsheet, and not a chat message.

A note on platform. These commands are written for macOS and Linux. On Windows, run them in WSL. Everything also works by clicking in the Validin web interface, but I prefer the API, as it is scriptable, repeatable, and is way easier to document in your organization’s knowledge base than a series of web UI screenshots.

Test the key.

export VALIDIN_KEY="paste_your_key_here"

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/ping"

You get back exactly this:

{"status":"OK"}

If you get an authentication error, the usual causes are a stray space in the pasted key, or a terminal that turned straight quotes into curly ones.

The export line lasts only for your current terminal session.

Check what your key can do, and what it has cost you:

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/paths"

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/profile/usage"

The first lists every endpoint your account may call. The second returns your remaining allowance. Neither counts against your quota, so run them freely.

Put a calendar reminder at day 175 to rotate the key.

Today’s command

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/domain/dns/history/symbolics.com?limit=250&time_format=iso&exclude_nx=true"

Swap in your own domain when you run it for real.

In the web interface, the same data is under Global Search: type the domain, open the DNS section, switch to Timeline view.

limit=250 is the Community maximum, and a query costs the same whether you ask for 10 results or 250, so always ask for 250. time_format=iso gives readable dates instead of Unix integers. exclude_nx=true drops records of the domain failing to resolve, which are occasionally interesting and mostly noise.

What comes back

{
  "query_opts": {"limit": 250, "wildcard": false, "categories_exclude": ["NX"]},
  "query_key": "symbolics.com",
  "status": "finished",
  "records": {
    "A": [
      {"key": "symbolics.com", "value": "64.6.98.185", "value_type": "ip4",
       "first_seen": "2019-08-26T00:00:00Z", "last_seen": "2025-07-21T12:00:00Z"},
      {"key": "symbolics.com", "value": "216.24.57.1", "value_type": "ip4",
       "first_seen": "2025-07-21T12:00:00Z", "last_seen": "2026-08-10T12:00:00Z"}
    ],
    "NS": [
      {"key": "symbolics.com", "value": "ns1.amerinoc.com", "value_type": "dom",
       "first_seen": "2019-08-27T00:00:00Z", "last_seen": "2026-08-10T12:00:00Z"},
      {"key": "symbolics.com", "value": "ns2.amerinoc.com", "value_type": "dom",
       "first_seen": "2019-08-26T00:00:00Z", "last_seen": "2026-08-10T12:00:00Z"}
    ],
    "PTR": [
      {"key": "symbolics.com", "value": "46.175.145.127", "value_type": "ip4",
       "first_seen": "2024-04-18T18:00:00Z", "last_seen": "2026-02-27T12:00:00Z"},
      {"key": "symbolics.com", "value": "185.253.219.169", "value_type": "ip4",
       "first_seen": "2024-02-09T06:00:00Z", "last_seen": "2025-03-14T00:00:00Z"}
    ]
  },
  "records_returned": 6,
  "limited": false
}

Six records. Not everything is complicated.

Three things about the structure, because they apply to every command in this series.

records is an object keyed by record type, not a flat list.

limited tells you whether results were truncated. records_returned tells you how many you got.

The limit applies across all record types combined, so a domain with many A records can push its nameservers off the end. If you want nameservers specifically, append /NS to the same URL.

How to read it

Sort mentally by last_seen and ask three questions.

What is current? 216.24.57.1 has a last_seen of today, so that is where the site lives now. It should match what your hosting provider tells you. If it does not, either you have a stale record or your provider is wrong about their own infrastructure.

What ended, and when? 64.6.98.185 ran from 2019 to July 2025 and then stopped, the same day the new address started. That is a clean, deliberate migration with no overlap, which is what a well-executed cutover looks like from the outside.

Compare that with what a bad migration looks like: two providers answering for the same name in the same week. Look for overlaps in your own output. Concurrent dates across unrelated providers are either a migration you can name or a question you need to answer.

What nameservers have you used? Both point to amerinoc.com and have not changed since 2019. Stable DNS hosting across seven years. Every NS value is a company that had authoritative control over where the domain pointed, so a provider you thought you left is worth a phone call.

The part that surprised me

Look at the PTR group.

Those are reverse DNS records: two IP addresses, 46.175.145.127 and 185.253.219.169, whose reverse lookup pointed at symbolics.com. Neither is one of the addresses the domain actually resolved to.

Here is what that means. Forward DNS, where your domain points, is controlled by you. Reverse DNS, where an IP address claims its name is, is controlled by whoever holds that IP address. Anyone can configure a server’s reverse lookup to claim it is yournonprofit.org, and you have no say in it and no notification.

Most of the time this is harmless. It is often a hosting provider’s misconfiguration, a copied server template, or a leftover from an old arrangement. Occasionally it is someone deliberately borrowing a reputable name.

It matters because some systems still treat forward-confirmed reverse DNS as weak evidence of identity, and because if one of those machines does something unpleasant, your domain name is what appears in somebody’s logs.

This is not something you can fix, and that is the point. You cannot remove another party’s reverse DNS entry. What you can do is know it exists, so that when a log entry with your name on it arrives from an address you have never used, you have seen the pattern before and can say so.

I would not have gone looking for this. It fell out of one query on a forty-year-old domain, which is a decent argument for running the query.

What a bad result looks like

An address that stopped resolving but was never removed from your zone. If that IP is reassigned and your DNS still points at it, a stranger is serving content under your name.

Nameservers from a provider you no longer have an account with. That is a domain-hijack path.

A cluster of changes on a date nobody can explain.

Long gaps where the domain did not resolve. Usually a billing lapse, worth knowing, because an expired domain can be registered by someone else.

A note on domains you did not register first

This command finds something nothing else will: what your domain was doing before you owned it.

symbolics.com is the clearest possible case. It has had two owners across forty years, and everything the first one did is part of the record the second one inherited. Tomorrow’s post shows that history quite literally.

It matters because reputation systems have memory. Blocklists, spam filters, and categorization services remember what a domain used to do. If your organization bought a domain rather than registering a fresh one, and your email deliverability has been unexplainably poor, the years before you are worth reading.

What to do about it

Make a list. Every address and nameserver in the output, the dates it was active, and the person or vendor responsible. Anything you cannot attribute goes at the top. Then open your DNS control panel and compare.

That is one query out of your fifty.

Tomorrow, Day 2: everything on the internet carrying your name, including hostnames from a company that went bankrupt in 1993.