IP reputation and block lists

In casual speech, IP reputation is a label: “this address is already bad.” The documents that actually sit under that conversation do not hand out the label. They describe four different things: an autonomous system as a unit of routing policy, a shared external IPv4 at a carrier, a mail list of addresses served over DNS, and the networks Yandex’s robots name for themselves. None of the four scores the quality of an ad click, and none says whether a visit is click fraud or an ordinary arrival.

An autonomous system is a routing policy, not a person

RFC 1930 (March 1996) calls an autonomous system a connected group of one or more IP prefixes. One or more operators run it, and it has one clearly defined routing policy. The system has a globally unique number, an ASN. The number takes part in exchanging external routing information and names the system itself, not a subscriber. The document’s recommended external protocol is BGP. The classic formula from BGP-4, which the RFC retells, is a set of routers under one technical administration that looks from the outside like one coherent reachability plan.

An ASN here is a unit of routing policy. It is not a data-center label and not an identifier of a person. The RFC does not split systems into “residential” and “hosting.” The number does not support “hosting, therefore a bot” or “residential, therefore a buyer.” It says which group of prefixes announces one policy outward.

One external address, several subscribers

RFC 6598 (April 2012) sets aside shared address space for carriers to use with Carrier-Grade NAT: the block 100.64.0.0/10. It is separate from the private addresses of RFC 1918 because it is meant for the carrier’s network. Packets with these addresses must not be forwarded past the carrier’s border. What the outside sees is a different, public IPv4, and several subscribers share it.

In the CGN consequences, geolocation systems locate the translation server, not the end device. Some sites limit how many simultaneous sign-ins one external public IPv4 may have. The document’s example is game consoles: two subscribers with one external address cannot connect to each other. That is a class of application breakage, not a measurement of an audience. The RFC gives no count of subscribers per address. It does not use the words “residential proxy” or “thousands of people.”

For the reputation of an address the consequence is direct. A shared external IPv4 is not one person and not one computer. A geo point taken from that address points at the translation server. A list that blocks the whole address hits everyone leaving through it at that moment. The RFC does not recommend closing the address on a site, and it does not tie CGN to invalid clicks.

A DNSBL is a shared list, and the document sets no policy

RFC 5782 (February 2010, informational, consensus of the Anti-Spam Research Group) describes a DNS blacklist as a shared list of IP addresses or domains queried over DNS. The lists began as a way to mark addresses for spam and other unwanted behavior. Network managers use a DNSBL to cut traffic and a DNSWL to accept it more readily. The document specifies how the query is built. It does not directly specify whom to put on the list or how to apply the list.

The document leaves the name RBL as a Trend Micro trademark for one historical list, not as a generic word. Calling every list an “RBL” does not follow from this text.

This is a description of mail lists. It does not score an ad click and does not recommend closing, on a website, an address taken from such a list. An address landing on a DNSBL does not answer who clicks ads, how click fraud differs from sklikivanie, or whether Yandex returns the money. A mail mark and ad spend are different ledgers. The document does not glue them together.

Yandex robot networks are not a label for the whole system

Yandex Webmaster’s help says Yandex’s robots use the autonomous networks AS13238, AS208722, and AS212066. Addresses change often, so no IP list is published. The help prefers a reverse-DNS check to an address list. An ASN belonging to Yandex does not mean every address in that system is a search robot. The system number and the role of a particular request are different checks. The reverse-DNS procedure is not repeated in this retelling; it is recorded separately.

Some robots fetch documents for something other than indexing and may ignore User-agent: *. YaDirectFetcher does not use the robots.txt file. Metrika’s robots are marked in the help table as not following the general robots.txt rules. The Metrika 4.0 variant fetches and caches CSS in order to reproduce a page in Webvisor. The records YandexAdditionalBot and YandexAdditional are honored in robots.txt so that content can be limited in quick answers with YandexGPT and in Search answers with Alice. They do not make indexing requests.

No rule follows that “AS13238 goes on a block list because it is Yandex,” and no rule follows that “AS13238 is always allowed.” Addresses change, no IP list is published, and not every request from these systems is a search crawl. Reputation glued together from a system number erases that difference.

What can be said about an address without adding a label

The four sources leave an address in different roles.

Reputation as a single word is not defined in these texts. There is a route, there is a shared public IPv4, there is a mail list with no application policy, and there are announced robot networks whose addresses change. The sources do not allow folding that into a verdict that the address is bad and the click is invalid.