Good Domain Registry Private Limited vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Good Domain Registry Private Limited est visible d'abord comme un bureau d'enregistrement de domaines, pas comme une marque de cloud. Sapage d'accueilindique qu'elle fournit des services d'enregistrement de domaines via un réseau mondial de partenaires, prend en charge de nombreux gTLD et ccTLD, et propose des services de registre en marque blanche, un accès API, des panneaux de contrôle en marque privée et un WHOIS de marque. Laliste des identifiants de registre IANArépertorie Good Domain Registry Pvt Ltd. comme accrédité sous l'ID 1533.
• Les preuves d'hébergement sont réelles mais contractuelles plutôt que riches en catalogues de produits. Lesconditions d'utilisationfont référence à l'hébergement partagé, à l'hébergement revendeur, aux VPS, aux serveurs dédiés, aux sauvegardes hebdomadaires, aux travaux de restauration payants, aux allocations de bande passante, aux limites de ressources, au crédit de disponibilité et aux réinitialisations de mot de passe des serveurs dédiés. L'extension de l'accord de revendeur pour l'hébergementstipule que Good Domain Registry fournit des services d'hébergement web, de serveur privé virtuel et de messagerie via des revendeurs.
• Les preuves réseau sont concrètes. APNIC identifieAS132322comme GDRPL-IN pour Good Domain Registry Private Limited, et APNIC répertorie103.14.120.0/22sous GDRPL-IN. RIPEstat a vuAS132322 annoncéle 12 juillet 2026, avecdix préfixes IPv4 /24 visibles, un voisin observé et aucun IPv6 visible dans lavue de statut de routagevérifiée.
• La question opérationnelle n'est pas de savoir si Good Domain Registry a une identité publique de registre et de réelles ressources de routage. C'est le cas. La question est de savoir quels racks, salles de centre de données, chemins amont, systèmes DNS, responsabilités des revendeurs, dépôts de sauvegarde, pièces de rechange matérielles, droits d'escalade du support et procédures de migration rendent ses services hébergés utilisables lorsqu'un serveur, un amont, un compte de facturation, un revendeur, un serveur de noms ou un processus d'installation tombe en panne.

Une surface de registre avec des fonctions d'hébergement en dessous

Le visage public de Good Domain Registry est celui d'un bureau d'enregistrement. Lapage d'accueilprésente GoodDomainRegistry comme un fournisseur industriel de solutions d'enregistrement de domaines dont les services sont disponibles via un réseau mondial de partenaires. Elle indique également que l'entreprise propose un large panier de gTLD et ccTLD, des services de registre en marque blanche, une API de programmation, des panneaux de contrôle en marque privée, un WHOIS de marque Port 43 et Web, ainsi que des outils de gestion des contacts. Lapage à proposva plus loin, décrivant l'entreprise comme un bureau d'enregistrement accrédité par l'ICANN, affirmant qu'elle possède plus de treize ans d'expérience dans les solutions d'enregistrement de domaines, et nommant Murugan Ranganathan et Ranganathan E M comme directeurs.

Cela fait de la première couche opérationnelle un plan de contrôle de registre et de revendeur. Les clients peuvent ne pas voir Good Domain Registry lorsqu'ils achètent un domaine auprès d'un partenaire, mais le service du partenaire peut dépendre du compte de registre, de l'API, du service WHOIS, des outils de mise à jour des contacts, des accords juridiques, du service des abus et des processus de renouvellement de Good Domain Registry. Une panne du bureau d'enregistrement de domaines n'est pas la même chose qu'une panne de machine virtuelle.

Elle peut arrêter les enregistrements, les transferts, les renouvellements, les modifications de contacts, les réponses WHOIS, les changements de serveurs de noms ou le triage des abus. Pour de nombreuses petites entreprises, ces fonctions de plan de contrôle sont plus importantes qu'un rack plein de calcul. Un domaine qui ne peut pas être renouvelé ou mettre à jour les serveurs de noms peut rendre un service hébergé par ailleurs sain inaccessible.

L'histoire de l'infrastructure, cependant, ne concerne pas seulement l'enregistrement de domaines. Les propres contrats publics de Good Domain Registry incluent également l'hébergement. Lesconditions d'utilisationtraitent de la configuration de compte pour les achats de serveurs dédiés et les transactions à haut risque, des transferts de compte depuis d'anciens hébergeurs, des serveurs partagés et revendeurs, des VPS, des serveurs dédiés, des sauvegardes hebdomadaires, des frais de restauration de sauvegarde, du crédit de disponibilité partagé/revendeur, des allocations de bande passante, des limites d'inodes, des serveurs semi-dédiés et de l'administration de serveurs dédiés. L'accord de revendeur pour l'hébergementstipule que Good Domain Registry fournit des services d'hébergement web, de serveur privé virtuel et de messagerie, et que chaque commande d'hébergement web, VPS ou messagerie est une commande d'hébergement dans le cadre du contrat de revendeur.

Cela suffit pour considérer Good Domain Registry comme une entreprise d'infrastructure dont l'offre publique est répartie sur deux couches. Une couche est l'infrastructure d'enregistrement de domaines: accréditation de registre, relations avec les registres, accords de domaine, panneaux de contrôle, WHOIS et support partenaire. L'autre couche est la capacité hébergée: hébergement partagé, hébergement revendeur, VPS, hébergement de messagerie et serveurs dédiés, au moins en tant que services décrits dans ses conditions et accords de revendeur.

Le site public ne fournit pas de catalogue de produits cloud moderne actuel avec des emplacements nommés, des SKU de processeur, des niveaux de stockage, des cartes réseau ou des photos d'installations. Ainsi, la note d'hébergement doit être abaissée. Le service est visible dans les conditions contractuelles et les enregistrements réseau, mais le parc physique derrière n'est que partiellement exposé.

