Planet Information Technology Solution and AS136903: IPv4, IPv6, RPKI, DNS, and ISP Continuity Costs

Summary

• Bangladesh Telecommunications Regulatory Commission and ISP Association of Bangladesh records identify Planet Information Technology Solution Limited as an ISP business in Dhaka. APNIC separately records the organisation behind active AS136903, an IPv4 allocation and an IPv6 assignment. Together, these records support the identity of a real directory company with a network-control surface; none is a certification of current service quality.
• APNIC records 103.98.106.0/23 and 2001:df1:1780::/48 for the organisation. At the observation time, RIPE NCC's Routing Information Service showed AS136903 announcing 103.98.107.0/24 and 2001:df1:1780::/48. Allocation and assignment records describe delegated resources, while BGP observations describe a bounded running state. Neither alone proves utilisation, capacity, resilience, or customer reach.
• The current route observations showed one visible neighbouring ASN, AS137491. That is a collector-derived, time-bounded path observation. It does not prove that Planet has only one supplier, one physical path, or no private, backup, or commercially undisclosed relationship. It does make diversity and exception handling important due-diligence questions.
• RIPE NCC's RPKI validator returned valid for the observed IPv4 and IPv6 routes. A valid result supports the narrow conclusion that the origin and prefix length are covered by suitable Route Origin Authorisations at the query time. It does not prove uptime, correct filtering, full path security, incident readiness, or fulfilment of an advertised service-level commitment.
• Planet's own website advertises home and corporate internet, fibre connectivity, dedicated bandwidth, static IP, VPN-related support, BDIX or CDN access, service-level language, and support or installation commitments. These are first-party capability and product statements. No evidence set used for this article provides independent latency, loss, throughput, uptime, restoration, support-response, or customer-production measurements.
• The current public website and ISPAB directory use planet-itsolutions.com, while the legacy domain carried in the directory record returned NXDOMAIN at the observation time. This is a bounded public-identity maintenance signal, not proof of an outage, its duration, its cause, or customer impact. It highlights the cost of synchronising DNS, email, registry, association, commercial, and support records during a domain transition.
• The durable cost stack is operational: route and ROA supervision, registry and abuse-contact upkeep, IPv4 and IPv6 parity, DNS and mail ownership, supplier and customer integration, evidence retention, incident triage, exception expiry, and portability planning. Visible routes and valid origin authorisation reduce uncertainty, but they do not eliminate this work.

A small ISP with a large control surface

The directory object is Md. Abdus Salam T/A Planet Information Technology Solution Ltd. Public institutional records use the shorter company form Planet Information Technology Solution Ltd. or Planet Information Technology Solution Limited. The name variants should not be treated as interchangeable without evidence, but several independent records provide a practical bridge. ISPAB lists Planet Information Technology Solution Ltd. as member G-351 and provides a divisional ISP licence reference, a Dhaka address, a representative link, and the current website.

A BTRC list dated 23 December 2024 includes Planet Information Technology Solution Limited at row 127 with licence number 14.32.0000.702.45.591.24.292. APNIC's active autonomous-system record describes AS136903 as PITSL-AS-AP and connects it to organisation ORG-PITS1-AP.

These records establish an accountable public identity more reliably than a marketing page alone. They cover different responsibilities. BTRC is the telecommunications regulator and its dated list is evidence of a recorded licence context at a stated time. ISPAB maintains an industry-association directory. APNIC maintains number-resource and contact records. RIPE NCC's public data services provide routing observations and validation results. The company website describes products, support surfaces, and commercial positioning.

Agreement among these sources strengthens entity resolution, but it does not turn any one institution into an auditor of the others.

The company's public control surface is larger than its website suggests. It includes an autonomous-system number, IPv4 and IPv6 resources, route-origin authorisations, public BGP announcements, abuse and technical contacts, a licensed ISP identity, authoritative DNS, email routing, website hosting, service descriptions, package information, and customer-support channels. Each control can be valid while another is stale. A route can remain visible while an abuse mailbox fails. A licence record can remain online while a domain changes. A website can advertise a service-level target while no public measurement verifies it.

Continuity depends on the joins between these systems.

This is where a reality-based company assessment differs from advocacy copy. The registry is a ledger and recordkeeper. It can show which organisation and contact roles are associated with an identifier. It cannot watch every router, verify every contract, or guarantee that a listed mailbox will resolve an incident. Running BGP observations show what selected collectors saw. They cannot reveal a full private topology or customer experience. First-party pages show what the company offers or promises. They cannot independently establish that the promise was achieved.

