BLAHAJ-CLOUD-ANYCAST Makes Its Routes Verifiable While Its

Summary

AS64473 has a verifiable public routing identity: RIPEstat showed two announced prefixes, and the sampled RPKI checks reported valid origin authorization for both.
PeeringDB describes Blahaj Cloud Anycast as global, IPv6-enabled and open to peering, but its AS64473 record lists no internet-exchange or facility attachments. That absence leaves the physical anycast footprint unproved.
A RIPEstat neighbour query exposed AS20473 as one visible AS64473 neighbour. It is an observation from that view, not evidence that AS20473 is the only upstream, serves every location, or defines the whole commercial arrangement.
AS34854 is a separate Blahaj Cloud network. Its Frankfurt facilities, LOCIX Frankfurt Peering LAN connection, five-prefix set and broader visible adjacency illuminate the difference between disclosed and undisclosed topology, but none of those facts can be transferred to AS64473.

A network can be visible without being locatable

Anycast creates an unusual disclosure problem. The routing technique lets the same address space be announced from more than one place, allowing the network to steer users toward an available or topologically attractive instance. From outside, however, the address can remain constant while the physical systems behind it change. A route collector may show that a prefix exists and that an autonomous system originates it. It does not necessarily show how many origin sites are active, which buildings contain them, who operates the equipment, or whether two apparently separate paths eventually depend on the same underlying service.

That distinction is especially important for BLAHAJ-CLOUD-ANYCAST. The public evidence is strong enough to establish a real routing surface. RIPE RDAP identifies AS64473 as BLAHAJ-CLOUD-ANYCAST Maria Merkel trading as Blahaj Studio. RIPEstat reported the autonomous system as announced when queried. Its announced-prefixes data returned one IPv4 block, 107.150.174.0/24, and one IPv6 block, 2a0c:6500::/48. Separate prefix-overview results associated both blocks with AS64473 and the same holder identity. Separate RPKI-validation results reported valid origin authorization for the AS64473 and prefix combinations.

Those are consequential facts. They make the anycast identity inspectable at the resource and routing-control levels. A researcher does not have to infer the network solely from marketing copy or a product name. The autonomous system, the address resources, the visible origin and the route authorization all align.

But none of those observations locates an anycast node. A valid route is not a facility record. An announced prefix is not a count of active sites. A global scope field is not a list of cities. Even the label BLAHAJ-CLOUD-ANYCAST describes intended network function rather than proving its physical implementation. The correct reading is therefore neither dismissive nor credulous. AS64473 is not merely an unverified claim, but the evidence proves less than a full resilience narrative would require.

This article uses that boundary as its organizing principle. It first identifies what Blahaj Cloud says it operates, then follows the AS64473 evidence from registry identity through prefix announcements, route authorization, neighbour visibility and PeeringDB. It uses AS34854 only as a separate comparison, because that network has public facility and exchange details that AS64473 does not. The resulting picture is useful precisely because it refuses to fill the blank spaces with assumptions.

The official boundary is narrower than a retail-cloud promise

Blahaj Cloud describes itself as networking and compute infrastructure managed by Blahaj Studio for its own and select non-profit projects. That wording defines a limited constituency. It supports the existence of an operating platform, but it does not support a claim that the service is generally available to retail buyers, that any particular organisation is a customer, or that the public can purchase a standard catalogue of capacity. "Own and select non-profit projects" should remain the governing phrase whenever the service boundary is discussed.

The official service description nevertheless spans several layers. It lists an autonomous internet network; IP, server and networking infrastructure; hosting; local internet registry services; and IP transit through AS34854. The description also contains an important qualification around ownership: the anycast network is excepted from the statement about owned infrastructure. The packet does not explain the contractual or operational meaning of that exception. It would be unsafe to turn it into a claim about leasing, outsourcing, third-party control or a particular deployment model.

It is enough to observe that the site's own wording distinguishes the anycast layer from the infrastructure it describes as owned.

The acceptable-use policy makes the operational surface more concrete without resolving the physical topology. It applies to connectivity and IP services, including hosting, IP and ASN assignments or sponsorships, and IP transit. A policy covering those services indicates that Blahaj Cloud expects to govern conduct across more than a single website or application. It also shows why network-resource evidence matters: address assignments, ASN sponsorship and transit create dependencies that are not captured by a generic "cloud" label.

