IBC Digital and AS10078: Hosting, DNS, Connectivity, and Operational Continuity Costs

Summary

IBC Digital is the trading identity tied in public APNIC records to Keltree Pty Ltd as trustee for The Kelly Family Trust, the same company object represented in the BTW directory.[1][2]
APNIC records show an active AS10078 object and an active portable allocation for 203.24.93.0/24. These registry facts identify accountable records; they do not prove how traffic is currently engineered.[3][4][5]
A bounded RIPE NCC observation found no prefixes directly announced by AS10078, while 203.24.93.0/24 was visible from 328 of 328 queried IPv4 full-table peers with observed origin AS56035. The RPKI query returned unknown, not invalid.[6][7][8][9]
IBC's public materials describe managed and self-managed hosting, DNS, monitoring, backups, patching, staging, system integration, and support. Those descriptions establish an offered capability and operating model, not measured uptime or a customer production result.[10][11][12][13][14][15][16][17][18]
The recurring cost is not limited to servers or bandwidth. It includes supervision, integration, maintenance, exception handling, evidence quality, responsibility boundaries, recovery testing, and the ability to move when a supplier, application, route, credential, or business requirement changes.

Image note: The accompanying Creative Commons photograph shows a historical data-centre room at the University of St. Gallen. It provides generic physical-infrastructure, maintenance, and operator-continuity context only. It does not depict IBC Digital, Keltree Pty Ltd, AS10078, AS56035, an IBC facility, a customer deployment, a service incident, measured reliability, or a production outcome.[19]

IBC Digital presents an unusually useful company object for infrastructure research because its public record crosses several layers that are often discussed as if they were one system. The current BTW directory names the exact legal and trading identity. APNIC records expose an autonomous-system entry and portable IPv4 space. DNS answers expose a current naming surface. RIPE NCC measurements expose a bounded view of routing state. IBC's own website and documents describe hosting, maintenance, integration, monitoring, backup, patching, and support processes. A terms document assigns responsibilities and limits.

Together, these sources show an operational landscape. They do not collapse into a single proof of performance.

That distinction is the core of the analysis. A registry entry can be accurate while a route is originated through a different autonomous system. A prefix can be globally visible while a specific application is unavailable. A hosting plan can include monitoring while its detection quality, escalation speed, and recovery performance remain unmeasured. A patch process can be well described while a particular application still contains unsupported dependencies. A service provider can offer backup and disaster-recovery options while a customer's restore path remains untested.

Each layer has its own evidence, owner, failure modes, and maintenance burden.

The public evidence therefore supports a reality-layer reading rather than an advocacy narrative. Number-resource registries are important recordkeepers, but they are not the running network. Current routing observations are operational signals, but they are not a complete history. Service pages describe intended capabilities, but they are not independent reliability studies. Contracts reveal risk allocation, but they do not eliminate operational risk. Customer outcomes require evidence from the customer system, measurement period, workload, change history, and recovery record. None of those should be invented.

The exact company identity and its public network records

The BTW directory entry identifies the company as Keltree Pty Ltd as trustee for The Kelly Family Trust T/A IBC Digital.[1] APNIC's member directory uses the same Keltree and IBC trading-name relationship, which provides an independent registry-side identity bridge rather than relying only on branding from a commercial website.[2] This matters because a technology company can operate under a trading name while contracts, resource registrations, invoices, and abuse contacts use a longer legal identity. Research that treats those strings as unrelated can miss the accountable entity; research that merges similar names without evidence can create a false match.

APNIC's Whois record for AS10078 describes the object as KPLATKFT-AS-AP and associates it with Keltree and IBC.[3] APNIC RDAP reports the autonomous-system object as active and supplies structured registrant, administrative, technical, and abuse-role records.[4] A separate RDAP object covers 203.24.93.0/24 as active portable address space associated with the same company identity.[5] These records are valuable because they preserve identifiers, role contacts, status, and registration history in machine-readable or operator-readable forms.

They should not be overread. An active ASN record does not by itself prove that the ASN is originating routes today. A portable IPv4 allocation does not prove that every address is used, reachable, secure, or served from a company-owned facility. A recorded contact does not prove that the person or mailbox will respond within a particular interval. The registry is a ledger of authority and responsibility. The running Internet is expressed through routing announcements, DNS delegations, server configurations, access controls, applications, and operational decisions made after the record was created.