The distinction also applies to artificial intelligence. The sources reviewed here do not support a claim that Planet develops or operates a proprietary AI model. There is no model card, benchmark, training disclosure, inference architecture, or attributable customer deployment in the evidence. It would be misleading to invent an AI capability merely because the article concerns a technology company. The relevant technical capabilities are connectivity and network control. Product reliability is a separate evidence class that requires measurements over time. Customer production results require attributable customer evidence.

This article keeps all three categories separate.

A small regional ISP can therefore have a technically significant control surface even when public disclosure is limited. The number of public pages is not the important measure. The important question is whether authority, running state, security metadata, operational contacts, and customer commitments remain aligned. That alignment is never a one-time configuration. It is a continuing management obligation.

What APNIC records and what it does not

APNIC's RDAP record for AS136903 identifies an active autonomous-system resource under the name PITSL-AS-AP and connects it to Planet Information Technology Solution Ltd. through ORG-PITS1-AP. Separate administrative, technical, abuse, and registrant roles provide an accountability structure. The organisation record supplies a public legal name and contact surface. The IRT-PITSL-BD record supplies abuse-contact information and validation dates for listed mailboxes. These are useful facts because incidents often fail at the ownership boundary rather than at the packet boundary.

An active ASN record does not mean that every service is active, healthy, or correctly configured. It means the record is active in the registry. A validated mailbox does not prove response speed or remediation quality. It indicates that a contact-validation process occurred at the recorded date. The correct operational response is to treat each registry field as a control that must be reconciled with live ownership. Role mailboxes should survive staff changes. Technical contacts should have an escalation path. Administrative contacts should be able to authorize changes.

Abuse handling should not depend on the same infrastructure that may be under investigation.

APNIC also records 103.98.106.0/23 as an active IPv4 allocation associated with Planet Information Technology Solution Ltd. A /23 contains two adjacent /24 networks. RIPE NCC's route observation discussed below showed one of those /24s, 103.98.107.0/24, announced by AS136903 at the query time. The registry allocation and the observed more-specific route are compatible facts, but they answer different questions. The allocation describes the recorded resource delegation. The route observation describes what selected collectors saw being announced.

It does not prove how every address is used, whether the other /24 is routed elsewhere or not at all, or how customer services are mapped.

The IPv6 record is similarly precise and limited. APNIC assigns 2001:df1:1780::/48 to the organisation, and RIPE NCC observed that /48 from AS136903. This is meaningful dual-stack evidence. It shows that IPv6 is not merely a line in a product description; the assigned prefix was visible in public routing at the observation time. It still does not prove that residential or corporate customers receive IPv6, that all applications work over it, or that monitoring and support provide equal coverage across protocol families.

Number resources need uniqueness, accurate records, security metadata, and continuity. Those needs produce work. The organisation must know which team owns the APNIC account, which contacts can approve changes, where credentials and recovery methods are held, how route policy is documented, and how a staff or supplier transition affects access. It should be possible to compare the approved inventory with registry records, router configuration, route collectors, RPKI repositories, monitoring systems, and customer dependencies. A mismatch should create an owned exception rather than a vague warning.

Registry records also create portability questions. An ASN and portable resources can support continuity when connectivity suppliers change, but portability is not automatic. Route policies, filters, ROAs, DNS, reverse DNS, security controls, monitoring, and customer configurations must move in a coordinated order. If an emergency forces those changes before responsibility is documented, the resource may be theoretically portable but operationally locked in.

The abuse-contact surface deserves separate attention. A public abuse role enables external parties to report harmful traffic or compromised systems. The difficult part is not publishing the address. It is triage, authentication, evidence preservation, ownership, customer coordination, legal handling, remediation, and closure. False positives and incomplete reports create exception costs. Genuine incidents may require action without disrupting unrelated customers. A registry can help a reporter find the door; it cannot guarantee what happens after the report enters.

APNIC is therefore most useful when treated as a ledger rather than a sovereign verdict. It establishes a chain of recorded identifiers and responsibilities. Running systems and accountable operators must keep that chain current. The moment a registry status is converted into a blanket reliability score, the assessment stops measuring the system that customers actually use.

Running routes narrow the factual picture

