ATWWW Pty Ltd, Web Hosting and Design, Sydney sells hosted capacity that still depends on racks, transit and repair windows

Summary

• ATWWW Pty Ltd, Web Hosting and Design, Sydney is tied to AS23867 in APNIC RDAP. The APNIC record is active, lists the name ATWWW-AU-AS, gives the description "ATWWW Pty Ltd, Web Hosting and Design, Sydney", and places the record in Australia.
• Current public routing evidence is negative. RIPEstat's AS overview says AS23867 is not announced, RIPEstat announced prefixes shows an empty prefix list, and RIPEstat ASN neighbours shows zero observed neighbours at the latest available time.
• The old address-resource trail is real but stale. APNIC RDAP for 202.46.132.0/22 labels the block ATWWWNET and describes an ISP and web development company at The Rocks, Sydney. RIPEstat prefix overview says the prefix is not currently announced, while RIPEstat routing history shows later origin history under AS45671 before the prefix disappeared from public routing.
• The corporate web trail should not be confused with live ATWWW network capacity. The Dubs home page describes a global finance marketing business with a Sydney sub-organization at 100 Harris Street, while the public IP used by that site, 103.69.130.119, is registered to QUAPE PTE LTD and is routed by AS131582, not AS23867.
• The network evidence grade is Negative for current ATWWW-hosted capacity: there is a registered and historically routed Australian ASN/address block, but no current public BGP footprint, no PeeringDB profile, no current neighbour visibility, no visible route-origin authorization for the old /22, and no public facility or customer-service proof.

A dormant route table is still an infrastructure fact

ATWWW is exactly the kind of name that can mislead a buyer if the buyer reads a registry label as a live service. The label says "Web Hosting and Design, Sydney", which sounds like customer-facing infrastructure. It points to an Australian hosting era when a small provider could combine design work, hosted sites, email, DNS, address space and upstream transit under one commercial wrapper. But the present public routing picture does not show a live ATWWW edge. That absence matters more than the nostalgia of the label.

The strongest direct company-specific record is the APNIC RDAP record for AS23867. It gives the autonomous-system name ATWWW-AU-AS, marks the record active, identifies the country as AU, and carries the description "ATWWW Pty Ltd, Web Hosting and Design, Sydney". The same record shows a registration event in 2008 and a last-changed event in 2021. It also lists a registrant entity, @www Pty Ltd, and contact data that now includes The Dubs email domain on abuse and registrant contacts. That is enough to say the number-resource identity exists and is not a random web-directory artefact.

It is not enough to say ATWWW is currently selling reachable hosting capacity from its own network. RIPEstat's AS overview for AS23867, queried for the latest available routing point, reports the holder as ATWWW-AU-AS - ATWWW Pty Ltd, Web Hosting and Design, Sydney and says announced: false. RIPEstat routing status reports zero IPv4 prefixes and zero IPv6 prefixes in announced space, zero peers seeing the ASN at the latest point, and no observed neighbours. RIPEstat announced prefixes shows an empty prefixes array. RIPEstat BGPlay also shows no initial state and no events for the recent window checked.

That makes the public interpretation narrow but important. ATWWW is a historical and registered infrastructure subject. It is not, on current public BGP evidence alone, a provable live hosting network. Any buyer, auditor or former customer who still sees an ATWWW name in account paperwork should treat that as a dependency to verify, not as a proof of service.

The old Sydney address block tells a useful but limited story

The old address block gives the article its physical shape. APNIC RDAP for 202.46.132.0/22 names the block ATWWWNET, marks it active, describes it as an "ISP and Web Development Company" at The Rocks, Sydney, and classifies it as ASSIGNED PORTABLE IPv4 space. The same record covers 202.46.132.0 through 202.46.135.255. It lists technical and administrative contact language for an administrator for at www Pty Ltd at 13 Hickson Road in Sydney, along with a registrant entry for @www Pty Ltd at 100 Harris Street.

That is the kind of record a hosting buyer should care about. Portable address space can outlive a product page, an office move or a change in upstream provider. It can anchor firewall rules, mail reputation, customer ACLs, VPN allowlists and old disaster-recovery plans. If a legacy customer once depended on a server inside that /22, the address block would be the thread to pull.

But the current routing evidence says the thread is not a live route. RIPEstat prefix overview for 202.46.132.0/22 says the prefix is not announced. RIPEstat BGP state shows no current BGP state and zero routes. RIPEstat routing status for the prefix says the prefix was first seen with origin AS23867 in 2003, but the last seen origin in the routing-status view is AS45671 in 2020.

