Summary

  • PANDI is the non-profit registry for Indonesia's .id country-code top-level domain, not a registrar selling ordinary retail registrations and not a cloud or hosting provider. Indonesian rules, PANDI's current description and the IANA root-zone delegation all converge on that institutional role.
  • The live network evidence points to AS132647. In a 15 July 2026 RIPE NCC view it originated eight IPv4 /24s and seven IPv6 /48s with full observed visibility, while AS56088 originated nothing and was last seen in that data on 15 February 2024.
  • PANDI has described a wide anycast footprint, a registry system designed for two million names, DNSSEC, independent APNIC secondary service and a history of node expansion. Those facts support real operating substance, but public material does not reveal current rack addresses, power feeds, zone-generation topology, database replication boundaries or tested recovery objectives.
  • The 2023 Semarang DNS incident demonstrates both the value and the limit of anycast. PANDI and APJII withdrew the affected BGP path, restoring service for impacted users, then repaired the node on site. That is route-level fail-away in practice, not proof that every city, facility and control system is physically independent.

The number in the name is not the network serving .id

An infrastructure researcher starting from the label PANDI-ID can easily land on AS56088. The APNIC registration is real: the autonomous system was registered in 2011, remains marked active in the registry, and names PANDI as the holder. Yet registration and operation are different questions. The RIPE NCC routing-status view for AS56088 showed no IPv4 or IPv6 prefixes visible on 15 July 2026. Its historical fields placed the last observed announcement, 203.119.112.0/24, on 15 February 2024.

Now follow the DNS rather than the label. The IANA delegation record for .id lists five authoritative names: b.dns.id, c.dns.id, d.dns.id, e.dns.id and ns4.apnic.net. The four PANDI names resolve to addresses inside 103.19.176.0/22, 45.126.56.0/22, 2402:ee80::/32 and 2001:df5:4000::/48. APNIC records associate those resources with PANDI. Current route observations place their visible /24 and /48 announcements behind AS132647, not AS56088.

That second autonomous system is not obscure residue. The APNIC RDAP record for AS132647 calls it IDNIC-PANDI-AS-ID, marks it active, and records a change as recently as 3 June 2026. The RIPE NCC routing-status result counted eight visible IPv4 prefixes covering 2,048 addresses and seven IPv6 /48s. Every RIPE RIS peer represented in that result saw the IPv4 and IPv6 space. That is strong evidence of a current public routing footprint.

The distinction matters because an ASN can survive as an administrative entity after traffic moves elsewhere. It also matters because a registered import or export statement is not the same as a live BGP path. The responsible conclusion is narrow: AS56088 still exists, but it does not currently demonstrate delivery of .id; AS132647 does. The reason for the division, the migration history, and any private function retained by AS56088 are not disclosed in the public record.

This makes PANDI a useful case study in why infrastructure identity should be assembled from control, addressing and live operation rather than a single name. The important entity is not whichever ASN appears first in a directory. It is the institution that controls registry policy and systems, plus the set of networks and suppliers that actually deliver the authoritative service.

A national registry, not a retail host

PANDI's identity is unusually well anchored. Its own institutional description says it is a non-profit association and the registry for Indonesia's top-level domain. It cites Ministerial Decree No. 806 of 2014, updated by Decree No. 218 of 2023. The independent root-zone record names Perkumpulan Pengelola Nama Domain Internet Indonesia as the .id manager. An ICANN redelegation report records how PANDI became the sponsoring organisation in 2013 after years of technical operation under an Indonesian government mandate.

Indonesian law draws the role boundary explicitly. Ministerial Regulation No. 23 of 2013 defines a registry as the operator responsible for managing, operating and maintaining the electronic domain-name system. It distinguishes that function from the registrar, which provides registration services to users. It gives the registry policy, infrastructure, oversight and dispute-resolution responsibilities, and requires continuity arrangements if the registry stops operating.

PANDI explains the commercial boundary in plainer terms. Its registry, registrar and registrant guide says a registry generally does not market and sell top-level names directly to the public; accredited registrars offer registrations to registrants. PANDI maintains the shared authority, accredits registrars and governs the namespace. Retail support, bundled web hosting, email, site builders and customer billing may be provided by registrars, but those are not evidence that PANDI itself sells compute capacity.