Cette distinction est importante pour le lecteur. Un partenaire peut vendre un bundle de domaine, un DNS géré, un transfert de courrier, un hébergement web et un VPS sous sa propre marque tandis que Good Domain Registry reste le registre amont ou le parent de service. Un client final peut voir une marque et une facture, tandis que la chaîne de défaillance traverse un partenaire, Good Domain Registry, les opérateurs de registre, les serveurs de noms DNS, le routage, les opérations du centre de données, le stock de serveurs et les files d'attente de support. C'est une structure familière dans l'industrie de l'hébergement.

C'est aussi pourquoi le système ne peut pas être évalué uniquement en demandant si le site web se charge.

L'identité corporative et de registre est plus forte que la carte des installations

L'identité de registre de Good Domain Registry est soutenue par de multiples sources publiques. LeCSV des identifiants de registre IANArépertorie Good Domain Registry Pvt Ltd. comme un bureau d'enregistrement accrédité avec l'ID 1533 et l'URL de base RDAPhttps://rdapserver.net/. Lapage des bureaux d'enregistrement accréditésde l'ICANN explique que la liste des bureaux d'enregistrement accrédités fournit des coordonnées publiques, des numéros IANA et des liens vers les sites web des entreprises accréditées pour agir en tant que bureaux d'enregistrement dans un ou plusieurs domaines génériques de premier niveau. La proprepage juridiquede l'entreprise indique que les domaines actifs enregistrés via GoodDomainRegistry par ses partenaires sont régis par l'accord registre-registrant et donne une adresse de notification pour Good Domain Registry Pvt Ltd. au 10, Pallavan Salai, Perambur, Chennai, Tamil Nadu, Inde-600011.

L'enregistrement de domaine du propre site de Good Domain Registry soutient également l'identité. La réponse RDAP de Verisign pourgooddomainregistry.commontre le domaine enregistré en novembre 2009, expirant en novembre 2026, avec Good Domain Registry Pvt Ltd. comme registre etGD1.GOODDOMAINREGISTRY.COMetGD2.GOODDOMAINREGISTRY.COMcomme serveurs de noms. Une recherche RDAP plus large surrdapserver.netdonne des coordonnées de contact à Chennai et Tamil Nadu, le même domaine Good Domain Registry, et des contacts administratifs ou techniques utilisant[email protected]et le numéro de téléphone +91 9360303099. Les enregistrements de domaine ne prouvent pas la propriété des racks, mais ils prouvent que le propre domaine de l'entreprise se trouve à l'intérieur du modèle d'exploitation de registre et de DNS qu'elle vend.

Les enregistrements APNIC ajoutent une identité réseau distincte. L'enregistrement RDAP AS132322identifie AS132322 comme GDRPL-IN, pays IN, actif, enregistré le 9 juillet 2012 et associé aux contacts de Good Domain Registry Private Limited au 34A, Main Road, Kennedy Square, Perambur, Chennai-600011. L'enregistrement RDAP 103.14.120.0/22répertorie GDRPL-IN comme espace IPv4 portable alloué, actif, enregistré le 9 juillet 2012, avec le même groupe d'adresses de Chennai et les contacts[email protected]et[email protected]. Lavue whoisde RIPEstat montre également aut-num 132322, as-name GDRPL-IN et la description Good Domain Registry Private Limited.

Il y a une nuance d'adresse petite mais importante. Les enregistrements réseau APNIC utilisent 34A, Main Road, Kennedy Square, Perambur. Lapage de contactde l'entreprise, lapage juridiqueet le module de l'agent de réclamation donnent 10, Pallavan Salai, Perambur. Ces enregistrements sont suffisamment proches géographiquement pour ne pas être présentés comme une contradiction. L'un peut être une adresse d'administration réseau, et l'autre peut être une adresse corporative ou de notification. Mais la variation rappelle que les données de contact administratif ne sont pas une carte des installations. Aucune des deux adresses n'identifie un étage de centre de données, une cage de rack, une alimentation électrique, une salle de rencontre amont ou un inventaire de serveurs.

La carte publique des installations est le point faible. Les conditions font référence à plusieurs reprises aux serveurs, aux actions du centre de données et à l'administration des serveurs dédiés, mais le site ne nomme pas les centres de données, les villes, les racks, la topologie d'alimentation, l'hôtel de transporteur, le fournisseur DDoS, le fournisseur de mains à distance, la conception du nœud hôte, l'emplacement du dépôt de sauvegarde ou le processus de remplacement du serveur.

Ce n'est pas inhabituel pour une petite entreprise d'hébergement dirigée par des partenaires, mais c'est la différence entre une identité opérationnelle visible et une plateforme cloud entièrement vérifiable.

Le modèle partenaire change qui doit répondre en cas de panne

Good Domain Registry indique qu'elle ne vend pas directement aux clients finaux dans le flux de registre ordinaire. Lapage de tarificationdéclare que l'entreprise fournit des services d'enregistrement de domaines via un réseau mondial de partenaires et ne vend pas directement aux clients finaux; elle indique que le tableau de tarification est indicatif et que le montant réel dépend de l'emplacement de l'acheteur et de l'organisation auprès de laquelle il achète. Lapage d'accueilindique que les services sont disponibles via des partenaires et met l'accent sur les services de registre en marque blanche. Lapage de supportdit aux propriétaires de domaines de contacter l'organisation par laquelle ils ont enregistré le nom de domaine, puis les oriente vers une recherche WHOIS s'ils doivent identifier cette organisation.

C'est un bon ajustement commercial pour l'infrastructure de registre. Les partenaires peuvent faire face aux clients, fixer les prix localement, regrouper les domaines avec l'hébergement ou la messagerie, et utiliser Good Domain Registry comme registre amont et plateforme. Mais cela crée une limite de support. Lorsqu'un client ne peut pas renouveler un domaine, modifier un serveur de noms, récupérer un compte d'hébergement ou escalader une plainte d'abus, la première ligne de support peut être le partenaire.

