DreamHost et l’AS26347 : la fiabilité de l’hébergement mutualisé

Résumé

ARIN enregistre l’AS26347 sous le nom actif DREAMHOST-AS et cite New Dream Network, LLC comme titulaire. Dans la capture RIPEstat, l’ASN était annoncé et 27 entrées de préfixes étaient observées. Cette concordance établit une identité réseau visible ; elle ne garantit pas qu’un site, une base ou un parcours d’achat fonctionne.
DreamHost distingue l’hébergement, l’enregistrement de domaine, les serveurs de noms, les enregistrements DNS, les fichiers et MySQL. Ses guides précisent que les copies disponibles chez l’hébergeur ne sont pas garanties et recommandent des sauvegardes sous le contrôle du client. La continuité exige donc un inventaire, une surveillance externe, des accès récupérables et des restaurations réellement testées.

DreamHost, LLC figure comme entreprise publiée dans le répertoire BTW. La documentation de la marque présente plusieurs familles de services : hébergement de sites, VPS géré, serveur dédié, WordPress géré, messagerie, enregistrement de domaines, stockage objet et calcul en nuage. Pour un client, tout peut apparaître sur un même compte. Pour l’exploitation, chaque produit conserve pourtant ses propres limites et responsabilités.

Un site de petite entreprise paraît simple : un nom de domaine, quelques pages et une facture mensuelle. Sa continuité dépend en réalité d’une série de maillons. Le domaine doit rester enregistré. La délégation DNS doit viser les bons serveurs. Les enregistrements doivent conduire à la bonne destination. Les routes internet doivent transporter le trafic. Les fichiers et la base doivent former un ensemble cohérent. Les certificats, le courrier et les services externes doivent répondre. Enfin, une personne autorisée doit pouvoir constater l’incident et agir.

Cette étude ne prétend pas connaître l’architecture privée de DreamHost et n’attribue aucun incident à l’entreprise. Elle examine ce que les preuves publiques permettent de dire, puis ce qu’elles ne permettent pas de conclure. L’objectif est de rendre les limites compréhensibles par un dirigeant, une association ou un commerçant qui ne travaille pas quotidiennement avec BGP ou DNS.

L’image de couverture est une scène photoréaliste générée pour BTW Media. Un opérateur non identifié relit une liste de reprise près de baies ordinaires sans marque. Elle ne représente ni DreamHost, ni New Dream Network, ni un salarié, ni un site, ni un équipement, ni un client, ni un incident, ni une performance ou un soutien réel.

Le registre conserve une identité, pas la disponibilité

La réponse RDAP d’ARIN nomme l’AS26347 DREAMHOST-AS et le marque actif. Un ASN, ou numéro de système autonome, est un identifiant unique qu’un réseau utilise pour échanger des routes avec d’autres réseaux. Pour un lecteur non spécialiste, il ressemble à un nom d’opérateur sur la carte routière de l’internet.

La fiche cite New Dream Network, LLC comme titulaire. Elle indique aussi un groupe NetOPs Dreamhost pour les rôles techniques et réseau, ainsi qu’un contact distinct pour les abus. La capture contient un événement d’enregistrement du 28 août 2002 et un dernier changement daté du 31 août 2015.

Ces données favorisent la coordination. Un autre opérateur peut rattacher une question de route ou un signalement à un objet unique plutôt qu’à une marque ambiguë. Une équipe peut comparer le nom, l’état et les contacts à une capture antérieure et enquêter sur un changement.

Le registre reste un grand livre. Il ne pilote pas les routeurs et ne voit ni chaque fibre, ni chaque bâtiment, ni chaque client, ni chaque application. Il ne mesure pas la latence, la capacité, la disponibilité du support ou la réussite d’une commande. Une inscription correcte ne remplace donc pas la preuve d’exploitation.

