DreamHost y AS26347: la continuidad del hosting compartido tambié

Resumen

ARIN registra AS26347 como DREAMHOST-AS activo y nombra a New Dream Network, LLC como titular. En la captura de RIPEstat, el ASN aparecía anunciado y había 27 entradas de prefijos observados. Es evidencia de una identidad operativa de red, no una garantía de que una tienda, una base de datos o un formulario estén disponibles.
DreamHost separa en su documentación el registro del dominio, la autoridad de los nameservers, los registros DNS, los archivos web y MySQL. También advierte que sus respaldos habituales no están garantizados y recomienda copias locales o externas. La continuidad requiere inventario, monitoreo, acceso recuperable y pruebas del lado del cliente.

DreamHost, LLC es una entidad de empresa publicada en el directorio de BTW. La visión general de la compañía enumera hosting web, VPS administrado, servidores dedicados, WordPress administrado, correo, registro de dominios, almacenamiento de objetos y cómputo en la nube. El mismo nombre comercial cubre productos distintos, cada uno con su propio reparto de control.

Para una pequeña organización, un sitio puede parecer una sola compra. Técnicamente es una cadena. El dominio debe renovarse; la delegación debe apuntar a los nameservers correctos; las respuestas DNS deben dirigir al destino previsto; las rutas deben transportar los paquetes; los archivos y la base deben coincidir; certificados, correo e integraciones tienen que funcionar; y una persona autorizada debe poder diagnosticar y actuar.

Este análisis no atribuye una falla a DreamHost ni pretende revelar una arquitectura privada. Examina la identidad y las observaciones públicas, y usa las guías y términos de la empresa para explicar dónde terminan las pruebas. La meta es que un lector sin experiencia en BGP pueda tomar decisiones operativas sin convertir un dato parcial en una promesa total.

La imagen principal es una escena editorial fotorrealista generada para BTW Media. Muestra a un operador no identificado revisando una lista de recuperación junto a racks comunes y sin marca. No representa a DreamHost, New Dream Network, empleados, instalaciones, clientes, equipos, incidentes, desempeño ni respaldo reales.

Un registro de números mantiene identidad, no salud

La respuesta RDAP de ARIN llama DREAMHOST-AS a AS26347 y lo marca activo. Un número de sistema autónomo, o ASN, es un identificador único que una red utiliza cuando intercambia información de rutas con otras redes. Para una persona no técnica, funciona como un rótulo en el mapa vial de internet.

El registro identifica a New Dream Network, LLC como titular, incluye un grupo NetOPs de Dreamhost en funciones técnicas y de operación, y mantiene un contacto separado para abuso. La captura informa un evento de registro del 28 de agosto de 2002 y una última modificación del 31 de agosto de 2015.

Esto tiene utilidad operativa. Otro operador puede dirigir una consulta de rutas o un reporte a un objeto reconocible. Una organización puede comparar cambios de nombre, estado o contacto y detectar una discrepancia. La unicidad reduce la ambigüedad que produciría usar solo una marca comercial.

El registro no es la red en ejecución. No muestra todos los routers, enlaces, centros, clientes o aplicaciones. No mide latencia, capacidad, velocidad de soporte ni éxito de una compra. Tampoco resuelve por sí solo derechos legales o la autorización de cada anuncio.

Por eso se necesita conciliación. La identidad administrativa, los contactos, las rutas observadas, la configuración del cliente y las pruebas de usuario deben describir realidades compatibles. Una diferencia amerita investigación; no autoriza una acusación automática.

RIPEstat agrega una observación con fecha y alcance

En la captura, RIPEstat relacionaba el recurso 26347 con DREAMHOST-AS y New Dream Network, LLC, y mostraba el sistema autónomo como anunciado. Eso indica que colectores de rutas veían al ASN participando en BGP en ese momento.

La respuesta de prefijos contenía 27 entradas durante la ventana del 22 de julio al 5 de agosto de 2026: 24 de IPv4 y tres de IPv6. Un prefijo describe un bloque de direcciones. La observación confirma una superficie visible en ambas familias.