Good Domain Registry peut contrôler le service amont, mais le revendeur peut contrôler la relation client, les factures, la vérification d'identité et la première réponse. Une panne de partenaire peut donc ressembler à une panne de Good Domain Registry pour l'utilisateur final, même si le système amont est sain.

Les documents juridiques renforcent cette structure. L'accord maître de revendeurétablit Good Domain Registry Pvt Ltd. comme parent et le partenaire comme revendeur. L'extension de l'accord de produit d'enregistrement de domainestipule que le revendeur fournit des services d'enregistrement, de gestion, de renouvellement ou de transfert via le parent et doit s'assurer que les registrants acceptent les conditions du registre, affichent les frais d'enregistrement et de renouvellement et envoient des rappels d'expiration. Il réserve également des droits étendus pour le parent et les fournisseurs de services de geler, supprimer, suspendre, refuser, annuler, modifier, prendre possession ou transférer une commande de domaine dans certains cas de conformité, de litige, d'exactitude ou de politique.

L'extension de l'accord d'hébergement applique la même logique parent-revendeur à la capacité hébergée. Elle stipule que le revendeur choisit de fournir des services d'hébergement web via le parent, et que chaque commande d'hébergement web, VPS ou messagerie est une commande d'hébergement. Elle indique également que certaines commandes d'hébergement peuvent être décrites avec des attributs illimités, mais Good Domain Registry peut appliquer des limites strictes à tout moment pour protéger l'intégrité du service, éviter la dégradation, traiter une violation ou éviter la responsabilité.

Cette clause est l'économie de la capacité partagée dans un paragraphe. La promesse de prix ou de plan public n'est pas identique à une capacité utilisable et non contestée. Le parent se réserve le droit de contraindre les ressources lorsque la plateforme partagée est stressée ou abusée.

Pour les clients, cela signifie que le chemin de défaillance comporte au moins trois couches. La première est le partenaire face au client: qui reçoit les paiements, les demandes de support, les pièces d'identité et les avis d'annulation. La deuxième est Good Domain Registry: plateforme de registre, parent d'hébergement, DNS, bureau des abus et opérateur réseau. La troisième est le fournisseur de services ou le centre de données derrière Good Domain Registry où l'alimentation, le transit et le travail matériel se produisent. Si une couche a une documentation incomplète ou une escalade lente, le client subit des temps d'arrêt.

Le bord réseau est réel et actuellement visible

La preuve technique la plus solide est AS132322. Lavue d'ensemble ASde RIPEstat a rapporté le 12 juillet 2026 que AS132322 était annoncé et détenu par "GDRPL-IN - Good Domain Registry Private Limited." Lestatut de routagede RIPEstat a montré une première preuve de route en juillet 2012, une dernière preuve le 12 juillet 2026, 10 préfixes IPv4 visibles, 2 560 adresses IPv4, une visibilité depuis 325 des 326 pairs RIS IPv4, aucun préfixe IPv6 visible et un voisin observé. C'est un signal opérationnel significatif: Good Domain Registry n'est pas seulement un nom juridique dormant ou un site web statique.

Lesdonnées de préfixes annoncésde RIPEstat ont répertorié dix préfixes IPv4 /24 pour AS132322 dans la fenêtre vérifiée du 28 juin au 12 juillet 2026: 103.14.120.0/24, 103.14.121.0/24, 103.14.122.0/24, 103.14.123.0/24, 103.91.186.0/24, 103.91.187.0/24, 103.169.176.0/24, 103.169.177.0/24, 163.128.112.0/24 et 163.128.113.0/24. Les quatre annonces 103.14.120.0/24 à 103.14.123.0/24 se trouvent dans l'allocation APNIC103.14.120.0/22pour GDRPL-IN.

Les autres blocs annoncés nécessitent plus de prudence. APNIC identifie103.91.186.0/23comme SBITPL, associé aux contacts Square Brothers au même groupe d'adresses de Perambur et aux contacts squarebrothers.com. APNIC identifie103.169.176.0/23comme ONEHOSTIN, avec des contacts onehost.in à Perambur. APNIC identifie163.128.112.0/23comme VPSJUNGL, avec des contacts vpsjungle.in à Kennedy Square à Perambur. Ce ne sont pas des preuves que Good Domain Registry possède toutes les entreprises connexes ou les marques clients. Ce sont des preuves qu'AS132322 originaire actuellement des préfixes enregistrés sous des noms administratifs réseau/d'hébergement connexes ou proches. Un lecteur devrait les traiter comme des ressources routées, pas comme des entités d'annuaire séparées ou des relations corporatives implicites.

Lavue de cohérence de routage ASde RIPEstat montre pourquoi la distinction est importante. Elle répertorie 103.14.120.0/22 comme présent dans whois mais pas dans BGP au niveau agrégé, tandis que les quatre /24 composants sont présents dans BGP. Elle répertorie 103.91.186.0/24, 103.91.187.0/24, 103.169.176.0/24, 103.169.177.0/24, 163.128.112.0/24 et 163.128.113.0/24 comme présents dans BGP et whois. C'est assez normal comme présentation de routage, mais cela signifie que les preuves de route publique doivent être décrites au niveau du préfixe plutôt que vaguement comme "tout le réseau de l'entreprise." Les agrégats, les clients et les allocations de marque peuvent différer.

La sécurité de l'origine de la route est mixte. Lavalidation RPKI pour 103.14.120.0/24et103.91.186.0/24a retourné inconnu car aucun ROA validant n'était présent dans ces réponses vérifiées. Lavalidation 103.169.176.0/24a retourné valide sous un ROA 103.169.176.0/23 avec une longueur maximale /24, et163.128.112.0/24a retourné valide sous un ROA /24. Ce n'est pas une découverte de puissance ou de rack. C'est une découverte d'hygiène de routage. Certaines annonces d'origine visibles ont une validation d'origine de route; d'autres non dans les réponses vérifiées.

Un amont visible fait de la diversité de transit une question vivante