RIPE NCC's announced-prefixes data for AS136903 showed two routes in the current query window: IPv4 prefix 103.98.107.0/24 and IPv6 prefix 2001:df1:1780::/48. Its routing-status response showed visibility for one prefix in each protocol family among the queried RIS peers. These observations are valuable because they test whether the registered resources have a visible running counterpart. They narrow the gap between a paper allocation and a network announcement.

They remain observations from a particular collection system and time. RIPE RIS does not claim that every route in the world appears at every collector, and very low-visibility routes may be absent from some outputs. A visible route does not establish bilateral reachability from every customer, application availability behind the edge, capacity headroom, path symmetry, packet loss, latency, or stability across the preceding month. It says that selected BGP collectors received a route matching the query.

The difference matters when reviewing a provider. A route can be visible while a customer VLAN, access circuit, DNS resolver, authentication service, or application is failing. Conversely, a temporary collector anomaly can make a route look less visible without a customer outage. Good monitoring separates control-plane visibility from data-plane and service measurements. Each signal should have its own owner, observation window, threshold, and escalation rule.

RIPE NCC's neighbour data showed AS137491 as one observed neighbour at the latest available observation time. It is tempting to relabel that ASN as Planet's only upstream and infer a single-homed design. The public evidence does not support that conclusion. BGP paths visible to collectors may omit private peering, internet exchanges, backup links that are not currently preferred, customer relationships, route servers, or contractual details. One observed neighbour is a due-diligence question, not a topology diagram.

The question is still important. A buyer or partner can ask how many physically diverse paths support the relevant service, whether they share ducts, power, facilities, or upstream dependencies, how failover is tested, which prefixes move during an incident, and what evidence demonstrates recovery. Answers should be tied to the purchased service boundary. A provider may have multiple network relationships while a specific customer circuit still depends on one access path. The reverse can also be true.

Route observations create an integration burden. The approved prefix inventory must match router filters, routing policy, RPKI authorisations, monitoring, DDoS controls, reverse DNS, security systems, capacity planning, and customer documentation. The IPv4 announcement is a more-specific route inside the registered /23, so maximum-length policy matters. An aggregate-only assumption in one system could reject an intended /24. An overly permissive rule could accept a route that was never approved. Configuration should be generated or reviewed against one controlled inventory, with exceptions recorded explicitly.

IPv4 and IPv6 must also be evaluated separately. The simultaneous visibility of one route in each family is a positive technical signal. It does not prove parity. IPv6 can have different transit, filtering, firewall, monitoring, DNS, customer-premises, and application behaviour. A failover test that checks only IPv4 can leave an IPv6 incident invisible. A support script that tells a customer to test only an IPv4 address can misclassify a dual-stack problem. Operational maturity requires per-family dashboards and incident steps, followed by service-level tests that exercise both.

The observation of current routes is therefore running-code evidence in a limited sense: it reflects what the routing system was doing, not merely what a registry said it could do. Running-code primacy does not mean that the latest collector output overrides authority records, contracts, or customer tests. It means that a control assessment should reconcile intended state with observable state. Neither should be assumed correct when they disagree.

For Planet, the public routing picture supports a bounded conclusion. AS136903 was visibly originating registered IPv4 and IPv6 resources, and the observed routes had a current RPKI-valid state. The evidence does not support claims about uptime, scale, performance, redundancy, or customer satisfaction. Those missing facts are not an invitation to speculate. They define the next verification layer.

RPKI helps, but it is not reliability

RIPE NCC's validator returned a valid result for AS136903 originating 103.98.107.0/24. The covering Route Origin Authorisation uses the registered 103.98.106.0/23 and allows announcements down to /24. The validator also returned valid for AS136903 originating 2001:df1:1780::/48. These results show that the observed origins and lengths were compatible with available authorisations when queried.

This is a meaningful security control. Without a suitable ROA, networks applying Route Origin Validation may classify an announcement as unknown. With a conflicting origin or disallowed prefix length, they may classify it as invalid and reject or de-preference it according to policy. A correct ROA reduces ambiguity and makes an unauthorized origin easier to distinguish from intended operation.

Validity is not a complete security verdict. Origin validation does not authenticate the entire AS path. It cannot show whether every transit network applies filtering, whether the authorized origin is compromised, whether a route leak preserves the valid origin, or whether traffic reaches the right application. It does not measure encryption, access control, DDoS resilience, DNS integrity, latency, packet loss, throughput, or incident response. A valid route can deliver traffic to a failing service.