The legal disclosure supplies a named operator and a regulatory context. It identifies Maria Felicitas Annika Merkel and Blahaj Studio in Germering, Germany, and gives DREG number 26/027. It states supervision as a provider of public telecommunications networks and services. It also states NIS2 supervision as a provider of DNS, cloud computing and telecommunications services. These details connect the public service description to a legal identity. They do not certify performance, geographical reach, security maturity or continuity arrangements. Regulatory classification is an operator fact, not a substitute for technical evidence.

That distinction matters because public infrastructure profiles often compress legal identity, product language and observed network behaviour into a single confidence level. Here they should be kept separate. The official pages are the right evidence for what Blahaj Cloud calls the service, which activities its policy covers and who the disclosure names. RIPE RDAP and RIPEstat are the right evidence for the registered and observed autonomous-system surface. PeeringDB contributes a structured interconnection profile. None of the three evidence classes should silently answer questions assigned to another.

The narrower reading is also more commercially useful. A prospective supported project does not need inflated claims about scale. It needs to know which statements are verifiable and which questions still require direct operator disclosure. The public record establishes that Blahaj Studio manages a networking and compute platform for a bounded set of uses. It does not establish an open market, named dependencies or standard service commitments. Keeping that boundary intact prevents an infrastructure assessment from manufacturing customers, demand or exposure that the sources do not name.

AS64473 has a coherent control-plane identity

The strongest AS64473 evidence is cumulative. No single field proves the whole network, but several independent observations agree about the same routing identity.

First, RIPE RDAP identifies autnum 64473 with the full holder string BLAHAJ-CLOUD-ANYCAST Maria Merkel trading as Blahaj Studio. RIPEstat's AS overview uses the shorter network label BLAHAJ-CLOUD-ANYCAST and showed the AS as announced at the time of the query. These records provide a stable distinction from AS34854, whose corresponding identities are BLAHAJ-CLOUD Maria Merkel trading as Blahaj Studio and BLAHAJ-CLOUD. The shared operator language does not merge the two AS numbers. Each remains a separate routing entity with its own visible resources and profile.

Second, RIPEstat's announced-prefixes response for AS64473 returned exactly two prefixes in the captured query: 107.150.174.0/24 and 2a0c:6500::/48. The packet records both as visible across the queried 2026-07-06 to 2026-07-20 timeline. This is a compact address surface, one IPv4 route and one IPv6 route, rather than evidence of a large portfolio. Prefix count alone says little about traffic volume, user population or the number of serving sites. A single anycast prefix can be originated from multiple locations, while multiple prefixes can be served from one location. The useful fact is that the routes were visible under AS64473, not that two routes imply any particular architecture.

Third, RIPEstat's prefix-overview data independently associated each prefix with AS64473 and the full BLAHAJ-CLOUD-ANYCAST holder. This per-prefix confirmation reduces the chance that an article is merely joining unrelated fields from an AS summary. The IPv4 and IPv6 resources each point back to the same network identity in the captured evidence.

Fourth, the RPKI-validation queries reported valid outcomes for AS64473 originating both 107.150.174.0/24 and 2a0c:6500::/48. Route Origin Authorisation allows a resource holder to state which autonomous system may originate a prefix, subject to the relevant maximum-length constraints. A valid result therefore answers an important control question: the observed origin and the published authorization were consistent for the two tested routes.

The alignment is meaningful for security and operations. Invalid-origin announcements can be rejected by networks that perform route-origin validation, while valid authorization removes that particular reason for rejection. The checks also demonstrate that the anycast-facing AS is not relying on an unexplained mismatch between the holder record and origin authorization in the sampled routes.

Yet RPKI validity has a precise limit. It does not tell a remote observer whether the route is available from one site or many. It does not prove that each serving instance is healthy, that configuration is synchronized, that upstream paths are independent, or that an application behind the addresses responds correctly. It does not establish who owns the machines, where they are located or how quickly service is restored after a failure. It verifies an authorization relationship at the routing layer. Treating it as a general reliability certificate would erase the most important distinction in this case.

The evidence therefore supports a carefully worded conclusion: AS64473 presents a coherent, authorized and publicly observable control-plane identity for Blahaj Cloud Anycast. That conclusion is stronger than "Blahaj Cloud says it has anycast." It remains narrower than "Blahaj Cloud has a documented global resilient platform." The latter would require a physical and operational evidence set that the packet does not contain.