Les preuves de routage sont visibles, mais l'image des voisins observés est étroite. Lavue des voisins ASNde RIPEstat a rapporté un voisin unique pour AS132322 au moment vérifié: AS17439. Lavue d'ensemble AS pour AS17439de RIPEstat identifie ce voisin comme "NCINSPL-IN - NTT COMMUNICATIONS INDIA NETWORK SERVICES PRIVATE LIMITED." L'enregistrement AS17439d'APNIC confirme NTT Communications India Network Services Private Limited, avec des coordonnées à Mumbai et un enregistrement actif. Leséchantillons BGPlayde RIPEstat pour du 10 au 12 juillet 2026 montraient à plusieurs reprises des chemins se terminant via AS17439 avant AS132322.

Cela ne prouve pas que Good Domain Registry n'a qu'un seul arrangement de transit commercial. Les collecteurs de routes publiques ne voient pas les sauvegardes privées, le basculement dormant, les contrats de fournisseur, les remises de couche 2, les tunnels d'urgence ou tout peering local. Cela signifie que la vue du collecteur public a vu un voisin amont.

Pour un client d'hébergement ou un revendeur, c'est la question de diligence raisonnable pertinente: AS17439 est-il le seul chemin actif transportant le trafic client, ou existe-t-il d'autres routes physiquement diverses qui prendraient la charge si AS17439, sa remise, une interconnexion, un routeur ou une fenêtre de maintenance amont tombe en panne?

La diversité de transit est importante différemment pour les deux couches de service. Pour les fonctions de registre, une panne peut affecter les appels API, le WHOIS, l'accès au panneau de contrôle, les modifications DNS et la réception des abus. Pour les fonctions d'hébergement, elle peut affecter l'accessibilité du site web, la livraison des e-mails, la gestion des VPS, les tableaux de bord clients, les transferts de sauvegarde et le support à distance. Si tous les services visibles par le client et les plans de contrôle dépendent du même chemin Chennai-amont, une panne amont peut devenir à la fois une panne client et une panne de support.

Si le DNS et l'hébergement sont également servis depuis le même domaine réseau, la panne devient plus facile à ressentir et plus difficile à contourner.

Le signal PeeringDB public est également faible. Une requête à l'API PeeringDB pourAS132322a retourné un tableau de données vide au moment vérifié. L'absence de PeeringDB ne prouve pas l'absence d'installations, de transit ou de participation à l'échange. De nombreux réseaux plus petits ne sont pas répertoriés, et certains réseaux évitent intentionnellement les profils d'interconnexion publics. Mais cela supprime une source publique qui pourrait autrement montrer les présences d'installations, les ports d'échange, la politique de trafic, les contacts NOC ou la portée géographique. Le résultat est une autre raison de ne pas revendiquer une connectivité multisite vérifiée à partir de preuves publiques.

Le statut de routage de Good Domain Registry mérite donc une note modérée. L'AS est actuel, largement visible et associé à plusieurs préfixes IPv4. La vue amont est étroite, IPv6 n'était pas visible dans la réponse de statut de routage AS, et la couverture de validation d'origine de route est inégale. Un client prudent devrait demander un diagramme réseau actuel, une liste de transit active, un processus de notification de maintenance, une portée de mitigation DDoS, un historique de surveillance et la preuve que le plan de gestion reste accessible lorsque le plan de service client est altéré.

La localité des données commence à Chennai mais ne s'arrête pas là

La balise de région pour ce profil est Inde, et la preuve d'identité publique la plus forte est indienne. Le registre, l'adresse de notification légale, l'adresse de l'agent de réclamation, les contacts APNIC, les numéros de téléphone et les enregistrements d'abus pointent tous vers Chennai ou l'Inde. Lapage de contactdonne Good Domain Registry Private Limited au 10, Pallavan Salai, Perambur, Chennai, Tamil Nadu, Inde-600011, avec des coordonnées d'abus. Lapage de contact d'abus dédiédonne[email protected]et +91 93603 03099. Lapolitique de confidentialitéindique que Good Domain Registry collecte, utilise, conserve et divulgue des informations provenant des utilisateurs de son site web et de son service d'hébergement.

Mais la localité des données n'est pas la même que l'emplacement de l'entreprise. Un bureau d'enregistrement de domaines peut servir des gTLD mondiaux via de multiples opérateurs de registre. Une plateforme de revendeur d'hébergement peut stocker des enregistrements d'identité clients, des tickets de support, des sauvegardes, des données DNS et du contenu d'hébergement dans différents systèmes. L'extension de l'accord d'enregistrement de domainenomme de nombreux TLD et indique que certains sont fournis via d'autres bureaux d'enregistrement, y compris des entités liées à PublicDomainRegistry pour de nombreuses extensions. L'extension de l'accord de services webcouvre le transfert de domaine, le transfert de courrier et le DNS géré via le parent. Ces services peuvent déplacer des données via des serveurs de noms, des systèmes de transfert de courrier et des plateformes DNS gérées qui ne sont pas équivalents à un serveur physique à Chennai.

Les conditions permettent également une large intervention opérationnelle. Lesconditions d'utilisationindiquent que l'utilisation des services de Good Domain Registry est soumise au droit du Tamil Nadu et de l'Inde pour le contenu, mais les mêmes conditions disent également que Good Domain Registry peut surveiller ses systèmes pour une utilisation autorisée, la gestion, la protection, la survivabilité et la sécurité opérationnelle. Elles indiquent que les informations des abonnés peuvent être divulguées aux forces de l'ordre sur demande légale. La politique de confidentialité indique que les informations peuvent être divulguées à des filiales, des entrepreneurs indépendants et des partenaires commerciaux, et que les informations peuvent être transférées dans le cadre d'une vente de l'entreprise.