This is why the cloud-service classification fails. Nothing in the IANA delegation, the Indonesian legal framework, PANDI's current mission, its registry policies or the observed DNS network supports a conclusion that PANDI is primarily an IaaS, VPS, bare-metal or managed-hosting vendor. It operates critical internet infrastructure and a regulated institutional control surface. Its public products beyond the registry, such as short-link and domain-abuse services, do not change the nature of the .id role.

The difference is not semantic. A hosting customer asks where a virtual machine runs and how to export its data. A registry user needs to know whether a name can be created, renewed, transferred, delegated and resolved; whether the zone stays authentic; whether a registrar failure can be contained; and whether an outage in one route or city leaves other authorities available. PANDI's infrastructure should be judged against those dependencies.

What PANDI actually controls

The registry's operational surface has several layers. First is the authoritative registry database: the canonical record of domain entities, registrar sponsorship, status codes, nameservers, expiry and security delegation data. PANDI calls its in-house platform Sistem Registri Mandiri, or SRM. Registrars transact with that system; public users see selected registration data through WHOIS and RDAP. PANDI's current RDAP endpoint appears in the IANA delegation record, confirming that registration-data service is part of the public boundary.

Second is zone production. Registry data must be transformed into the .id zone that authoritative DNS servers publish. A successful retail transaction is not enough if the resulting delegation never reaches the zone, if zone generation is delayed, or if secondary servers receive inconsistent versions. Public reporting names the services but does not document the production chain, signer placement, transfer topology or maximum propagation interval. Those remain operational unknowns.

Third is authoritative DNS. The five names in the root delegation are logical service identities. Four are PANDI names and one is APNIC's ns4.apnic.net. A resolver can ask any responsive authority for .id data. Multiple names, IPv4 and IPv6, anycast routing and an external secondary create several kinds of diversity, but they are not interchangeable. A different hostname may still share an origin network, a software image, a signing system, a provider or a facility with another hostname.

Fourth is cryptographic integrity. At the research cut-off, a DNSViz analysis of .id exposed the DS-to-DNSKEY authentication path and provided an independent inspection surface for the signed chain. DNSSEC protects the authenticity and integrity of DNS data; it does not keep a server online, add bandwidth or fix a bad delegation. Key management is therefore both a security control and a failure domain.

Fifth is registration governance. PANDI accredits registrars, sets technical and operational requirements, monitors compliance, handles complaints and provides a dispute mechanism. Its 2024 registrar self-assessment report says 25 accredited registrars participated in the programme, with mixed results and an average compliance score of 85.92%. Those registrars are a distributed customer interface, but PANDI remains the common registry dependency behind them.

Finally there are supporting services: helpdesk, monitoring, security assessment, domain-abuse intelligence and dispute administration. These matter because a registry incident is not only a packet problem. A registrant may need a human escalation when a registrar closes, a transfer is stuck, abusive use is disputed or registration data are wrong. Resilience includes the ability to make controlled changes under stress without weakening security or losing accountability.

The delegated DNS has five names but more than five machines

IANA's five-name delegation is the stable public contract. It does not reveal the machine count. PANDI has repeatedly described a larger unicast and anycast deployment behind those names. Its 2022 annual report said it installed domestic nodes in Jakarta, Bandar Lampung, Balikpapan, Bandung and Semarang, alongside existing nodes in Jakarta, Bogor, Yogyakarta, Surabaya, Bali and Makassar. It also named new overseas installations in India and South Korea and existing ones in the United States, Netherlands, Australia, China and Russia.

A later PANDI DNS-resolution presentation described 17 domestic and 23 overseas nodes. It associated the PANDI names with multiple cities and countries, and separately listed APNIC locations for ns4.apnic.net. It also named BIND9, Knot, NSD and CoreDNS research, plus BIRD, Quagga and FRRouting in the broader DNS and BGP environment. This is meaningful disclosure because it shows that a logical name may fan out across many systems and routing sessions.

But it is not a facility inventory. A city label does not tell a reader which data centre houses a node, who owns the rack, which carrier provides the cross-connect, whether two listed nodes share a building, or whether their power and management networks are independent. The count also combines different operating boundaries: APNIC's secondary is not a PANDI-operated machine merely because it serves the .id zone. Locations in a presentation can change after publication, and anycast directs a user to a route-selected instance rather than a fixed geographic endpoint.