This separation also avoids a common ownership mistake. A resource can be registered to one organisation and announced through another network under an agreed arrangement. A hosting company may use upstream transit, data-centre connectivity, managed routers, cloud services, or a partner ASN without surrendering every responsibility for the service that its customers buy. Conversely, having an ASN or portable prefix does not mean the company directly operates every router, path, facility, or security control involved in delivery.

The useful question is not simply "Who owns the number?" It is "Which party controls each decision, which record captures that authority, and how does the running configuration remain consistent with it?"

For IBC Digital, the public identity chain is strong enough to support a company-specific investigation. It connects the directory object, APNIC membership, AS10078, and 203.24.93.0/24. The chain does not reveal the full corporate structure, supplier agreements, private network diagram, current equipment inventory, or customer topology. Those remain outside the evidence.

Registry state and running routing state are different surfaces

RIPE NCC's Routing Information Service offers a timestamped observation rather than a permanent verdict. At the capture used for this research, its routing-status and announced-prefix data for AS10078 showed no prefixes directly announced by that ASN.[6][7] That observation must not be described as an outage. An ASN can remain active in a registry while not originating routes at a particular time. It may be retained for portability, future use, policy history, a non-public context, or an arrangement that is not visible as direct origination from the queried collectors. Public evidence here does not identify the reason.

The portable prefix tells a different current story. RIPE NCC's routing-status data for 203.24.93.0/24 showed the prefix visible from all 328 queried IPv4 full-table peers, with AS56035 observed as the origin.[8] That is evidence of broad visibility at the observation time. It is not evidence of a historical service level, end-to-end application correctness, absence of route leaks, optimal paths, or customer satisfaction. BGP visibility answers whether collectors can see a route and its observed origin.

It does not answer whether a web request succeeds, whether packets follow the intended commercial path, or whether a database transaction completes correctly.

The different ASN identities create a useful operational question without licensing speculation. APNIC ties AS10078 and the portable /24 to Keltree/IBC. RIPE RIS observed AS56035 originating the /24. A responsible operating model should be able to explain that relationship through current authorization, supplier records, routing policy, change control, and incident contacts. The public record does not establish whether AS56035 is an upstream, managed network, hosting partner, historical arrangement, or another authorized operating role.

The correct conclusion is simply that registry identity and observed origin differ and should be reconciled by accountable operators.

RPKI adds another boundary. The RIPE NCC validation query for AS56035 and 203.24.93.0/24 returned unknown with no validating Route Origin Authorization found for the observed pair.[9] Unknown is not invalid. It means the available validation path did not produce a valid or invalid result under the queried state. Calling it invalid would turn an absence of validating data into a claim of conflict. Calling it secure would be equally unsupported. The operational task is to understand whether a ROA is intended, who can authorize it, how max-length and origin choices should be governed, and how a change would be tested without disrupting legitimate announcements.

These distinctions create at least five records that must remain coherent: the APNIC organization and contact record, the AS10078 aut-num object, the 203.24.93.0/24 inetnum object, the authorization or commercial basis for observed origination, and the live route seen by external collectors. DNS and application configuration add further layers. A mismatch can be benign, planned, stale, or dangerous. Classification requires evidence. It cannot be replaced by a traffic-light label generated from one query.

DNS exposes another control surface

At the research observation time, ibc.com.au returned IPv4 address 203.24.93.37, no IPv6 address in the bounded query, authoritative nameservers ns1.ibc.com.au and ns2.ibc.com.au, and a Microsoft-protection mail exchanger.[5][8] These answers connect the company's public domain to the registered /24 and expose role separation across web addressing, authoritative DNS, and email handling. They do not disclose every hidden origin, reverse proxy, firewall, backup site, or provider relationship.

The nameserver pattern also illustrates why DNS requires its own supervision. Two labels do not automatically imply two independent failure domains. Independence depends on address diversity, routing, hosting, software, credentials, change paths, monitoring, and recovery authority. Public names alone cannot prove those properties. An operator should know whether both nameservers can be changed through the same account, whether an erroneous zone template can affect both, whether stale glue or registrar access can delay recovery, and whether external resolvers observe the same intended answers.

