Dial-Up Pools Hide in Residential Space: Detect Them Without Hard-Banning Customers

A datacenter blocklist will not catch a dial-up pool. The address is ordinary broadband: usage_type says DYN, the ASN is a consumer ISP, and geo looks like a real city. The only thing that changes is the tenant — a line that redials on demand, picks up a fresh address, and burns through hundreds of residential IPs a day before those same addresses go back to real subscribers.

That is the core idea: network type describes the pipe; dial-up pool describes how the pipe is being used right now. IP99 by ThreatHunter reports the latter as dialup_pool in risk.signals, with evidence_state and computed_at so you know whether the observation is still worth acting on.

What a dial-up pool is

A dial-up pool (Chinese ops slang: 秒拨 / miaobo, "per-second redial") is a set of ADSL or fibre lines that reconnect on demand. Each reconnect gets a new public address from the carrier — sometimes across many cities. One line can exhaust hundreds of legitimate residential addresses in a day. Later the same day, a normal household may inherit one of those addresses.

Related plumbing in the same market:

• Rotating residential proxies — SDK on a phone or router; the address belongs to a real subscriber and changes hands every few minutes.
• Hijacked exits — a device owned by a victim briefly sold as an exit (hijacked_proxy).
• VPN / cloud phone / cloud function exits — different signals (vpn, cloud_phone, cloud_service); different disposition.

None of these need to sit in datacenter space. That is why "block IDC ASN" and "allow DYN" both fail in opposite directions.

Why usage type cannot see them

network.usage_type answers "what kind of network is this?" For dial-up pools the honest answer is residential broadband (DYN). A residential allowlist has zero precision against this product; a datacenter denylist has zero recall. The mark is not on the address — it is in observed presence in proxy supply, and that observation ages out in minutes to hours.

So you need three things together:

1. A signal that the address is (or was) in that supply — e.g. dialup_pool and often proxy.
2. How fresh that observation is — evidence_state + computed_at.
3. A score that compresses freshness and strength of evidence — not "probability this IP is an attacker."

Live lookups (2026-10-22)

No key. Anonymous free quota is 500/day per client IP (60/min). Signed-in free is 5,000/day; overseas self-serve Pro starts at $29/mo for volume (mainland China: free + enterprise contract only).

# Active dial-up sample (public demo IP from IP99 docs; residential samples churn)
curl https://ip99.com/v1/ip/27.22.66.200

# Homepage example that used to carry dialup_pool — today proves expiry
curl https://ip99.com/v1/ip/1.197.213.232

# Datacenter control
curl https://ip99.com/v1/ip/8.8.8.8

# Your own egress
curl https://ip99.com/v1/ip

1) Active dial-up (mask last octet in tickets)

Captured ~2026-10-22 13:15 UTC. Displayed body masks the last octet; the curl above uses the full public demo address.

{
  "ip": "27.22.66.x",
  "computed_at": "2026-10-22T13:15:10Z",
  "evidence_state": "active",
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "admin_code": "420624",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 78,
    "level": "high",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Read it left to right: still DYN residential space; signals say dial-up pool + proxy presence, and hijacked_proxy warns the line owner may be a victim; evidence_state: active and a mid/high score mean the evidence is fresh and strong enough to step up — not that you have proven a human attacker.

2) Same product story, opposite clock: expiry

1.197.213.232 is a public homepage sample that older docs showed around score 62 with dialup_pool + proxy. Re-fetched the same day as the active sample:

{
  "ip": "1.197.213.232",
  "computed_at": "2026-10-22T13:14:56Z",
  "evidence_state": "none",
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": { "score": 0, "level": "none" }
}

Still DYN. Score 0 with evidence_state: none means no current verifiable evidence — a blind spot, not a permanent "clean" badge. Yesterday's dial-up exit must not permanently brand tomorrow's subscriber. IP99's slogan for this: every answer is a judgement that expires, not a permanent label.

3) Datacenter control

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

hosting (and mobile) are network attributes, not risk for scoring. Do not ban on them alone. crawler is benign and does not participate in scoring. IP99 has no Tor signal — do not invent one.

How to act on a dialup_pool hit

Official disposition guidance is generic, not a contract:

1. evidence_state first. active → the observation is current. stale → seen before, aged out to score 0; weak prior only. none → never seen here; do not treat as allowlist proof.
2. Step up, don't stop. Fresh proxy / dialup_pool on signup, coupon claim, or new-device login justifies CAPTCHA, second factor, delay, or rate limit — not a permanent IP or account ban on residential customers.
3. Read hijacked_proxy carefully. The handset or line owner is often a victim. Prefer challenge over account termination.
4. Store computed_at with the decision. When someone disputes a block, you need the observation time, not a naked "bad IP" tag.
5. Re-query at decision time. Dial-up and rotating residential evidence decays in minutes to hours. Caching a verdict across sessions recreates the false-positive gap the product is designed to close.

Score bands (same docs): 0 → do not stamp "clean"; 1–29 → log; 30–69 → verify rather than ban; 70–100 → decide by business cost, still preferring time-bounded controls on DYN.

DYN vs signals (the distinction that matters)

If your pipeline only branches on usage_type == IDC, you will miss this class entirely. If it permanently denylists every DYN that ever scored high, you will ban the next household that inherits the address.

Try it

curl https://ip99.com/v1/ip/27.22.66.200
curl https://ip99.com/v1/ip/1.197.213.232
curl https://ip99.com/v1/ip/8.8.8.8

Start at ip99.com or the English API reference at ip99.com/api. Before the next hard ban on a "residential" IP, ask: are you blocking a pool that redials — or the subscriber who gets that address an hour later?