Esos 27 elementos no son 27 clientes, servidores, productos o ubicaciones. Tampoco forman necesariamente un inventario jurídico completo. Los colectores miran desde puntos concretos y una ruta puede cambiar o no ser visible de la misma manera en todas partes. El conjunto no mide pérdida de paquetes, ancho de banda o funcionamiento de WordPress.

Esta diferencia ayuda a aplicar la primacía de la realidad en ejecución. ARIN indica lo registrado. RIPEstat informa lo que sus observadores vieron. Una sonda del cliente indica si la aplicación respondió. Cada capa sirve para una pregunta distinta.

Una pyme puede beneficiarse sin administrar BGP. Basta con saber qué dominios y direcciones son críticos, cuál es el origen esperado cuando corresponda y quién debe validar una alerta. El objetivo es descubrir cambios antes del incidente, no convertir cada diferencia en una conclusión pública.

PeeringDB orienta, pero no audita la capacidad

El perfil capturado de PeeringDB nombra a DreamHost, presenta New Dream Network, LLC como nombre alternativo, vincula AS26347 y dreamhost.com, y clasifica la red como Content, de alcance global y con política general abierta. También muestra estimaciones de 25 prefijos IPv4 y uno IPv6.

Las cifras no tienen que coincidir exactamente con las 24 y tres entradas de RIPEstat. PeeringDB es un directorio mantenido por el operador y sus campos pueden tener otro alcance. RIPEstat presenta observaciones durante una ventana. Compararlas como si fueran la misma métrica generaría una falsa contradicción.

El endpoint de intercambio devolvió una fila operacional asociada con un identificador de intercambio. El endpoint de instalaciones no devolvió filas. Un resultado vacío no prueba que DreamHost carezca de edificios, enlaces privados, equipos o diversidad. Solo describe el contenido del perfil en ese punto.

PeeringDB es útil como mapa para contacto y planificación. No es un estudio independiente de topología, tráfico o resiliencia. Una conexión declarada no demuestra que pase por allí el tráfico de un cliente, ni que tenga capacidad libre o una ruta física independiente.

La decisión responsable combina este mapa con contratos vigentes, mediciones, pruebas de ruta y confirmaciones directas cuando el riesgo lo exige.

Una marca reúne productos con responsabilidades distintas

DreamHost presenta hosting web, VPS, servidores dedicados, DreamPress, correo, dominios, DreamObjects y DreamCompute. Una cuenta puede combinar varios, pero cada producto cambia la frontera entre proveedor y cliente.

En hosting compartido, el proveedor administra gran parte de la plataforma común. El cliente mantiene contenido, credenciales, aplicaciones y varias configuraciones. Un VPS puede aportar más control o aislamiento, pero también traslada al cliente más parches, seguridad y observación. El almacenamiento de objetos tiene otra medida contractual.

No se debe trasladar una promesa de un producto a otro. Restaurar archivos no restaura automáticamente MySQL. Una condición de DreamObjects no define el hosting general. Una incidencia de una plataforma no explica por sí misma el estado del DNS o de un servicio de pagos externo.

El control mínimo es un inventario por producto: cuenta, plan, dominios, archivos, bases, correo, certificados, servicios externos, propietario técnico y propietario de negocio. Para una web pequeña puede ser una sola hoja, siempre que esté actualizada.

“Estamos en DreamHost” no ofrece instrucciones de recuperación. “El dominio está aquí, los nameservers están allá, estos registros sirven la web, esta base corresponde a estos archivos, la copia externa está en este lugar y estas personas pueden actuar” sí las ofrece.

El DNS distribuye autoridad a lo largo de una cadena

La guía de DreamHost distingue el registrador, el proveedor de hosting, los nameservers y los registros DNS. El registrador conserva el dominio. Los nameservers definen dónde se administra la zona. Los registros apuntan la web, el correo y otros servicios a destinos concretos.

Todas las funciones pueden estar en DreamHost o repartirse. Esa flexibilidad permite migraciones y configuraciones híbridas, pero añade puntos de falla. Un servidor nuevo puede estar sano mientras el dominio sigue apuntando al anterior. Cambiar nameservers sin copiar registros de correo puede cortar más servicios que la web.

La organización debe conservar un inventario y una exportación de la zona. Las cuentas del registrador y DNS necesitan autenticación fuerte, contactos de recuperación institucionales y renovación supervisada. No conviene depender del correo personal de un contratista que ya no trabaja allí.