Pour un client, la question pratique n'est pas "Good Domain Registry est-il indien?" Les preuves disent oui. La question est de savoir où se trouve chaque catégorie de données: contacts de domaine, données de compte revendeur, historique de commandes, messages de relais de confidentialité WHOIS, tickets de support, contenu d'hébergement, bases de données, boîtes aux lettres de messagerie, dépôts de sauvegarde hebdomadaires, données de zone DNS et journaux. Les pages publiques ne fournissent pas d'inventaire des données par pays. Le résultat est une réserve de souveraineté des données.

L'identité de registre et de contact est indienne; la pile de services peut impliquer des opérateurs de registre, des partenaires, des fournisseurs de services, des centres de données, des systèmes de sauvegarde et des plateformes de courrier ou DNS au-delà des informations visibles sur le site public.

Cela importe le plus lorsqu'un incident traverse les frontières de responsabilité plutôt que les frontières sur une carte. Un revendeur peut être dans un pays, Good Domain Registry en Inde, un opérateur de registre ailleurs, un fournisseur de services d'hébergement dans un autre lieu, et un client final dans encore une autre juridiction. Une plainte d'abus de registre, un litige de transfert de domaine, une demande de restauration de sauvegarde ou une réinitialisation de mot de passe de serveur dédié peut toucher plusieurs règles opérationnelles.

Le dossier public ne montre pas comment ces règles sont conciliées lors d'une panne critique en temps.

La capacité installée n'est pas la même que la capacité utilisable

Les preuves d'hébergement de Good Domain Registry sont les plus fortes là où elle fixe des limites. Les conditions publiques et l'accord d'hébergement sont moins brillants qu'une page produit, mais ils exposent l'économie de l'hébergement partagé et revendeur. Lesconditions d'utilisationstipulent que les utilisateurs ne peuvent pas utiliser 20 % ou plus des ressources système pendant plus de 90 secondes, ne peuvent pas exécuter de processus serveur autonomes non surveillés, ne peuvent pas exécuter des tâches cron plus fréquemment que toutes les 15 minutes, et doivent respecter les limites MySQL sur certains plans partagés. L'extension de l'accord d'hébergement établit des contraintes similaires, y compris les limites sur les processus longs, l'utilisation P2P, les e-mails en masse, l'utilisation excessive des ressources, le nombre de fichiers, le stockage des e-mails, la taille de la base de données et les fichiers de sauvegarde stockés.

Ces conditions sont normales dans l'hébergement partagé car un hôte partagé vend plus de capacité théorique qu'un utilisateur ne devrait en consommer en continu. La proposition de valeur fonctionne lorsque chaque client utilise une petite partie, les abus sont contrôlés rapidement et le fournisseur peut limiter ou suspendre les valeurs aberrantes. Les mêmes économies rendent les attributs "illimités" dangereux s'ils sont lus littéralement.

L'accord d'hébergement indique que certains attributs peuvent consister en des ressources illimitées, mais Good Domain Registry peut appliquer des limites strictes pour éviter la dégradation et protéger les produits parents et OrderBox. C'est la bonne lecture publique: illimité est un terme de facturation et d'emballage, pas une garantie de CPU, disque, réseau ou travail de support illimité.

Les serveurs dédiés semblent différents mais ont leurs propres limites physiques strictes. Les conditions mentionnent les achats de serveurs dédiés, les scans de pièce d'identité gouvernementale ou de carte de crédit pour les transactions à haut risque, les réinitialisations de mot de passe des serveurs dédiés, les actions administratives du centre de données et la responsabilité de sauvegarde des serveurs dédiés.

Elles indiquent que Good Domain Registry peut réinitialiser un mot de passe de serveur dédié si le mot de passe enregistré n'est pas à jour afin que des audits de sécurité puissent être effectués comme requis par le centre de données, et que les serveurs dédiés ne sont pas sauvegardés par Good Domain Registry. Elles indiquent également que les clients peuvent acheter un disque dur supplémentaire et maintenir des sauvegardes dessus.

Ces clauses impliquent des limites de centre de données et de contrôle matériel, mais elles ne nomment pas le centre de données ni ne divulguent les pièces de rechange, les fenêtres de mains à distance, les SLA de remplacement ou la redondance d'alimentation.

La capacité VPS se situe entre les deux. L'accord de revendeur d'hébergement nomme les services VPS, et les conditions excluent les VPS de la garantie de remboursement qui s'applique à l'hébergement partagé et revendeur. Mais le site ne publie pas de page produit VPS actuelle avec des détails sur le CPU, la RAM, le stockage, l'hyperviseur, la sauvegarde, l'instantané, la migration ou l'emplacement. Cela force une dégradation.

L'entreprise déclare publiquement qu'elle fournit un hébergement VPS via le modèle revendeur, mais le dossier public ne prouve pas le nombre d'hyperviseurs installés, la marge de manœuvre utilisable, la migration en direct, l'architecture de stockage ou le temps de restauration.

Il en va de même pour l'hébergement de messagerie et le DNS géré. L'accord de services web couvre le DNS géré et le transfert de courrier, tandis que l'accord d'hébergement couvre l'hébergement de messagerie. Ces services sont lourds en plan de contrôle. Leur fiabilité dépend des files d'attente de messagerie, des systèmes anti-abus, de la diversité des serveurs de noms DNS, de l'accessibilité des résolveurs, de la propagation des modifications de zone et des contrôles de compte, pas simplement de la capacité des racks.

Les pages publiques ne fournissent pas l'architecture anycast DNS, la conception du cluster de messagerie ou les règles de rétention des files d'attente. Un client devrait donc demander des détails opérationnels spécifiques au service plutôt que de supposer que l'activité de longue date d'un bureau d'enregistrement prouve un hébergement résilient.

Les sauvegardes et restaurations sont explicitement limitées