The operational cost appears during change. If Planet changes the origin, advertises a new more-specific route, introduces a backup ASN, or modifies the aggregate strategy, router configuration and ROA scope must remain synchronized. Deploying the route first can create an invalid state. Authorizing a broad maximum length without need can increase the set of routes that validators accept. Updating only documentation can leave both systems unchanged. The change plan needs intended prefixes, origins, maximum lengths, rollout order, validation, rollback, and closure evidence.

Maintenance also includes expiry and access. The team must know who can edit RPKI records, how that account is recovered, whether role changes remove obsolete access, and how an emergency is approved. A backup connectivity arrangement is not operationally ready if no one can update its ROA during the event. The authorization process should be tested before an outage, not discovered during one.

Monitoring should preserve more than a red or green label. A useful record includes prefix, origin ASN, validator, result, covering ROA, maximum length, query time, and route visibility. If the result changes, the owner needs to determine whether the route, the ROA, the validator view, or the intended policy changed. The incident should not close merely because the dashboard turns green again; the organization should record cause, corrective action, and any exception that remains.

RPKI can therefore lower one class of origin-risk uncertainty while increasing the need for disciplined lifecycle management. That is a worthwhile trade. It is not free, and it cannot substitute for product reliability evidence. Planet's valid observed routes are a positive control-plane fact. They are not proof that any advertised service-level objective was achieved.

Product capability, service reliability, and customer outcomes

Planet's first-party website describes a portfolio that includes home and corporate internet, fibre connectivity, dedicated bandwidth, static IP options, VPN-related support, and enterprise IT services. Its package page publishes residential tiers and describes BDIX or CDN access, contention, and static-IP availability for at least one tier. Service and contact pages use support, restoration, installation, and service-level language. These pages establish what the company says it can provide.

Capability is the first evidence class. The APNIC and routing records strengthen the case that Planet operates a genuine ISP control surface: an ASN exists, registered IPv4 and IPv6 resources exist, both protocol families were observed in BGP, and the routes validated under RPKI. The website identifies products that plausibly use that network surface. This is stronger than an unanchored marketing claim, but capability still describes what could be delivered, not what every customer receives.

Product reliability is the second class. Reliability would require measurements over defined boundaries and time windows. For internet access, useful evidence could include availability, packet loss, latency, jitter, throughput, congestion, restoration time, DNS performance, route stability, power and facility resilience, and incident response. The measurement location matters. A backbone target does not describe a last-mile circuit. A speed test to a local cache does not describe international performance. An IPv4 test does not prove IPv6 parity. An aggregate monthly percentage may hide repeated short failures during business hours.

The evidence used here contains no independent time series for those measures. Planet's website may advertise a service-level figure or response commitment, but the article cannot convert the advertisement into an achieved result. A due-diligence process should ask how the metric is calculated, what is excluded, which components are covered, who collects the data, whether customers can audit it, and what remedy applies. The answer may differ between residential packages, corporate access, dedicated capacity, and managed services.

Customer production outcomes are the third class. A customer result could involve application availability, branch continuity, successful remote work, stable voice, payment processing, cloud reachability, backup completion, or recovery from an incident. No attributable customer case study or production measurement in the source set supports such a claim. The absence should remain explicit. It is not evidence of poor performance, and it is not permission to invent a satisfied customer narrative.

The three classes are often blended because the result sounds persuasive: a company has fibre, therefore the service is reliable, therefore customers achieve better outcomes. Each arrow requires evidence. Fibre can reduce some physical constraints but can still be affected by cuts, power, active equipment, capacity, configuration, supplier dependencies, or poor incident handling. A static IP can enable applications but also creates security, routing, reverse-DNS, and support responsibilities. A VPN-related service can provide connectivity but does not prove application performance or endpoint security.

The same discipline applies to support. A published phone number, installation time, or restoration target is a capability or commitment. Reliability evidence would show response and restoration distributions over time, severity definitions, exclusions, and ticket closure quality. Customer outcome evidence would show whether the affected production process recovered. A ticket marked closed can coexist with a recurring fault or an unhappy customer. Operational control needs both technical closure and customer confirmation where appropriate.