The absence of an AAAA answer in one bounded query should also be treated as an observation, not as a universal capability judgment. It says that the queried name did not return IPv6 at that point. It does not show whether other services use IPv6, whether an IPv6 migration is planned, or whether the design deliberately remains IPv4-only. The responsible analysis identifies the gap without inventing strategy.

Email further broadens the dependency map. A Microsoft-protection MX record shows that mail delivery involves a provider distinct from the web address and authoritative nameserver labels. A domain incident can therefore involve registrar authority, DNS hosting, web hosting, mail configuration, certificate state, and provider-specific administration. Recovery requires the right credentials and contacts across all of them. A company can have a reachable website while mail is impaired, or valid mail routing while the web application is unavailable. A single "site up" indicator is not enough.

DNS is also where portability becomes concrete. Zone data, registrar access, nameserver changes, DNSSEC state if deployed, certificate validation records, mail-verification records, and application endpoints must be exportable and understandable before a provider change. An emergency migration that begins with reconstructing records from screenshots is already late. Good continuity treats the namespace as a controlled asset with an approved inventory, outside observation, and rehearsed authority path.

What IBC's hosting materials establish

IBC's current hosting page describes Australian-hosted website, application, and mobile-middleware services. It names NEXTDC P2 Perth as the production location, NEXTDC P1 Malaga for backup and disaster-recovery capability, and a separate HostAway Malaga environment for staging and user-acceptance testing where an active maintenance agreement applies.[10] The page lists websites, content-management systems, web applications, databases, search and caching components, monitoring, patching, backups, access control, TLS, web-application firewall configuration, controlled releases, and optional higher-availability designs.[10]

Those are first-party capability claims. They show what IBC says it can provide and how it frames the service. They do not independently verify that every customer receives every control, that the controls operated continuously during a defined period, or that a specific recovery met an objective. The page recommends a 99.9 percent availability model for many clients and says higher-availability designs can be priced where requirements justify the cost.[10] A recommendation is not a measurement. An architecture option is not proof that it was purchased, correctly implemented, or successful under failure.

An older hosting plan document provides additional historical detail.[11] It described full-service and self-service options, dedicated virtual servers, DNS services, monitoring, backup, firewalls, physical access controls, redundant providers, environmental controls, and facilities in Perth and Sydney. Because the document was prepared in 2018 and reflects a different facility description from the current page, it should be read as historical evidence of the service model, not as a current inventory. The change itself is instructive: facilities, providers, technologies, and commercial plans evolve.

Operations need a mechanism to retire stale documents, update runbooks, and prevent an old promise from being mistaken for present configuration.

The same document separated managed hosting from control-panel self-service.[11] That split changes responsibility. In a managed arrangement, the provider may perform more configuration, patching, monitoring, and response. In a self-managed arrangement, the customer assumes more application and account work. Yet neither model removes shared boundaries. The customer still controls content, business decisions, user access, and requirements. The provider still controls parts of the environment and escalation path. Suppliers control other facilities or networks.

A failure at the boundary can produce delay even when every party performs its own narrow task.

IBC's 2022 hosting terms make that allocation more explicit.[12] They allow maintenance windows, set service and liability boundaries, assign customers responsibility for supplied material and application security, permit security action against content that threatens shared systems, and describe testing before material becomes operational. They also address data handling, connectivity to remote client locations, access codes, termination, and liability limits.[12] These clauses do not tell us how often incidents occur. They show which exceptions the operating model anticipates and how financial or legal exposure is distributed.

The terms require customer applications to remain patched and describe a ten-day period for applying open-source security patches, sooner where possible.[12] IBC's separate patch-management service describes a more detailed workflow: daily availability checks for critical updates, monthly application to a test environment, client testing, scheduled production deployment one week after testing unless a hold is requested, source control, a separate test environment, and bounded minor-issue coverage.[13] Larger problems, server operating-system or PHP upgrades, unsupported modules, and major core upgrades require separate work or

quotation.[13]

That is a realistic boundary. Routine patching is not the same as lifecycle modernization. A security update may be simple when dependencies remain supported and tests are representative. It becomes a project when a plugin is abandoned, a runtime version is obsolete, an integration relies on deprecated behavior, or a database change cannot be rolled back safely. The cost moves from predictable maintenance into exception handling. Customers who budget only for routine patches accumulate risk precisely where the standard process stops.

System integration turns hosting into dependency management