La bonne pratique consiste à rapprocher plusieurs réalités : identité administrative, contacts, annonces observées, configuration du client et tests du service. Une divergence déclenche une vérification ; elle ne devient pas automatiquement une accusation.

L’observation des routes apporte une preuve temporelle

RIPEstat associait la ressource 26347 à DREAMHOST-AS et New Dream Network, LLC dans la capture, et indiquait que le système autonome était annoncé. Cela signifie que des collecteurs de routes voyaient l’ASN participer au routage mondial à ce moment-là.

La réponse sur les préfixes contenait 27 entrées pendant la fenêtre observée du 22 juillet au 5 août 2026 : 24 en IPv4 et trois en IPv6. Un préfixe représente un bloc d’adresses. Le résultat montre donc une présence visible des deux familles d’adresses.

Le nombre 27 ne compte ni les clients, ni les machines, ni les offres, ni les centres de données. Il ne constitue pas un inventaire juridique complet. Un collecteur observe depuis certains points ; une route peut être visible ici et filtrée ailleurs. La capture ne mesure pas non plus le débit, les pertes ou la santé de WordPress.

Cette différence illustre la primauté du système qui fonctionne réellement. Le registre dit ce qui est enregistré. Les collecteurs disent ce qu’ils ont vu circuler. Les sondes du client disent si son application répond. Une équipe sérieuse conserve ces couches séparées et les rapproche pendant un incident.

Pour une PME, il suffit souvent de connaître les domaines et adresses critiques, l’origine attendue lorsqu’elle est pertinente et les personnes capables de vérifier une anomalie. L’alerte n’a pas vocation à transformer le responsable du site en ingénieur réseau ; elle évite de découvrir la dépendance au milieu d’une panne.

PeeringDB fournit une carte déclarative et limitée

Le profil PeeringDB capturé nomme DreamHost, donne New Dream Network, LLC comme autre nom, rattache le profil à l’AS26347 et renvoie vers dreamhost.com. Il décrit un réseau de type Content, de portée globale, avec une politique générale ouverte et des estimations de 25 préfixes IPv4 et un préfixe IPv6.

Ces estimations ne doivent pas être comparées mécaniquement aux 24 et trois entrées de RIPEstat. Le profil est entretenu par l’opérateur et peut suivre une portée différente ; RIPEstat restitue une observation bornée dans le temps. Les deux sources répondent à des questions voisines, mais pas identiques.

L’API d’interconnexion a renvoyé une ligne opérationnelle liée à un identifiant d’échange. L’API des installations n’a renvoyé aucune ligne. Une liste vide n’établit pas que DreamHost n’utilise aucune installation, aucune liaison privée ou aucune diversité. Elle décrit seulement ce que ce point de terminaison déclaratif contenait lors de la capture.

PeeringDB aide à s’orienter et à préparer une discussion d’interconnexion. Il n’a pas la valeur d’un audit indépendant de capacité ou de résilience. Une ligne opérationnelle ne prouve pas que le trafic d’un client l’emprunte, et plusieurs lignes ne garantiraient pas nécessairement des chemins physiquement séparés.

La règle est de garder la carte et ses limites ensemble. Pour une décision importante, il faut ajouter le contrat, les mesures actuelles, les observations de chemin et, si nécessaire, une confirmation directe.

Plusieurs produits sous une marque ne forment pas un seul système

La vue d’ensemble de DreamHost distingue l’hébergement de site, le VPS, le dédié, DreamPress, la messagerie, les domaines, DreamObjects et DreamCompute. Le niveau d’administration transféré au fournisseur ou conservé par le client varie selon le produit.

En hébergement mutualisé, l’entreprise cliente bénéficie d’une plateforme largement gérée. Elle reste responsable de son contenu, de ses comptes, des choix applicatifs et d’une partie des réglages. Un VPS ou un serveur dédié peut offrir davantage de contrôle, mais aussi davantage de travail de sécurité, de mise à jour et de surveillance.

