Five Days of Validin, Day 2: Everything with your name on it

Yesterday you looked at where a domain pointed. Today you find out what else exists under it.

Two commands, because they answer the same question from opposite directions and neither is complete on its own.

Command one: subdomains

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/domain/subdomains/symbolics.com?limit=250"

This endpoint applies wildcard: true by default, so you do not need to pass it.

Real output, complete:

{
  "query_opts": {"limit": 250, "wildcard": true, "key_only": true},
  "status": "finished",
  "query_key": "symbolics.com",
  "records": {
    "subdomains": [
      {"value": "symbolics.com"},
      {"value": "scrc.symbolics.com"},
      {"value": "stony-brook.scrc.symbolics.com"},
      {"value": "plantain.scrc.symbolics.com"},
      {"value": "mail.symbolics.com"},
      {"value": "ftp.symbolics.com"},
      {"value": "circles.symbolics.com"},
      {"value": "www.symbolics.com"}
    ]
  },
  "records_returned": 8,
  "limited": false
}

Set your expectations correctly: this returns names and nothing else. No dates, no addresses. The response runs in key_only mode. You get an inventory, not a timeline. To find out whether a name is still live, run yesterday’s DNS history command against that specific hostname.

Read that list again

scrc.symbolics.com was the Symbolics Cambridge Research Center. stony-brook and plantain are individual machines that sat inside it.

Symbolics went bankrupt in 1993. These are hostnames for research computers at a facility that stopped existing more than thirty years ago, and they are still discoverable today with one free query.

That is the entire thesis of this post, stated more dramatically than I could have arranged deliberately. Infrastructure does not clean itself up. Names outlive the machines, the departments, the vendors, and sometimes the companies. Somebody created stony-brook.scrc in the 1980s to do a job, that job ended, and the name is still here.

Your 2019gala.yournonprofit.org is the same phenomenon on a shorter timescale. So is the staging site your web contractor built in 2021 and never mentioned again.

The rest of the list is legible in the same way. mail. and www. are current. ftp. is a protocol most organizations retired years ago. circles. is a project name that meant something to someone once.

Why this finds things your DNS provider does not

Your zone file is what you have configured today. This is what the internet has observed over time, assembled from passive DNS and certificate transparency.

A subdomain appears here because somebody resolved it, or because a certificate was issued for it, even if it is not in your current zone. That includes names created by a vendor on their own infrastructure, names from a hosting account you closed, and names live for three weeks in 2019.

The imperfection runs the other way too. A name never publicly resolved and never certificated will not appear. This is a strong signal, not a complete inventory.

Command two: certificates

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/domain/certificates/symbolics.com?wildcard=true&limit=250"

Certificate Transparency is a public, append-only log of TLS certificates. Every publicly trusted certificate authority must publish what it issues. The point was to catch CAs issuing certificates they should not have. The side effect is that anyone can look up every certificate ever issued for any domain, including yours.

wildcard=true pulls in subdomains, which is where the interesting results live.

Leave time_format=iso off this one. It is ignored here. Outer timestamps come back as Unix integers, though the certificate dates nested inside are already ISO.

Real output, one record, trimmed:

{
  "query_key": "symbolics.com",
  "status": "finished",
  "records_returned": 148,
  "limited": false,
  "records": {
    "ctstream": [
      {
        "key": "symbolics.com",
        "value_type": "JSON",
        "first_seen": 1785628800,
        "value": {
          "timestamp": "2026-08-02T19:37:07Z",
          "update_type": "X509LogEntry",
          "common_name": "symbolics.com",
          "cert_issuer": "/C=US/O=Google Trust Services/CN=WE1",
          "issuer": {"C": "US", "O": "Google Trust Services", "CN": "WE1"},
          "not_before": "2026-07-10T17:09:15Z",
          "not_after": "2026-10-08T18:09:07Z",
          "details": {
            "fingerprint": "257033e1d1147c9a...",
            "fingerprint_sha256": "...",
            "domains": []
          }
        }
      }
    ]
  }
}

Records sit under records.ctstream, and the useful content is nested inside value. The details.domains array holds any additional names the certificate covers.