IBC's system-integration page describes work across cloud APIs, on-premises environments, legacy servers, security controls, staging, functional and performance testing, documentation, post-integration monitoring, changing data fields, and changing authentication flows.[17] These descriptions matter because most production systems are not isolated websites. They exchange identity, content, orders, payments, files, notifications, records, and analytics with systems controlled by different teams and vendors.

An integration creates at least two contracts: the technical interface and the organizational response path. The technical contract includes endpoints, schemas, authentication, certificates, rate limits, retries, timeouts, ordering, data validation, and error semantics. The organizational contract identifies who can change each side, who receives alerts, who approves data repair, and who decides whether to pause or roll back. Documentation can describe both, but only rehearsed operations show whether they work under pressure.

Legacy integration raises specific costs. A protocol may remain functional while its library is unsupported. An on-premises endpoint may be reachable only through a narrow firewall rule or an account known to one administrator. A scheduled file transfer may have no idempotency guarantee. A field added by one system may be silently truncated by another. A certificate rotation may require coordinated deployment across organizations with different maintenance windows. None of these is solved by saying that the systems are "integrated."

Modern cloud APIs create different constraints rather than eliminating them. Provider authentication changes, quotas, webhooks, regional failures, version retirements, and data-residency rules all require monitoring and ownership. A managed provider can absorb part of that work, but the customer must still authorize changes and understand business impact. Integration reliability is an end-to-end property. A provider can keep its middleware healthy while the upstream API rejects requests or the downstream business process applies data incorrectly.

IBC's process page says a project manager is assigned, requirements are discussed, and project-plan documents cover specifications, responsibilities, schedules, and budgets.[15] This is a capability and workflow claim. Its analytical importance is that technical work includes coordination. Requirements must be converted into explicit acceptance tests. Responsibilities must be named before a failure. Budgets must include maintenance rather than only implementation. A plan can reduce ambiguity, but it does not prove that a particular project met time, cost, security, or performance goals.

The service-plan page exposes another operational mechanism: time-based support.[16] It distinguishes monthly plans, prepaid blocks, and casual service, with shorter billing intervals for planned arrangements and authorization requirements for casual work. That model reveals a hidden incident variable: approval latency. A technically simple change can wait for a purchase order, named approver, or budget decision. A prepaid arrangement may reduce that delay. Neither choice is inherently correct; the important point is that administrative readiness affects recovery time.

Four recurring operating-cost classes

The visible evidence supports four cost classes that are broader than hosting fees.

1. Supervision cost

Supervision is the work of observing the system, interpreting signals, assigning ownership, and verifying recovery. Monitoring products can check availability, resource use, certificates, logs, backups, DNS, and routes. They cannot determine every business consequence without context. An alert needs a threshold, suppression rule, escalation path, and operator who can distinguish a real fault from expected maintenance or a bad vantage point.

For IBC's public control surface, supervision could include the domain's DNS answers, nameserver reachability, certificate status, application checks, prefix visibility, observed origin, abuse contact health, backup jobs, patch state, and integration queues. The public evidence does not show IBC's actual dashboards or alert design. Those examples are control requirements derived from the exposed dependencies, not claims about an internal implementation.

Supervision also requires outside views. A service can report itself healthy while external DNS, routing, or certificate validation fails. A route can be visible at collectors while a particular access network has a path problem. A web endpoint can return HTTP 200 while a login, search, form submission, or scheduled integration is broken. Layered monitoring costs more than a single ping because it is designed to detect different failure classes.

2. Integration cost

Integration cost begins before code. Teams must agree on identifiers, data ownership, security boundaries, failure semantics, retention, and change authority. During implementation, they build adapters, test environments, credentials, network paths, deployment procedures, and reconciliation tools. After launch, they maintain versions, certificates, permissions, documentation, and test data.

The cost rises when one side is legacy, weakly documented, or governed by another organization. It also rises when the integration is business-critical but low-volume: rare transactions produce little routine evidence, so teams may discover an error only during an exceptional event. A mature operating model keeps a synthetic or controlled test path, reconciles expected and actual records, and preserves a manual procedure for high-impact exceptions.

3. Maintenance cost

Maintenance includes patching, runtime upgrades, database care, configuration review, capacity changes, certificate renewal, account review, documentation, backup validation, and removal of obsolete components. IBC's patch page makes the boundary between routine and exceptional work visible.[13] A small compatible update can follow the monthly test-and-release path. An unsupported module or major platform upgrade cannot be treated as the same task.