La politique de sauvegarde est l'un des avertissements publics les plus clairs. Lesconditions d'utilisationde Good Domain Registry indiquent que son service de sauvegarde est fourni à titre de courtoisie, que les sauvegardes hebdomadaires des serveurs partagés et revendeurs sont uniquement à des fins administratives et que les clients sont responsables du maintien de leurs propres sauvegardes sur leurs propres ordinateurs personnels. Les conditions indiquent également que Good Domain Registry ne compense pas les données perdues ou incomplètes si les sauvegardes ne fonctionnent pas correctement, et qu'il n'y a aucune garantie quant à la disponibilité des sauvegardes.

Le chemin de restauration ajoute une autre contrainte. Les conditions indiquent que la restauration de sauvegarde n'est pas incluse dans les frais d'hébergement et entraîne des frais administratifs de Rs.500 ou 10 $ par instance si un client souhaite que Good Domain Registry restaure un site à partir du dépôt de sauvegarde hebdomadaire. Elles indiquent également que Good Domain Registry ne peut pas garantir l'intégrité du dépôt de sauvegarde hebdomadaire et que les sauvegardes ne seront pas fournies pour les comptes suspendus ou résiliés pour quelque raison que ce soit, sauf accord écrit contraire. Ce n'est pas une clause cachée.

C'est une déclaration publique selon laquelle les sauvegardes contrôlées par le client font partie de la conception du service.

Il existe d'autres contraintes de stockage. Les conditions interdisent d'utiliser l'hébergement partagé ou revendeur comme système de sauvegarde, de stockage ou d'archivage, n'autorisent qu'une seule sauvegarde cPanel ou Plesk pour le même compte pendant au plus trois jours calendaires, plafonnent certains stockages de messagerie et SQL, avertissent que les comptes abusant des serveurs comme stockage de messagerie peuvent être suspendus ou résiliés, et indiquent que les comptes dépassant certains seuils d'inodes ou de disque peuvent être retirés du système de sauvegarde hebdomadaire hors site.

L'extension de l'accord d'hébergement stipule de manière similaire que les commandes d'hébergement web et de messagerie ne peuvent pas être utilisées comme dispositifs de sauvegarde ou de stockage et ne peuvent pas stocker plus de deux fichiers de sauvegarde de site web.

Ces limites sont économiquement sensées. Un hébergement partagé ou revendeur à bas prix ne peut pas être à la fois un stockage de sauvegarde illimité, un stockage d'archives de courrier illimité, un stockage multimédia illimité et un site web de production. Mais ce sont aussi des faits opérationnels. Si un revendeur utilise l'hébergement Good Domain Registry comme seule copie de stockage pour les sites web clients, il construit sur une politique publique qui décline les garanties de sauvegarde.

Si un client VPS ou serveur dédié suppose que Good Domain Registry maintiendra des sauvegardes, les conditions disent le contraire, en particulier pour les serveurs dédiés et semi-dédiés.

Le chemin de défaillance pratique est simple. Un serveur tombe en panne, une base de données est corrompue, un problème de facturation suspend le compte ou un site est compromis. Le client demande une restauration. Good Domain Registry peut avoir une sauvegarde hebdomadaire, mais elle peut être indisponible, exclue, obsolète, supprimée en raison de seuils de disque, indisponible en raison de suspension ou soumise à des frais. Si le client n'a pas conservé de copie indépendante, la panne devient un événement de perte de données. C'est la différence entre la capacité installée et le service récupérable.

Le support, les abus et la conformité sont des surfaces opérationnelles

Les pages de support de Good Domain Registry sont orientées domaine, mais elles révèlent encore comment les incidents se déplacent. Lapage de supportindique que GoodDomainRegistry fournit des services d'enregistrement de domaines via son réseau de partenaires, dit aux propriétaires de domaines de contacter l'organisation par laquelle ils ont enregistré, et donne l'adresse d'abus lorsqu'ils doivent identifier l'organisation d'enregistrement. Lapage de contactdivise les demandes en support de domaine, programme de partenariat, plaintes de spam, plaintes de faux WHOIS, contact du propriétaire du domaine et contact direct GoodDomainRegistry si la voie partenaire ne fonctionne pas. Elle indique que les plaintes peuvent être transférées en interne à la bonne équipe, avec un certain délai.

Lapage de signalement d'abusfournit deux voies: processus de traitement des abus et contact d'abus dédié. Lapage de processusindique que Good Domain Registry enquêtera et enregistrera les signalements d'abus, peut agir en cas de violation de ses conditions, de la politique ICANN ou de la politique de registre appropriée, peut demander des informations supplémentaires, peut valider une plainte auprès du client et crée un ID de ticket pour suivre le signalement. Elle couvre le phishing, le spam, les logiciels malveillants, la contrefaçon, le contenu nuisible, la violation de propriété intellectuelle, l'invasion de la vie privée et l'inexactitude du WHOIS. Lapage de contact d'abus dédiédonne l'e-mail et le numéro de téléphone d'abus.

C'est une preuve positive d'une surface d'abus. Cela ne prouve pas les performances du temps de réponse, le personnel en dehors des heures ouvrables, la couverture linguistique, l'escalade vers les centres de données, l'autorité de restauration ou la capacité de routage d'urgence. Les conditions indiquent que le fait de ne pas répondre aux e-mails du service d'abus dans les 24 heures peut entraîner une suspension ou une résiliation du service, et que tous les problèmes d'abus doivent être traités par ticket ou e-mail avec une réponse dans les 24 heures. L'obligation de réponse incombe en partie au client.

Dans un environnement d'hébergement, une classification d'abus peut devenir un incident d'infrastructure car elle peut suspendre le site web, le service de messagerie, le VPS, le serveur dédié ou le chemin du nom de domaine.

L'escalade du support est particulièrement importante dans le modèle revendeur. Les conditions indiquent que les revendeurs sont responsables du support de leurs clients et que Good Domain Registry ne fournit pas de support aux clients des revendeurs. Si un client d'un revendeur contacte Good Domain Registry, l'entreprise peut mettre le compte client en attente jusqu'à ce que le revendeur assume la responsabilité. Cela protège la sécurité du compte et les limites du revendeur, mais cela peut ralentir la résolution d'un incident pour un utilisateur final qui ne comprend pas la chaîne.