IPv4 and IPv6 align at origin, not necessarily in deployment

AS64473's two-prefix set creates an apparent symmetry. The IPv4 route 107.150.174.0/24 and the IPv6 route 2a0c:6500::/48 were both visible under the same autonomous system. Prefix-overview data connected both to the same full holder identity, and the two RPKI queries each returned a valid result for AS64473 as origin. PeeringDB also marks the network as IPv6-enabled. Taken together, the sources support a dual-family routing surface with consistent public identity and origin authorization.

That is a stronger statement than merely noting that an IPv6 field exists in a profile. There is observed IPv6 address space in the announced set, and the captured validation result is tied to the actual AS64473 origin and prefix combination. The same chain exists for IPv4. A dependency review can therefore begin from evidence that both protocol families were represented in the public routing record during the queried period.

The symmetry ends there. Nothing in the packet demonstrates that IPv4 and IPv6 are originated from an identical set of anycast locations. It does not show that the two families use the same upstreams at each location, share the same withdrawal automation, or reach the same service instances. It does not establish equivalent performance or failure behaviour. Even when one autonomous system originates both routes, the physical and operational paths behind them can only be assessed with more detailed evidence.

This distinction is material because "IPv6 enabled" can be interpreted too broadly. In the source set it is supported as an interconnection-profile attribute and by a visible IPv6 announcement. It is not proof that every service available over IPv4 is available over IPv6, that application health is checked in both families, or that a failure triggers coordinated route changes. The packet contains no application probes, per-site route observations or failover records. Any claim of protocol parity would exceed the evidence.

The related-looking address strings across the two Blahaj Cloud autonomous systems also require discipline. AS64473 originates 2a0c:6500::/48. AS34854's five-prefix set includes 2a0c:6500:1::/48 and 2a0c:6500:100::/40, along with a separate IPv6 block and two IPv4 routes. Similar numerical structure may invite a reader to treat the networks as one deployment. It does not provide a direct facility or topology link. The origin AS remains the relevant boundary in this packet: the first IPv6 prefix is observed under AS64473, while the latter prefixes are observed under AS34854.

The query timeline is another limit. The fact packet records the AS64473 prefixes as visible across the 2026-07-06 to 2026-07-20 period returned by the announced-prefixes request. That supports visibility during the captured interval. It is not a historical availability measure and cannot be converted into an uptime percentage. A route can remain visible while a service behind it is impaired, and a collected view does not describe every user's path. The observation should be timestamped rather than promoted into a permanent service property.

For a project considering dependency on the anycast service, protocol-family diligence should therefore be explicit. The useful questions are whether the IPv4 and IPv6 prefixes originate at the same active sites, whether site and upstream diversity differ by family, whether health checks withdraw each route independently, and whether a service failure can leave one family advertised but unusable. The sources neither confirm nor deny those scenarios.

The safest summary is narrow: AS64473 had one observed IPv4 prefix and one observed IPv6 prefix, both attached to the same public holder and both RPKI-valid for the tested origin. This is evidence of coherent route control across two protocol families. It is not evidence of identical physical coverage, application parity or recovery behaviour. The difference between those propositions is exactly the difference between a verifiable anycast-facing control plane and an unproved execution map.

PeeringDB supplies scope and policy, not a site map

PeeringDB's record for network 22942 adds a different set of attributes. It names Blahaj Cloud Anycast, associates it with ASN 64473 and the Blahaj Cloud website, and lists the IRR AS-SET AS-MERKEL. Its information types are Content and Non-Profit. The profile marks global scope, IPv6 capability and an open peering policy. It reports a mostly outbound traffic ratio and a traffic band of 100-1000Mbps.

These fields help characterize how the network presents itself to potential interconnection partners. "Content" and mostly outbound traffic are compatible with a service that sends responses or hosted material toward users. "Non-Profit" fits the official description of infrastructure for own and select non-profit projects. An open policy indicates willingness to peer under the profile's stated terms. Global scope signals an intended reach beyond a single region.

But each field needs restraint. The 100-1000Mbps band is not a measurement of customer-usable capacity. It does not reveal peak traffic, committed bandwidth, reserve margin or the distribution of traffic among sites. "Mostly outbound" is a ratio description, not proof of what applications generate the bytes. "Global" is a scope classification, not physical deployment evidence. "Open" does not show which networks actually peer at which locations. None of these attributes establishes service-level commitments.