Deferral changes the shape of cost. Holding a patch may reduce immediate change risk while increasing exposure and future integration effort. Upgrading immediately may reduce known vulnerability exposure while introducing compatibility risk. The decision needs severity, exploitability, dependency, test coverage, rollback, business calendar, and compensating controls. "Patch faster" is not a complete policy, and "avoid change" is not a continuity strategy.

4. Exception-handling cost

Exceptions are where capability is tested. A route appears from an unexpected origin. A DNS record differs from the approved state. A customer asks to hold a security update. A plugin is abandoned. A restore produces incomplete data. A certificate expires during a freeze. An upstream API changes authentication. A suspicious upload threatens a shared host. A supplier account is locked while the named administrator is unavailable.

Each exception needs authority, evidence, containment, communication, and a path back to controlled state. The hosting terms anticipate some of these situations by allowing IBC to test, remove, or suspend threatening content and by assigning customer responsibilities.[12] Those rights may protect a shared environment, but exercising them can affect availability. The operating design should therefore define who is contacted, what evidence is preserved, what minimum service can continue, and how the customer verifies restoration.

Exception handling is often priced outside standard service because it is uncertain and labor-intensive. The cost is not a defect in itself. Pretending the cost does not exist is the risk. Buyers need to understand which work is included, which requires authorization, and which can proceed during an urgent security or continuity event.

Conditional failure modes and the controls they require

The following failure modes are derived from the public control surface. They are not claims that IBC Digital or any customer experienced them.

Registry-to-routing divergence

The registered organization, ASN, prefix, and observed route origin may cease to match the intended arrangement. The cause could be a planned provider migration, an obsolete record, a leaked route, or an unauthorized announcement. A control should compare approved origin policy with outside observations, preserve current supplier authorization, and identify who can change routing or registry records. A response should not automatically withdraw a route based on one collector; it should verify scope and authority first.

RPKI ambiguity

An unknown result can be mistaken for invalid, or the absence of a ROA can be treated as proof that no change is needed. The control is an explicit origin-authorization policy. If a ROA is intended, authorized staff need access, a reviewed prefix and max-length design, and external validation after publication. If it is not yet intended, the risk and migration path should be recorded. Automation should preserve the three-state meaning of valid, invalid, and not found.

DNS authority loss

Registrar credentials, nameserver access, or zone ownership can become concentrated in one person or account. A compromised or unavailable account can block correction. Controls include named organizational ownership, multifactor authentication, recovery contacts, role-separated approval for high-impact changes, an export of the approved zone, and external monitoring. Recovery exercises should verify that people can actually reach the registrar and DNS provider rather than merely possessing a written procedure.

Common-mode nameserver failure

Two nameserver labels can share the same software, network, facility, credentials, or configuration pipeline. A single error may affect both. Controls should examine real failure domains, not count labels. External tests can compare address, route, response, and DNSSEC behavior. Change rollout canarying or independent verification can reduce the chance that one bad zone or deployment reaches every authority at once.

Stale address-to-origin assumptions

A domain can continue resolving to an allocated address while the intended service moved, a proxy changed, or the observed route origin changed. Asset inventories should link domain, address, prefix, origin, provider, certificate, and application owner. Changes should update the inventory and outside tests. This is especially important when portable address space is announced through a partner or upstream ASN.

Patch hold without compensating controls

IBC's process allows a customer to request a hold after testing.[13] A hold can be reasonable when a patch breaks essential functionality, but it creates a period in which the old state remains exposed. The decision record should include the reason, affected version, exploitability, access restrictions, monitoring, rollback or repair owner, and an expiry date. An indefinite hold without ownership turns a temporary exception into unmanaged technical debt.

Unsupported component trap

A plugin, module, runtime, or library may no longer work with a supported platform. Routine patch service may exclude the replacement work.[13] A control should inventory support status and identify end-of-life dependencies before an urgent security update forces the issue. Budget and schedule need room for removal or replacement. A customer should also know whether source code, data, and configuration can move to an alternative.

Test environment drift

IBC describes separate staging and test environments.[10][13][17] A test can pass while production fails if versions, data shapes, permissions, traffic, integrations, or infrastructure differ. Controls should record material differences, refresh representative data safely, test external dependencies, and verify the exact production artifact. Staging reduces risk; it does not eliminate it.