The duplication will alarm you if nobody warns you

148 records came back for four hostnames.

Two things cause this. Each certificate is logged twice, once as a PreCertEntry and once as an X509LogEntry. And CAs submit to multiple CT logs for redundancy, so the same certificate appears again from Google, Sectigo, TrustAsia, and others. In this output a single certificate showed up across five different logs.

Then multiply by renewal. These are 90-day certificates, so each hostname generates a fresh set four times a year.

Deduplicate on details.fingerprint_sha256. Two records with the same SHA-256 are one certificate seen twice.

Without knowing this you will badly overestimate how many certificates exist, and 148 is alarming enough to send someone looking for a breach that is not there.

What the certificates tell you that the subdomains did not

The certificate output covers symbolics.com, www.symbolics.com, ftp.symbolics.com, and circles.symbolics.com.

Compare that against the subdomain list. The historical scrc machines appear in subdomain data but hold no certificates, which is what you would expect for names that predate the web. And ftp. and circles. hold current, actively renewing certificates, which tells you they are live services somebody is maintaining, not just names in a zone file.

That comparison is the real technique. Names in certificates but not in your subdomain list usually mean a vendor holds a certificate for a name no longer pointed anywhere. Names in both are your live footprint. Names in subdomain data only are often historical.

All 148 records came from one issuer family, Google Trust Services. A single consistent issuer is a good sign: it suggests one automated system managing certificates rather than several people obtaining them ad hoc.

If you see several unrelated CAs, do not panic first. Content delivery networks rotate between certificate authorities as part of normal operation. Work out whether your CDN or host explains it before treating it as a finding. Most of the time it does.

Reading the combined picture

Print both lists and write the responsible person or vendor next to each name. That is the whole exercise and it is more useful than it sounds.

The names that matter most

Anything with dev, test, staging, uat, or demo. Built for convenience, not security. Often debug output, default credentials, or a copy of production data.

Anything with wp, wordpress, blog, or old. Unmaintained WordPress is the most reliable way into a small organization I know of.

Anything with vpn, remote, portal, admin, or login. These authenticate to something. If one exists you did not know about, find out what.

Anything following no naming convention you recognize.

What is expiring

Sort certificates by not_after. Anything inside 30 days you cannot account for is a Monday morning problem.

The failure mode is specific. A certificate on a service nobody watches expires. Visitors get a full-page browser warning saying the site is unsafe. If that is your donation page, you lose donations silently, because people who see a security warning do not call to complain.

Automated renewal made this rarer, not rare. It breaks when a validation method changes, when a DNS record moves, or when the person who set it up leaves and renewal notices go to a dead mailbox.

The one that deserves an afternoon

A wildcard certificate you cannot account for. A *.yournonprofit.org certificate is a skeleton key for every subdomain. One certificate, one private key, and whoever holds it can present a trusted certificate for any name under your domain.

If a wildcard exists and you cannot say which system holds the private key, that is a real finding.

What to do about it

For each unknown name: what is it, who set it up, is it still running. Yesterday’s command answers the third.

If it is dead, remove the DNS record and cancel the hosting. Leaving the record while the host disappears creates a dangling record, and when someone else claims that hosting resource they inherit your subdomain.

If it is live and nobody owns it, it needs an owner today or it needs to be switched off today.

If it belongs to a vendor, add it to your vendor list with a note about what happens when the contract ends. Most nonprofit vendor agreements say nothing about decommissioning, which is how the 2019 gala site is still online.

Then fix certificate notifications so expiry warnings go to a shared mailbox more than one person reads. That single change prevents most expiry outages I see.

The organizational fix

The technical fix is a cleanup project. The organizational fix is a rule: nothing gets a subdomain without a named owner and an end date.

That rule is free, it is one sentence in whatever passes for your IT policy, and it prevents the entire category. Small organizations cannot out-staff this problem. They can out-process it.

And if you need an argument for why it matters, stony-brook.scrc.symbolics.com is still resolvable thirty-three years after the company that built it filed for bankruptcy.

That is three queries out of your fifty.

Tomorrow, Day 3: the records that decide whether a stranger can send email as your executive director.