Los cambios de DNS merecen revisión de producción: valor nuevo, valor anterior, alcance, responsable, prueba y condición de reversión. Un segundo revisor es especialmente útil cuando se mueve la autoridad completa.

El registro administrativo ayuda con unicidad y coordinación. La delegación y las respuestas activas determinan el comportamiento real. Esa separación resume el enfoque Heng.lu: el libro de registro es necesario, pero no gobierna por sí solo el código y los sistemas en ejecución.

Propagación no significa una actualización simultánea

La guía de propagación explica que los resolvedores guardan respuestas hasta que vence el TTL. Proveedores de acceso y otros operadores administran cachés con tiempos propios. DreamHost señala que el cambio suele verse en unas horas, aunque algunos casos pueden llegar a 72 horas.

El TTL predeterminado indicado para sus servidores es de cinco minutos. Eso no equivale a una garantía mundial de cinco minutos. El valor anterior pudo tener otro TTL, el dispositivo puede tener caché y un cambio de delegación sigue mecanismos diferentes.

En una migración, algunos usuarios pueden llegar al destino nuevo y otros al antiguo. Si ambos aceptan escrituras, la base de datos puede dividirse. Probar desde una sola oficina y apagar el servidor viejo crea un riesgo evitable.

El plan debe permitir coexistencia: bajar TTL con anticipación cuando sea adecuado, conservar el entorno anterior de forma segura, consultar directamente la autoridad, probar varios resolvedores y redes, y observar transacciones en ambos destinos.

No toda falla posterior a un cambio es “propagación”. Un registro equivocado, una zona ausente, un dominio vencido, un certificado incorrecto o una aplicación rota necesitan diagnósticos diferentes. Las respuestas capturadas desde los lugares afectados acotan la causa.

El estado público y el ticket responden preguntas diferentes

DreamHost dirige a los clientes a su página oficial de estado para avisos actuales y futuros, a un historial para eventos anteriores y al soporte técnico si un sitio presenta problemas. La página pública comunica bien una incidencia amplia; el ticket transporta evidencia de una cuenta específica.

Una página verde no demuestra que la web de un cliente funcione. Puede existir un registro DNS erróneo, un certificado vencido, una cuota agotada o un defecto en la aplicación. De manera inversa, una sonda puede responder mientras otros usuarios sufren un incidente amplio.

Un reporte útil contiene dominio o servicio, hora inicial, síntoma visible, ubicación, cambios recientes y resultados desde más de una red. Debe evitar contraseñas y datos personales. Dos personas autorizadas deberían poder entrar en la cuenta y seguir el caso.

El cierre de la incidencia del proveedor es un hito, no la prueba final. El cliente debe verificar resolución, páginas, inicio de sesión, escrituras, correo o compra según el servicio. La conclusión se alcanza en la función de negocio.

La promesa de uptime tiene exclusiones, reloj y remedio

Los términos generales describen una garantía de disponibilidad para hosting y excluyen, entre otras cosas, mantenimiento previamente anunciado y errores de código o configuración del cliente. También dicen que la evaluación del tiempo de caída comienza cuando el cliente abre un ticket.

Ese detalle convierte la detección y la escalada en controles económicos. Si el equipo detecta a las 02:00 y abre el caso a las 03:00, el impacto de negocio comenzó antes que el reloj contractual. Una alerta sin propietario prolonga ambas brechas.

El crédito descrito equivale al costo actual de un día de hosting por cada hora o fracción calificada, con un máximo del 10 % de la siguiente renovación prepagada. Es un ajuste de factura, no una compensación automática por ventas, personal, comunicación o reputación.

DreamObjects tiene una definición separada de 99,9 % mensual. No debe mezclarse con la garantía general. Un SLA es una herramienta útil solo cuando se conserva el producto, el objeto medido, el período, las exclusiones, la forma de reclamar y el remedio.

El negocio necesita una meta adicional: ¿qué acción de usuario debe completarse y cuánto tiempo puede fallar? La disponibilidad del proveedor y la disponibilidad de la empresa se pueden informar juntas sin tratarlas como equivalentes.