Une erreur fréquente consiste à emprunter une promesse à une offre et à l’appliquer à toutes. Une restauration de fichiers ne restaure pas forcément MySQL. Le taux propre à DreamObjects ne mesure pas l’hébergement général. Un message d’état relatif à une plateforme ne décrit pas chaque domaine ou service de paiement du client.

Un inventaire par produit évite cette confusion. Il doit mentionner le compte, l’offre, les domaines, les fichiers, les bases, le courrier, les certificats, les dépendances externes et le responsable métier. Pour un petit site, une seule page suffit si elle reste actuelle.

Dire « notre site est chez DreamHost » est utile commercialement mais insuffisant en situation d’urgence. Dire où le domaine est enregistré, qui porte le DNS, où résident les fichiers et la base, où se trouve la copie indépendante et qui peut intervenir produit une véritable carte de reprise.

Le DNS répartit l’autorité entre plusieurs acteurs

Le guide DNS de DreamHost sépare le bureau d’enregistrement, l’hébergeur, les serveurs de noms et les enregistrements. Le bureau conserve l’enregistrement du domaine. Les serveurs de noms désignent l’endroit où la zone DNS est administrée. Les enregistrements orientent ensuite le site, le courrier ou d’autres services.

Ces fonctions peuvent être regroupées chez DreamHost ou réparties entre plusieurs fournisseurs. La souplesse est utile, mais elle crée des points de passage. Un nouveau serveur peut fonctionner tandis que le domaine vise encore l’ancien. Une modification de serveur de noms peut déplacer toute la zone et interrompre le courrier si des enregistrements n’ont pas été reproduits.

Le client doit conserver un inventaire et une exportation récente de la zone. Les comptes du registrar et du DNS doivent employer une authentification forte et une voie de récupération appartenant à l’organisation. Les renouvellements et les avis de paiement doivent être surveillés comme des événements d’exploitation.

Chaque changement important a besoin d’une valeur attendue, d’une valeur précédente, d’un propriétaire et d’une condition de retour arrière. Le contrôle par une seconde personne est particulièrement précieux avant de changer la délégation, car l’impact peut dépasser le seul site web.

Le registre aide à maintenir l’unicité et la chaîne administrative. Ce sont néanmoins la délégation et les réponses effectivement servies qui gouvernent la réalité du moment. Cette séparation rejoint le principe Heng.lu : le registre coordonne, mais ne remplace pas le code et l’état qui fonctionnent.

La propagation crée temporairement plusieurs réalités visibles

DreamHost explique que les résolveurs mettent les réponses en cache jusqu’à expiration de leur TTL. Les fournisseurs d’accès et d’autres opérateurs peuvent conserver les données selon leurs propres règles. Le guide parle généralement de quelques heures, avec des cas pouvant aller jusqu’à 72 heures.

Le TTL par défaut indiqué pour les serveurs DreamHost est de cinq minutes. Ce chiffre n’est pas une garantie mondiale en cinq minutes. L’ancienne valeur peut avoir porté un TTL différent ; un appareil ou une application peut aussi maintenir son cache ; une nouvelle délégation suit un chemin particulier.

Pendant une migration, certains visiteurs peuvent ainsi arriver sur le nouveau site et d’autres sur l’ancien. Si les deux acceptent des écritures, deux bases peuvent diverger. Un test effectué depuis un seul bureau ne suffit pas à déclarer le basculement terminé.

Il faut préparer une période de coexistence : réduire les TTL pertinents avant une opération planifiée, maintenir l’ancien environnement de manière contrôlée, comparer la réponse autoritative et plusieurs résolveurs, puis surveiller les transactions des deux côtés. L’ancien service ne doit pas être supprimé parce qu’un seul ordinateur voit le nouveau.