En cas de panne de serveur, de préoccupation de détournement de domaine, de domaine expiré, de plainte d'abus ou de demande de sauvegarde, le client peut avoir besoin que le revendeur, Good Domain Registry et l'opérateur du centre de données agissent en séquence.

La politique de crédit de disponibilité limite également ce que les clients peuvent demander. Les conditions indiquent qu'un serveur partagé ou revendeur avec un temps d'arrêt physique en dehors du niveau de disponibilité de 99 % peut recevoir un mois de crédit de compte, à la discrétion de Good Domain Registry et avec une justification écrite. Les rapports de surveillance tiers peuvent ne pas être utilisés car la surveillance dépend de la capacité réseau et de la disponibilité du transit.

Les conditions définissent la disponibilité comme rapportée par le système d'exploitation et le serveur Web Apache, qui peuvent différer des services individuels. Les serveurs dédiés sont couverts par une garantie réseau avec un crédit au prorata pour les temps d'arrêt non liés à la garantie de disponibilité partagée/revendeur. Ces définitions ne sont pas des détails juridiques mineurs; elles déterminent si un client reçoit une compensation lorsque le service visible tombe en panne.

Les chemins de défaillance clés à tester

Le premier chemin de défaillance est la panne du plan de contrôle du registre et du DNS. Le propre site de Good Domain Registry dépend de ses serveurs de nomsgd1etgd2dans l'enregistrement RDAP Verisign. Son offre publique comprend des panneaux de contrôle en marque privée, un WHOIS de marque, une intégration API et des services de DNS géré ou de transfert de courrier. Si la connexion au compte, l'API, le WHOIS, les modifications de serveurs de noms, le traitement des renouvellements ou le DNS géré échouent, les clients peuvent perdre le contrôle même si un serveur web est sain. Une question de diligence raisonnable devrait demander si les plans de contrôle du registre, les serveurs de noms et les portails de support sont séparés géographiquement et opérationnellement du réseau d'hébergement.

Le deuxième chemin de défaillance est le transit amont. RIPEstat a vu un voisin observé, AS17439. Si ce chemin, cette remise ou cette politique amont échoue, les dix /24 visibles peuvent être affectés à moins qu'il n'existe un chemin de basculement public ou privé non vu dans les données du collecteur. Les clients utilisant l'espace IP hébergé par Good Domain Registry, les sites web hébergés par des revendeurs, les services de messagerie ou les portails de gestion devraient demander si le trafic de service, les sauvegardes et l'accès au support traversent tous la même dépendance amont.

Le troisième chemin de défaillance est la contention du nœud hôte ou du serveur partagé. Les conditions d'hébergement partagé et revendeur limitent le CPU, la mémoire, le disque, le réseau, la bande passante, les inodes, le nombre de fichiers, la taille de la base de données, le stockage de messagerie et les fichiers de sauvegarde. Ces limites existent car les systèmes partagés peuvent être dégradés par un seul compte.

La question du client n'est pas seulement "Combien de ressources sont annoncées?" C'est "À quelle vitesse un voisin bruyant est-il contenu, comment les clients sont-ils notifiés et qu'arrive-t-il aux données lors d'une suspension ou d'une migration?"

Le quatrième chemin de défaillance est la réparation du serveur dédié. Les conditions impliquent que des audits de sécurité requis par le centre de données, des réinitialisations de mot de passe et des actions administratives peuvent se produire, et que les serveurs dédiés ne sont pas sauvegardés par Good Domain Registry.

Un acheteur de serveur dédié devrait demander quel centre de données contrôle les mains à distance, comment les disques sont remplacés, si la gestion hors bande est incluse, quel stock de matériel existe, si le RAID est utilisé, où vivent les sauvegardes et combien de temps les données restent après non-paiement ou suspension pour abus.

Le cinquième chemin de défaillance est la non-récupérabilité des sauvegardes. Les sauvegardes hebdomadaires sont des sauvegardes de courtoisie, pas des sauvegardes garanties. Un travail de restauration payant peut être possible, mais l'intégrité de la sauvegarde n'est pas garantie, les comptes suspendus peuvent ne pas recevoir de sauvegardes et les services semi-dédiés ou dédiés nécessitent des sauvegardes client. Un acheteur d'hébergement devrait tester l'exportation et la restauration avant le premier incident.

Un revendeur devrait exiger des clients qu'ils conservent leurs propres copies et devrait conserver une copie indépendante en dehors de la plateforme Good Domain Registry.

Le sixième chemin de défaillance est la disparition du partenaire ou l'escalade lente. Les pages de tarification, de support et juridiques de Good Domain Registry pointent toutes vers un réseau de partenaires. Si le partenaire cesse de répondre, ne renouvelle pas un domaine, ne transmet pas les avis d'expiration, gère mal le paiement, perd les identifiants de compte ou retarde la réponse aux abus, le registre amont ou le parent d'hébergement peut ne pas être la première partie que le client final peut contacter. L'entreprise fournit des voies de contact directes, mais le modèle public place toujours le support du revendeur en premier.

Le septième chemin de défaillance est la suspension politique. Les conditions donnent à Good Domain Registry de larges droits de suspendre, résilier, désactiver ou supprimer du contenu pour abus, spam, contenu interdit, abus de ressources, mots de passe faibles, non-paiement et autres raisons politiques. Certains de ces contrôles sont nécessaires pour maintenir l'infrastructure partagée utilisable et garder l'espace d'adressage hors des listes noires. Ils créent également un risque opérationnel pour les clients dont les sites web ou les boîtes aux lettres sont critiques pour l'entreprise.

Un processus politique erroné ou retardé peut devenir un temps d'arrêt.

Ce qui améliorerait la note des preuves