El hosting compartido sigue teniendo recursos finitos

La política Unlimited afirma que almacenamiento o transferencia ilimitados no eliminan límites de CPU, memoria y entrada/salida de disco en una plataforma compartida. Un sitio mal optimizado que afecte a otros usuarios puede tener que migrar a un servidor privado.

Esto no acusa a ningún cliente. Describe la gobernanza necesaria para compartir infraestructura. La palabra “ilimitado” puede distraer del recurso que realmente se agota: una consulta pesada, un proceso automático, una extensión defectuosa o un pico legítimo.

Conviene vigilar tiempos de respuesta, errores, trabajos fallidos y carga de base desde la aplicación. Optimizar consultas, caché, imágenes y tareas periódicas mejora experiencia y reduce presión.

Cambiar a VPS o a otro plan puede aportar capacidad, pero también más administración. La decisión debe basarse en mediciones, habilidades y costo del incidente. Una migración planeada es preferible a una reacción durante la temporada alta.

Archivos y MySQL son dos objetos de recuperación

La guía para restaurar un sitio dice que DreamHost suele conservar aproximadamente dos semanas de archivos, sin garantizar su disponibilidad, y recomienda respaldos locales. El procedimiento restaura archivos, no la base, y puede tardar aproximadamente de cinco a quince minutos según el volumen.

La guía de MySQL describe copias diarias y alrededor de cinco días generalmente disponibles. También afirma que no están garantizadas y recomienda firmemente copias externas controladas por el cliente.

En un CMS, los archivos contienen temas, extensiones y medios; la base contiene publicaciones, usuarios, pedidos y ajustes. Recuperar los archivos del martes con la base del viernes puede dejar una aplicación visible pero incoherente. Una actualización puede haber cambiado código y esquema al mismo tiempo.

Por eso se necesita un conjunto de recuperación: archivos, base, configuración, secretos, certificados, DNS y dependencias. La empresa debe saber qué piezas pertenecen al mismo punto y quién puede acceder a ellas.

La copia independiente protege frente a bloqueo de cuenta, borrado o compromiso. Debe estar cifrada, con permisos limitados, retención definida y borrado seguro. Independencia no significa duplicar datos sensibles sin control.

Una copia solo se convierte en evidencia al restaurarla

Un respaldo exitoso prueba que un proceso informó éxito. No demuestra que incluyó todo, que las claves existen, que el personal actual conoce los pasos o que el tiempo cumple la necesidad del negocio.

La prueba representativa recupera archivos y base en un destino aislado, aplica configuración, usa un nombre seguro y ejecuta una acción parecida a la del usuario. Evita enviar pagos o mensajes reales y protege los datos durante el ejercicio.

El objetivo de punto de recuperación mide cuántos datos se pueden perder. El objetivo de tiempo de recuperación mide cuánto puede durar el corte. Un respaldo diario puede servir a un sitio informativo y ser insuficiente para una tienda activa.

El acta debe conservar fecha, copia, pasos, duración, resultado y problemas. Un ensayo fallido que produce una mejora es útil. Una suposición no probada sigue oculta hasta la emergencia.

Monitorear significa observar el recorrido del usuario

El estado del proveedor muestra una vista global. Las métricas del hosting muestran recursos. Una sonda externa muestra acceso desde una red. La aplicación muestra errores. La prueba de negocio indica si terminó una reserva, compra, donación, acceso o formulario.

No son una sola luz verde. La portada puede cargar mientras el pago falla. El servidor puede responder mientras el DNS apunta a otra parte. La ruta puede existir mientras el certificado está vencido.

Cada alerta necesita destinatario, gravedad y acción. Un buzón sin vigilancia no es monitoreo. Hay que evitar también la fatiga: demasiadas alarmas irrelevantes ocultan la importante.

Los tiempos permiten aprender: inicio del impacto, detección, ticket, recuperación técnica y primera transacción correcta. Esa línea separa retraso de observación, reparación de infraestructura y retorno del negocio.

El control organizativo es parte de la disponibilidad

Muchos sitios nacen bajo una sola persona. El empleado o proveedor registra el dominio, crea la cuenta y guarda credenciales. Si se va, la infraestructura puede seguir activa mientras la empresa pierde autoridad para cambiarla.