Corporate buyers should therefore define acceptance tests before relying on broad product language. Tests can cover route reachability, IPv4 and IPv6, DNS, throughput at agreed times, failover, application paths, security controls, contact escalation, and evidence access. Testing should be authorized and scoped; this research did not conduct private tests or benchmarks. The purpose of specifying them is to show what would be needed to turn capability into a reliability conclusion.

There is also a contractual integration cost. Service boundaries, demarcation points, customer-premises equipment, power responsibility, monitoring ownership, maintenance windows, incident severity, response targets, restoration targets, credits, and exit assistance should be explicit. A technically functional connection can still create operational friction if each party assumes the other owns DNS, routing, firewall, or escalation. The contract should map responsibility to controls rather than use one general promise.

Planet's public evidence supports a credible but bounded assessment. It has a verifiable network identity and advertises relevant services. The evidence does not support a public score for achieved uptime, performance, support quality, or customer production success. Keeping that boundary visible is not excessive caution. It is the basis for useful, testable due diligence.

The hidden cost of a changing public identity

Planet's current website is available at planet-itsolutions.com, and ISPAB's member page links that domain. At the observation time, the site exposed home, about, services, packages, contact, and leadership pages. The current domain resolved in public DNS and had visible mail and sender-policy records. The legacy domain carried in the directory record, planetinfotechltd.com, returned NXDOMAIN in the same observation window.

NXDOMAIN means the queried name did not exist in the DNS response at that time. It does not reveal how long the state persisted, why it occurred, whether the domain expired, whether it was intentionally retired, or whether any customer service depended on it. It does not prove a network outage. The responsible conclusion is narrower: the public identity has changed, and at least one legacy name was not resolving when checked.

Domain transitions create a cross-system maintenance project. The website, email, SPF, certificates, registrar contacts, authoritative nameservers, social profiles, association directories, regulator records, APNIC contacts, invoices, contracts, customer portals, support scripts, monitoring, search results, and printed material may all contain the old identity. Updating the website alone does not complete the transition. Every stale reference can delay a customer, peer, regulator, supplier, or abuse reporter trying to reach the right owner.

Email is particularly sensitive. If historic role addresses used the old domain, an NXDOMAIN state can prevent delivery before a sender receives any helpful redirect. A website can redirect HTTP traffic, but DNS and mail need separate controls. A planned retirement should inventory addresses, preserve or replace important role mailboxes, publish current contacts, notify counterparties, and monitor attempted use. Security teams should also consider the risk of a retired domain later becoming available to another registrant.

DNS ownership is another control boundary. The current domain's authoritative nameservers, web origin, MX target, and SPF policy may be operated through different accounts or suppliers. An account recovery failure at the registrar can block delegation changes even while hosting remains healthy. A nameserver problem can affect web and mail discovery without changing AS136903. An origin failure can affect the site while DNS remains correct. Monitoring should distinguish these layers.

Registry and directory synchronisation adds institutional latency. APNIC, BTRC, ISPAB, the company's website, and the BTW directory do not share one database or update schedule. A stale domain in one directory is not necessarily evidence that the company failed to maintain its network. It is evidence that public records can diverge. The remediation is to identify an authoritative current value for each purpose, update the records under the company's control, request corrections elsewhere, and preserve a dated audit trail.

This work has a direct support cost. When customers cannot find the current portal or email address, they call other numbers or escalate through sales. When peers see inconsistent domains, they spend time authenticating a change. When an abuse reporter receives a bounce, remediation can be delayed. When staff rely on search results, they may send credentials or sensitive details to a stale surface. Public identity is therefore part of operational continuity, not just branding.

Portability planning should include the current domain and any legacy names. The company should know who owns registration, renewal, DNS hosting, certificates, mail administration, website deployment, and recovery contacts. Changes need a staged sequence, rollback values, and independent checks from outside the network. A migration is complete only when intended users and counterparties can find and authenticate the new surface, not merely when the new home page loads.

Supervision, integration, maintenance, and exception costs

Supervision

Supervision starts with a control inventory. For AS136903, the inventory should include the APNIC ASN and organisation records, 103.98.106.0/23, 2001:df1:1780::/48, intended BGP announcements, ROAs, route filters, technical and abuse contacts, DNS zones, mail records, monitoring endpoints, ISP licence records, supplier dependencies, and customer-specific commitments. Public evidence cannot reveal whether Planet already maintains such an inventory, so this is a cost model, not a claim about its internal practice.

