Hosting and Nameserver History

datapulse_dns_dphistory returns a domain’s hosting and nameserver history: the dated versions of its web, mail and nameserver providers as observed in the DataPulse names corpus, served by the BON Search API.

What the data is

For every listed PSL+1 name the corpus keeps one record: the providers of four services (see Service Types). The history is the change log of that record, not a series of snapshots:

• The log begins on 2023-04-07, the initial snapshot. Every domain listed then has an a on that day. Nothing earlier exists for any domain.
• A version is written only when the record changes. A domain whose setup never changed has a single version, however popular it is (microsoft.com has one; wikipedia.org has two).
• Changes land mostly on the first of a month from 2024 on. A first listing (a) can fall on any day. Expect month granularity when dating a change.
• It holds no CNAME, A or AAAA records. Web hosting appears only as the ASN of the address the site resolves to, so CDN use is visible as an ASN (13335 for Cloudflare), not as a CNAME chain.

Parameters

Input handling

• Canonicalized, but no hostname reduction. This is a DNS tool: the name’s spelling is canonicalized (surrounding whitespace and every trailing dot removed, case folded, Unicode label separators read as dots, IDN folded to its A-label form) and the hostname level is kept. www.github.com and github.com are different lookups and answer differently. Only the RDAP tools (datapulse_live_rdap, datapulse_live_rdap_bulk, datapulse_dns_rdap_history) reduce a hostname to its registrable domain, because RDAP only knows registered names. When the IDN conversion or the trailing dot changed your input, the response carries submitted_domain with what you sent. The rules for every tool are in datapulse_help(topic="normalization").
• Which names are listed. Registrable domains, and names under registry-run private suffixes (microsoft.jp.net, uk.com), are corpus entries because each is a delegated zone. Hostnames under platform suffixes (octocat.github.io, foo.blogspot.com, app.herokuapp.com) are records inside the platform’s zone, not delegations, so the corpus answers found: false for them even when the site is live. Look up the platform’s own name (github.io) for the infrastructure behind them.
• A public suffix is looked up as it stands. co.uk, jp.net and github.io have their own records (they are delegated names with nameservers and, often, a website).
• A single label is rejected (com, localhost) with the validation library’s invalid domain error. So are IP literals, URLs and labels over 63 characters.
• A name the corpus never listed is answered, not errored: the API’s own envelope comes back with found: false and an empty Versions list, plus a hint as a second content item. Treat that as the answer “never listed”, not as an outage. An outage is an error carrying the BON Search API’s HTTP status and its body verbatim.

Response Format

{
  "query": "github.com",
  "datetime": "2026-09-16T22:11:02.84Z",
  "server_id": "bonsearch-1",
  "results": {
    "Name": "github.com",
    "Versions": [
      {"YMD": 20230407, "Type": "a", "Body": {"name": "github.com", "services": [...]}},
      {"YMD": 20260401, "Type": "c", "Body": {"name": "github.com", "services": [...]}}
    ]
  },
  "complete": true,
  "found": true
}

Version Types

These are DataPulse listing events, not registry events. a is not a registration date; it is when the name first passed the corpus quality gate, which may be long after registration. d is not a registry deletion; a de-listed domain is usually still registered and simply stopped resolving or functioning. For registry-side events use datapulse_dns_rdap_history; for how listing is decided see datapulse_help(topic="methodology").

Body

Every version’s Body has the same shape, whatever its Type:

{
  "name": "kevbo.org",
  "services": [
    {"type": "AW", "providers": [{"asn": 6181}]},
    {"type": "MX", "providers": [{"name": ["postoffice-ipv4.kevbo.org"], "asn": 6181}]},
    {"type": "OperationalNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]},
    {"type": "ReportedNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]}
  ]
}

• services is always an array. It is empty for every d, and for a c whose services all vanished (a de-listing in progress; the d follows on the next cycle). The API itself emits null or omits services in those cases; the tool normalizes them.
• providers[].name lists the hostnames grouped under one provider. It is absent for AW, which is an address, not a hostname.
• providers[].asn is the provider’s autonomous system number as a flat integer, absent when unknown. ASN operator names and countries are not included; the number is the fact.

Service Types

OperationalNS and ReportedNS normally agree. When they differ, the delegation and the zone’s own NS set have diverged: a nameserver migration in progress, or a stale delegation. That disagreement is itself a useful signal and is worth reporting.

Example: kevbo.org

{
  "query": "kevbo.org",
  "datetime": "2026-09-17T15:47:57.8Z",
  "server_id": "bonsearch-1",
  "results": {
    "Name": "kevbo.org",
    "Versions": [
      {"YMD": 20230407, "Type": "a", "Body": {"name": "kevbo.org", "services": [
        {"type": "AW", "providers": [{"asn": 10796}]},
        {"type": "MX", "providers": [{"name": ["mail-ipv4.kwhite.net"], "asn": 63949}]},
        {"type": "OperationalNS", "providers": [{"name": ["ns-204-a.gandi.net", "ns-227-c.gandi.net", "ns-228-b.gandi.net"], "asn": 209453}]},
        {"type": "ReportedNS", "providers": [{"name": ["ns-204-a.gandi.net", "ns-227-c.gandi.net", "ns-228-b.gandi.net"], "asn": 209453}]}]}},
      {"YMD": 20240405, "Type": "c", "Body": {"name": "kevbo.org", "services": [
        {"type": "AW", "providers": [{"asn": 10796}]},
        {"type": "MX", "providers": [{"name": ["mail-ipv4.kwhite.net"], "asn": 63949}]},
        {"type": "OperationalNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]},
        {"type": "ReportedNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]}]}},
      {"YMD": 20241001, "Type": "c", "Body": {"name": "kevbo.org", "services": [
        {"type": "AW", "providers": [{"asn": 6181}]},
        {"type": "MX", "providers": [{"name": ["mail-ipv4.kwhite.net"], "asn": 63949}]},
        {"type": "OperationalNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]},
        {"type": "ReportedNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]}]}},
      {"YMD": 20251001, "Type": "c", "Body": {"name": "kevbo.org", "services": [
        {"type": "AW", "providers": [{"asn": 6181}]},
        {"type": "MX", "providers": [{"name": ["postoffice-ipv4.kevbo.org"], "asn": 6181}]},
        {"type": "OperationalNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]},
        {"type": "ReportedNS", "providers": [{"name": ["aron.ns.cloudflare.com", "quinton.ns.cloudflare.com"], "asn": 13335}]}]}}
    ]
  },
  "complete": true,
  "found": true
}

Read it as: listed in the initial snapshot on Gandi nameservers; nameservers moved to Cloudflare by 2024-04-05; web hosting moved from AS10796 to AS6181 by 2024-10-01; mail moved onto the same AS6181 host by 2025-10-01. Each c carries the whole record, so the change is whatever differs from the version before it.

Example: a de-listing (fyrios.com)

"Versions": [
  {"YMD": 20260104, "Type": "a", "Body": {"name": "fyrios.com", "services": [
    {"type": "AW", "providers": [{"asn": 13335}]},
    {"type": "OperationalNS", "providers": [{"name": ["ns-cloud-d1.googledomains.com", "ns-cloud-d2.googledomains.com", "ns-cloud-d3.googledomains.com", "ns-cloud-d4.googledomains.com"], "asn": 15169}]},
    {"type": "ReportedNS", "providers": [{"name": ["ns-cloud-d1.googledomains.com", "ns-cloud-d2.googledomains.com", "ns-cloud-d3.googledomains.com", "ns-cloud-d4.googledomains.com"], "asn": 15169}]}]}},
  {"YMD": 20260201, "Type": "c", "Body": {"name": "fyrios.com", "services": []}},
  {"YMD": 20260301, "Type": "d", "Body": {"name": "fyrios.com", "services": []}}
]

Listed on 2026-01-04 with no mail; by 2026-02-01 nothing answered any more (the c with empty services), and on 2026-03-01 it left the corpus. Removal is confirmed on the cycle after the services vanish, so a domain can sit listed with an empty record for about a month. datapulse_help(topic="why_missing") walks through pairing this arc with datapulse_dns_rdap_history to find the registry-side reason (a hold, in this case).

Reading a Timeline: Known Noise

Not every c is a change the operator made. Check these before reporting one.

1. Anycast ASN churn. The same nameserver or MX hostnames are attributed to a different asn from one month to the next, because the address measured sits in an anycast or multi-homed network. co.uk’s nic.uk nameservers wander among five ASNs, producing about twenty c versions with no nameserver change; bbc.co.uk’s messagelabs MX hosts flip between AS16509 and AS396982. Compare hostnames first. An ASN-only difference with the same hostnames is a move only if it persists and the hostnames eventually change too.
2. One host, two ASNs. The same MX hostname can appear twice in one version under different ASNs (bücher.com) when its addresses were measured in two networks. It is one mail provider, not two.
3. The 2025-09-01 collection gap. Domains on Google Workspace mail (github.com, gfycat.com, hotbit.io and others) lost their alt1–alt4 aspmx.l.google.com hosts on 20250901 and regained them on 20251001. That is two spurious c versions per affected domain. Disregard a c on either date whose only change is the set of Google MX hosts.
4. A c with empty services is a de-listing in progress, not a configuration change (see the fyrios.com example).
5. Listing flap. A domain can alternate d / a month after month with the same providers throughout: microsoft.jp.net was de-listed and re-listed four times between 2025-12 and 2026-08, and each d followed a version that still had AW and OperationalNS. The check failed on something the record does not show; in two of the four cycles the version before the d had also lost ReportedNS, in the other two it had not. Read such a run as one unstable delegation, not as repeated outages and migrations, and do not date anything from the individual a and d entries.

Use Cases

• Infrastructure migration tracking. When did the site or the nameservers move, and from which network to which. Pair with datapulse_dns_rdap_history for the registrar-side dates of the same period.
• Email provider history. Which MX hosts and networks handled mail, and when they changed; the lead indicator for a tenant move (for example onto Microsoft 365 or Google Workspace).
• Corroborating a suspension or lapse. The a → c (empty) → d arc dates when a name stopped functioning; datapulse_help(topic="why_missing") covers the procedure.
• Provenance of infrastructure similarity. After datapulse_dns_dptechsim matches, the timelines show whether the shared setup is long-standing or recent.

Data Coverage

• Every corpus entry since 2023-04-07: registrable domains under ICANN suffixes and under registry-run private suffixes, plus delegated suffixes themselves; not hostnames under platform suffixes. See datapulse_help(topic="methodology").
• One version per change, mostly dated the first of a month from 2024 on; a first listing can be any day. There are no daily snapshots and no pre-2023 data.
• Web, mail and nameserver providers only, as hostnames and ASNs. No CNAME, A, AAAA, TXT or registrar data; no ASN operator names.