Cada servicio crítico necesita un dueño de negocio y un operador técnico. La organización debe controlar las direcciones de recuperación y contar con al menos dos personas autorizadas que puedan actuar sin compartir una identidad personal.

Los privilegios deben ser limitados. No todos necesitan modificar nameservers o borrar bases. Cuentas separadas, autenticación fuerte, revisión de accesos y un proceso de emergencia registrado reducen el riesgo.

Renovaciones, tarjetas y avisos de cobro también son operación. Un dominio puede dejar de servir por administración vencida sin que falle un equipo físico.

El costo real supera la cuota mensual

La factura compra una plataforma accesible. La supervisión agrega cuentas, actualizaciones, DNS, certificados y monitoreo. La integración agrega correo, pagos, identidad y APIs. La recuperación agrega almacenamiento independiente, instrucciones y ejercicios.

La falla agrega pedidos perdidos, trabajadores detenidos, soporte, consultores urgentes y reputación. La salida agrega traslado de datos, DNS, validación y coexistencia. Estos costos no niegan el valor del hosting compartido; permiten compararlo honestamente.

Un portafolio personal puede tolerar horas o días. Una tienda o agenda puede perder valor en minutos. El diseño debe ser proporcional. La máxima redundancia no es necesaria para todo, pero el dominio, los datos y la capacidad de actuar no deberían depender de un individuo indocumentado.

Un plan sencillo para una organización pequeña

Primero, una hoja de inventario con cuenta, plan, dominio, registrador, DNS, archivos, base, correo, certificado, integraciones, respaldos, fechas y responsables.

Segundo, definir la transacción crítica y probarla desde fuera. Asignar la alerta y la autoridad para abrir un ticket, comunicar o activar una alternativa.

Tercero, mantener copias externas de archivos y MySQL, cifradas y con retención acorde a la pérdida aceptable. Guardar instrucciones fuera de la cuenta productiva.

Cuarto, restaurar en un destino aislado, ejecutar la acción de negocio, medir el tiempo y corregir sorpresas. Repetir después de cambios importantes.

Quinto, planear DNS: exportar la zona, entender la delegación, preparar reversión y probar varias redes antes de retirar el destino anterior.

Finalmente, cerrar en la capa correcta. Que vuelva el panel, el servidor o el DNS no basta. La evidencia final es una acción de usuario correcta, datos reconciliados y tareas posteriores asignadas.

Conclusión práctica

La evidencia permite una conclusión limitada. ARIN registra AS26347 como DREAMHOST-AS activo y a New Dream Network, LLC como titular. RIPEstat observó el ASN anunciado y 27 entradas de prefijos. PeeringDB aporta un perfil mantenido por el operador, no una auditoría de capacidad.

Los documentos de DreamHost revelan las fronteras que importan. Dominio, nameservers y registros pueden tener autoridades distintas. Los cachés retrasan una vista uniforme. La página de estado y el ticket cumplen funciones diferentes. El hosting general y DreamObjects se miden de manera distinta.

Archivos y base tienen restauraciones y retenciones habituales separadas. La disponibilidad de esas copias no está garantizada y la empresa recomienda respaldos controlados por el cliente. CPU, memoria y disco siguen siendo recursos gobernados en el entorno compartido.

Una pyme no necesita operar la red mundial. Necesita preservar el dominio, los datos, los accesos y la capacidad de decidir. El proveedor aporta la plataforma; inventario, evidencia, respaldo externo y recuperación probada convierten esa plataforma en continuidad.

Sources

Atribución de la imagen

Imagen editorial fotorrealista original generada para BTW Media: un operador no identificado revisa una lista de recuperación en un escritorio modesto junto a racks de red comunes y sin marca. Se creó con la herramienta integrada y se convirtió a JPEG de 1600 × 900. No usa fotografía de terceros, logo, marca, pantalla real ni sistema propietario. No representa ni sugiere a DreamHost, New Dream Network, empleados, instalaciones, clientes, equipos, arquitectura, incidente, rendimiento o respaldo.

DreamHost y AS26347: la continuidad del hosting compartido también depende del DNS, los respaldos y el cliente