The longer RIPEstat routing-history view for the prefix makes the handoff visible. AS23867 originated 202.46.132.0/22 for long stretches from 2003 through 2013. Later, AS45671 carried the same prefix through long stretches from 2014 into 2020. APNIC RDAP for AS45671 identifies that ASN as AS45671-NET-AU, a wholesale services provider associated with Servers Australia Pty. Ltd. The safe conclusion is not that ATWWW currently uses Servers Australia, and not that an old customer workload moved there. The safe conclusion is more modest: the address block has a history that outlived AS23867's own public announcements, and the later route origin was a different Australian wholesale network.

That matters for continuity. When a customer asks whether an old hosted account is still recoverable, the answer may sit in contract archives, account migrations and DNS records rather than in the current ATWWW route table.

The current web trail points away from AS23867

The APNIC records connect @www Pty Ltd contact data with The Dubs email domain, and The Dubs home page gives a current public corporate trail. The page describes The Dubs as a finance marketing business, says it was founded in 1996, and lists a Sydney sub-organization at 100 Harris Street, Pyrmont. That address overlaps the registrant address carried in the APNIC RDAP entries for AS23867 and 202.46.132.0/22. It is a reasonable continuity signal for the corporate or contact side of the record.

It is not a route-capacity signal for ATWWW. The current The Dubs site resolves to a hosted web endpoint outside the ATWWW ASN. APNIC RDAP for 103.69.130.119, the address seen for The Dubs' public web service in this check, places the allocation under QUAPE PTE LTD in Singapore. RIPEstat network-info for 103.69.130.119 maps it to 103.69.130.0/24 and AS131582. RIPEstat prefix overview says the aligned prefix is announced by AS131582, with holder QUAPEPTELTD-AS-AP - QUAPE PTE LTD. APNIC RDAP for AS131582 identifies that ASN as QUAPE PTE LTD.

This is one of the article's most practical findings. A company can have a live website without operating its own old ASN. A design or marketing business can still exist while its historical hosting network is dormant. A customer can see a corporate name, a phone number, or a current domain and assume there is live owned infrastructure behind it. The route table says that assumption would be unsafe here.

The distinction protects both sides. It avoids accusing ATWWW of operating capacity that is not visible. It also warns customers not to use a corporate web page as proof of rack location, support hours, restore capability or data locality. If a workload is still dependent on an ATWWW-labelled account, the proof has to come from present service documents, live DNS, current billing, support access, backup-export tests and a route or provider map for the actual hosting address.

Historical upstreams are not current redundancy

The old APNIC whois-derived data visible through RIPEstat whois for AS23867 includes import and export lines for AS7474 and AS1221. It says AS23867 accepted ANY from AS7474 and AS1221, exported AS23867 to both, and had a default route preference to AS7474. In plain infrastructure terms, those fields describe an old two-upstream design: Telstra-era Australian transit on one side and Optus-era Australian transit on the other.

The age and current route state change the meaning. A buyer should not read those policy lines as current transit diversity. They are useful historical clues. They say the ATWWW network record once described upstream relationships with two major Australian ASNs. They do not say those sessions exist now, that circuits are paid, that routers are powered, that provider contracts are active, or that customer traffic can still fail over.

This is where public route evidence is unforgiving. RIPEstat ASN neighbours for AS23867 shows zero neighbours at the latest available time. RIPEstat AS path length shows an empty stats array. PeeringDB's API query for AS23867 shows "Entity not found". In another setting, a PeeringDB profile might show exchange ports, facilities, traffic levels or contact roles. Here, PeeringDB's own about page is still useful context because it describes PeeringDB as a public interconnection database for networks, clouds, services and facilities, but the absence of an AS23867 profile means there is no user-maintained public interconnection profile to audit.

The result is a sharp procurement lesson. Historical upstream diversity is not operational redundancy. Redundancy exists only when the current service has at least two functioning paths, enough remaining capacity after one path fails, independent escalation contacts, and a recent test showing that traffic, support and billing continue under the failed state.

Hosting economics convert missing evidence into customer risk

Hosted capacity is sold as convenience: the customer rents an outcome rather than buying the router, rack, power feed, software licences, disks, staff and carrier contracts separately. That convenience is real. It is why small businesses, agencies and local teams buy hosting. The provider absorbs complexity and bills it as a service.

