Summary

  • Earlier coverage associated Poyraz Hosting with AS210574 and reported that no active prefix announcements had been observed, but that observation was historical and accompanied by explicit uncertainty.
  • This investigation could identify the relevant RIPE Database, RIPEstat, PeeringDB and routing-observer sources, but did not capture usable current payloads from them.
  • The result is not proof that AS210574 is dormant, inactive or continuously operating. It is an evidence boundary: the public record reviewed here does not establish the present relationship between Poyraz Hosting and an operating network.

The question behind the ASN

Poyraz Hosting’s public profile creates a familiar infrastructure ambiguity. A company can advertise hosting services, appear in a network registry and hold an autonomous system number without presenting a verifiable, currently visible routing footprint. Conversely, a lack of evidence in one observation window does not prove that an ASN has never operated or cannot operate later.

The distinction matters because an autonomous system is an identifier used in inter-domain routing, not a certificate of service delivery. To move from registry identity to documented operation, an investigation needs several kinds of evidence: a dated registration record, observed prefixes, routing visibility, path data, continuity over time, and an operator or service record that aligns with the network evidence.

The prior BTW profile supplied a baseline. It associated Poyraz Hosting with AS210574, referenced a Turkish hosting website and reported that no active prefix announcements had been observed. It also described customer scale, financial information and actual service delivery as unverified. That profile’s value was the watchpoint: a future announcement, registry change or credible corporate disclosure could materially change the assessment.

This article asks a narrower and more demanding question: what can current public evidence establish now, and what remains only a candidate for verification?

Four planes of evidence

The first plane is registry identity. A current RIPE Database aut-num object could show the registered name, organisation reference, maintainers, routing-policy attributes, status, remarks and modification history. Those fields would describe the administrative record. They would not, on their own, prove that Poyraz Hosting currently originates routes or delivers services.

The relevant RIPE Database endpoint was identified for this investigation, but the current registration fields were not captured in a usable live response: RIPE Database aut-num endpoint. The correct conclusion is therefore limited. The current registration values were not verified in this run. It would be inaccurate to replace that limitation with a statement about the present holder, status or policy attributes.

The second plane is routing visibility. RIPEstat provides separate views for an ASN overview, announced prefixes and routing status. Each could contribute a different observation: an overview label or announcement state, a prefix set with observation times, and a status summary shaped by the data available to the service. The endpoints were identified, but their current values were not verified in captured payloads: RIPEstat overview, announced prefixes and routing status.

That distinction is essential. A verified zero-result from a named source during a stated window could support wording such as “no prefix was observed by that source during that window.” A failed or unusable retrieval supports only that a current response was not obtained. It does not establish a zero prefix count, an outage or dormancy.

The third plane is continuity. A single routing observation is weaker than a dated sequence showing first seen, last seen, withdrawals, reappearances and periods of visibility. RIPEstat’s routing-history and BGP-update endpoints were identified for that purpose, but the run did not verify current intervals or event counts: routing history and BGP updates.

Without those intervals, no defensible duration can be assigned to an apparent absence. The evidence cannot show whether AS210574 has never announced, announced briefly, withdrew routes before the observation, or remained visible only to collectors not represented in the available response.

The fourth plane is operational alignment. PeeringDB can provide an operator-maintained network record, while an independent routing observer can provide another view of visible routes and path data. Those sources are useful precisely because they answer different questions. PeeringDB is a participant-maintained record; a routing observer reflects its own collectors and processing. Neither should be treated as conclusive evidence of commercial relationships or service continuity without corroboration.

The PeeringDB lookup and bgp.tools page were identified, but current record values were not verified in this run: PeeringDB network lookup and routing-observer page. The operator website was also part of the prior evidence boundary, but its current service status was not independently captured for this investigation: Poyraz Hosting website.

Paths are observations, not contracts

AS-path adjacency is another area where infrastructure reporting can overstate what the data means. If a routing collector sees AS210574 next to another ASN, that is evidence of an observed path at a particular time and through a particular collection system. It does not, by itself, establish a customer-provider relationship, settlement-free peering agreement, transit purchase, ownership link or operational dependence.

The RIPEstat ASN-neighbours endpoint was identified, but current adjacency values were not verified: ASN-neighbours endpoint. A responsible account would need to report the observation time, collector limitations and direction of the path before discussing topology. It would also need separate evidence before turning adjacency into a commercial or organisational claim.

This is more than a wording preference. Routing data describes how announcements were observed to move through a measurement system. It does not automatically describe who paid whom, who controlled the infrastructure, or whether an adjacency was persistent. The missing current payload means that this investigation cannot name AS210574’s present neighbours or infer a relationship from them.

What the retrieval record says

The research record is itself part of the result. The investigation located authoritative or relevant endpoints for registration, prefixes, routing status, history, updates, neighbours, PeeringDB and independent observation. It also recorded that usable current responses were not captured. A later focused search returned no source candidates, and a targeted attempt to retrieve the RIPE registration object reported that the endpoint could not be accessed through the available research tooling.

Those outcomes should not be confused with source findings. “No response was retrieved” is a statement about the research process. “No routes were announced” is a statement about a routing observation. The first cannot substitute for the second.

The same discipline applies to the company’s services. The prior profile described a website advertising hosting-related services, while noting that customer base, financials and actual network services were not publicly documented. This investigation did not capture a current website or service-status response that would justify upgrading those claims. The present scale, customer infrastructure and commercial continuity therefore remain unknown.

What would change the assessment?

The assessment would move if several evidence planes began to align. A current registry record would establish the administrative identity and relevant timestamps. A verified announced-prefix response would show which routes, if any, were attributed to AS210574 at a stated observation time. Routing status and independent observer data could test whether that visibility was broad or collector-specific.

A longitudinal record would be more significant than a single announcement. Repeated visibility, documented withdrawals and reappearances, and a stable sequence across independent collectors could establish operational continuity. An aligned operator record, service page, facility disclosure or corporate filing could then connect the routing footprint to Poyraz Hosting rather than merely to the ASN as an abstract resource.

The reverse change would also matter. A registry modification, changed organisation reference, new maintainer or materially different routing policy could alter who appears responsible for the resource. Such a change would be a signal to investigate, not proof by itself of a transfer of control or a live service.

Bounded conclusion

Earlier coverage provides a historical association between Poyraz Hosting and AS210574 and a historical report that active prefix announcements had not been observed. This investigation adds a four-plane audit—registry identity, routing visibility, continuity and operational alignment—but it does not produce a current verified value for any of those planes.

The defensible conclusion is therefore narrower than “Poyraz Hosting is dormant.” The available evidence does not establish whether AS210574 is currently being operated, whether it has a persistent routing footprint, or whether the company’s advertised services correspond to live infrastructure. It establishes an unresolved public record and a concrete monitoring plan.

The next meaningful signal would be a dated, independently verifiable prefix announcement that can be connected to the ASN and then to the operator through aligned records. Until that happens, AS210574 should be treated neither as proof of an operating network nor as proof of an inactive one.