The public routing picture reinforces the existence of geographic and supplier dispersion without locating racks. The RIPE NCC announced-prefixes result for AS132647 returned the eight IPv4 /24s and seven IPv6 /48s visible during the first half of July. BGP paths to 103.19.179.0/24 and 45.126.57.0/24 showed different sets of adjacent networks in public collectors. That is consistent with multi-provider anycast delivery. It does not prove that every node is active, healthy or physically separate.

PeeringDB illustrates the disclosure gap. Its AS132647 profile identifies PANDI, provides NOC and abuse contacts, and describes an open policy, but it lists zero public exchange points and zero interconnection facilities. PeeringDB is voluntary, so empty facility fields do not negate observed BGP connectivity. They do mean the public cannot use that profile to map PANDI's racks or verify claimed site diversity.

The Semarang incident shows how fail-away works

On 15 June 2023, PANDI published an unusually concrete notice about a Semarang DNS incident. It said the BIND9 service on the Semarang anycast server did not run correctly. Some internet service providers reaching .id through the Indonesia Internet Exchange were affected. PANDI contacted the APJII Semarang team to disconnect BGP connectivity, after which affected access returned to normal. PANDI then carried out an on-site repair and restored the BGP path.

The episode reveals a real recovery mechanism. An unhealthy anycast instance can be removed from routing so queries choose other available paths. This is materially better than a single fixed server whose failure continues to attract traffic. It also shows an operator boundary: PANDI depended on APJII personnel controlling the exchange-side connectivity and on local hands for physical or system repair.

It would be wrong to turn the notice into a claim of a national .id outage. PANDI described impact to some ISPs using a particular exchange path, not universal failure. Other DNS nodes continued serving. It would also be wrong to say the network healed automatically. The account describes human coordination, a BGP withdrawal and on-site work. Recovery speed therefore depended on detection, correct diagnosis, reachable contacts and the authority to change routing.

The incident also separates software redundancy from route redundancy. A daemon failure occurred on one node. BGP was still capable of attracting users until operators withdrew the path. Anycast availability requires health monitoring that can either suppress a bad route automatically or alert people fast enough to do it. Public material does not state whether PANDI now uses automated route health checks, how many query failures trigger withdrawal, whether each node has an out-of-band path, or whether route restoration requires manual approval.

For users, the lesson is not that anycast failed. It is that anycast is an operating system made from DNS software, routing policy, exchange relationships, monitoring and people. The same IP address can lead to different physical instances, but a shared configuration mistake can still affect many instances at once. Geographic spread addresses some failures; it does not eliminate common software, signing, configuration or governance risks.

AS132647 supplies visible route diversity

AS132647's current public record is stronger than a typical thin company ASN. APNIC ties the ASN and its address blocks to PANDI. RIPE RIS sees both address families. The named authoritative IPv4 addresses fall inside the visible PANDI prefixes, and the equivalent IPv6 addresses are also publicly routed. A sampled RIPE NCC BGP-state view for 103.19.179.0/24 contained hundreds of collector paths ending at AS132647.

Those paths had multiple penultimate networks. In the sample, large groups arrived through AS29802 and AS20473, while other paths used different Indonesian and international ASNs. A separate view for 45.126.57.0/24 showed a different adjacent-AS mix, including AS58396, AS56630, AS34927 and AS38496. This pattern is compatible with distinct anycast deployments and multiple delivery suppliers, but the route snapshot alone does not establish the holder name or commercial role of any adjacent ASN.

It is safer to call these observed adjacent paths than contractual upstreams. A collector sees the path selected at one time from one vantage point. It does not reveal the commercial agreement, whether a relationship is paid transit, settlement-free peering, remote peering or a hosted anycast arrangement. It also cannot prove that paths use physically diverse ducts, entrances or power domains.

Route authorization adds another layer. A RIPE NCC RPKI validation result for 103.19.177.0/24 found valid route-origin authorizations for AS132647 at the observation time. This is evidence for one sampled IPv4 prefix, not an all-prefix audit. For that route, validation reduces the chance that networks enforcing route-origin validation will accept an unauthorized origin. It does not prevent PANDI from announcing a bad route, an authorized supplier from misconfiguring propagation, or an application failure behind a valid route.