The risk is that the same convenience hides the asset boundary. A customer invoice may say web hosting, managed server, cloud, email, DNS or maintenance. The physical dependency may be one cabinet in Sydney, a reseller account under a wholesale provider, a virtual machine in Singapore, a control panel on a separate platform, a backup stored in another country, or a domain/DNS account held by a third party. The invoice phrase rarely exposes those layers.

ATWWW's public record is a reminder that old hosting businesses can leave long shadows. The ASN and /22 show a historical route footprint. The Dubs web presence shows corporate continuity but not live ATWWW-owned network capacity. The QUAPE route for The Dubs' present site shows how a business can have current web reachability through another provider entirely. None of those facts is suspicious by itself. Together, they mean a customer should not assume that the old hosting supplier still has direct control of the physical stack.

Hosting economics also explain why a thin public footprint deserves a downgrade. If AS23867 is not announced and the old /22 is not routed, a buyer cannot inspect current prefix count, transit diversity, RPKI state for live routes, exchange participation, traffic trend, route stability or neighbour changes. The absence of public data does not prove every service is gone. A provider can use upstream address space, hyperscale cloud, reseller hosting or private contracts. But it does mean the old ATWWW network itself cannot be credited with current customer-facing capacity without additional proof.

The economics question is therefore: who is being paid to keep the service alive, and which assets do they actually control? If the answer is not visible in the current route table, it has to be visible in contracts, service inventories and recovery tests.

Rack location is a fact, not a brand feeling

The directory name says Sydney, and the old APNIC records say Sydney in several ways: The Rocks, 13 Hickson Road, 100 Harris Street, and Australia as country. That gives the story a local anchor. It does not give a rack coordinate. There is no public evidence here that AS23867 currently occupies a specific data centre, owns cabinets, leases cages, has cross-connects, or maintains powered hardware in Sydney.

That distinction is not pedantic. Data locality, latency, support access and failure recovery all depend on where the equipment actually sits. A Sydney office address is not a data hall. A web-design address is not a colocation footprint. A national country code on an ASN is not a guarantee that customer data, backups or management access stay in Australia.

The Australian interconnection market gives buyers good questions to ask. The Internet Association of Australia describes itself as operating IX Australia, and its peering page states that IAA hosts seven internet exchanges across Australian locations, including Sydney, and colocates equipment in data centres with port speeds from 10 Gbps through 400 Gbps. That does not mean ATWWW is present on IAA or in any particular Sydney facility. It means a real Sydney hosting footprint should be able to name a facility, a carrier path, an exchange or transit plan, and the exact operational role of each location.

For ATWWW, the verified public statement should be conservative: the old resource records are Sydney-linked, but no current public facility evidence was found for AS23867. If a customer still relies on ATWWW-labelled hosting, the next step is not to ask "are you in Sydney?" The next step is to ask "which live service IPs, in which facility or upstream environment, under which contract, with which restore path, and with which proof of Australian or overseas data placement?"

Power and facility constraints decide whether the service can be restored

When the public route table is dormant, the customer cannot infer power resilience. That matters because the most painful hosting failures are often physical before they are logical. A rack loses power. A breaker trips. A UPS transfer fails. A remote-hands queue backs up. A switch fails with no spare on site. A fibre cross-connect is moved during a maintenance window. A support team can see the alarm but cannot reach the cage.

If ATWWW or a successor account is still providing any hosted service, the facility evidence should answer six questions. First, where is the live production equipment or platform account? Second, who has physical or administrative control? Third, which power domains and carrier entrances are used? Fourth, which spares are stocked locally? Fifth, who can approve emergency work after hours? Sixth, where is the recovery copy if the primary site cannot be restored?

The public ATWWW evidence does not answer those questions. The old /22 and ASN prove a historical network identity. The empty current route state says that identity is not now visible as an independent BGP origin. That makes the facility question more important, not less. A service may have moved to a wholesale provider, a hosting reseller platform or a public cloud account. In each case the customer's true failure path changes.

For example, a wholesale-provider migration can improve facility resilience while weakening portability if the customer's IP addresses, backups or control panels are now tied to a new supplier. A public-cloud move can improve hardware replacement while shifting the support path to account recovery, identity management and region choice. A dormant legacy server can be worse than either: still billing, still depended on, but with unknown spares and no independently observable route footprint.

The buyer should ask for a recent restore test. Not a promise. Not a generic service page. A timestamped restore result showing what was restored, where it landed, how long it took, who approved it, and what data or configuration did not come back.