Each control needs an owner and freshness rule. Route visibility may need near-real-time alerting. ROAs and registry contacts change less often but require review after staffing, supplier, or routing changes. DNS and certificates have renewal and expiry cycles. Licence and association records need periodic reconciliation. Customer service objectives need measurement and reporting windows. Supervising all of them through one generic status is unsafe because a green route monitor cannot validate a mailbox, licence, or customer application.

The company also has to supervise evidence quality. RIPE RIS observations are time-bounded. APNIC records can be current while a published contact no longer reaches the responsible team. First-party pages can be updated without independent verification. BTRC's PDF is dated. A defensible review records source, query time, returned value, and the question that source can answer. It also records what the source cannot answer.

Integration

Integration connects the control inventory to running operations. Router policies must agree with the intended prefix set and ROA maximum lengths. Monitoring must know both IPv4 and IPv6 expectations. DDoS or filtering systems need the same routes and origins. DNS and reverse-DNS responsibilities must be aligned with services. Ticketing and escalation should map alerts to the people who can authorize a change. Contracts should reflect the actual demarcation points.

Supplier integration is a likely cost even when the public relationship map is incomplete. The one observed BGP neighbour cannot define all relationships, but any transit, peering, hosting, domain, DNS, mail, or infrastructure supplier introduces access, maintenance, escalation, billing, and exit dependencies. The provider should know which failures it can repair directly and which require another party. A customer should know which part of the service objective survives a supplier incident.

Customer integration adds another layer. Static addressing, VPN configuration, firewall policy, customer-premises equipment, branch routing, cloud paths, DNS, and application monitoring can cross the service boundary. A change that is correct for Planet's network may break a customer's fixed assumption. Maintenance notifications and acceptance tests should therefore identify affected controls rather than announce a generic network change.

Maintenance

Maintenance is the recurring work required after the initial service is functioning. Route policies change, filters need review, ROAs must follow intended origins, contacts rotate, credentials expire, DNS records change, certificates renew, packages evolve, and monitoring accumulates noise. IPv4 and IPv6 create parallel workstreams. The current visibility of both families is positive, but parity has to be maintained in firewall rules, incident procedures, dashboards, customer support, and application tests.

Public identity maintenance belongs in the same cycle. The current and legacy domains should be reviewed across APNIC, ISPAB, BTRC, customer communications, certificates, mail, and support material. A record that is merely old should not trigger a production incident, but it should have a correction owner. Without that owner, harmless divergence can become harmful during an emergency.

Evidence retention is another maintenance cost. Route and RPKI snapshots, DNS changes, incident tickets, authorization records, supplier communications, customer notices, and acceptance tests should be retained according to operational and legal needs. The goal is not unlimited logging. It is enough context to reconstruct what was intended, what changed, who approved it, what users experienced, and how the system returned to an accepted state.

Exception handling

Normal workflows are rarely the most expensive part. Exceptions expose missing authority. A route may need an emergency origin change while the person with RPKI access is unavailable. An abuse report may concern a customer address while the reporter supplies insufficient evidence. A DNS account may be locked during a domain transition. IPv4 may recover while IPv6 remains impaired. A backup path may be technically available but filtered by a remote network.

Each exception needs classification, authority, expiry, rollback, and closure evidence. Temporary route announcements should not become permanent undocumented state. Broad emergency ROAs should be narrowed or removed when the event closes. Substitute contacts should be updated in the registry. Manual DNS changes should be reconciled with the source of truth. A customer workaround should have an owner and end condition.

Exception handling also has an opportunity cost. Senior engineers, legal contacts, customer support, suppliers, and managers may all be pulled into an incident. A company that advertises a simple monthly package still carries this hidden coordination burden. Automation can reduce repetitive checks, but it cannot eliminate judgment about authority, customer impact, or acceptable risk. Poorly governed automation can distribute an incorrect route, ROA, or DNS value faster than a manual process.

The operating-cost conclusion is straightforward. Registry records and RPKI make controls more visible and verifiable. They do not make operations self-maintaining. The company and its customers still pay for supervision, integration, maintenance, and exception handling, whether those costs are explicit in a contract or absorbed during incidents.

Failure modes that deserve explicit tests

The first failure mode is stale authority. APNIC may show an active object while a listed role account is no longer monitored or the person with account access has left. A periodic contact check can detect part of the problem, but recovery authority also needs testing. The control should verify that a role, not only an individual, can authenticate and approve urgent changes.

