Summary
- ThaiNS is not evidenced as a conventional retail VPS or public-cloud seller. Its demonstrated hosted capacity is the back-end registry, authoritative DNS, DNSSEC, registration-data access, public recursive DNS and 24/7 monitoring infrastructure behind
.th,.ไทยand.scb. - The operating footprint is real. IANA records a six-server authoritative set for
.th; APNIC and routing telemetry show two live ThaiNS autonomous systems; and exchange records show AS141362 attached in Bangkok and Chiang Mai. Those signals establish operations, but not rack count, power design or contractual independence. - Resilience is partly visible and partly asserted. ThaiNS says its registry service is dual-site and has an offshore disaster-recovery site. The authoritative DNS set spans several address ranges and network origins. Yet facility names, recovery objectives, test results, spare-hardware policy and customer migration mechanics are not public.
- The practical risk is a chain, not a single server. A registry database failure, bad zone publication, DNSSEC signing error, route withdrawal, exhausted hardware stock, missed alarm or contract dispute can produce very different effects. Customers need separate evidence for data integrity, resolution continuity, recovery and exit.
The category needs correction before the infrastructure can be understood
The name Thai Name Server invites two shortcuts. One is to assume that the company merely runs a few name servers. The other is to treat a corporate activity description that mentions rented server space as proof of a normal hosting catalogue. Both shortcuts obscure what the company actually does.
An aggregated Thai corporate record identifies Thai Name Server Company Limited, registration number 0105544084547, as active, incorporated on 30 August 2001 and based at 159 Pichai Road in Bangkok. The filed activity description is broad: database development and storage, homepage production and rental of server space. That wording explains why the company can appear in a cloud-service collection. It does not show a current menu of shared hosting, virtual machines, bare-metal servers or storage volumes. ThaiNS's own public service catalogue does not advertise those products.
What it advertises is more specialised. ThaiNS describes itself as a registry and back-end registry operator established to restructure .th management. It lists registry systems, DNS, RDAP, Anycast, monitoring and consultancy. The company therefore sells hosted capacity in the sense that an organisation can place a top-level-domain operation on ThaiNS's systems instead of building the registry, signing, resolution and monitoring stack itself. That is infrastructure hosting, but it is not interchangeable with renting a general-purpose virtual server.
This distinction matters for failure analysis. A retail web host's central questions are usually tenant isolation, compute oversubscription, storage durability, bandwidth, support and export. A registry operator adds another set: whether registrars can submit changes, whether the authoritative zone is generated correctly, whether signatures remain valid, whether registration data can be recovered, and whether a top-level domain can keep resolving while the control system is under repair. Those are different services with different clocks.
The evidence supports retaining Hosting economics because ThaiNS explicitly sells the alternative to installing registry infrastructure in-house. It also supports Data sovereignty and locality because the service handles domain-registration data, publishes Thailand's national namespaces and claims an offshore recovery site. It does not support describing ThaiNS as a public cloud provider, so Cloud service dependency would overstate what is visible.
The company operates inside a three-part authority structure
ThaiNS's importance cannot be read from the company name alone. Policy authority, registry operation and retail registration are separated.
The IANA delegation record for .th names the Thai Network Information Center Foundation as the country-code top-level-domain manager. The foundation's registry-and-registrar page says it designated Thai Name Server as the registry on 1 April 2008 and separately designated T.H.NIC Co., Ltd. as registrar. The current registration guideline describes ThaiNS as the back-end operator that collects, stores and processes registration data received through the registrar.
That division means ThaiNS runs a crucial operating surface without owning every policy decision or customer interaction around it. The foundation determines the framework for .th and .ไทย. A registrar accepts and validates registrations under that framework. ThaiNS maintains the registry database and turns approved state into technical service. A registrant may experience those layers as one national domain system, but a failure can start in any one of them.
The .scb example makes the boundary even clearer. The ICANN registry-agreement page identifies Siam Commercial Bank as the registry operator under the 2014 agreement. The IANA delegation names the bank as sponsoring organisation and ThaiNS as technical contact. ThaiNS's service page cites .scb as a reference site, while the public .scb policy set distinguishes sponsor, back-end operator and registrar. ThaiNS supplies the technical operating layer; it does not become the bank or the owner of the string.
This is also why network records must be handled carefully. APNIC address records can name the foundation as allocation holder while a ThaiNS autonomous system originates a more-specific route. A BKNIX exchange port can be operated by ThaiNS without making BKNIX a ThaiNS subsidiary. A name server on an externally originated network can support the Thai zone without proving that ThaiNS owns the remote facility. The meaningful relationship is operational dependency at a particular layer, not automatic corporate ownership.
What ThaiNS actually hosts
The company's back-end registry product is the clearest form of hosted capacity. ThaiNS says its systems are purpose-built for registry service and upgraded to conform with international standards. A customer can ask ThaiNS to operate a domain without installing the underlying infrastructure itself. The service page cites .th, .ไทย and .scb, which turns a generic claim into a small but verifiable reference set.
The workload includes at least five technical surfaces.
First is the core registry database: the canonical record of domains, registrars, contacts, hosts, statuses and delegation information. Second is the registrar-facing registration system, commonly reached through the Extensible Provisioning Protocol. IANA's EPP repository-identifier registry includes Thai Name Server for SCB. Third is zone generation and authoritative DNS publication, which converts registry state into responses the rest of the Internet can use. Fourth is registration-data disclosure through WHOIS and RDAP. Fifth is security and operations around those systems: DNSSEC signing, access control, monitoring, backups, incident response and recovery.
ThaiNS also operates services adjacent to the registry. Its public DNS page publishes a free recursive resolver at IPv4 address 203.159.77.77 and IPv6 address 2405:3340:e000::77:77. Its Anycast page describes a service with CommunityDNS at BKNIX. Its monitoring page offers 24/7 monitoring to organisations that do not want to build an in-house centre. Its consultancy page covers DNS management, new-gTLD applications and registry launch.
These are related products, not one undifferentiated cloud. A customer buying registry operation depends on database state and registrar interfaces. A user choosing the free resolver depends on the two published resolver addresses. An organisation buying monitoring depends on ThaiNS staff, alerting and escalation. A domain relying on an Anycast node depends on route propagation and the partner arrangement. One service can fail while the others continue.
Four service planes have four different failure clocks
The most useful way to assess ThaiNS is to separate control, publication, query and support.
The control plane is the registry database and registrar interface. If it stops, registrars may be unable to create, renew, transfer or update names. Existing authoritative DNS can continue serving the last valid zone. The incident is serious, but it need not make every website disappear immediately.
The publication plane turns database state into signed zone data and sends it to authoritative servers. A failure here can leave old data in service, delay a change or, in the worst case, distribute incorrect or invalidly signed data. The zone's refresh, retry and expiry timers become part of the recovery window.
The query plane comprises authoritative name servers for the top-level domain. A route, server or site can disappear while other authoritative nodes answer. If enough independent nodes survive, ordinary users may notice nothing. If all reachable copies fail after recursive caches age out, names below the TLD can become difficult or impossible to resolve even when their web and mail servers are healthy.
The support plane includes monitoring, people, communications and change authority. It determines whether a fault is noticed, correctly classified and assigned to someone who can act. The public RDAP policy illustrates the separation: ThaiNS can throttle or withhold RDAP from heavy query sources to protect that service, and it explicitly says RDAP does not replace the EPP-based Shared Registry System. An RDAP restriction is not the same event as a registry outage or a DNS outage.
Capacity has to be judged on each plane. Domain count indicates registry workload. Queries per second and attack absorption indicate DNS headroom. Transaction rate and queue depth indicate registrar capacity. Backup age and replay performance indicate recoverability. Shift coverage and escalation time indicate support capacity. A single bandwidth number cannot stand in for all of them.
The physical estate is visible only at its edges
ThaiNS publishes a Bangkok office at 159 Pichai Road. Its contact page lists weekday office hours, while its recruitment material locates systems, network, security and monitoring roles at the same address. The office is therefore a credible operational location. It is not safe to equate the office with every production rack.
The company makes a stronger architecture claim on its registry-service page: dual-site service plus an offshore disaster-recovery site. Those words imply at least a primary/secondary production design and a recovery copy outside Thailand. They do not reveal whether the two active sites have separate power feeds, flood zones, carriers, management networks or hardware stock. They do not say whether the offshore site is hot, warm or cold; how often data reaches it; whether DNSSEC keys are available there; or how long a controlled failover takes.
The historical baseline is unusually useful. IANA's 2010 evaluation of the .ไทย delegation recorded name servers on two topologically diverse networks but in the same geographic area. It also recorded periodic offsite backups, regular data escrow and principal operations in one physical location. That report cannot describe the 2026 design. It does show exactly what has to be tested in the newer claim: whether ThaiNS moved from backup-and-escrow protection around a concentrated core to genuinely independent live sites.
Exchange data provides another edge view. PeeringDB lists AS141362 on two operational 10 Gbps connections at BKNIX in Bangkok and a 1 Gbps connection at BKNIX Chiang Mai. The exchange's Chiang Mai list independently includes Thai Name Server. This proves exchange attachment in two cities. It does not prove that the registry database, zone-signing system or spare servers exist in Chiang Mai. A router port and a registry recovery site are not the same asset.
PeeringDB returns no facility rows for ThaiNS. That is a disclosure gap, not a finding that the company has no facilities. Operators often omit private interconnects and colocation details from voluntary directories. Still, the absence limits external verification: there is no public inventory connecting a specific service to a named building, power system, rack, cross-connect or facility operator.
The authoritative set is broader than ThaiNS's own visible network
The strongest resilience evidence is the root-zone delegation itself. IANA lists six authoritative nameservers for .th: a.thains.co.th, b.thains.co.th, c.thains.co.th, nn1.thains.co.th, ns.thnic.net and p.thains.co.th. Five have both IPv4 and IPv6 addresses; ns.thnic.net is listed with IPv4. The .ไทย delegation lists five: all of those except c.thains.co.th.
These addresses do not sit behind a single ThaiNS prefix. Current routing observations place them in several distinct route origins. The b server is in the prefix announced by ThaiNS AS142437. Other listed servers sit in address space originated by National Telecom, CommunityDNS, Netnod, UniNet and AS42. That spread is a meaningful defence against one rack failure or one route withdrawal. It is stronger evidence than a marketing diagram because the root delegation and global routes are directly observable.
It still should not be exaggerated. Multiple nameserver labels can point into the same operational failure domain. Anycast can put many sites behind one address, but the public address alone does not reveal the number or location of those sites. Different origin networks improve route diversity, but a shared zone-generation error can reach all of them. A bad signed zone is replicated redundancy: every server can be available and consistently wrong.
The authoritative set also does not reveal recovery responsibility. If a remotely operated node fails, ThaiNS may depend on a partner's replacement window. If zone transfer or distribution fails, the remote node may continue with an older copy until timers force a different state. If glue or delegation changes are required, the foundation and IANA process may enter the chain. The physical and administrative dependencies vary by node.
A third-party .th TLD report observed all six IPv4 endpoints and most IPv6 checks working in its late-June 2026 snapshot, with one unsuccessful IPv6 test for p.thains.co.th. A single failed check is not evidence of a durable outage, and the report is not a service-level monitor. It is best read as a point-in-time signal that the set was substantially responsive, not as proof of continuous availability.
AS141362 shows a live service network, not a complete topology
APNIC records AS141362 as active and registered to Thai Name Server Co.,ltd. RIPEstat reported it announced on 12 July 2026, originating 203.159.77.0/24 and 2405:3340:e000::/48. The published public-resolver addresses sit in those prefixes. That connects the company identity, assigned resources, live routing and an advertised service.
PeeringDB's ThaiNS network record describes AS141362 as IPv4- and IPv6-capable, with open peering and self-reported traffic in the 5-10 Gbps range. Its exchange rows show the two Bangkok 10 Gbps connections and one Chiang Mai 1 Gbps connection. These are useful installed-capacity signals. They should not be summed into a promise of 21 Gbps of customer-usable service. Ports can be redundant, oversubscribed, limited by upstream paths or devoted to different traffic.
Observed BGP paths frequently place BKNIX immediately before AS141362, while some vantage points see other adjacencies. That suggests more than one route presentation to the global Internet. It cannot establish which links are paid transit, settlement-free peering, route-server propagation or backup. Contractual diversity requires contract and circuit evidence, not path inference alone.
The address allocation adds another boundary. APNIC's record for the enclosing range names the Thai Network Information Center Foundation as holder, while AS141362 is the observed origin of the more-specific /24. This is coherent with the wider THNIC operating family. It also means a procurement review should map resource authority, route operation and application ownership separately rather than assuming they all sit in one contract.
A second live ThaiNS ASN is useful, but not automatically independent
ThaiNS also holds AS142437, registered in 2021. Routing telemetry reported it live on 12 July 2026 with 203.159.64.0/24 and 2405:3340:e011::/48. The authoritative b.thains.co.th addresses fall inside those prefixes, so the second ASN is not an unused identifier: it carries a visible part of the .th and .ไทย nameserver set.
That is material evidence of separation from AS141362. The two ASNs originate different IPv4 and IPv6 blocks. They were allocated in different years. They carry different public services. A fault restricted to the AS141362 prefixes need not remove b.thains.co.th.
The limit is upstream concentration. A current routing summary for AS142437 shows one observed peer, AS4750, for both address families. This does not prove that the service has only one physical circuit or one hidden route; public collectors do not see every arrangement. It does mean the public evidence cannot support a claim of transit diversity for that ASN. A second ASN behind one observed upstream is a resilience component, not a complete resilience proof.
Both AS142437 prefixes were shown as RPKI-valid in the same routing summary. Valid route-origin authorisation reduces one class of routing mistake or hijack acceptance. It does not keep a router powered, repair a fibre, replace a failed line card or guarantee that the DNS process behind the address is answering.
Installed capacity is not usable capacity
The workload trend is visible. THNIC Foundation annual reports put .th registrations at 75,357 in 2021, 79,506 in 2022, 82,254 in 2023 and 84,771 in 2024. They put .ไทย at 30,311, 32,058, 32,580 and 34,220 respectively. Across the two namespaces, the reported total rose from 105,668 to 118,991 over those four year ends.
Those figures show a growing database, not a stressed one. Domain count is a poor substitute for DNS traffic because one popular name can generate more queries than thousands of quiet names. It is also a poor substitute for transaction load because renewal calendars, registrar automation and policy changes can create bursts. Still, the continuity and growth of the totals are positive operating evidence: the registry has been maintaining a substantial national namespace over time.
Installed network capacity is partly visible in exchange ports and prefixes. Usable capacity is not. There is no public count of servers, racks, processor cores, storage replicas, signing devices, power feeds, replacement units or staff per shift. There is no published peak query rate, attack headroom, zone-generation time, EPP transaction ceiling or backup-restore throughput. The self-reported PeeringDB prefix fields are implausibly large for the two prefixes actually observed and should be ignored.
This gap matters because redundancy consumes capacity. Two sites each sized for half the normal load do not provide full failover. A disaster-recovery site that can restore the database but cannot sign and publish the zone is not a complete substitute. Spare storage without compatible network ports does not shorten a router replacement. A nominally available rack can be unusable if the right engineer, credential or vendor part cannot reach it during a maintenance window.
The correct status is therefore neither "unverified shell" nor "fully evidenced resilient platform." ThaiNS has a sustained workload, current routes, live authoritative endpoints, current certification and active operational hiring. Its headroom and failover capacity remain private.
The economics are those of registry outsourcing
ThaiNS's offer is economically attractive for the same reason managed infrastructure usually is: specialised fixed costs can be shared. A prospective top-level-domain operator does not need to hire a 24/7 DNS and registry team, build EPP and RDAP services, arrange authoritative distribution, maintain signing controls, procure monitoring or rehearse recovery alone. ThaiNS says it can provide the back end without the customer installing infrastructure.
The savings create concentration. The customer depends on ThaiNS's hardware refresh cycle, network purchases, security controls, staffing and subcontractors. If the contract price does not fund enough spare capacity or independent sites, the apparent saving becomes deferred risk. If the service is deeply customised, migration can cost more than initial deployment.
Public pricing is absent, so no claim about ThaiNS's margins or customer economics is justified. The useful questions are structural. Does the fee include attack capacity, secondary-site operation and tested recovery? Are third-party authoritative nodes included under one service level? Who pays for emergency hardware and expedited remote hands? Are registrar interfaces, escrow, DNSSEC keys, monitoring and data export priced as one service or separate obligations?
The .scb reference shows the attraction and the dependency in a concrete form. Siam Commercial Bank retains sponsorship and contractual responsibility for the TLD while ThaiNS supplies technical registry operation. That arrangement lets the bank avoid building every layer itself. It also makes continuity dependent on a transition plan that covers database state, DNS, signing, registration data and registrar connectivity, not simply a copy of a website.
Data locality is a design fact, not a slogan
ThaiNS operates Thailand's national top-level domains and handles registration records. Its privacy policy describes the company as controller for personal data used in its services and names domain, contact, nameserver and registrar information among the records associated with registry and RDAP operation. The policy places those duties under Thailand's Personal Data Protection Act.
The public-resolver page argues for keeping more DNS traffic inside Thailand and reducing privacy leakage. Local routing can support that aim when Thai users reach a domestic resolver or authoritative node instead of sending queries abroad. The BKNIX Bangkok and Chiang Mai presence is relevant because domestic interconnection can shorten paths and reduce dependence on international links.
But locality is not absolute. ThaiNS advertises an offshore disaster-recovery site. The authoritative set includes addresses carried on several external networks. Anycast can answer from different places depending on routing. Registration-data backups, escrow deposits, logs and recovery copies may have different locations from live DNS nodes. None of this is inherently contradictory; geographic separation is a resilience control. It means a customer should ask which data categories leave Thailand, in what form, under whose custody and with what return or deletion obligations.
The 2024 foundation report says ThaiNS manages registration-data storage, backups and DNS, but it does not identify where each copy resides. The privacy policy explains purposes and rights, not a full infrastructure map. A credible locality claim therefore needs a data-location schedule: primary database, replicas, backups, escrow, logs, support access, signing material and analytics, each tied to a jurisdiction and operator.
The labor layer is unusually visible
Infrastructure descriptions often stop at hardware. ThaiNS's recruitment page offers a better view of the human system. It describes a Bangkok-based 24/7 network operations centre, staff who monitor servers, networks, backups and security logs, and officers who open and assign trouble tickets, act as outage focal points and work rotating shifts. Network-engineering duties include routing, switches, firewalls, VPNs, monitoring and documented change. Systems duties include server setup, maintenance, backup and recovery for mission-critical systems.
This is positive evidence that ThaiNS understands the work behind its service claims. It also exposes the dependency. A 24/7 centre is only as resilient as shift coverage, escalation authority, documentation and retention. The page lists roles and desired positions; it does not reveal how many qualified people are currently on each shift, whether the listed posts are filled, or how quickly a senior engineer can act outside office hours.
The distinction between office support and emergency support also matters. The contact page gives normal weekday hours. The monitoring roles describe round-the-clock operation. A customer needs the latter commitment in contract form: incident channels, acknowledgement targets, severity definitions, named escalation levels and authority to initiate failover. An always-lit alarm screen is not the same as an engineer empowered to repair the system.
Security evidence is meaningful, but it is not capacity evidence
ThaiNS holds BSI certificate IS 763878 for ISO/IEC 27001:2022. The certificate covers the back-end registry operation, core domain-name database, public DNS and registrar-facing registration systems. It records an original registration date in 2022 and a current certification period from 13 June 2025 to 12 June 2028.
That is stronger than a generic badge because the scope matches the important systems. It shows an externally certified information-security management system around the registry's core. The 2023 foundation report also says ThaiNS participated in a national critical-cyber-threat exercise. The .scb DNSSEC practice statement describes protected primary and secondary facilities, restricted physical access and controlled key operations.
None of these records promises uninterrupted service. ISO certification does not disclose spare-server count, generator runtime, transit diversity or restore speed. An exercise demonstrates preparation only to the extent that its scenario, result and remediation are known; the public report does not provide them. A practice statement describes intended controls but is not a continuous measurement of their execution.
The fair conclusion is that security governance is evidenced more strongly than physical capacity. Buyers should value the certificate and policy set, then ask for the operational evidence that certification does not supply: recent recovery tests, failover timings, capacity thresholds, incident history and corrective actions.
Failure path one: registry state, billing and provider contracts
A back-end registry can fail while every authoritative server remains reachable. Database corruption, a failed database change, an EPP defect or an incorrect registrar transaction can stop new work or alter the wrong record. The existing zone may continue to answer from its last published copy, hiding the control-plane fault from ordinary users while registrars accumulate requests.
Recovery requires more than restoring a disk image. The operator must know the last consistent transaction, reconcile registrar requests, regenerate the zone, preserve DNSSEC continuity and confirm that RDAP reflects the same state. If the database, journal, zone and escrow copy represent different moments, choosing the wrong one can turn a short outage into a data-integrity incident.
Commercial failure has similar technical consequences. If a registry customer disputes an invoice, ends a provider contract or becomes unable to pay, service continuity depends on termination terms. A responsible contract should prevent abrupt suspension of a critical namespace, define notice and cure periods, preserve emergency DNS, and require cooperation with a replacement operator. It should say who owns custom code, configuration, monitoring history and credentials.
For .th, the foundation's policy authority and designation provide an institutional layer beyond the operating company. For a commercial back-end customer, the answer may depend much more heavily on the service contract and ICANN transition requirements. The public ThaiNS pages do not publish a standard exit schedule, migration format or transition-assistance period. Those terms should be treated as unresolved, not assumed.
Failure path two: racks, power, routes and hardware stock
A registry application still runs on physical equipment somewhere. A rack loses power, a top-of-rack switch fails, a cross-connect is moved incorrectly, cooling degrades or a storage controller reaches end of life. Dual-site architecture reduces the impact only if the sites do not share the failed dependency and the surviving site has enough usable capacity.
ThaiNS's authoritative distribution is a strong defence against one DNS rack failure. AS141362's Bangkok and Chiang Mai exchange presence adds route options. AS142437 gives b.thains.co.th a separate originated network. External authoritative addresses add further diversity. Yet the central registry database and signing system may be more concentrated than the query layer. Public DNS diversity should not be used as proof of registry-database diversity.
Upstream failure is also service-specific. AS142437 has one publicly observed peer, while AS141362 appears through BKNIX and other paths. A route withdrawal from one ThaiNS ASN does not remove all authoritative servers, but it can remove the resolver or the b node from affected networks. A BKNIX maintenance window may alter domestic paths without interrupting overseas authoritative nodes. A partner-node problem may affect an address outside both ThaiNS ASNs.
Hardware stock decides whether a contained fault stays contained. A spare drive is not a spare router. A spare router without matching optics and configuration is not a short repair. A replacement signing device may require ceremony, authorisation and key restoration. ThaiNS's recruitment material mentions equipment control and server maintenance, but no public policy states which critical parts are held on site or the vendor replacement window.
Failure path three: DNSSEC can make healthy servers return unusable answers
THNIC Foundation says ThaiNS has signed .th and .ไทย since 2009. That protects validating users against forged DNS data when the chain is correct. It also introduces a failure mode in which authoritative servers are reachable but validators reject the answer because signatures, keys, delegation records or timing are wrong.
The .scb DNSSEC practice statement is useful because it identifies protected facilities, key roles and publication duties. It shows that signing is not merely software running beside the zone file; it includes restricted access, controlled key material, registrar submissions of delegation-signer records and publication into the parent chain.
A recovery site must reproduce those capabilities. Restoring the registry database without access to valid signing keys can delay safe publication. Restoring old keys or old signed zones can collide with rollover state and signature expiry. Clock error can invalidate otherwise correct signatures. A rushed emergency change can therefore turn a storage incident into a resolution incident.
The 2024 DNSSEC status report shows that adoption among domains below .th remained limited, although important sectors had stronger participation. That means a TLD-signing failure would not affect every child in exactly the same way. It would nonetheless damage the trust chain for validating users and every signed delegation that relies on it.
Failure path four: RDAP and the public resolver can fail without the registry failing
ThaiNS's RDAP service gives the public structured registration data for .th and .scb. Its own policy allows protective limits on mass queries and says RDAP is not the EPP registration system. An RDAP outage or throttle can disrupt investigators, rights holders, administrators and automated lookup users while registrations and DNS continue.
The free recursive resolver is another separate dependency. Only users or networks configured to send queries to the published addresses depend directly on it. If that resolver fails, they can change resolver or fall back according to local configuration; the authoritative .th servers may remain healthy. Conversely, a failure of an authoritative TLD server can affect many recursive resolvers while ThaiNS's own recursive service still answers cached data.
These distinctions should shape incident communication. "DNS is down" is too vague. ThaiNS should identify whether the event concerns recursive resolution, authoritative service, registry transactions, RDAP, zone signing or route reachability, and give a service-specific next update.
Failure path five: monitoring, escalation and migration
ThaiNS advertises 24/7 monitoring and describes staff who handle alarms and outages. A monitoring failure can be quieter than a server failure: the service degrades, but the first useful alert comes from a registrar or outside resolver. Coverage must include application correctness, not just host reachability. A DNS process can answer while serving a stale zone; an EPP endpoint can accept connections while transactions fail; an RDAP endpoint can return structurally valid but outdated data.
Escalation is the bridge between signal and repair. The first operator must know whether to call network, database, security, DNSSEC or facility staff. Someone must have permission to withdraw a bad route, stop zone publication, switch sites or begin restoration. If a partner-operated authoritative node is involved, the contact path crosses company boundaries. If IANA delegation data must change, the time horizon becomes longer again.
Migration is the final recovery option and often the least tested. A replacement back-end operator needs an accurate registry export, registrar mappings, EPP statuses, contacts, host entities, DNSSEC records, billing and policy state, zone data, RDAP behavior and documentation. It may need temporary parallel operation while the old and new systems converge. Private signing keys may not be exportable, which makes controlled rollover part of the move.
Data portability is therefore not satisfied by a downloadable database file. It requires formats, frequency, validation, credentials, runbooks, contractual cooperation and a rehearsed sequence. ThaiNS's public pages say the platform is managed for customers; they do not publish these exit mechanics.
Recovery is a chain from data to route
A credible recovery claim for ThaiNS has to answer five linked questions.
Is the state recoverable? Backups and escrow must be recent, internally consistent and protected. The 2010 IANA report recorded offsite backups and regular escrow, and later foundation reports continue to assign backup responsibility to ThaiNS. The missing evidence is restore age, success rate and reconciliation procedure.
Can the application run elsewhere? ThaiNS says it has dual-site service and an offshore recovery site. The missing evidence is which components run at each site, whether the recovery environment is continuously compatible, and whether it can carry the full transaction and query load.
Can the recovered state be published safely? Zone generation, DNSSEC signing and distribution must work. Key material, clocks, parent records and remote authoritative nodes have to align. An available database with an unpublishable zone is not recovered service.
Can users reach it? Routes, exchange ports, transit and authoritative distribution have to direct traffic to healthy nodes. Two live ASNs and multiple external nameserver networks are positive evidence, but the central application's network path is not publicly mapped.
Can people complete the change? Monitoring staff, senior engineers, security custodians, facility access and customer contacts must be available. Recruitment descriptions show that ThaiNS assigns these functions. They do not disclose staffing depth or test performance.
This chain explains why a design-capacity statement is not enough. Recovery time is controlled by the slowest unprepared step. A database restore measured in minutes provides little comfort if a signing ceremony takes a day, a replacement cross-connect takes two days or the customer has no authorised person to approve delegation changes.
Who is affected when the chain breaks
The largest affected group is not a list of ThaiNS retail customers. It is the registrants and users of the namespaces ThaiNS operates.
A control-plane outage affects registrars and registrants trying to create, renew, transfer or modify names. A publication delay affects registrants whose changes have not reached the zone. A broad authoritative failure affects people trying to reach websites, mail systems, government services, schools and businesses under .th or .ไทย after caches expire. A DNSSEC error especially affects users behind validating resolvers. An RDAP outage affects people who need registration information, while a public-resolver outage affects those configured to use ThaiNS's resolver.
The workload has national reach. The 2024 foundation report counted 84,771 .th names and 34,220 .ไทย names. Those totals do not equal simultaneous users, and many domains may be quiet. They do show that even a compact operator can sit behind a large and varied set of institutions.
The .scb service has a narrower namespace but a high consequence for the sponsoring bank. A defect could affect the bank's brand-domain operations even if .th remains normal. Monitoring customers could experience separate effects again. Incident scope has to be established by product, zone, address family, route and geography.
What a customer should require before relying on the capacity
ThaiNS has enough public evidence to justify serious diligence rather than dismissal. The diligence should request documents that connect the visible service to the hidden physical stack.
For sites and power, request a current architecture schedule naming the two active sites and offshore recovery site by jurisdiction and operator. It should identify which registry, signing, RDAP, monitoring and DNS components run at each; whether power and cooling are independently backed; and whether any pair shares a building, utility feed, metro fibre route or remote-hands provider.
For network diversity, request circuit and routing diagrams that distinguish exchange peering, route-server use, private interconnect and paid transit. AS141362's Bangkok and Chiang Mai exchange ports and AS142437's separate prefixes should be mapped to services. The customer should see whether the b node's observed AS4750 dependency has a private or physical alternative and how IPv4 and IPv6 fail separately.
For capacity, request normal and peak EPP transactions, zone-generation duration, authoritative and recursive query rates, attack headroom, storage growth, replication lag and per-site failover limits. Require evidence that one site can carry the defined critical load after another fails. Port speed alone should not satisfy this requirement.
For hardware and maintenance, request lifecycle dates, spare-stock policy, support contracts and replacement targets for routers, switches, storage, compute, signing devices and optics. Maintenance terms should state whether work is hitless, which services can be degraded, how registrars are notified and what rollback trigger applies.
For recovery, request the latest restore and site-failover reports with observed recovery time and recovery point, not only targets. The test should cover registry state, registrar transactions, signed zone publication, authoritative distribution, RDAP and monitoring. Exceptions should have owners and completion dates.
For people, request a service-specific escalation matrix, 24/7 acknowledgement times, staffing minimums, on-call depth and partner contacts. Normal office hours and NOC hours should be separated. The contract should identify who can authorise site failover, route changes, key operations and emergency customer communication.
For data locality, request a copy-by-copy schedule for live databases, replicas, backups, escrow, logs and support access. It should state jurisdiction, encryption, retention, controller or processor role, subprocessors and deletion on exit. The offshore recovery claim makes this a necessary resilience and governance question, not an accusation.
For portability, require periodic, validated registry exports and enough documentation for a successor to reconstruct policy and technical state. Define transition assistance, parallel-run support, DNSSEC rollover, registrar testing, emergency DNS continuity, data return and secure destruction. Contract suspension should not be allowed to create an abrupt public-resolution failure.
For transparency, request a service-status channel and incident reports that separate registry, authoritative DNS, recursive DNS, RDAP, monitoring and network events. Availability numbers should define measurement points and exclusions. An independent check of authoritative service from multiple Thai and international networks would make the redundancy claim much easier to evaluate.
The operating-status conclusion is positive, with a physical-evidence downgrade
ThaiNS has a thin promotional footprint but not a thin operating footprint. Its identity is corroborated by foundation, IANA and APNIC records. Its registry role persists across annual reports. The .th and .ไทย delegations are live. Two ThaiNS ASNs were announced on the publication date. AS141362 has visible exchange attachments in Bangkok and Chiang Mai. The current ISO certificate covers the relevant systems. These facts support an operating company and an active infrastructure role.
The downgrade belongs elsewhere. Public evidence does not locate the active registry sites, identify the offshore recovery jurisdiction, quantify headroom, verify transit contracts, state restoration objectives, show recent failover results or explain customer exit. Multiple authoritative networks reduce query-plane risk, but they do not prove that the central database and signing stack can move cleanly between sites.
The final network evidence grade is Medium. ThaiNS is more consequential than the generic cloud label suggests and more operationally visible than its modest website implies. The unresolved question is not whether it exists. It is whether the physical, contractual and human dependencies behind its national registry role are independent enough, and tested often enough, to keep a database repair, route change or maintenance window from becoming a namespace incident.