Backup success without restore proof

The hosting materials describe backups and disaster-recovery capability.[10][11] A completed backup job proves only that a process reported success. Recovery depends on readable media, retained credentials, complete data, application consistency, compatible infrastructure, and a tested sequence. Restore exercises need defined recovery points, acceptance checks, and evidence that business-critical functions work after restoration.

Monitoring blind spot

An infrastructure check may remain green while a customer journey fails. A synthetic check may pass while a background integration queue grows. A route collector may see the prefix while a regional access network has a problem. Controls need multiple layers, but alerts must remain actionable. Too many low-quality alerts create another failure mode: operators stop trusting them.

Approval latency during an incident

Casual work may require authorization before it begins, while a plan or prepaid block can reduce that delay.[16] During a security or availability event, missing commercial approval can extend impact. Buyers should decide in advance which emergency actions are pre-authorized, which financial threshold applies, and who can approve exceptions outside business hours. This is a governance control with technical consequences.

Shared-host containment conflict

The terms permit action when customer content threatens a server or other hosted sites.[12] Immediate containment may protect the wider environment while interrupting the affected customer. The control is a documented containment ladder: restrict access, preserve evidence, isolate the workload, notify the right contact, identify the unsafe component, and establish conditions for restoration. The provider and customer need aligned expectations before the event.

Integration replay or data divergence

If an API call times out, neither side may know whether the transaction completed. Blind retry can create duplicates; no retry can lose work. Controls include idempotency keys, durable queues, reconciliation reports, and a manual exception process. The public evidence does not reveal IBC's implementation. These are necessary design questions for any integration provider and customer.

Supplier or facility transition

IBC's older plan and current page name different facility arrangements.[10][11] That does not indicate a problem; it demonstrates that operating environments evolve. A transition can affect addressing, routing, DNS, certificates, firewall rules, backup paths, monitoring, access credentials, and contracts. Controls should map dependencies, test rollback, preserve data portability, update public and internal records, and retire obsolete access after completion.

Key-person dependency

The public team and process pages describe specialist roles and project management.[15][18] Any small or specialized provider can face concentration risk when one person holds context or access. Buyers should ask whether critical procedures, credentials, supplier contacts, and architectural decisions are documented and recoverable by another authorized person. This is not a claim about IBC staffing resilience. It is a due-diligence requirement derived from the service model.

Capability, reliability, and customer outcomes must remain separate

Capability evidence answers whether a service or process exists in the provider's described model. IBC's pages and documents support claims that the company offers hosting, managed support, staging, patching, backups, system integration, and related services.[10][11][13][14][15][16][17][18] APNIC records support claims that the company identity is associated with AS10078 and 203.24.93.0/24.[3][4][5] DNS and RIPE observations support bounded claims about answers and routing at the capture time.[6][7][8][9]

Reliability evidence requires repetition over time and a defined service boundary. It might include independent availability measurements, incident records, restore tests, change success rates, route stability, DNS error rates, patch compliance, or recovery exercises. None of the public sources reviewed provides a complete longitudinal dataset for IBC's customer services. A first-party statement about monitoring or availability is relevant to the intended service, but it does not substitute for measurements.

Customer production outcomes require even more specificity. A customer may care about completed transactions, staff productivity, regulatory reporting, public access, revenue protection, or recovery of a critical process. Infrastructure can be available while the business outcome fails because data, identity, integration, or application logic is wrong. Conversely, a customer may preserve the business process through a workaround while one technical component is unavailable. Outcome claims therefore need named workloads, baselines, observation periods, and customer-authorized evidence.

This separation protects both readers and operators. It prevents an active registry record from being presented as a performance badge. It prevents broad route visibility from being called application uptime. It prevents a service catalogue from becoming a customer testimonial. It also helps a buyer ask better questions. Instead of "Is the hosting reliable?" the buyer can ask which components are measured, from which locations, with what objective, over what period, and with what restore evidence.

Due-diligence questions for buyers and operators

The following questions follow directly from the public evidence and its limits.