The external APNIC authority creates useful separation. RIPE NCC network-info results placed the delegated NS4 IPv4 address and IPv6 address behind AS18366 rather than AS132647 at the observation time. APNIC's service-status page identifies NS4 as an anycast service for regional registries and country-code domains and showed it operational during research. This means at least one root-delegated authority crosses both organisational and network boundaries. The remaining unknown is how zone data are transferred, authenticated and monitored between PANDI and APNIC, and what stale-data behaviour applies if transfers stop.

DNSSEC makes the control plane safer and less forgiving

DNSSEC is central to .id because a national namespace is a high-value target for cache poisoning and unauthorized modification. The root's DS record tells validating resolvers which .id key to trust; signatures in the child zone then authenticate the answers. PANDI has also made DNSSEC support part of registrar accreditation and continues to run government and registrar training, including a DNS and DNSSEC workshop in February 2026.

The security benefit carries operational discipline. If PANDI publishes signatures that expire, loses access to the signing key, or coordinates a key rollover incorrectly with the root, validating resolvers can reject otherwise reachable data. A route can be healthy while answers fail validation. Conversely, a valid DNSSEC chain says nothing about whether the underlying web service is safe or whether a registered name is abusive.

Public evidence confirms signing but does not describe key custody. It does not state whether key-signing keys are held in hardware security modules, how many authorised people are required for a rollover, whether signing is online or offline, where backup key material is stored, or when the last full recovery exercise occurred. Those details need not all be public, but independent assurance could establish the control quality without exposing sensitive implementation data.

The registrar boundary matters here too. A registrant who wants DNSSEC for a child domain normally sends DS data through a registrar to the registry. The registrar interface, SRM transaction, validation logic and .id zone publication must all preserve the right values. PANDI's accreditation requirements say registrar systems must support DNSSEC management and staff must have the relevant expertise. That is a useful baseline, though the 2024 self-assessment results show that compliance maturity across registrars is not uniform.

The operational watchpoint is therefore end-to-end: root DS, .id keys, signatures, child DS publication and registrar handling. Counting signed domains alone would not prove safe key lifecycle management. A stronger public measure would report successful validation, rollover exercises, DS transaction error rates and the share of accredited registrars that pass technical DNSSEC tests.

Registry capacity is measured in names and transactions, not virtual machines

PANDI said at the end of 2025 that .id had reached 1,431,960 registered names. The dated announcement provides a clearer baseline than a live counter without an observation timestamp. It also set a 2026 ambition of 1.5 million names. The installed registry and DNS systems have to support that scale, but domain count is not equivalent to server capacity.

PANDI's 2022 annual report described an SRM upgrade intended to accommodate at least two million .id names. It mentioned a master-master server scheme, registry connectivity up to 1 Gbps, local server connections up to 100 Gbps and an additional firewall. In its review of 2023, PANDI again said SRM had been improved to hold two million names, with architecture changes and data and application optimisation. A February 2024 notice then recorded a completed infrastructure migration and post-migration configuration work, with transactions monitored as normal.

If the two-million design figure remains current and the 2025 domain count is directly comparable, registered names occupy about 71.6% of that nominal envelope, leaving roughly 568,000 names before the stated threshold. That arithmetic is informative but incomplete. It does not account for deleted entities retained for audit, contacts, hosts, history, DNSSEC records, transaction bursts, reporting replicas, dispute holds or database overhead. Nor does it say whether two million is a tested maximum, an engineering target or a comfortable operating level.

Authoritative DNS capacity is a different quantity. Query load depends on resolver behaviour, negative answers, TTLs, attacks and the popularity of particular names, not just the number of registered domains. An anycast node with adequate ordinary traffic capacity may saturate during a distributed denial-of-service event. The public node count and route diversity suggest a strategy for absorbing and distributing load, but no current queries-per-second capacity, normal utilisation, attack headroom or per-node limits are disclosed.

Hardware procurement offers only historical fragments. A March 2022 PANDI specification for three DNS servers called for eight-core processors, 32 GB of memory, mirrored 480 GB solid-state storage and dual power supplies. That proves a concrete equipment acquisition plan, not the total installed fleet or today's usable capacity. The machines may have been deployed, replaced, reassigned or supplemented. Procurement quantity should never be multiplied by a benchmark to invent service capacity.