The most revealing PeeringDB fields may be the empty attachment counts. For AS64473, the record reports ix_count 0 and fac_count 0. Within this public profile, there are no listed internet-exchange connections and no listed facilities. An empty PeeringDB attachment set is not proof that the network has no physical sites or interconnections. Any announced AS must reach the wider routing system somehow, and PeeringDB is not a compulsory census of every arrangement. Private links, transit-delivered sessions, unlisted sites or incomplete profile maintenance are all logically possible. The packet does not select among those explanations.

What the zero counts prove is narrower and still important: the supplied PeeringDB record does not disclose a physical or exchange map for AS64473. A researcher cannot use it to name even one AS64473 facility. It cannot support a PoP count. It cannot show whether two sites use separate buildings, power systems, carriers or operational teams. It cannot establish the geography behind the global label.

This is the core disclosure asymmetry. The network publishes enough structured information to be found as an anycast AS, to advertise its peering posture and to expose valid routes. It does not publish, in the sources available here, the site-level information needed to model physical concentration. That asymmetry is not itself evidence of poor design. It is evidence that the design cannot be independently assessed from this packet.

The distinction should survive when the profile is reduced to a dashboard or risk note. A green indicator for RPKI should mean only that the tested prefix-origin pairs were valid. A global tag should mean only that PeeringDB assigns global scope. A zero beside facilities or exchanges should mean that no attachments are listed in that profile, not that the network literally operates nowhere. Combining those fields into an unqualified availability rating would manufacture a conclusion that none of them supports.

The useful output is a split assessment: route identity and authorization are evidenced; site distribution and independence are unresolved.

That split also protects the operator from an inverse overclaim. Lack of a public PoP list is not proof that there is one site, and one visible neighbour is not proof that there is one physical connection. Public-data analysis can identify missing disclosure, but it cannot replace missing disclosure with a worst-case architecture. The evidence boundary runs in both directions. It blocks optimistic claims about diversity and pessimistic claims about concentration. What remains is a clearly defined diligence gap that can be addressed through direct technical information or through a user architecture designed not to depend on assumptions.

The difference matters to users because anycast's value arises from implementation, not naming. The same prefix announced in genuinely independent locations can reduce latency and preserve reachability when one site or path fails. The same prefix announced from locations that share a provider, control system or underlying building can retain hidden common modes of failure. A route table can show multiple paths without revealing all shared dependencies beneath them. Without a location and dependency map, the observer can verify the routing surface but cannot grade its resilience.

The official site reportedly refers to anycast with global locations, and PeeringDB marks global scope. Those statements justify describing the network as global in its public positioning. They do not justify inventing cities, regions or a minimum number of PoPs. The plural language may suggest more than one location in ordinary usage, but the packet provides no named list and no independently attributable site count. A rigorous profile must leave that map blank rather than complete it through implication.

One visible neighbour is an observation, not a universal topology

RIPEstat's ASN-neighbours response for AS64473 returned one visible left neighbour, AS20473. It returned no right neighbours and no uncertain neighbours in that queried output. This is the only neighbour observation for AS64473 in the packet, and its evidentiary weight is explicitly downgraded from the high-confidence registry and prefix facts.

The result matters because it demonstrates at least one visible adjacency in the data view. AS64473 was not merely an isolated registry entity; the routing observation connected it to AS20473. That is useful when checking whether a public anycast identity participates in the global routing system.

The result does not establish that AS20473 is the universal upstream for Blahaj Cloud Anycast. Neighbour datasets are shaped by collector visibility, route propagation, the time of observation and the method used to classify paths. A commercial or technical relationship may also be more nuanced than an AS-path adjacency implies. The left label belongs to the queried RIPEstat output; it should not be rewritten as a definitive customer, provider or settlement relationship without a source that says so.

Nor does a single visible neighbour prove a single physical path. One autonomous-system adjacency can be implemented through multiple sessions and locations, while several logical relationships can share a physical dependency. Conversely, the absence of other neighbours in one output does not prove that no other sessions, private connections or site-specific arrangements exist. The data supports an observed edge in a routing graph, not a complete contract inventory.