The second is route and ROA divergence. AS136903 could intentionally introduce a different origin or prefix length while the old ROA remains. The route might then become invalid at networks that enforce origin validation. The reverse failure is an authorization that remains broader than the intended routing policy. Prevention requires a coordinated change record and pre-deployment validation; response requires comparison of intended route, observed route, and covering ROA.

The third is route withdrawal or reduced visibility. A public collector may stop seeing 103.98.107.0/24, 2001:df1:1780::/48, or both. The first step is to determine whether the observation is collector-specific, policy-specific, or broadly reproduced. The next step is to test the customer service boundary. A route alarm alone does not identify whether the cause is maintenance, filtering, upstream failure, configuration, power, or an intentional withdrawal.

The fourth is hidden concentration. The single observed neighbour may reflect the currently preferred public path, while other paths exist. It may also represent a concentration risk for the relevant route. Public data cannot decide. The correct test examines physical, facility, power, control-plane, and supplier diversity for the purchased service. Two contracts that share one duct or router are not independent in the way an availability model might assume.

The fifth is IPv4 and IPv6 divergence. One protocol family may remain reachable while the other fails because of routing, filtering, DNS, firewall, customer-premises, or application differences. Dual-stack clients can mask or amplify the issue depending on address selection and fallback behaviour. Monitoring should test both directly, and incident communications should identify which family is affected.

The sixth is DNS or public-identity drift. The current site may work while a historic email address or directory link fails. The observed NXDOMAIN on the legacy domain is not evidence of a past incident, but it demonstrates why stale identities must be found. A controlled transition should test web, mail, certificates, registrar recovery, nameservers, SPF, contact pages, and high-value external directories.

The seventh is support escalation failure. A customer may reach a published number but fail to reach someone authorized to change routing, DNS, or a supplier circuit. Service desks need severity definitions, ownership maps, out-of-band contacts, and a path to technical decision-makers. Closure should confirm the customer outcome, not merely that a ticket changed status.

The eighth is abuse-handling friction. A report may be genuine, mistaken, malicious, or incomplete. Immediate disconnection can harm an innocent customer; inaction can prolong harm. The process should preserve evidence, authenticate the relevant allocation and time, notify the responsible party, apply proportionate controls, and record the decision. Published APNIC contacts support discovery but do not replace this process.

The ninth is monitoring false confidence. A dashboard may show BGP visibility and RPKI validity while access circuits are congested or an application is unreachable. Another dashboard may flag a collector change as an outage. Controls should stay disaggregated until an owner has classified the event. Composite scores can be useful for prioritization, but they should link back to raw evidence and service impact.

The tenth is dependency lock-in. Domain accounts, supplier configurations, static addresses, customer firewall rules, monitoring history, and undocumented escalation relationships can make a nominally portable service difficult to move. An exit test should identify which assets the company or customer controls, what cooperation is required, how long DNS and routing changes take, and how rollback works. Portability that has never been tested is an assumption.

None of these scenarios is presented as an incident that happened at Planet. They are failure modes implied by the public control surface and common ownership boundaries. Their value is practical: each can be converted into a test, an owner, and a closure criterion without inventing private architecture or customer results.

A practical accountability scorecard

An evidence-based assessment of Planet should avoid a single score that hides category boundaries. A compact scorecard can instead record the status, age, owner, and limitation of each control.

Entity and regulatory identity. BTRC's dated divisional ISP list, ISPAB's member directory, and APNIC's organisation records align on the Planet company identity. The scorecard should preserve exact names, identifiers, dates, and any current primary regulatory confirmation. A dated list is evidence, not perpetual authorization.

Number-resource authority. APNIC records active AS136903, IPv4 allocation 103.98.106.0/23, and IPv6 assignment 2001:df1:1780::/48. The operational check is whether account access, contacts, intended use, and recovery authority remain current. Allocation does not prove deployment or performance.

Running route state. RIPE RIS observed 103.98.107.0/24 and 2001:df1:1780::/48 from AS136903 in the query window. The scorecard should retain timestamps, collector limits, expected routes, and changes. Visibility is not availability or customer experience.

Origin security metadata. Both observed routes returned RPKI-valid. The scorecard should retain covering ROA, maximum length, origin, and lifecycle owner. Validity does not secure the entire path or service.