The practical capacity conclusion is therefore mixed. PANDI has disclosed a registry design scale above the dated domain count, a substantial DNS node claim and visible multi-provider routing. It has not disclosed enough to calculate registry transaction headroom, authoritative query headroom, storage growth, failover capacity after losing a major site, or how much of the fleet is simultaneously usable during maintenance.

Physical resilience remains the largest public unknown

The office address in the IANA record is a legal and administrative contact point in Tangerang. It is not proof of a production data centre. PANDI's 2020 annual report said it relocated infrastructure from a Tier 3 to a Tier 4 data centre, but did not identify the provider, address, certification scope, power design or whether the labels referred to a formal certification. The 2022 annual report and 2024 DNS presentation identify cities and countries, not buildings.

That leaves important questions unanswered. Is SRM split between two metro areas or merely two rooms in one campus? Does master-master describe active writes across failure domains or servers inside one site? Are the registry database, zone generator and DNSSEC signer colocated? Do domestic anycast nodes receive configuration from one central controller? Which overseas nodes are PANDI-owned hardware, leased virtual systems, managed anycast instances or partner-operated secondaries?

Power redundancy is similarly opaque. Dual power supplies in a server only help if they connect to independent distribution paths. A Tier label does not establish the customer's actual rack configuration, maintenance history or fuel arrangements. Physical diversity requires evidence of separate utility paths, generators, cooling, fire zones, carrier entrances and local-hands arrangements. None of those can be inferred from BGP.

The public map should therefore be read as a service-presence map, not a cable or facility map. Jakarta appearing several times in the 2024 presentation may indicate multiple nodes, but it does not prove multiple buildings. The United States appearing under several DNS names may indicate provider diversity, but it does not identify cities or common suppliers. Cairo and Sao Paulo, added in PANDI's 2023 report, demonstrate expansion at that date; they do not establish current operation in July 2026.

The external APNIC server is the clearest independent boundary because it belongs to a separate organisation and ASN. Even there, logical independence is not the same as complete failure independence. APNIC still needs an authentic, timely copy of the zone. A bad zone generated by PANDI can be distributed faithfully by every secondary. A DNSSEC signing error can be replicated globally. The registry's most consequential common dependencies are likely upstream of the anycast edge.

This is not an argument for publishing rack coordinates or sensitive security designs. A registry can demonstrate resilience through audited control descriptions, broad metro disclosure, recovery-test results, dependency categories and aggregate availability. The gap is that current public evidence is rich on expansion and sparse on tested failure domains.

Registrar diversity is not registry diversity

PANDI's accredited registrars give users choice at the retail layer. They compete on price, support, bundled services and customer experience. They also create operational alternatives: if one registrar exits, names can in principle be moved to another. PANDI's 2025 notice concerning the end of PT Indonesia Satu Tujuh's accreditation described a transfer service for affected names, illustrating the registry's continuity role.

But all accredited registrars ultimately depend on SRM and the .id authoritative system. Twenty-five registrars do not equal twenty-five registries. A central registry database failure can stop create, renew, update and transfer operations across the market even while existing domains continue resolving from the published zone. Conversely, one registrar's billing outage may block its customers without affecting the DNS or other registrars.

PANDI's published accreditation conditions require registrar applicants to operate application, database, web, email and DNS servers in Indonesia; maintain backups; support DNSSEC; provide minimum staffing; and hold a plan for transferring names if they cannot continue. These requirements place some continuity duties at the edge. The 2024 self-assessment is valuable because it acknowledges that documented requirements need verification.

The failure modes have different clocks. If a registrar portal is down for an hour, customers may be inconvenienced but existing names resolve. If it remains unavailable across an expiry or urgent security change, impact grows. If SRM is unavailable, registrations and changes may pause while DNS continues. If zone production or authoritative DNS fails, users may lose resolution even though registry records are intact. Recovery planning should state these layers separately.

Registrant protection also depends on data portability. A registrar exit requires accurate sponsorship records, authentication controls and a process that prevents hijacking while allowing legitimate transfer. PANDI's registration policy and public exit notice show that it recognises this responsibility. Public metrics could go further by reporting transfer completion times, unresolved exit cases and whether emergency processes are exercised before a registrar actually fails.

