One Field Sorts Datacenter From Human, Until Your Customer Rents a Server

A walkthrough published on dev.to argues that a single field on an autonomous system record, `type`, sorts almost any IP address into three buckets: datacenter traffic, an organization, or a real person on a home connection ^[1]. That is worth attention because the same classification is usually assembled from guesswork about address ranges, while the ASN record is a property of the network operator rather than an inference from the number ^[2].

The mechanics are unglamorous, which is the point. Every public IP belongs to an ASN, and the ASN carries a `type` of `ISP`, `HOSTING`, `BUSINESS`, `EDUCATION`, or `GOVERNMENT` ^[3]. `HOSTING` means a datacenter or cloud provider, `ISP` means a consumer access network, and the remaining three mean an organization operating its own address space ^[4]. The author collapses those three into one "organization" bucket, so five enumerated values reduce to three outcomes plus an `unknown` fallback when the lookup fails ^[5][6]. Practically, the discriminating work is being done by two labels.

The example given is `49.12.0.0`, which you cannot classify by eye; the lookup returns AS24940, Hetzner Online GmbH, tagged `HOSTING` ^[7]. The sample record also carries `domain`, `date_allocated` of 2002-06-03, `allocation_status` of `ASSIGNED`, RIR `RIPE`, and route counts of 84 IPv4 and 6 IPv6 prefixes ^[8] - 90 announced prefixes inheriting one label ^[9]. You can also query by AS number instead of IP, in which case the top-level `ip` field is dropped from the response; the guide's example, AS1 (Level 3), comes back as `BUSINESS` ^[10][11]. That is the useful mode if your logs or CDN already hand you an ASN, or if you are building a static allowlist of every ASN a partner operates ^[12].

Two operational caveats before anyone wires this into a request path. The `type` field requires a paid plan; the free tier returns AS number, organization, and country, which is three of the eleven fields in the sample record and none of the classification ^[13][14]. And the reference implementation uses connect and read timeouts of 1.0 and 1.5 seconds and never raises, returning `unknown` so the caller picks fail-open or fail-closed ^[6][15]. That choice is where the cheapness stops: fail-closed on a timeout means your abuse rule starts rejecting people because a third-party API was slow.

Now the failure the angle turns on. The guide is explicit that `type` describes the network operator, not whoever is using the address, so when a business runs on rented cloud space the operator is a hosting company while the tenant is a business, and reading `type` alone mislabels it ^[16]. This is not an edge case in fraud and abuse work; it is the population you are most likely to be wrong about. A rule that treats `HOSTING` as a stand-in for automation will penalise exactly the legitimate corporate traffic that egresses through a cloud NAT or a rented VPN, and it will do so consistently, because the ASN answer never changes. The signal you wanted was "is this a script"; the field you measured was "who owns the wire".

What to watch: the source promises four places where `type` stops being enough and the excerpt only develops one, so the other three are unverified here ^[17]. If you are building on this, check your plan tier for `type` before writing any logic that keys off it ^[13], and treat `HOSTING` as a reason to ask for a second signal rather than a verdict.