Transit failure is invisible until the remaining path is tested

The old route policy for AS23867 mentions AS7474 and AS1221. Those were meaningful Australian upstream clues. But a transit relationship is only useful if it is current, paid, configured, monitored and large enough for the failed state. A line in an old registry entity does not carry packets.

Current evidence is the other way around. AS23867 has no current announced prefixes in RIPEstat. It has no current observed neighbours. The old prefix is not announced. The PeeringDB query has no profile. RIPEstat RPKI validation for 202.46.132.0/22 with origin AS23867 shows status: unknown and no validating ROAs. APNIC's RPKI guidance explains that route origin authorizations help prove which ASN may originate a prefix, and RFC 6811 describes BGP prefix-origin validation states. For the old ATWWW route pair, the visible state is not a current valid origin.

That does not mean a customer service using another provider is insecure. It means the old ATWWW route cannot be credited with route-origin protection or transit diversity today. If service now runs elsewhere, the relevant RPKI, upstream and neighbour evidence belongs to the new routed prefix and origin ASN. The Dubs public site is a good example: its current address resolves into QUAPE PTE LTD's AS131582 route, so the route-risk review would follow QUAPE's prefix, not AS23867.

Transit failure should be tested twice. The provider should show that it can lose one upstream or facility path without losing reachability. The customer should also test whether it can move away from the provider if the provider itself fails. In hosting, failover and exit are different capabilities. A provider can have within-platform redundancy but poor data portability. A customer can have a backup but no tested DNS, certificate, database and application restart plan. The route table will not save either side if those steps are not rehearsed.

Hardware stock and support labour are part of capacity

The phrase "hosted capacity" can make capacity sound like a number on a plan. In practice it is a combination of inventory and labour. A provider needs servers, disks, optics, routing cards, spare cables, console access, passwords, supplier accounts, monitoring and enough qualified people to act when the alarm is not routine.

ATWWW's public evidence does not expose any of that current capacity. It does not show active hypervisors, storage clusters, backup servers, inventory, support rosters or remote-hands contracts. The absence is normal for a private hosting supplier, but the route-table downgrade means there is no independent public sign that an ATWWW-owned edge is carrying customers. A buyer should therefore demand operational proof if any service is still sold or renewed under the ATWWW label.

Support labour deserves equal weight with hardware. A single knowledgeable administrator can keep a small hosting environment running for years, but that same concentration becomes a customer risk during illness, leave, staff changes or a serious incident. A larger provider can have more staff and still fail if the first-line team cannot reach the people who control DNS, backups, billing, domains or the virtual platform.

The support test should not be abstract. It should ask for the route from customer ticket to qualified operator. Which channel works if the hosted site is down? Which phone number is staffed after hours? What proof of identity is needed to approve a restore? Can the provider export a complete copy if the control panel is broken? Who can change DNS if the account owner is unavailable? How are incidents communicated if the provider's own website or email shares the affected platform?

For a dormant or migrated network identity, the support question becomes even sharper: who, today, can act on the old accounts, old IP references and old domain relationships?

Billing and account control can fail like a router

Hosting failures do not always begin with a failed port. They can begin with billing. A card expires, an account is suspended, a domain renewal fails, a control-panel licence lapses, a reseller account is locked, or an ownership dispute prevents support from acting. To the customer, the result can look like an outage even though the physical infrastructure is fine.

ATWWW's public record has several account-control clues. The APNIC RDAP records have old and current contact references. The abuse contact was validated in 2026 through a The Dubs email address. The current public The Dubs site runs on a different provider network. The old ATWWW ASN is dormant. The old /22 is dormant. Those facts do not show a billing problem. They show a situation where account boundaries may have changed over time.

That is exactly the kind of setting where customers should identify the legal and administrative owner of every dependency. Who bills the hosting? Who controls the domain registrar account? Who controls DNS? Who controls certificates? Who has the root or administrator account? Who can authorize an export? Who owns the IP addresses in any firewall allowlist? Who can respond to abuse or security notices?

The answer may be simple. It may be The Dubs, a successor provider, a wholesale platform, a cloud account, or a customer-owned migration. But it should be written down. If the customer only knows "ATWWW handles it", the customer does not know enough.

Billing and account control also determine the exit path. A provider that is technically competent can still trap a customer if exports are incomplete, nameservers are not under customer control, or account ownership cannot be proved. For legacy web hosting, the assets to test are mundane but vital: web files, databases, mailboxes, DNS zone files, TLS certificates, cron jobs, analytics tags, redirects, access logs, backup archives and any hardcoded IP dependencies.