This makes AS20473 simultaneously relevant and limited public evidence. Ignoring it would discard the only captured AS64473 adjacency. Promoting it into the whole topology would overstate the view. The defensible formulation is exact: in this RIPEstat query, AS20473 was the one visible AS64473 neighbour. Every broader proposition, including universal upstream status, location coverage, failover responsibility and exclusivity, remains unproved.

That narrow reading also prevents a common anycast analytical error. Observers sometimes equate upstream diversity with physical resilience and count AS neighbours as though each were an independent failure domain. Even if additional neighbours were visible, that count alone would not show whether sessions terminate in separate facilities, whether the facilities share power or fibre, or whether route announcements are controlled through one management plane. For AS64473, the evidence does not even support the broader neighbour count, making any resilience score based on adjacency especially speculative.

The appropriate due-diligence response is not to declare the network fragile. It is to identify the missing questions. Where is the AS64473 prefix originated? How many currently active origin sites exist for IPv4 and IPv6? Which autonomous systems provide reachability at each site? Are routing policies and control credentials isolated? What is withdrawn during a partial failure, and how is withdrawal tested? Those questions arise from the evidence gap; the packet does not provide their answers.

AS34854 is a comparison, not a proxy

AS34854 belongs in this analysis because the official Blahaj Cloud material identifies it as the network used for IP transit, and because its public record is substantially more detailed. It must nevertheless remain separate from AS64473. Shared branding and operator identity do not permit the facilities, exchange connection, prefixes or neighbours of one autonomous system to be assigned to the other.

RIPE RDAP identifies AS34854 as BLAHAJ-CLOUD Maria Merkel trading as Blahaj Studio, while RIPEstat uses BLAHAJ-CLOUD and showed the AS as announced. The separate naming mirrors the functional distinction: AS64473 is the anycast-facing subject; AS34854 is the main Blahaj Cloud network in the evidence set.

RIPEstat returned five announced prefixes for AS34854: 2a0c:6500:1::/48, 2.56.11.0/24, 2a0c:b642:fc0::/43, 2a0c:6500:100::/40 and 45.151.215.0/24. That is a different and larger visible prefix set than the two routes under AS64473. The count still cannot be converted into customers, servers or capacity. It shows a broader address-routing surface for the main network.

The packet includes sampled RPKI-validation checks for two AS34854 IPv4 routes, 2.56.11.0/24 and 45.151.215.0/24, and both returned valid for AS34854 origin. These are samples, not a full validation of all five announced prefixes. The correct statement is that the tested IPv4 routes had valid ROAs for AS34854, not that every AS34854 route was exhaustively checked.

The neighbour view is also wider. RIPEstat returned 30 unique AS34854 neighbours, broken down in the packet as 14 left, five right and 11 uncertain. AS1299 and AS6939 appear among the visible left neighbours. As with AS20473, these are observed routing relationships in the query rather than a contractual provider list. The uncertain category is an additional warning against assigning business roles from path position alone. Even so, the contrast is clear: the captured public routing view around AS34854 is much denser than the one around AS64473.

PeeringDB makes the disclosure difference tangible. Network 20982 names Blahaj Cloud, also identified as Blahaj Studio, at ASN 34854. It lists Content, NSP and Non-Profit information types, European scope, a 1-5Gbps traffic band and a balanced traffic ratio. It reports one internet exchange and two facilities.

Those facilities are Digital Realty Frankfurt FRA1-27 and MK Netzdienste Datacenter. The exchange record is LOCIX Frankfurt Peering LAN, shown with speed 40000, IPv4 address 185.1.166.127 and IPv6 address 2001:7f8:f2:e1:0:a250:4854:1. The entry marks the connection operational and identifies it as a route-server peer. These are unusually specific public attachment facts compared with AS64473's zero facility and exchange counts.

The evidence supports saying that AS34854 has disclosed Frankfurt facility and exchange presence in PeeringDB. It does not support saying that AS64473 runs at Digital Realty Frankfurt FRA1-27, MK Netzdienste Datacenter or LOCIX Frankfurt Peering LAN. No source in the packet directly links those AS34854 attachments to the AS64473 anycast origins. The official statement that IP transit is provided via AS34854 also does not close that gap. A service relationship between the networks can exist without every AS64473 announcement sharing AS34854's listed physical footprint.

Using AS34854 correctly therefore requires two moves. First, it demonstrates that Blahaj Cloud is capable of publishing facility and exchange details for one of its networks. Second, it shows what kind of evidence is absent for the anycast AS. It does not reveal the missing AS64473 details by analogy.