Entity and authority: Which legal entity signs the hosting and maintenance agreement, and how does the IBC trading name map to billing, security, privacy, and escalation contacts?
Address and routing: What is the approved relationship among AS10078, 203.24.93.0/24, and the currently observed AS56035 origin? Which party can authorize or change the route?
RPKI: Is a ROA planned for the portable prefix? If so, who controls publication, what origin and max-length policy will be used, and how will external validation be checked?
DNS: Who owns registrar and authoritative-DNS credentials? Are nameserver failure domains genuinely independent, and is an approved zone export available?
Facilities: Which current services run in each named location, and which statements in older plan documents no longer describe the current environment?
Availability: What exactly is covered by any availability objective, how is it measured, what exclusions apply, and what evidence is available over a defined period?
Backup and recovery: What is backed up, how often is a restore tested, which dependencies are included, and what customer acceptance test marks recovery complete?
Patching: Which application and infrastructure layers are included, how are urgent updates handled, and what happens when the customer requests a hold?
Unsupported dependencies: Who inventories unsupported modules, runtimes, and integrations, and how are replacement projects funded before an emergency?
Staging parity: Which production differences cannot be reproduced in staging, and how are those risks handled during release?
Monitoring: Which infrastructure and customer-journey checks run externally, and who owns each alert outside normal working hours?
Integration: Are retries idempotent, are queues reconciled, and can operators repair partial transactions without direct database improvisation?
Security containment: What actions may the provider take immediately on a shared-host threat, what evidence is preserved, and what are the restoration conditions?
Approval latency: Which urgent actions are pre-authorized, and who can approve additional work when ordinary procurement is unavailable?
Portability: Can the customer export code, data, DNS records, certificates, configuration, logs, and documentation in usable formats?
Supplier change: How are provider, facility, route, or platform migrations tested, communicated, and independently verified?
Key-person continuity: Can another authorized operator recover credentials, contacts, and system context if the usual specialist is unavailable?
Evidence: Which statements are service capabilities, which are contractual objectives, which are repeatedly measured reliability results, and which are verified customer outcomes?

These questions are not a scorecard against hidden facts. They are a way to turn a public control surface into a disciplined review. An answer can be acceptable even when the system is modest, provided responsibility, evidence, and recovery are clear. A sophisticated architecture with ambiguous ownership can be harder to operate than a simpler system with tested procedures.

What the evidence establishes and what remains unknown

The evidence establishes an exact company identity across the BTW directory and APNIC membership records. It establishes active APNIC objects for AS10078 and 203.24.93.0/24. It establishes a bounded current routing observation in which AS10078 had no directly announced prefixes in the queried data while the /24 was broadly visible with AS56035 as observed origin. It establishes an RPKI result of unknown for that observed pair. It establishes current DNS answers for the public domain.

It establishes that IBC publicly offers hosting, maintenance, patch management, system integration, and support arrangements and publishes contractual boundaries around some of that work.

The evidence does not establish why the observed route uses AS56035, whether the arrangement is temporary or permanent, or whether AS10078 is used elsewhere. It does not establish IBC's complete private architecture, supplier contracts, security controls, staffing coverage, monitoring design, incident history, capacity, route history, restore performance, or customer production outcomes. It does not prove that every service-page statement applies to every customer.

It does not prove that a local website fetch timeout observed during research was a production outage; other readers retrieved the pages, so the correct classification is vantage-specific access behavior rather than service failure.

The image is also bounded evidence. It is an archival photograph of another organization's historical data centre. It illustrates that physical infrastructure and human operation have always required supervision, maintenance, media handling, environmental control, and continuity planning. It says nothing about IBC's facilities or technology.

Conclusion

IBC Digital's public footprint is not valuable because it yields a simple verdict. It is valuable because it exposes the layers that a verdict would otherwise hide. The directory and APNIC records identify an accountable company and number resources. Current routing observations show that registry identity and live origination are not the same thing. DNS exposes another set of operational dependencies. IBC's own materials describe a managed-service model in which hosting, staging, patching, integration, support, and customer authorization meet. The terms show that risk and responsibility remain shared.

The practical lesson is that dependable hosting is an operating discipline, not a feature list. Capability must be configured. Reliability must be measured over time. Customer outcomes must be verified in the customer's real process. Supervision, integration, maintenance, and exception handling are recurring costs, especially when resources, providers, applications, and authorization paths change. A mature buyer or operator keeps the registry ledger, running configuration, external observations, contractual duties, and recovery evidence aligned without pretending that any one of them proves the rest.