Data sovereignty is a placement and control question

The article's topic includes data sovereignty and locality because the ATWWW evidence spans Australia and Singapore in a way a customer could easily misread. The historical ATWWW number resources are Australian. The Dubs current website is associated with a Sydney sub-organization but resolves to QUAPE PTE LTD address space in Singapore. That is not automatically a privacy problem. It is a reminder that country labels at different layers answer different questions.

The OAIC guidance on APP 8 says an Australian Privacy Principles entity generally must take reasonable steps before disclosing personal information to an overseas recipient and can remain accountable for certain overseas handling. It also explains that cloud storage with effective customer control can be analysed differently from disclosure in some circumstances. The practical point for hosting buyers is clear: the location of the office, the ASN country, the web server IP, the backup repository and the support team may differ, and each difference can change the control and compliance analysis.

For ATWWW, no public record proves that customer data currently sits in Australia under AS23867. No public record proves that customer data sits in Singapore either, except for the narrow fact that the current The Dubs website is served from an IP registered to a Singapore provider. A customer must not generalize from The Dubs' corporate site to every ATWWW-labelled service. The evidence should instead lead to a placement inventory.

That inventory should list production data, backups, logs, email, DNS, management access, support tickets, security monitoring and billing records. For each item, the customer should know the country, the operator, the subcontractor if any, the retention period, the export format, the deletion process and who can access it. Data locality is not a slogan. It is a table of places and powers.

Route security helps only after there is a route to secure

RPKI and routing-security practice matter for hosting, but they cannot create current service where none is visible. For ATWWW, the old route pair 202.46.132.0/22 from AS23867 has an unknown validation state in the RIPEstat RPKI validation check. That means no validating ROA was found for that prefix/origin pair in the query. Since the prefix is not currently announced, the immediate risk is not that customers are being served by an invalid ATWWW route. The immediate point is that the old network cannot be counted as a validated current origin.

The broader lesson comes from MANRS for Network Operators, which describes filtering, anti-spoofing, coordination and public routing data as minimum actions for safer routing. RFC 7454 gives operational guidance around BGP filtering and security. RFC 7908 defines route leaks as a class of BGP failure that can misdirect traffic even when the servers themselves are healthy.

Those practices are relevant to any live hosting edge. A current provider should know which prefixes it originates, which ROAs cover them, which route objects exist, which neighbours accept them, and what happens if an invalid route appears. If the service has moved from AS23867 to another network, the customer should apply the same review to the new origin AS. If the service is no longer live, the customer should remove stale IP references rather than treating old routing data as resilience.

Routing security is not the whole service. It does not prove backup integrity, support readiness, database consistency or physical redundancy. But it is a basic check for any customer-facing hosting network. The absence of a current ATWWW route removes one thing to audit and raises another question: what live network, if any, is actually carrying the workload?

Migration risk is the hardest legacy problem

Legacy hosting dependencies often survive because migration is irritating. A site still works. A mailbox still receives orders. A DNS record still points somewhere nobody wants to touch. The budget for a clean rebuild is always next quarter. Then a provider disappears, a control panel breaks, a TLS certificate expires, a PHP version changes, a nameserver fails, or a billing login is lost.

ATWWW's public evidence is exactly the kind that should trigger a migration audit. The old ASN is dormant. The old /22 is dormant. The current The Dubs web presence is elsewhere. The old contact data has changed over time. The public records do not show a live customer-hosting platform under AS23867. If a customer still has a business process tied to ATWWW-era infrastructure, the risk is not just outage. The risk is that the customer will not know where to recover from.

A proper migration test starts with discovery. List all domains, DNS zones, mailboxes, databases, web roots, redirects, API endpoints, cron jobs, certificates, third-party integrations and IP allowlists. Identify which are active, which are abandoned, and which are business critical. Then test export and restart on a neutral destination. The first migration test should not wait for a crisis.

The provider-contract question is also important. If a current service is provided by a wholesale or reseller platform, the customer needs to know whether the contract allows direct support from the underlying provider during failure, whether data can be exported without the reseller, and whether DNS or IP addresses can be moved if the reseller relationship ends. A cloud account owned by the provider is different from a customer-owned cloud account. A backup visible in a control panel is different from a backup the customer has downloaded and restored.

The operating rule is simple: if the customer cannot prove the restore, the customer does not yet own the exit.