This comparison sharpens the uncertainty rather than resolving it. For AS34854, a researcher can point to two named facilities and one named exchange in Frankfurt, then combine those entries with a five-prefix set and a broader observed neighbour graph. The researcher still cannot infer complete redundancy or usable capacity, but there are concrete attachment points to investigate. For AS64473, the researcher has authorized routes, a global anycast profile and one visible neighbour, but no named attachment points in the source set.

The separation also guards against an identity shortcut. BLAHAJ-CLOUD-ANYCAST and BLAHAJ-CLOUD are not stylistic variants for one database row. AS64473 and AS34854 are distinct administrative routing identifiers. A physical fact attached to one must stay there unless a source explicitly bridges it. In infrastructure analysis, respecting that boundary is not pedantry. It is what prevents a well-documented companion network from lending unsupported certainty to a less-documented service.

Route authorization cannot price the hidden dependency

For a supported project, the practical question is not whether AS64473 exists. The evidence answers that. The question is what dependency is accepted when a service relies on it, and whether the available information is sufficient to value that dependency.

The public record provides several positive controls. The operator and legal identity are named. The service has an acceptable-use framework covering connectivity and IP services. The anycast AS is announced. Its captured IPv4 and IPv6 prefixes map to the same holder, and both sampled origin combinations are RPKI-valid. PeeringDB provides a scope, traffic band, traffic ratio, policy and AS-SET. Those signals reduce ambiguity about who presents the network and how it appears at the control-plane level.

The record withholds or does not establish the variables that translate routing visibility into operational exposure. There is no named AS64473 PoP list. There is no facility inventory for the anycast AS. There is no evidence-led count of active sites, and no indication of whether IPv4 and IPv6 have identical deployment coverage. There is no documented upstream set by site. The single visible AS20473 adjacency cannot supply that map. There is no packet evidence for service-level commitments, failover tests, spare systems, incident response, backup routing or recovery boundaries.

Capacity is similarly downgraded. PeeringDB's 100-1000Mbps traffic band describes a profile range, not an offer of bandwidth to a project. The two-prefix count measures address announcements, not throughput. The official list of hosting and network services describes scope, not available inventory. A buyer or supported organisation cannot calculate headroom, contention, growth tolerance or failure-mode capacity from those fields.

This matters for hosting economics because undisclosed dependencies are difficult to price. A small nonprofit project may rationally accept a service with limited public documentation if the operator provides direct answers, if the project can tolerate interruption, or if an alternative path exists. A critical DNS or application dependency may require stronger evidence about site independence and failover behaviour. The same public record can therefore be adequate for one workload and inadequate for another. The distinction turns on impact and recovery requirements, not on a generic verdict about the provider.

The bounded constituency complicates external measurement. Infrastructure for own and select non-profit projects may not expose the sales documents, public status commitments or customer references associated with a broad retail service. That does not make the network unserious. It does mean an analyst should not import the disclosure expectations or scale assumptions of a mass-market cloud into this case. The correct response is to identify the decisions that cannot be made from public evidence alone.

Those decisions include concentration risk. A global anycast label can coexist with hidden common dependencies in control, upstream connectivity or physical hosting. Without the site map, a user cannot determine whether a regional event removes one announcement while leaving others independent, or whether a shared component affects all instances. It also includes protocol parity: the packet confirms one IPv4 and one IPv6 route, but it does not show that both families are originated from the same set of locations or fail over in the same way.

It includes change risk. The RIPEstat results are observations from the query period, not promises that the neighbour graph or announced set will remain unchanged. RPKI authorization can be updated, routes can be added or withdrawn, and PeeringDB profiles can change. A due-diligence conclusion should be timestamped and periodically rechecked rather than treated as permanent.

Most importantly, the unknowns should remain explicit in any downstream use. "Unknown" does not mean "absent," and it does not mean "present." AS64473 may have multiple sites, diverse paths and effective operational controls, but this packet does not prove them. It may also depend more heavily on one arrangement than the global label suggests, but the packet does not prove that either. The honest analytical state is unresolved.

A practical evidence ladder for users and partners

The AS64473 case is easier to evaluate when its claims are sorted into an evidence ladder rather than compressed into one trust score.