La « propagation DNS » ne doit pas devenir l’explication automatique de toute erreur. Une valeur incorrecte, une zone absente, un domaine expiré, un certificat invalide ou une application en panne ont d’autres causes. Les réponses observées depuis les lieux affectés fournissent la preuve utile.

Page d’état, support et mesure du temps

La page de notifications de DreamHost oriente les utilisateurs vers le site d’état officiel pour les informations présentes et futures, vers l’historique pour les événements passés et vers le support technique lorsqu’un site rencontre un problème.

La page publique renseigne efficacement sur un incident large. Le ticket transporte les données propres à un compte. Aucun des deux ne couvre toutes les causes. Un état vert peut coexister avec un mauvais enregistrement DNS, un certificat expiré, un espace saturé ou un défaut applicatif chez un seul client.

Les conditions générales ajoutent une limite importante : l’évaluation contractuelle du temps d’arrêt commence lorsque le client ouvre un ticket. Une équipe qui détecte à 02 h 00 et attend 03 h 00 pour contacter le support a déjà perdu une heure métier et démarre plus tard le compteur défini par le contrat.

L’engagement général mentionne des exclusions, notamment la maintenance annoncée et les erreurs de code ou de configuration du client. Le crédit décrit correspond à un jour de coût d’hébergement par heure ou fraction d’heure admissible, plafonné à 10 % du prochain renouvellement prépayé. Ce crédit ne rembourse pas automatiquement les ventes perdues, le travail du personnel ou l’atteinte à la réputation.

DreamObjects possède en outre une définition séparée à 99,9 % sur le mois. Il serait faux de la présenter comme le mode de calcul de tout l’hébergement. Un SLA est utile lorsqu’on conserve son objet, sa période, ses exclusions, son déclenchement et son recours.

« Illimité » ne supprime pas les ressources partagées

La politique Unlimited de DreamHost explique que stockage ou transfert illimités ne signifient pas CPU, mémoire et entrées-sorties disque sans limite sur un serveur mutualisé. Un site mal optimisé qui affecte d’autres utilisateurs peut devoir évoluer vers un serveur privé.

Cette règle ne prouve pas qu’un client particulier a créé un problème. Elle décrit le mécanisme de gouvernance nécessaire à une plateforme partagée. L’équilibre permet à de nombreux clients de bénéficier d’une infrastructure gérée à un prix accessible.

Le goulot n’est pas toujours le volume de fichiers. Une requête de base inefficace, une extension défectueuse, une tâche planifiée ou un trafic légitime peuvent consommer CPU ou disque. Le client doit surveiller les temps de réponse, erreurs, tâches échouées et tendances de charge au niveau de son application.

Passer à un VPS peut offrir d’autres ressources mais ajoute des tâches d’administration. Le choix doit suivre des mesures et la conséquence métier, pas un réflexe. Une hausse planifiée après observation coûte généralement moins qu’une migration improvisée pendant une période de pointe.

Fichiers et base de données exigent deux restaurations coordonnées

Le guide de restauration du site indique que DreamHost conserve généralement environ deux semaines de copies de fichiers, sans en garantir la disponibilité, et recommande une copie locale. La procédure documentée concerne les fichiers, pas la base, et peut prendre environ cinq à quinze minutes selon le volume.

Le guide MySQL décrit des sauvegardes quotidiennes, avec environ cinq jours généralement disponibles. Là encore, DreamHost ne garantit pas la présence d’une copie et recommande fortement des sauvegardes hors site sous le contrôle du client.

Pour un CMS, les fichiers peuvent contenir thèmes, extensions et médias, tandis que la base contient contenus, utilisateurs, commandes et réglages. Restaurer les fichiers de mardi avec la base de vendredi peut produire un site visible mais incohérent. Une mise à jour peut aussi avoir modifié le code et le schéma ensemble.

La continuité demande donc un ensemble de reprise cohérent : fichiers, base, configuration, secrets, certificats, DNS et dépendances. La méthode exacte varie selon l’application, mais le responsable doit savoir quels éléments appartiennent au même point de récupération.