Who is affected when this kind of system fails

The affected population depends on what, if anything, remains under ATWWW-labelled service. If the only remaining evidence is historical number resources, the affected party is mainly the corporate owner and anyone cleaning up stale records. If old customer websites, email or DNS still depend on legacy accounts, the affected parties are the businesses whose public presence, forms, mail delivery or customer support depend on those accounts. If firewall allowlists or supplier integrations still reference the old /22, the affected parties may include partners who do not know the route is gone.

Small hosting failures often spread through trust rather than traffic volume. A local business may lose email. A financial-marketing client may lose a campaign landing page. A supplier API may reject a migrated server because the source IP changed. A domain may expire because the person who held the login left years ago. A backup may be useless because the database dump exists but the application version does not.

The Dubs connection makes this especially worth checking, but not because it proves a current ATWWW service. The Dubs is a current public business with Sydney, Singapore and London signals on its website. If any historical ATWWW infrastructure obligation remains inside that business or its clients' archives, the gap between old network evidence and current corporate presence could hide it. The responsible step is inventory, not speculation.

Customers should ask who would be notified if the old /22 were permanently retired, who would be responsible if abuse notices arrived, who can answer questions about historical logs, and who can help former customers migrate. Even a negative current network finding has operational work attached to it.

The verification plan for a buyer or auditor

The first verification step is to identify live service IPs. Do not begin with the company name. Begin with the domains, mail exchangers, VPN endpoints, application URLs and control panels the customer actually uses. Resolve them. Map the resulting IPs to current prefixes and ASNs. If they point to AS23867 or 202.46.132.0/22, the public routing data should immediately be rechecked because the July 2026 evidence says those routes are not announced. If they point to QUAPE, Servers Australia, a hyperscale cloud, a CDN or another hosting provider, the audit should follow that live provider.

The second step is to map control. Who owns the domain registrar login, DNS provider, hosting account, cloud account, certificates, backups and billing? Who can authorize changes? Who can export data? Who can revoke old access? Control is often more important than brand.

The third step is to test restore. Restore a copy of the site, database, mail and DNS on a separate destination. Measure the time, document the missing parts, and test whether the application can run without old private assumptions. If mail is involved, test SPF, DKIM, DMARC, mailbox export and inbound cutover. If a fixed IP is involved, test whether partners can accept a new address or whether the old allowlist still drives operations.

The fourth step is to test support. Open a non-emergency ticket and an emergency path. Confirm that the support team can identify the account, the platform, the data location and the recovery owner. Ask for a written maintenance and incident-notification process. Ask what happens if the provider's own website or email is unavailable.

The fifth step is to test locality and contract terms. Ask where production data, backups, logs and support records are located. Compare the answer with the OAIC APP 8 questions if personal information is involved. Ask whether subcontractors or overseas hosting providers are used. Ask how deletion and export work at the end of service.

These steps are not special to ATWWW. ATWWW is a useful case because the public evidence forces the discipline. A live-looking company trail and a dormant route table can coexist. The only safe response is to follow the live workload.

The bottom line

ATWWW Pty Ltd, Web Hosting and Design, Sydney has a real place in Australian internet history. AS23867 is registered. 202.46.132.0/22 is an APNIC-assigned portable block labeled ATWWWNET. The records carry Sydney addresses and The Dubs contact continuity. The old route history shows years of public visibility, followed by later origin through another Australian wholesale network.

The current public operating evidence is negative. AS23867 is not announced. It has no current public prefix list, no current neighbours, no PeeringDB profile, no current path-length data, and no recent BGPlay state. The old /22 is not announced. The old AS23867/prefix pair has no visible validating ROA in the check. The current The Dubs site sits on QUAPE PTE LTD's AS131582 address space rather than ATWWW's ASN.

That does not prove that every ATWWW-era customer dependency is gone. It proves that the old ATWWW network cannot be credited as live customer-facing capacity from public routing evidence. If someone is still buying or relying on a service under this name, the burden shifts to current proof: live IPs, facility or platform location, provider contracts, support escalation, backup and restore tests, route-security state, data-location terms and a clean migration path.

The practical advice is unsentimental. Treat ATWWW as a historical Sydney-linked hosting identity unless current service evidence says otherwise. Do not rely on the old ASN as resilience. Do not rely on the corporate web page as proof of infrastructure. Follow the workload, test the restore, and make sure the customer can leave before a rack, upstream, account or support path fails.