At the first level are identity and scope claims. The official pages name Blahaj Cloud and Blahaj Studio, describe infrastructure for own and select non-profit projects, list the service categories and provide policy and legal disclosures. Maria Felicitas Annika Merkel, Germering, DREG number 26/027 and NIS2 appear in that operator context. These facts answer who publicly stands behind the service and what broad activities are claimed.

At the second level are resource and route facts. RIPE RDAP and RIPEstat connect AS64473 to BLAHAJ-CLOUD-ANYCAST Maria Merkel trading as Blahaj Studio. They show the AS as announced and identify 107.150.174.0/24 and 2a0c:6500::/48 as its two captured prefixes. Prefix-overview and RPKI-validation results reinforce that resource-to-origin chain. These facts answer whether the anycast-facing routing identity is publicly observable and authorized in the tested combinations.

At the third level are interconnection descriptors. PeeringDB names Blahaj Cloud Anycast, attaches AS-MERKEL, marks global scope, IPv6 and open peering, and supplies traffic descriptors. RIPEstat contributes the one visible AS20473 neighbour. These facts describe how the network appears to the interconnection ecosystem, but they are incomplete as topology.

At the fourth level would be physical execution evidence: named AS64473 sites, facility attachments, exchange sessions, per-site upstreams and the relationship between the IPv4 and IPv6 deployments. That level is absent from the packet. AS34854 has some fourth-level evidence in Digital Realty Frankfurt FRA1-27, MK Netzdienste Datacenter and LOCIX Frankfurt Peering LAN, but those entries belong to the separate BLAHAJ-CLOUD network.

At the fifth level would be operational assurance: monitoring coverage, withdrawal logic, isolation of route-control credentials, change procedures, tested failover, incident communication, recovery objectives and post-incident evidence. The packet contains no such AS64473 documentation. Neither valid ROAs nor an operational flag on AS34854's LOCIX entry can fill this level.

This ladder gives a prospective dependency owner a focused request list. Ask for the current AS64473 origin-site inventory without assuming the answer. Ask whether the two address families share the same locations and path diversity. Ask which upstream and facility dependencies are common across sites. Ask how a failed service instance or unreachable site causes a route withdrawal, and how that behaviour has been tested. Ask what monitoring distinguishes an application failure from a BGP failure. Ask what commitments, if any, apply to the specific supported project.

Answers can be shared privately when public disclosure would create security or commercial concerns. The point is not that every network must publish a complete blueprint. The point is that the absence of public data changes the type of assurance available. A user should replace inference with direct diligence, contractual language or an architecture that tolerates uncertainty.

The ladder also prevents low-value questions. Prefix ownership does not need to be guessed because the resource records answer it. Route-origin authorization does not need to be inferred because the RPKI checks address the sampled routes. Conversely, asking for a "global PoP count" without clarifying active sites, address-family coverage and common dependencies may produce a marketing number with little risk value. Evidence should be requested at the layer where the decision actually sits.

The safest conclusion is precise, not negative

Blahaj Cloud Anycast has more public substance than a product label. AS64473 is a distinct announced network. RIPEstat exposed two prefixes, and the associated RPKI checks found valid origin authorization. RIPE RDAP, prefix-overview data and PeeringDB align around the BLAHAJ-CLOUD-ANYCAST identity. The public profile also expresses global scope, an open peering policy and a nonprofit-oriented service context.

The evidence stops before the physical anycast system becomes visible. PeeringDB lists no AS64473 facilities or exchanges. The neighbour query exposed AS20473 in one view but cannot establish the full provider or site topology. No supplied source names the AS64473 PoPs, proves physical diversity, measures usable capacity, identifies supported projects, or documents availability and recovery controls.

AS34854 makes that limit easier to see. Its separate BLAHAJ-CLOUD profile discloses Frankfurt attachments, a LOCIX Frankfurt Peering LAN connection, more announced prefixes and a broader observed neighbour set. Those facts show a different network with a richer public footprint. They do not locate AS64473.

The resulting assessment is neither an endorsement of resilience nor evidence of its absence. It is a statement about observability. Blahaj Studio has made the anycast control plane sufficiently legible to verify identity, announcements and origin authorization. It has not, in this source set, made the physical failure domains legible enough for an outside party to model them. Any organisation that depends on the service should preserve that distinction and obtain the missing assurance at the level its own risk requires.

BLAHAJ-CLOUD-ANYCAST Makes Its Routes Verifiable While Its Anycast Geography Remains Unproven