Une copie indépendante protège contre un problème de compte, une suppression ou une indisponibilité de la couche habituelle. Elle doit être chiffrée, soumise à des droits limités, conservée selon une politique et supprimée proprement. « Indépendante » ne signifie pas « copiée sans précaution ».

La restauration testée vaut plus qu’une icône verte

Un travail de sauvegarde réussi prouve qu’un processus a déclaré une écriture. Il ne prouve pas que toutes les données sont présentes, que les clés existent, que le personnel actuel saura agir ou que le délai métier sera respecté.

Un exercice représentatif restaure fichiers et base dans un environnement isolé, applique la configuration, reconnecte un nom de test et exécute une action proche de celle de l’utilisateur. Il vérifie aussi les droits, secrets et intégrations sans envoyer de paiements ou de courriels réels.

L’objectif de point de reprise mesure la perte de données tolérable. L’objectif de temps de reprise mesure la durée acceptable d’arrêt. Une copie quotidienne peut convenir à un site vitrine et être insuffisante pour une boutique active. Une opération de fichiers annoncée à dix minutes ne représente pas le temps total de reprise du métier.

Le compte rendu conserve la date, la copie choisie, les étapes, la durée, le résultat et les écarts. Un exercice qui échoue mais mène à une correction produit une information utile. Une hypothèse jamais testée reste invisible jusqu’à l’incident réel.

La surveillance doit suivre l’action de l’utilisateur

L’état du fournisseur répond à une question globale. Les métriques d’hébergement décrivent des ressources. Une sonde externe teste une URL depuis un réseau. Les métriques applicatives observent les erreurs. Un contrôle métier confirme qu’une réservation, une commande, un don ou une connexion aboutit.

Ces voyants ne doivent pas devenir un seul feu vert. Une page d’accueil peut répondre alors que le paiement échoue. Le serveur peut fonctionner tandis que le DNS vise ailleurs. Le certificat peut expirer alors que les routes restent visibles.

Chaque alerte a besoin d’un propriétaire et d’une action. Un courriel que personne ne consulte n’est pas une supervision. Il faut définir la gravité, les horaires de couverture, l’escalade et les limites pour éviter la fatigue d’alarme.

Les horodatages relient l’incident au contrat et au métier : début de l’impact, première détection, ouverture du ticket, retour de l’infrastructure, transaction réussie. Ils montrent où se situent le délai de détection et le temps réel de reprise.

Une organisation doit conserver le pouvoir d’agir

De nombreux sites sont créés par une seule personne. Elle enregistre le domaine, ouvre le compte et garde les mots de passe. Si elle quitte l’organisation, l’infrastructure peut rester saine alors que l’autorité opérationnelle disparaît.

Chaque service critique a besoin d’un responsable métier et d’un opérateur technique. L’organisation doit contrôler les adresses de récupération. Au moins deux personnes autorisées doivent savoir accéder au registrar, à l’hébergement et aux copies sans partager un compte personnel.

Les privilèges restent limités. Tout le monde n’a pas besoin de modifier les serveurs de noms ou de supprimer une base. Les comptes séparés, l’authentification forte, la revue des droits et une procédure d’urgence journalisée réduisent le risque.

Les renouvellements, cartes de paiement et messages de facturation appartiennent à l’exploitation. Une échéance oubliée peut arrêter le domaine ou le service sans panne physique. La continuité comprend donc également l’administration ordinaire.

Six coûts se cachent derrière la facture d’hébergement

Le prix mensuel achète une plateforme utile. La supervision ajoute les accès, mises à jour, DNS, certificats et surveillance. L’intégration ajoute le courrier, le paiement, l’identité et les API externes. La récupération ajoute le stockage indépendant, la documentation et les exercices.