Path and diversity evidence. One neighbouring ASN was visible in the public observation. This field should remain "needs service-specific verification" rather than being marked single-homed or redundant. Commercial and physical diversity require direct evidence.

DNS and public identity. The current domain was live, while the legacy directory domain returned NXDOMAIN at the observation time. The scorecard should track current domain ownership, authoritative DNS, email, certificates, recovery, stale references, and transition status. It should not infer outage impact from one DNS response.

Product commitments. Planet's website publishes connectivity and support claims. Each commitment should map to a measurable service boundary, observation method, exclusion, reporting period, escalation path, and remedy. Marketing language is not a measured result.

Customer production outcomes. No attributable outcome evidence was available in the reviewed source set. This should be recorded as unavailable, not scored as failure or success. Customers can supply acceptance tests and production evidence under appropriate confidentiality.

Operations and exceptions. The assessment should ask whether route, ROA, DNS, contact, supplier, dual-stack, and support exceptions have owners, expiry, rollback, and retained evidence. Public records cannot answer this fully. A provider can demonstrate the process without disclosing sensitive topology.

The scorecard should distinguish measured, record-derived, first-party, and unavailable evidence. It should also preserve age. A route snapshot taken today and a licence PDF dated 2024 do not have the same freshness, but each may remain relevant to a different question. The correct response to age is targeted verification, not silent substitution.

Planet's public control surface earns a bounded positive conclusion. The directory company is connected to a licensed ISP identity, active APNIC records, visible IPv4 and IPv6 routing, and valid origin authorisation. The current website provides a substantial product and contact surface. These facts support further diligence. They do not support an unqualified claim about reliability, support quality, or customer outcomes.

The strategic question is whether the organisation can continually reconcile authority, running state, promises, and observed results. That work includes humans, process, suppliers, and evidence, not just routers. The value of registry and routing transparency is that it turns some assumptions into testable controls. The remaining gaps should also be made explicit, assigned, and tested rather than filled with confident language.

Sources

1. Planet Information Technology Solution home page for the current public identity, service categories, and contact domain.
2. Planet Information Technology Solution about page for attributed company history and capability statements.
3. Planet Information Technology Solution services page for attributed home, corporate, static-IP, VPN, dedicated-bandwidth, support, and service-level language.
4. Planet Information Technology Solution packages page for attributed residential package, contention, BDIX/CDN, and static-IP language.
5. Planet Information Technology Solution contact page for the current contact surface and attributed response or installation language.
6. Planet Information Technology Solution chairman page for attributed leadership and company-scope statements.
7. Company-hosted BTRC-approved tariff artifact for the company's published package context, not independent regulatory confirmation.
8. ISPAB member record for Planet Information Technology Solution Ltd. for member G-351, divisional licence reference, current website, and association identity.
9. BTRC divisional ISP licence list dated 23 December 2024 for the dated Planet row and licence identifier.
10. APNIC RDAP record for AS136903 for PITSL-AS-AP, active status, and organisation linkage.
11. APNIC RDAP record for ORG-PITS1-AP for the organisation identity and public contacts.
12. APNIC RDAP record for IRT-PITSL-BD for the abuse-contact and validation-date surface.
13. APNIC RDAP record for 103.98.106.0/23 for the active IPv4 allocation.
14. APNIC RDAP record for 2001:df1:1780::/48 for the active IPv6 assignment.
15. RIPE NCC announced-prefixes data for AS136903 for the bounded observation of one IPv4 and one IPv6 route.
16. RIPE NCC routing-status data for AS136903 for current queried-peer visibility and observation metadata.
17. RIPE NCC ASN-neighbours data for AS136903 for the time-bounded observation of AS137491.
18. RIPE NCC RPKI validation for 103.98.107.0/24 for the IPv4 origin-valid result and covering maximum-length policy.
19. RIPE NCC RPKI validation for 2001:df1:1780::/48 for the IPv6 origin-valid result.
20. Public DNS observations for the current and legacy domains, queried on 2 August 2026, for the bounded A, NS, MX, SPF, and NXDOMAIN statements.

Featured-image note: the article uses Rubin Observatory / NSF / AURA's photograph of coiled fibre-optic cable and conduit at a construction site, available from Wikimedia Commons under CC BY 4.0. It is generic infrastructure context and does not depict Planet Information Technology Solution Ltd., its network, facilities, customers, or service results.