Sovereignty does not mean every DNS packet stays in Indonesia

PANDI describes .id as Indonesia's digital identity, and the legal framework places registry responsibility under Indonesian authority. That is a meaningful form of sovereignty: policy, delegation and institutional accountability are attached to an Indonesian association and government framework. It does not imply that every authoritative copy of the zone or every query remains inside the country's borders.

Anycast deliberately places service near users. PANDI's reports describe nodes across Asia, Europe, the Americas and Australia, while APNIC's independent authority is itself globally distributed. A resolver outside Indonesia may reach a nearby overseas node. An Indonesian resolver may also select an overseas path if routing policy makes it preferable. BGP chooses paths, not national policy goals.

This distinction should be explicit for data-locality analysis. Public DNS zone data are meant to be widely served; they are not equivalent to the registry's non-public customer and operational records. The public evidence does not locate the authoritative registry database, backups, logs, abuse data, dispute documents or key-management systems. It therefore cannot establish that all sensitive registry data remain in Indonesia, nor that they leave it.

The architecture can support both national control and global availability. A registry may keep canonical write systems and sensitive data under domestic control while distributing signed public zone data to overseas secondaries. That design would be coherent, but it must not be assumed without evidence. The operator should distinguish canonical registry data, public zone copies, monitoring telemetry and support records when discussing locality.

The topic also reaches the registrar layer. PANDI's accreditation page sets Indonesian server and data-centre requirements for applicants, while retail providers may bundle other services with different locations. A .id name says nothing by itself about where the associated website, email or customer data are hosted. National namespace identity and workload locality are separate properties.

The credible failure paths

The first failure path is a bad anycast instance. PANDI's Semarang recovery notice shows the mechanism: a DNS daemon fails, the route continues attracting some users, monitoring identifies the problem, and operators withdraw BGP until repair. The relevant controls are service-aware health checks, fast route suppression, local access, configuration consistency and cautious reintroduction.

The second is a route or supplier failure. The RIPE NCC routing-status view shows AS132647 reaching public collectors through many observed paths, reducing dependence on one visible path. Yet sampled prefixes show different adjacent-AS sets, and a node's alternatives may be narrower than the ASN-wide graph suggests. A commercial anycast host, exchange, transit network or route server can fail. Recovery depends on where each prefix is announced and whether another healthy instance remains attractive to the affected resolvers.

The third is a common configuration failure. A malformed zone, incorrect access control, broken software release or bad routing policy can propagate across many nodes. Geographic replication then spreads the error. Staged deployment, diverse implementations, validation before publication and rapid rollback are more relevant than node count for this class of incident. PANDI's 2024 presentation mentions several DNS software families, but it does not say which production names use which software or whether updates are staggered; implementation diversity therefore remains unverified.

The fourth is a zone-generation, signing or transfer failure. This sits between SRM and the edge. A stale but correctly signed zone may continue resolving until signatures or operational policy expire; a newly generated bad zone may spread quickly. APNIC's secondary helps only if it has a good copy. Useful controls include serial monitoring, signature-expiry alarms, independent validators, protected transfer channels and a rehearsed way to hold or roll back publication.

The fifth is a DNSSEC key event. Loss, compromise or rollover error can affect every validating user. Hardware, ceremonies and backups matter, but so do coordination with IANA and time allowed for caches. PANDI's 2026 DNSSEC workshop shows institutional attention to DNSSEC; it is not a substitute for evidence about PANDI's own key recovery tests.

The sixth is registrar failure or compromise. A failed registrar can strand customers; a compromised one can submit malicious changes. Accreditation, authentication, change controls, anomaly detection and registry locks can limit damage. Transfer procedures need to preserve continuity without becoming a takeover path.

The seventh is human and organisational concentration. The network can be distributed while knowledge and authority remain concentrated in a small team. Incident response may require PANDI, APJII, APNIC, a data-centre provider, an anycast host and one or more transit networks. Contact freshness, escalation rights and exercises determine whether technical diversity is usable under pressure.

A live response is evidence of operation, not an availability guarantee