L’échec ajoute les ventes perdues, les employés immobilisés, le support client, les consultants urgents et la réputation. La sortie ajoute copie des données, déplacement du DNS, validation et coexistence. Ces coûts ne rendent pas l’hébergement mutualisé mauvais ; ils empêchent de confondre une facture basse avec le coût total.

Un portfolio personnel peut tolérer une longue reprise. Une boutique ou une plateforme de dons peut perdre de la valeur en quelques minutes. Le contrôle doit rester proportionnel. La redondance maximale n’est pas nécessaire partout, mais l’autorité, l’inventaire et une copie récupérable ne devraient pas dépendre d’une personne inconnue.

Plan de contrôle accessible à une petite structure

Premièrement, rédiger l’inventaire d’une page : comptes, offre, domaine, registrar, DNS, fichiers, base, messagerie, certificat, dépendances, copies, échéances et responsables.

Deuxièmement, définir l’action métier critique et la tester depuis l’extérieur. Nommer le destinataire de l’alerte et l’autorité qui peut ouvrir un ticket, communiquer ou déclencher un repli.

Troisièmement, conserver des copies indépendantes des fichiers et de MySQL. Protéger leur accès, fixer une rétention fondée sur la perte acceptable et garder les instructions hors du compte de production.

Quatrièmement, restaurer dans un environnement isolé, puis exécuter l’action métier. Mesurer le temps, corriger les étapes manquantes et recommencer après une évolution majeure.

Cinquièmement, préparer les changements DNS : exporter la zone, comprendre la délégation, prévoir le retour arrière et tester depuis plusieurs réseaux avant de supprimer l’ancienne destination.

Enfin, clore l’incident au niveau métier. Le retour du panneau, du serveur ou du DNS n’est qu’une étape. La preuve finale est l’action utilisateur réussie, les données réconciliées et les suites attribuées.

Conclusion pratique

Les preuves publiques autorisent une conclusion précise. ARIN tient l’AS26347 sous le nom DREAMHOST-AS et rattache le titulaire à New Dream Network, LLC. RIPEstat a vu l’ASN annoncé et 27 entrées de préfixes dans la fenêtre capturée. PeeringDB ajoute un profil entretenu par l’opérateur, avec les limites propres à une donnée déclarative.

Les documents DreamHost rendent les frontières concrètes. Domaine, serveurs de noms et enregistrements DNS peuvent relever d’autorités différentes. La propagation produit des vues temporaires différentes. Le statut public et le ticket de support ne servent pas au même diagnostic. Les engagements de l’hébergement général et de DreamObjects ne partagent pas le même objet.

Surtout, fichiers et base possèdent des voies de restauration distinctes. Les durées habituelles de conservation ne sont pas garanties, et le fournisseur recommande des copies locales ou hors site. Sur une plateforme mutualisée, CPU, mémoire et disque restent aussi des ressources gouvernées.

L’enseignement n’est pas qu’une PME doit construire son propre réseau. Elle doit préserver ce qu’elle seule peut posséder : l’autorité sur les comptes, une carte du DNS, une copie indépendante, une surveillance de l’usage réel et la capacité testée de décider. Le fournisseur apporte la plateforme ; le client transforme cette plateforme en continuité.

Sources

Attribution de l’image

Image éditoriale photoréaliste originale générée pour BTW Media : un opérateur non identifié relit une liste de reprise à un bureau modeste près de baies réseau ordinaires sans marque. La scène a été produite avec l’outil de génération intégré puis convertie en JPEG 1600 × 900. Elle n’utilise aucune photographie tierce, aucun logo, aucune marque, aucun tableau de bord réel ni aucun système propriétaire. Elle ne représente ni DreamHost, ni New Dream Network, ni un salarié, ni une installation, ni un client, ni un équipement, ni une architecture, ni un incident, ni une performance ou un soutien.

DreamHost et l’AS26347 : la fiabilité de l’hébergement mutualisé dépend aussi du DNS, des sauvegardes et du client