Good Domain Registry pourrait améliorer la note opérationnelle publique avec plusieurs divulgations qui ne nécessitent pas de publier des diagrammes sensibles. La première est un inventaire des services. L'entreprise pourrait indiquer quels services d'hébergement sont actuellement vendus via des partenaires, lesquels sont des conditions contractuelles héritées et quels services sont activement provisionnés: hébergement partagé, hébergement revendeur, hébergement WordPress, hébergement de messagerie, VPS, serveurs semi-dédiés et serveurs dédiés.

Le dossier public prouve maintenant que ces catégories existent dans le langage juridique et de support, mais il ne montre pas le stock de plans actuel ou la géographie active.

La deuxième est la limite des installations et de la propriété. Une brève déclaration nommant le pays, la ville, le type d'installation, le propriétaire des mains à distance, la classe de redondance d'alimentation, la politique de dépôt de sauvegarde et le processus de remplacement matériel faciliterait l'évaluation des affirmations de capacité hébergée. Cela aiderait également à distinguer les services directement opérés par Good Domain Registry des services fournis via des fournisseurs de services ou des plateformes partenaires.

La troisième est la diversité du réseau. AS132322 pourrait publier un résumé actuel du transit et de la politique de routage: amonts actifs, méthode de basculement, gestion DDoS, couverture RPKI, statut IPv6, chemin de notification de maintenance et si les services clients utilisent des préfixes appartenant à Good Domain Registry ou l'espace d'adressage du partenaire/fournisseur. RIPEstat montre un bord réseau visible, mais la vue publique ne voit actuellement qu'un seul voisin et une validation d'origine de route mitigée.

La quatrième est la clarté des sauvegardes et de l'exportation. Chaque service devrait avoir une déclaration claire de la fréquence des sauvegardes, de la conservation, des frais de restauration, de la cible de restauration, de la méthode d'exportation client, du pays de sauvegarde, des déclencheurs d'exclusion de sauvegarde et de la disponibilité après suspension. Les conditions existantes sont honnêtes quant aux garanties limitées, mais elles ne suffisent pas pour qu'un client décide si un site web, une archive de messagerie, une base de données ou un serveur virtuel peut survivre à une mauvaise semaine.

La cinquième est la procédure d'incident du revendeur. L'entreprise pourrait publier un flux pour les clients finaux lorsqu'un revendeur est injoignable, y compris la vérification d'identité, le sauvetage d'expiration, l'escalade de transfert de domaine, l'appel d'abus, la demande de sauvegarde d'hébergement et la mise à jour DNS d'urgence. Cela ne ferait pas s'effondrer le modèle revendeur; cela rendrait le chemin de défaillance moins opaque.

Jusqu'à ce que ces divulgations existent, la note des preuves publiques devrait s'arrêter à Moyen. Good Domain Registry a une identité de registre durable, une liste officielle de bureau d'enregistrement accrédité, des accords juridiques publics, des surfaces d'abus et de contact visibles, AS132322 enregistré auprès d'APNIC, un espace IPv4 alloué et une visibilité BGP actuelle sur dix annonces /24.

La note s'arrête avant Fort car le dossier public n'identifie pas les emplacements des installations, l'architecture multisite, le stock matériel, l'intégrité des sauvegardes, l'inventaire actuel VPS/dédié, un deuxième amont visible, la disponibilité IPv6 client, les installations PeeringDB publiques ou un chemin de sauvetage garanti pour le client final à travers la chaîne de revendeur.

Conclusion

Good Domain Registry Private Limited doit être lu comme un bureau d'enregistrement de domaines et une plateforme partenaire à Chennai avec un vrai bord réseau et des services d'hébergement contractuellement visibles, pas comme un opérateur cloud entièrement transparent. L'identité publique de registre est forte: IANA répertorie Good Domain Registry Pvt Ltd. comme un bureau d'enregistrement accrédité, les propres pages de l'entreprise décrivent un bureau d'enregistrement accrédité par l'ICANN opérant via des partenaires, et les pages juridiques donnent une adresse de notification à Chennai et un chemin d'accord registre-registrant.

L'identité réseau est également réelle: APNIC enregistre AS132322 et 103.14.120.0/22 sous GDRPL-IN, et RIPEstat a vu AS132322 annoncé avec dix IPv4 /24 le 12 juillet 2026.

Les preuves de capacité hébergée sont plus prudentes. Les conditions et les accords de revendeur montrent des obligations d'hébergement web, d'hébergement revendeur, de VPS, d'hébergement de messagerie, de serveurs semi-dédiés et dédiés, des limites de sauvegarde, des limites de ressources et un langage de crédit de disponibilité. Mais les pages publiques ne nomment pas les centres de données, les racks, les transporteurs au-delà du voisin AS17439 observé, les pièces de rechange matérielles, l'inventaire des plans actifs, les contrôles d'intégrité des sauvegardes ou les garanties de migration client.

C'est une surface d'infrastructure fonctionnelle avec des détails opérationnels importants manquants, ni une coquille vide ni un cloud entièrement documenté.

Pour un acheteur de domaine occasionnel, le modèle partenaire peut être ordinaire. Pour un revendeur, développeur, agence ou entreprise mettant des sites web, des e-mails, du DNS, des domaines ou des serveurs virtuels derrière la plateforme de Good Domain Registry, les questions devraient être plus pointues. Quelle partie reçoit les demandes de support? Quel espace IP le service utilisera-t-il? Quels amonts le transportent? Quels serveurs de noms et panneaux de contrôle sont séparés du réseau d'hébergement? Quelles sauvegardes peuvent être exportées sans intervention du personnel? Que se passe-t-il lorsque le revendeur est injoignable?

Combien de temps les données suspendues sont-elles récupérables? Qui peut remplacer un disque défaillant ou déverrouiller un serveur dédié? La réponse à ces questions est l'endroit où la simplicité apparente d'un bundle domaine-hébergement se transforme à nouveau en racks, transit et fenêtres de réparation.