Point-in-time public records on 15 July 2026 added useful confirmation. The IANA delegation record listed the five expected .id authorities; DNSViz's .id analysis exposed the signed delegation and DNSKEY chain; and PANDI's RDAP response for pandi.id returned a structured record with a database-update timestamp from the same day. The RIPE NCC routing-status view showed all represented peers seeing AS132647's IPv4 and IPv6 space. Together, these public endpoints establish that the registry's delegation, registration-data and routing surfaces were observable around the research cut-off.

They do not establish an annual service level. A recursive DNS answer may come from cache. Even a successful authoritative query would prove only that the reached instance answered, not that every anycast instance was healthy. A route collector samples BGP from participating peers, not every network on the internet. An RDAP response says the read service worked at that moment; it does not test registrar writes, zone publication, failover or database recovery.

For a registry, meaningful monitoring needs diversity in both geography and function. Probes should ask every logical authority over IPv4 and IPv6, validate DNSSEC, compare SOA serials, test TCP as well as UDP, observe routes, query RDAP and perform controlled registrar transactions. The results should be correlated so an operator can tell the difference between an unreachable node, a stale zone, a broken signature, a route leak and a central registry problem.

This is why the article relies most heavily on converging public records rather than a single ping or lookup. IANA proves the delegation contract; APNIC proves resource registration; RIPE RIS shows public route visibility; DNSViz exposes the observable trust chain; PANDI's reports explain intended architecture; and the Semarang notice exposes a real incident mechanism. Each evidence type answers a different question, and none should be stretched beyond it.

What the evidence supports, and what it does not

The operating verdict is positive on identity and observable network function. The IANA record identifies PANDI as the .id registry and delegates the zone to four PANDI authorities and APNIC's secondary. AS132647 has broad dual-stack route visibility, the authoritative addresses sit inside its announced resources, and DNSViz exposed a signed chain at the research cut-off. PANDI's dated reports show sustained investment in SRM, DNS nodes, security and registrar oversight.

The evidence is medium on present physical resilience. Historical reports and a 2024 technical presentation describe many locations. The Semarang notice proves at least one named anycast node existed and was repaired on site in 2023. BGP shows multiple adjacent ASNs. None of this reveals the current facility matrix, independent power domains or central-system topology.

The evidence is also medium on capacity. PANDI's 2022 report stated a two-million-name SRM design, and its 2025 count of 1.431 million registrations sat below that number. Yet no current transaction tests, utilisation, DNS query capacity, attack headroom or failover capacity are public. The registry may have added capacity after 2023; it may also have constraints that a simple name count misses.

The evidence is strong that the original hosting thesis is wrong. Registry and registrar are expressly separated in law and PANDI's own material. Public network resources support authoritative DNS and registry services. No credible evidence establishes customer-facing compute, VPS, bare-metal or cloud capacity sold by PANDI. Treating the association as a cloud vendor would obscure the infrastructure that actually matters.

The next disclosures that would sharpen the picture

The most useful improvement would be a current service topology at the level of failure domains rather than exact addresses. PANDI could state how many domestic and overseas anycast instances are active per logical name, which are PANDI-operated versus partner-operated, how many independent metros host central registry services, and whether the signer and zone generator share a site with SRM.

Second, availability reporting should separate DNS, RDAP/WHOIS, SRM transactions, zone publication and support. PANDI's 2022 annual report did this to a degree, publishing service-level results for DNS, WHOIS and SRM. Current rolling figures, incident definitions and maintenance treatment would show whether growth has preserved reliability.

Third, capacity disclosure should use service units. Registered-name headroom is useful for SRM. Transactions per second, peak registrar sessions, zone build time, signature validity margin, authoritative queries per second and tested attack absorption describe different constraints. A loss-of-largest-site test would reveal usable capacity after failure, not just installed capacity before it.

Fourth, the organisation could publish aggregate recovery evidence: the date and scope of the latest registry failover, zone rollback, DNSSEC key-recovery and registrar-exit exercises; whether objectives were met; and which improvements followed. Such reporting can protect sensitive details while giving registrants and government stakeholders evidence that redundancy works.

Finally, the AS-number split deserves explanation. A concise statement of AS56088's retained purpose, why public origin moved to AS132647, and whether any dependencies still connect the two would prevent stale classification. The current data already tell the essential story: the .id registry is a live, distributed institutional service, but its operational centre of gravity is AS132647. Reading AS56088 alone misses the network; calling PANDI a cloud provider misses the institution.