Resumen
- CloudTeknoloji es la empresa detrás de daha.net. Lapágina de información comercialpública menciona a CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. como la empresa legal, indica que daha.net es la marca, lista la dirección de Estambul, teléfono, número MERSIS y número de registro mercantil, y describe servicios de alojamiento, servidores cloud, dominio, SSL, correo electrónico y servicios de TI relacionados.
- La reclamación de infraestructura es específica pero no totalmente independiente. Lapágina acerca dedice que los sistemas de daha.net se gestionan desde Estambul 4. Levent y están alojados en ICS centros de datos de Estambul, con afirmaciones de Tier III, PCI/DSS, capacidad de internet redundante, fibra independiente del operador, UPS, alimentación A+B, seguridad física y refrigeración. Los lectores deben tratar esas afirmaciones como propias de la empresa a menos que se corroboren en contratos con clientes o certificados de las instalaciones.
- La huella de enrutamiento público es actual y reducida.La vista general de AS de RIPEstatmuestra AS202048 anunciado para CloudTeknoloji, y losdatos de prefijos anunciadosmuestran un prefijo visible, 46.28.232.0/24, en el período de finales de junio al 12 de julio de 2026. Losrecuentos de prefijos RISmuestran un prefijo IPv4 originado, sin prefijos en tránsito y sin prefijo IPv6 originado.
- La principal pregunta del cliente no es si daha.net existe. Es cuánto del sitio web, VPS, correo, DNS, plan de respaldo y migración de un cliente está atado a una instalación en Estambul, un pequeño bloque de direcciones enrutado, la ruta ascendente ICS observada actualmente, las ventanas de respuesta de soporte y los términos contractuales que depositan parte de la responsabilidad de respaldo y pérdida de datos en el cliente.
La empresa es más clara que muchos nombres de alojamiento poco definidos
La identidad pública de CloudTeknoloji está inusualmente bien definida para un pequeño operador de alojamiento. Lapágina de información comercial de daha.netindica el nombre legal como CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S., afirma que daha.net es la marca, lista Maslak como la oficina fiscal, proporciona el número de impuesto 5470543764, el número MERSIS 0547054376400001 y el número de registro mercantil 759033, y dice que la empresa se fundó en 2010. La misma página incluye una dirección en Sultan Selim Mahallesi, NEF 09 Plaza 4. Levent B Blok No:7/121, Kagithane, Estambul, además de teléfono, fax, correo electrónico y detalles KEP.
Esto es importante porque no se trata simplemente de un alojamiento anónimo que vende dominios. Un comprador puede conectar la marca, la empresa, la dirección, la identidad registral y la identidad de red pública. Elregistro de organización de RIPE para ORG-SBHv1-RIPEenumera a Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. en Turquía, muestra el mismo número de registro mercantil, identifica el tipo de organización como LIR y proporciona una dirección y número de teléfono en Kagithane, Estambul. Elregistro aut-num de RIPE para AS202048nombra el AS como CloudTeknoloji, lo describe como Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. y lo vincula a la misma organización RIPE.
La historia de la marca completa luego la oferta orientada al cliente. Lapágina acerca dedice que daha.net opera desde 2010 y atiende a clientes individuales y corporativos con servicios de alojamiento y servidores. Enmarca la marca como parte de Cloud Teknoloji Bilisim Hizmetleri Ticaret Anonim Sirketi y describe un conjunto de servicios que incluye alojamiento, servidor cloud, alojamiento para revendedores, dominio, SSL y correo corporativo. Lapágina de contactoproporciona teléfono público, fax, correos de soporte, dirección y detalles KEP, por lo que los compradores tienen una vía visible para ventas, soporte y notificaciones formales.
Por lo tanto, la empresa no opera detrás de un escaparate completamente opaco. La evidencia respalda un proveedor de alojamiento turco real, una empresa legal con nombre, un canal minorista de marca, una identidad LIR de RIPE y un AS anunciado. La degradación comienza no en la identidad, sino en la escala y la redundancia. Los registros públicos pueden probar la empresa y una red enrutada.
No prueban cuánto hardware está desplegado, cuántos racks están bajo control directo, cuánta capacidad de reserva se mantiene, con qué frecuencia se prueba la conmutación por error o si la recuperación del cliente puede completarse sin el sitio principal de Estambul.
La huella de enrutamiento es real, actual y pequeña
El panorama de la red pública es sencillo.La vista general de AS de RIPEstat para AS202048mostraba al titular como CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. y marcaba el AS como anunciado el 12 de julio de 2026. Losdatos de prefijos anunciados de RIPEstatmostraban un prefijo visible, 46.28.232.0/24, desde el 28 de junio de 2026 hasta el 12 de julio de 2026. Losrecuentos de prefijos RIS de RIPEstatmostraban un prefijo IPv4 originado, cero prefijos IPv4 en tránsito, cero prefijos IPv6 originados y cero prefijos IPv6 en tránsito en el momento de la consulta del 12 de julio.
Eso es suficiente para mostrar una operación pública activa. Lavista general de prefijo de RIPEstat para 46.28.232.0/24marca el /24 como anunciado por AS202048. Losdatos de estado de enrutamiento de RIPEstatmostraron que 325 de 326 pares de alimentación completa IPv4 veían la ruta en el momento de la muestra, con un prefijo IPv4 visible y 256 direcciones de espacio IPv4 anunciado. También mostró cero espacio IPv6 visible y un vecino observado. Lavalidación RPKIdevolvió un ROA válido para AS202048 y 46.28.232.0/24, con longitud máxima 24.
La misma evidencia limita la afirmación. Un solo /24 es una huella de direcciones públicas pequeña. Puede albergar servidores de nombres autoritativos, nodos de alojamiento, relays de correo, puntos finales de gestión, servicios VPS de clientes o sistemas de monitoreo, pero no es evidencia de una amplia región de nube regional. La ausencia de origen IPv6 visible es especialmente notable para un vendedor moderno de alojamiento y nube.
La visibilidad solo IPv4 no hace que los servicios sean inutilizables, pero indica que los clientes que necesitan servicios públicos de doble pila deben solicitar disponibilidad IPv6 explícita en lugar de asumir que existe.
Tampoco hay una entrada de red pública en PeeringDB para este ASN: labúsqueda en PeeringDB para ASN 202048devuelve un conjunto de datos vacío. La ausencia en PeeringDB no es prueba de una ingeniería débil. Muchos pequeños proveedores dependen del tránsito ascendente y no mantienen perfiles de intercambio públicos. Aun así, elimina un lugar común e independiente donde los operadores publican la presencia en instalaciones, los niveles de tráfico, la política de peering, los contactos NOC y las conexiones de intercambio. Para CloudTeknoloji, los datos públicos visibles dicen "AS enrutado real, un /24 IPv4 actual, autorización de ruta válida, sin origen IPv6 visible, sin perfil de peering público."
Eso es una calificación de evidencia media, no negativa. La red es visible y actual, pero deja al cliente la tarea de solicitar pruebas privadas de capacidad multisitio, diversidad de tránsito, capacidad de repuesto de hosts y diseño de rutas de recuperación.
El límite del rack es Estambul, no una nube sin ubicación
El lenguaje de las instalaciones de la propia empresa es lo suficientemente preciso como para dar forma a la conversación sobre riesgos. Lapágina acerca dedice que los sistemas se gestionan desde un centro de operaciones en Estambul 4. Levent y están alojados en el ICS centros de datos ubicado en Estambul, descrito como certificado PCI/DSS y estándar Tier III. También afirma tener más de 100 Gbps de capacidad de acceso a Internet redundante, fibra independiente del operador, sistemas de energía y UPS completamente redundantes, alimentación dual A+B, seguridad física y refrigeración. Lapolítica de serviciorepite la afirmación de ubicación de forma más sencilla: los servidores de daha.net están alojados en ICS centros de datos de Estambul, Tier III.
Eso convierte la palabra de marketing "nube" en un lugar. El servicio del cliente depende de racks en Estambul, un operador de instalaciones, distribución de energía, refrigeración, cableado, conexiones cruzadas, puertos de conmutador, sesiones de tránsito, almacenamiento, inventario de hardware y personas que pueden realizar reparaciones. Algunos de estos pueden estar controlados directamente por CloudTeknoloji. Otros recaen en ICS centros de datos o en los operadores ascendentes.
Las páginas públicas no revelan qué racks son alquilados, qué equipos son propiedad de CloudTeknoloji, cuánta capacidad de la instalación está reservada para daha.net, o si los mismos productos pueden conmutar por error a otra ciudad turca o a otro país.
La distinción es importante para la localidad de los datos. La oferta de CloudTeknoloji es atractiva para los clientes turcos en parte porque parece mantener la capacidad de alojamiento y servidor en Turquía. Lapágina VDSanuncia ubicación en Estambul, virtualización VMware ESXi y paquetes VDS respaldados por SSD. Lapágina Pro Cloudanuncia nuevamente ubicación en Estambul, con procesadores Xeon Gold 6138, soporte gestionado y almacenamiento SSD NVMe. Lapágina de alojamientoanuncia alojamiento en ubicación Estambul, Linux LiteSpeed, Windows IIS, SSL gratuito y backups semanales. Losdatos de geolocalización de RIPEstat para 46.28.232.0/24también sitúan el prefijo público en Turquía en el momento de la comprobación.
Pero la localidad no es lo mismo que la resiliencia. Una instalación turca puede cumplir con los requisitos de jurisdicción, latencia o soporte lingüístico de un cliente y aún así dejar a ese cliente expuesto a un fallo en un solo sitio. Si el servicio alojado principal, la copia de seguridad, el portal de soporte y el DNS del cliente dependen todos del mismo campus o de la misma entrega de operador, el cliente tiene control local pero independencia limitada.
Una afirmación de continuidad más sólida nombraría un segundo sitio, una ubicación de restauración probada, un dominio administrativo separado, un objetivo de tiempo de recuperación definido y una ruta de exportación clara.
El catálogo de servicios vende capas, no solo servidores
La gama de productos de daha.net es más amplia que la de una tienda de VPS limitada. Lapágina de información comercialdice que la empresa opera en alojamiento web, servidor cloud, registro de dominios, certificados SSL, correo electrónico y servicios de TI relacionados. La navegación y las páginas de producto muestran la misma amplitud:servidores cloud VDS estándar,servidores Pro Cloud gestionados,alojamiento web, alojamiento WordPress, alojamiento para revendedores, alojamiento corporativo, servicios de dominio, certificados SSL, licencias de panel de control, Microsoft 365, correo masivo y servicios de mantenimiento de servidores.
Esa amplitud es comercialmente útil. Una pequeña empresa puede comprar dominio, alojamiento, correo, certificado, VPS y soporte de un solo proveedor. Una agencia puede mantener los dominios y sitios de sus clientes bajo una sola cuenta. Un sitio de comercio electrónico turco puede elegir infraestructura alojada en Estambul y soporte en turco en lugar de aprender una consola de hiperescala. Un cliente que ha superado el alojamiento compartido puede pasar a VDS o Pro Cloud gestionado sin cambiar de marca.
La misma amplitud también dificulta la inspección de las dependencias. El registro de dominios depende de los canales del registrador y del registro. El correo electrónico puede depender de plataformas externas así como de DNS y soporte locales. SSL depende de las autoridades de certificación y los tiempos de validación. VDS depende de hipervisores, almacenamiento y red. La nube gestionada depende del acceso del personal y la disciplina de cambios. El mantenimiento del servidor depende de las habilidades y disponibilidad de los ingenieros.
Una factura agrupada puede hacer que todo esto parezca un solo servicio, mientras que la cadena de fallos sigue cruzando varios operadores.
Las páginas públicas de CloudTeknoloji hacen un trabajo decente al nombrar algunos ingredientes técnicos. La página VDS anuncia VMware ESXi, almacenamiento SSD, acceso root completo, procesadores Intel Xeon E5-2695 V4 y tamaños de paquete desde máquinas más pequeñas de dos núcleos hasta niveles de seis núcleos, 8 GB de RAM y 80 GB de SSD. La página Pro Cloud anuncia Xeon Gold 6138, SSD NVMe, recursos asignados, servicio gestionado, actualizaciones de seguridad, optimización y seguimiento técnico. La página de alojamiento anuncia Linux LiteSpeed, Windows IIS, SSD NVMe, cPanel o Plesk y backups semanales. Estas no son palabras vacías.
Identifican familias de productos y algunas clases de hardware.
Sin embargo, la información pública se detiene antes de las preguntas de capacidad más difíciles. ¿Cuántos hosts físicos soportan cada familia de planes? ¿Cuál es la ratio de sobreconcesión? ¿Cuántos nodos de repuesto pueden absorber el fallo de un host? ¿Los sistemas de almacenamiento VDS son locales, compartidos, replicados o respaldados por instantáneas? ¿El nivel Pro Cloud se ejecuta en hosts diferentes al VDS estándar, o simplemente en una clase de recurso superior con soporte gestionado? ¿Los repositorios de backup están fuera de la capa de almacenamiento de producción?
¿Puede un cliente exportar una imagen de VM, o solo archivos y backups del panel de control? Esas preguntas deciden si un plan vendido es cómodo solo durante los días normales o duradero durante los días de reparación.
La ruta ahora parece depender del lado ICS de la instalación
La ruta de enrutamiento pública apunta al límite instalación/operador. Elregistro aut-num en la base de datos RIPE para AS202048contiene líneas de política de importación y exportación para AS48678, AS42910 y AS214588. Sin embargo, laconsistencia de enrutamiento AS de RIPEstatmuestra una diferencia entre la política registrada y el enrutamiento observado: AS214588 está en BGP y en los datos de política, mientras que AS48678 y AS42910 aparecen en los datos de política pero no fueron observados en BGP en el momento de la muestra. Losdatos de vecinos ASN de RIPEstattambién informaron de un único vecino izquierdo, AS214588, para el último tiempo disponible.
AS214588 no es un salto aleatorio no relacionado. Elregistro AS214588 de RIPElo nombra comoicsteknoloji, y lavista general de AS214588 de RIPEstatda como titular a ICS Bilisim Teknolojileri Danismanlik Hizmetleri A.S. Los datos de política de AS214588 muestran relaciones ascendentes con Turkcell/Superonline, Turk Telekom y Vodafone. Lamuestra de estado BGP para 46.28.232.0/24muestra igualmente rutas globales que alcanzan AS202048 a través de AS214588 en las rutas muestreadas.
Esto no prueba que CloudTeknoloji no tenga un enlace de respaldo privado, una ruta de fibra oscura o una recuperación fuera de banda. Los colectores BGP públicos solo muestran lo que es globalmente visible en un momento dado. Pero para un cliente que compra capacidad alojada, la ruta pública actual sigue siendo significativa. Si el servicio de internet público de AS202048 se alcanza actualmente a través de AS214588, entonces la coordinación de las instalaciones y del ascendente con el lado ICS forma parte de la superficie operativa de CloudTeknoloji.
Un error de enrutamiento, una disputa comercial, un fallo de conexión cruzada, un problema de mitigación DDoS, un evento de energía, un fallo del operador o una entrega mal configurada en esa ruta pueden afectar a los clientes de CloudTeknoloji incluso si su VM está sana.
La pregunta práctica es la diversidad de tránsito. La propia página de la empresa de CloudTeknoloji afirma tener fibra independiente del operador y más de 100 Gbps de capacidad de internet redundante para su infraestructura. Esa es una afirmación sólida, pero la vista pública del AS muestra un solo vecino observado en el borde de CloudTeknoloji. Estas dos afirmaciones pueden coexistir si la instalación subyacente tiene múltiples operadores mientras que el propio AS de CloudTeknoloji utiliza actualmente la red ICS como la entrega de tránsito público.
También pueden coexistir si las opciones de respaldo están reservadas para uso de la instalación, circuitos privados o conmutación por error manual en lugar de ser visibles como sesiones BGP simultáneas. El cliente debe preguntar qué interpretación aplica.
Para servicios críticos, la respuesta debe ser contractual y técnica. Los clientes necesitan saber si sus IP públicas siguen siendo accesibles a través de un segundo ascendente si AS214588 está dañado, si hay conmutación por error de ruta automática, si el filtrado DDoS depende de la misma ruta, y si DNS, paneles de gestión y portales de soporte permanecen accesibles si se retira la ruta AS202048 primaria. Sin esas respuestas, la evidencia pública respalda una visión cautelosa: la ruta actual es real, limpiamente autorizada y visible, pero externamente concentrada.
La capacidad alojada se vende como instantánea, pero la reparación no es instantánea
La página VDS enfatiza la configuración rápida y los aumentos de recursos fáciles. Dice que los servidores cloud utilizan virtualización VMware ESXi, almacenamiento SSD, acceso root completo y recursos aislados, y anuncia aumentos de recursos a través del panel del cliente. La página Pro Cloud va más allá, vendiendo servicio gestionado, recursos asignados, procesadores Xeon Gold y SSD NVMe para sitios más pesados, SaaS, agencias, comercio electrónico y proyectos de alto tráfico. Esta es la promesa al cliente: tome un servidor sin ser dueño de un servidor.
La realidad operativa es más lenta. Un servidor virtual puede crearse en minutos, pero el sustrato físico aún falla en horas. Los discos fallan. Las reconstrucciones RAID consumen E/S. Los hosts requieren actualizaciones de firmware. Los puertos del conmutador se comportan mal. Los hipervisores necesitan parches. Los trabajos de backup pierden ventanas. Un pool de almacenamiento puede estar lleno incluso cuando una página de cuenta dice que el plan está activo. Una palabra de nube pública no elimina la caja de piezas.
Lapolítica de servicioes útil porque admite parte de esta fricción. Dice que las cuentas pagadas con tarjeta de crédito pueden activarse en unos minutos, pero los servicios más allá del alojamiento y el registro de dominios - incluyendo servidores cloud, licencias, certificados SSL y correo masivo - pueden tardar hasta ocho horas en instalarse o entregarse fuera del horario laboral. Dice que los pedidos por transferencia bancaria requieren aviso de pago y comprobaciones. Dice que los servicios de alojamiento y servidor cloud impagados se eliminan de los servidores después de 30 días. También dice que los Servidores Cloud utilizan un pool compartido de 10 Mbit a menos que el cliente alquile una línea para un límite diferente.
Esos detalles no hacen que el producto sea malo. Lo hacen finito. "Instantáneo" es una experiencia de ventas para la ruta común. La entrega fuera del horario laboral, los aumentos de capacidad, la instalación de software personalizado, los cambios de línea y las cuentas morosas tienen reglas diferentes. Un cliente que planifica una migración a CloudTeknoloji no debe asumir que cada cambio de recurso, adición de licencia o excepción de ancho de banda es automático.
Debe preguntar si el ancho de banda predeterminado del plan es suficiente, si la opción de pago cambia solo el límite de velocidad o también la prioridad de ruta, si se requiere renumeración de IP para cambios de línea, y si los aumentos de recursos tienen restricciones a nivel de host.
El lenguaje del pool compartido de 10 Mbit es especialmente importante. Muchos compradores de VDS piensan primero en núcleos, RAM y disco. El rendimiento de la red a menudo se hace visible solo cuando un sitio es atacado, se ejecuta una restauración de backup, comienza una campaña de comercio electrónico o se debe distribuir un archivo multimedia. Un pool compartido de 10 Mbit puede ser suficiente para sitios de negocios tranquilos, pero no sustituye una ruta de recuperación de alto rendimiento probada.
Si un cliente espera restaurar cientos de gigabytes rápidamente o servir grandes ráfagas de tráfico, la regla de velocidad de red pertenece a la discusión de diseño antes de realizar el pedido.
Los compromisos de soporte son visibles, pero no todos son iguales
daha.net publica varias declaraciones de soporte, y deben leerse en conjunto en lugar de selectivamente. Lapolítica de servicioenumera soporte telefónico en días laborables de lunes a viernes, de 09:00 a 17:30, soporte contable en días laborables durante la misma ventana, y soporte técnico por correo electrónico los siete días de la semana, 24 horas, con una garantía de respuesta de 60 minutos. Más adelante en la misma política, la sección de soporte al cliente dice que daha.net se compromete a responder en 60 minutos durante el horario laboral y en ocho horas fuera del horario laboral. Lapágina acerca dey lapágina de contactotambién se refieren a la disponibilidad telefónica en días laborables y al acceso continuo por correo electrónico o ticket de soporte.
El matiz importa. Una respuesta no es lo mismo que una reparación. Una respuesta puede confirmar la recepción, identificar el servicio afectado, pedir credenciales o decir que se ha contactado a un proveedor. La reparación puede depender del personal de la instalación, ingenieros ascendentes, stock de hardware, una licencia de proveedor, el administrador del cliente o un registro de dominio. Para el soporte de alojamiento rutinario, una respuesta de 60 minutos puede ser suficiente.
Para una caja de comercio electrónico caída, una interrupción de correo, un ERP inaccesible, un servidor comprometido o una restauración de base de datos fallida, el cliente necesita términos de escalamiento, no solo términos de primera respuesta.
La historia de soporte de CloudTeknoloji es más sólida que la de un host económico sin contacto porque publica números de teléfono, correos de soporte, una ruta de ticket, dirección comercial, dirección KEP y términos escritos. El riesgo es que los mismos términos publicados también muestran límites naturales: la cobertura telefónica no es 24 horas, parte de la entrega de servicios no esenciales puede esperar fuera del horario laboral, y el tiempo de respuesta fuera del horario laboral se describe de dos maneras.
Un comprador debe preguntar qué cláusula controla su producto específico, si Pro Cloud gestionado obtiene un escalamiento diferente al VDS no gestionado, si la respuesta de emergencia incluye intervención a nivel de instalación, y si existe un sistema de severidad con nombre con objetivos de tiempo de reparación.
El personal también se cruza con la migración. La página VDS anuncia soporte de migración gratuito, incluyendo el traslado de sitios web y bases de datos sin pérdida de datos o interrupción del servicio. Eso es valioso si es cierto en el caso de un cliente, pero debe ser delimitado. Mover un sitio web cPanel no es lo mismo que mover una aplicación personalizada, un servidor Windows, una base de datos viva, un archivo de correo, una zona DNS, una configuración DNSSEC, una lista blanca de firewall, trabajos cron e integraciones de terceros.
Los clientes deben preguntar qué cubre la "migración gratuita", qué debe ser preparado por el cliente, si la migración se programa, si se incluye la reversión y cuánto tiempo debe permanecer activo el sitio antiguo.
Las ventanas de mantenimiento son explícitas y lo suficientemente grandes como para importar
La cláusula de mantenimiento es una de las señales más claras de que la nube de CloudTeknoloji sigue siendo infraestructura ordinaria. Lapolítica de serviciodice que cuando se necesita mantenimiento del servidor, mudanza o actualizaciones de hardware, se advierte a los clientes con una semana, tres días y un día antes de la interrupción. Dice que dichas interrupciones no excederán un total de 96 horas en un año y no se realizarán durante el horario laboral a menos que sea necesario. También excluye la responsabilidad por fuerza mayor por retrasos, insuficiencias o incumplimientos.
Noventa y seis horas al año no es un objetivo de tiempo de inactividad; es un techo de mantenimiento tal como está escrito en la política. Aun así, es una cifra significativa para la planificación del cliente. Un negocio que lee solo el lenguaje de tiempo de actividad de la página de alojamiento puede esperar un servicio casi continuo. Un negocio que lee la política ve que el trabajo de infraestructura planificado puede consumir un número significativo de horas a lo largo de un año. Eso puede ser aceptable para sitios de bajo riesgo, entornos de desarrollo, folletos de pequeñas empresas o aplicaciones locales no críticas.
No es suficiente para un cliente cuyo sistema de pedidos, centro de llamadas, flujos de pago o sistemas clínicos deben funcionar durante cada noche de mantenimiento.
La pregunta importante es cómo se aísla el mantenimiento. ¿Se puede vaciar un host mientras las cargas de trabajo continúan en otros lugares? ¿Se migran en vivo los clientes VDS entre hosts? ¿El mantenimiento del almacenamiento requiere tiempo de inactividad? ¿Son redundantes los eventos de mantenimiento de red en la capa de conmutador o de tránsito? ¿Pueden los clientes de Pro Cloud comprar una disponibilidad mayor que el VDS estándar? ¿Se prueban las restauraciones de backup después del reemplazo de hardware? ¿El aviso de una semana, tres días y un día se aplica a todo el mantenimiento o solo al tiempo de inactividad esperado?
La política proporciona el patrón de alerta público, pero el cliente necesita detalles de arquitectura.
Esto también afecta a los clientes de agencias y revendedores. Si un revendedor aloja docenas de sitios de clientes en daha.net, un evento de mantenimiento puede convertirse en docenas de correos electrónicos de clientes. Si un proveedor de servicios gestionados utiliza daha.net como una capa VPS turca, una noche de reparación puede afectar a todos los clientes descendentes. Si un operador de comercio electrónico tiene una campaña programada, el aviso de mantenimiento debe ser compatible con las ventanas de congelación. La capacidad alojada se convierte en un calendario compartido, no solo en un gráfico de recursos.
El lenguaje de los backups es útil porque no es excesivamente reconfortante
El lenguaje de los backups de daha.net es más honesto que el de muchas páginas de alojamiento, y debe leerse con atención. Las páginas de productos de alojamiento y VDS anuncian funciones de backup semanal o periódico. Lapolítica de servicioda la regla más dura: los servidores de alojamiento se respaldan semanal y mensualmente, los servicios de servidor no se respaldan a menos que el cliente compre el servicio de backup, los backups pueden ser defectuosos o inutilizables, no se ofrece garantía a los clientes a partir de esos backups, y la copia de seguridad de la cuenta es responsabilidad del cliente. También dice que cuando un cliente necesita un backup tomado por daha.net, la empresa puede proporcionar un backup disponible a su discreción, dependiendo del sistema de backup.
Ese lenguaje debería alejar a los clientes del pensamiento mágico. Una etiqueta de backup en un plan de alojamiento no es lo mismo que un servicio de restauración garantizado. Para el alojamiento compartido, los backups semanales y mensuales pueden ayudar con la eliminación accidental o el fallo del sitio, pero la política niega la recuperación garantizada. Para VDS y servicios de servidor, la política dice que el backup no está incluido a menos que se compre. Para cargas de trabajo críticas, el comprador debe asumir que necesita su propio plan de backup probado hasta que los términos escritos digan lo contrario.
La diferencia entre "el backup existe" y "la restauración funciona" es central para esta empresa. CloudTeknoloji vende capacidad alojada, pero el cliente aún puede ser dueño de la protección de datos. Un sitio WordPress puede respaldarse a nivel de aplicación en una cuenta de almacenamiento externa. Un VDS puede hacer instantáneas en una región separada. Una base de datos puede transmitir réplicas o volcados a un segundo proveedor. El DNS puede alojarse con un operador separado. El cliente puede reducir el riesgo haciendo de CloudTeknoloji el host principal sin convertirlo en el único lugar donde existen los datos.
El cliente debe hacer cinco preguntas sobre los backups antes de usar daha.net para algo importante. Primera, ¿está incluido el backup para este producto exacto, o debe comprarse por separado? Segunda, ¿dónde se almacena el backup en relación con el sistema principal alojado en ICS? Tercera, ¿con qué frecuencia se prueba una restauración? Cuarta, ¿quién tiene las claves de cifrado y los derechos de administrador? Quinta, ¿cuánto tiempo llevaría una restauración completa a la velocidad de red predeterminada? La política pública responde parte de la primera pregunta y advierte que las demás importan.
La facturación, cancelación y eliminación de datos son parte del tiempo de actividad
Los artículos de infraestructura a menudo se centran en rutas y racks, pero los términos de CloudTeknoloji muestran que el estado comercial puede ser igual de importante. Lapolítica de serviciodice que los pedidos impagados durante siete días se cancelan automáticamente. Dice que los servicios de alojamiento y servidor cloud que no se renuevan se eliminan completamente de los servidores un mes después del período de renovación. Dice que la cancelación del servicio elimina la cuenta junto con los backups. También restringe la elegibilidad de reembolso para algunos complementos, licencias, dominios, SSL y otros servicios, y dice que la elegibilidad de reembolso del Servidor Cloud puede desaparecer si el equipo técnico instala complementos o software a petición del cliente.
Para un sitio web de consumo, estos términos pueden ser rutinarios. Para una carga de trabajo empresarial, son una dependencia. Un fallo en la tarjeta de pago, una disputa de factura, un retraso en la adquisición o un cambio de personal puede convertirse en la eliminación de datos si la renovación no está controlada. Un cliente que se aleja de daha.net debe exportar archivos, bases de datos, DNS, buzones de correo, certificados, claves, licencias e imágenes de servidor antes de la cancelación o la no renovación. Un cliente que depende de los backups para la reversión debe entender si esos backups desaparecen con la cuenta.
Aquí es donde la economía del alojamiento se encuentra con el riesgo. Un proveedor local empaquetado puede ser más barato y fácil que construir infraestructura redundante desde cero. Pero el alojamiento más barato a menudo devuelve parte de la responsabilidad operativa al cliente: disciplina de renovación, backups, preparación de migración, almacenamiento de credenciales, gestión de bloqueo de dominio, TTL de DNS y copias de restauración fuera del proveedor. El cliente debe tener un plan de salida desde el primer día, no después de un incidente.
El plan de salida es simple en principio. Mantenga el acceso al registrador independiente donde sea posible. Mantenga exportaciones de DNS. Mantenga backups fuera de la plataforma. Sepa qué direcciones IP están vinculadas a listas blancas. Mantenga una lista actualizada de certificados SSL y fechas de renovación. Pruebe la restauración de un sitio en otro proveedor. Mantenga la continuidad del correo electrónico fuera de una sola cuenta de alojamiento web si el correo es crítico. Nada de esto significa evitar CloudTeknoloji. Significa usarlo como un proveedor, no como la única copia del negocio.
La soberanía de datos es un punto de venta real con una compensación de recuperación
Para los clientes turcos, el alojamiento local puede ser valioso. Puede reducir la latencia para los usuarios nacionales, simplificar el soporte lingüístico y fiscal, mantener los contratos bajo una jurisdicción familiar y respaldar las preferencias de localidad de datos. Las páginas oficiales de CloudTeknoloji se inclinan por ese perfil local: oficinas en Estambul, instalaciones en Estambul, soporte en turco, aceptación de pedidos solo en Turquía según la política, identidad legal turca, dirección KEP y un conjunto de servicios orientado al alojamiento local, dominios y correo electrónico empresarial. Lavista de geolocalización para 46.28.232.0/24también alinea el prefijo público visible con Turquía.
La localidad, sin embargo, puede concentrar el riesgo si no se combina con una recuperación independiente. Un cliente que debe mantener los datos en Turquía puede necesitar aún un segundo sitio turco, un segundo proveedor, una segunda cuenta de backup o al menos un DNS y un acuerdo de restauración separados. Un cliente que puede usar una copia de recuperación en el extranjero puede obtener una separación geográfica más fácil, pero debe considerar los límites legales, de privacidad y contractuales. Las páginas públicas de CloudTeknoloji no resuelven esa compensación. Muestran un proveedor centrado en Turquía.
No publican una arquitectura de recuperación multisitio completa.
La conclusión correcta no es que el alojamiento local turco sea débil. Es que la soberanía y la resiliencia son objetivos de diseño separados. El primero pregunta dónde residen los datos y qué ley se aplica. El segundo pregunta si un cliente puede continuar después de un fallo de sitio, ruta, almacenamiento, personal o cuenta. CloudTeknoloji puede ayudar con lo primero manteniendo los servicios en Estambul. El cliente aún debe verificar lo segundo.
Esto es especialmente cierto para los clientes con cargas de trabajo reguladas, reputacionales o sensibles a los ingresos. Una escuela, clínica, agencia, tienda de comercio electrónico u oficina profesional puede elegir daha.net porque el servicio de asistencia habla el mismo idioma, la entidad legal es accesible y el servidor está en Estambul. Eso es racional. Pero si el mismo servicio es también el único host DNS, el único host de correo, la única ubicación de backup y la única ruta al soporte, entonces una ventaja local se convierte en un punto único operativo.
La solución no es abstracta: backup separado, DNS separado, conmutación por error documentada, restauración probada y escalamiento por escrito.
Quién se ve afectado cuando este sistema falla
El primer grupo afectado son los clientes de alojamiento compartido. Estos son los usuarios más propensos a sentir los límites de la plataforma pero menos propensos a entender la instalación detrás de ellos. Un fallo de alojamiento compartido puede dejar fuera de línea sitios web, buzones de correo, bases de datos, paneles de control y rutas de renovación de SSL a la vez. Es posible que el cliente no tenga acceso root o control directo de backup. Por lo tanto, las exenciones de responsabilidad de backup de la política de servicio son más importantes para los clientes menos técnicos.
El segundo grupo son los clientes de VDS y Pro Cloud. Tienen más control, pero también heredan más responsabilidad. Un cliente de VDS no gestionado tiene acceso root y puede construir su propia pila, pero las actualizaciones del sistema operativo, la seguridad de las aplicaciones, la planificación de backup y restauración de bases de datos pueden recaer en el cliente. Un cliente de Pro Cloud gestionado puede obtener más ayuda, pero aún debe confirmar exactamente qué capas se gestionan, cuáles son de soporte de mejor esfuerzo y cuáles siguen siendo propiedad del cliente.
El tercer grupo son las agencias y revendedores. Convierten un proveedor ascendente en muchas promesas descendentes. Si compran alojamiento para revendedores, capacidad VDS o servidores gestionados de daha.net, sus propios clientes pueden ver a la agencia como el operador. Una ventana de mantenimiento de daha.net, una cola de soporte o un problema de ruta se convierte en un incidente de la agencia. Estos clientes necesitan actualizaciones de estado, plantillas de comunicación con el cliente, backups de migración y límites de servicio claros antes de que comiencen los problemas.
El cuarto grupo son los clientes de dominio y correo electrónico. La expiración del dominio, las limitaciones de transferencia, los errores de DNS y los fallos de enrutamiento de correo pueden durar más que una interrupción web. La política de servicio describe avisos de renovación de dominio, renovación automática, períodos de restauración y condiciones de transferencia. Los clientes que colocan dominio, DNS, alojamiento y correo bajo una sola cuenta obtienen comodidad. También ponen la renovación, las credenciales y el escalamiento de soporte en un solo lugar.
Separar el acceso de propiedad del control de alojamiento puede reducir ese riesgo.
El último grupo afectado es el propio CloudTeknoloji. Un AS público pequeño y una ruta concentrada no significan automáticamente debilidad operativa, pero sí significan que cada incidente público puede tener un peso reputacional. Si los clientes ven la marca como un socio de fiabilidad local, esperarán avisos claros, páginas de estado honestas, actualizaciones rápidas de reparación y ayuda práctica de migración. La política de servicio público ya reconoce los avisos de mantenimiento y la respuesta de soporte. La siguiente señal de madurez sería un historial de incidentes transparente y términos de recuperación específicos por producto.
Qué resolvería las preguntas abiertas
El registro público es suficiente para un perfil cauteloso, pero no suficiente para una evaluación de resiliencia de alta confianza. Cinco revelaciones adicionales cambiarían materialmente la calificación.
Primero, CloudTeknoloji podría publicar o proporcionar bajo contrato un límite de instalación y propiedad: qué servicios se ejecutan en ICS centros de datos, cuáles son hardware propiedad de CloudTeknoloji, cuáles son capacidad alquilada y cuáles dependen de proveedores externos. Segundo, podría publicar términos de backup específicos por producto: backups incluidos, backups de pago, retención, ubicación externa, tiempo de restauración, pruebas de restauración y responsabilidad del cliente.
Tercero, podría indicar el diseño de tránsito para AS202048: ascendentes actuales, comportamiento de conmutación por error, manejo de DDoS, disponibilidad de IPv6 y si AS48678 o AS42910 siguen siendo opciones de respaldo disponibles o solo líneas de política históricas. Cuarto, podría proporcionar compromisos de mantenimiento y emergencia por nivel de producto, distinguiendo la respuesta de la reparación. Quinto, podría documentar los derechos de salida: exportación de VM, backups del panel de control, exportación de zona DNS, soporte de transferencia de dominio, límites de portabilidad IP y plazos de eliminación de cuenta.
Algunos de estos detalles pueden existir ya en contratos con clientes o propuestas de venta. El problema es la verificabilidad pública. Desde fuera, la empresa tiene una huella de identidad más sólida que muchos hosts, una ruta activa y autorizada, y una historia coherente de alojamiento en Estambul. También tiene una red pública visible pequeña, sin origen IPv6 visible, una ruta ascendente observada a través de ICS, y términos de servicio que depositan una responsabilidad significativa de backup y renovación en el cliente.
El trabajo del comprador es hacer coincidir la criticidad de la carga de trabajo con esa evidencia. Un sitio de folleto de bajo riesgo, un pequeño sitio WordPress, una configuración de correo de empresa local o un VPS de desarrollo pueden encajar cómodamente. Un escaparate de alto tráfico, un almacén de datos regulado, un servicio público de emergencia, una aplicación crítica de pagos o una plataforma de revendedor multicliente deberían requerir redundancia escrita y evidencia de restauración antes de mover la producción.
En resumen
CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. no merece ni el descarte ni la confianza ciega. La empresa detrás de daha.net es identificable, ha operado bajo una identidad comercial turca visible, publica información de contacto y legal, vende un amplio catálogo de alojamiento, afirma tener instalaciones en Estambul y mantiene un AS público activo. La ruta pública para AS202048 está anunciada, es visible para los colectores y está cubierta por una autorización RPKI válida para 46.28.232.0/24.
La precaución es que la huella pública es estrecha. Un /24 IPv4 visible, sin origen IPv6 visible, sin perfil público de PeeringDB y un solo vecino AS observado actualmente no prueban una amplia redundancia. Los términos de servicio oficiales también recuerdan a los clientes que los servidores cloud, los backups, el mantenimiento, las horas de soporte, el ancho de banda y el estado de renovación tienen límites.
En términos sencillos, CloudTeknoloji vende capacidad alojada que puede ser valiosa para las empresas turcas, pero esa capacidad aún depende de racks, tránsito, energía, reemplazo de hardware, respuesta del personal y la disciplina de backup y migración del propio cliente.
La postura correcta del comprador es práctica: use el proveedor local cuando su alojamiento en Estambul, soporte turco y servicios empaquetados se ajusten a la carga de trabajo, pero haga que el proveedor muestre la ruta de recuperación. Pregunte dónde residen los datos, dónde se encuentra el backup, qué ruta conmuta por error, cómo se escalan las reparaciones, qué tan rápido se puede ejecutar una restauración completa, qué sucede después de la no renovación y cómo el cliente puede salir limpiamente.
Hasta que esas respuestas estén escritas y probadas, la evidencia pública respalda un perfil de infraestructura de confianza media: operación real, profundidad de red pública limitada y preguntas de recuperación que importan más que la palabra "nube".