Resumen

  • La Bangladesh Telecommunication Regulatory Commission y la ISP Association of Bangladesh identifican a Planet Information Technology Solution Limited dentro del sector ISP de Dhaka.[8][9] APNIC registra por separado la organización vinculada al AS136903 activo, una asignación IPv4 y una asignación IPv6.[10][11][13][14] Son pruebas de identidad y responsabilidad, no de rendimiento.
  • En la ventana observada, RIPE NCC veía al AS136903 anunciar 103.98.107.0/24 y 2001:df1:1780::/48.[15][16] La observación procede de colectores BGP y está limitada en el tiempo. No mide disponibilidad, capacidad, latencia, pérdida ni experiencia de todos los clientes.
  • La vista pública mostraba un vecino, AS137491.[17] No demuestra que Planet tenga un solo proveedor, un único camino físico o ninguna relación privada o de respaldo. Convierte la diversidad en una pregunta que debe resolverse con evidencia directa.
  • El validador RPKI de RIPE NCC devolvió valid para las rutas IPv4 e IPv6 observadas.[18][19] El resultado confirma que origen y longitud estaban cubiertos por ROA compatibles. No garantiza el camino completo, filtrado correcto, seguridad integral, disponibilidad ni cumplimiento de una promesa de servicio.
  • La web de Planet anuncia acceso residencial y corporativo, fibra, ancho de banda dedicado, IP estática, soporte relacionado con VPN, BDIX o CDN y compromisos de atención o servicio.[1][2][3][4][5][6][7] Son declaraciones de capacidad. Las fuentes no contienen mediciones independientes de velocidad, latencia, pérdida, disponibilidad, restauración o resultados de clientes.
  • El dominio actual planet-itsolutions.com estaba operativo, mientras que el dominio histórico del directorio devolvía NXDOMAIN en la observación. La diferencia señala un coste de sincronización de identidad pública, no una interrupción demostrada ni su duración, causa o impacto.
  • El coste estable está en la supervisión de registros y rutas, la integración de ROA, la paridad IPv4/IPv6, el mantenimiento de DNS y correo, los contactos de abuso, la coordinación de proveedores, las excepciones, la conservación de evidencias y la portabilidad.

Un objeto de empresa exacto y varias formas públicas

El directorio identifica el objeto como Md. Abdus Salam T/A Planet Information Technology Solution Ltd. Las fuentes institucionales y la web utilizan formas más cortas, como Planet Information Technology Solution Ltd. o Planet Information Technology Solution Limited. La coincidencia de palabras no basta para unir empresas, pero tampoco sería razonable crear una entidad distinta por cada variación ortográfica. Hay que conservar el nombre de cada fuente y buscar identificadores comunes.

ISPAB ofrece una unión clara: miembro G-351, licencia ISP divisional, dirección en Dhaka y dominio actual.[8] La lista de BTRC de 23 de diciembre de 2024 sitúa a Planet en la fila 127 y conserva el número 14.32.0000.702.45.591.24.292.[9] APNIC registra PITSL-AS-AP, AS136903 y ORG-PITS1-AP.[10][11] Los documentos tienen finalidades diferentes, pero juntos sostienen la identidad de la empresa del directorio como operador con recursos numéricos.

La fecha y la función de cada fuente limitan la conclusión. Una lista regulatoria fechada no se convierte automáticamente en autorización perpetua. Un registro de asociación no certifica la calidad. Un objeto APNIC activo no inspecciona los routers. La convergencia permite investigar al mismo operador, no concederle una puntuación universal.

La superficie pública abarca ASN, direcciones, rutas, ROA, contactos, dominio, servidores autoritativos, correo, web, ofertas y soporte. Cada componente puede quedar desfasado respecto a otro. La continuidad consiste en detectar esa divergencia, asignarla y cerrarla con evidencia.

No existe en las fuentes una base para atribuir a Planet un modelo propio de inteligencia artificial. No hay ficha de modelo, referencia comparativa, arquitectura de inferencia ni despliegue de cliente. La capacidad relevante es operar conectividad. La fiabilidad del producto necesita una serie de medidas. El resultado del cliente necesita evidencia atribuible. Las tres categorías no deben fusionarse.

APNIC registra autoridad, no experiencia del usuario

El objeto RDAP del AS136903 está activo y enlaza el número con Planet.[10] ORG-PITS1-AP conserva la identidad organizativa y los contactos.[11] IRT-PITSL-BD publica la vía de abuso y fechas de validación de buzones.[12] La separación entre funciones administrativas, técnicas y de abuso es importante porque una incidencia puede requerir autorización, ejecución y comunicación de personas distintas.

Un estado activo describe el registro, no todos los servicios. Un buzón validado no aporta una distribución de tiempos de respuesta. APNIC actúa como libro de registro: preserva identificadores, delegación, contactos e historial. La empresa debe mantener las cuentas, recuperar el acceso y comprobar que los roles siguen llegando a quien puede actuar.

APNIC registra 103.98.106.0/23 como recurso IPv4 activo de Planet.[13] La observación BGP incluye 103.98.107.0/24, una parte más específica de ese bloque.[15] La asignación indica autoridad registrada; el anuncio indica estado observado. Ninguna permite deducir cómo se usa cada dirección o por qué el otro /24 no aparece en esa vista.

El recurso IPv6 2001:df1:1780::/48 también está registrado y fue anunciado.[14][15] Es evidencia de operación de doble pila, pero no de despliegue universal entre clientes. La equivalencia de IPv4 e IPv6 depende de filtros, cortafuegos, DNS, equipos de acceso, aplicaciones, observabilidad y soporte.

Los recursos crean costes de ciclo de vida. La organización debe saber quién controla APNIC, quién aprueba una ruta, cómo se recuperan credenciales, qué prefijos se esperan, qué ROA los cubren, cómo se configura DNS inverso y qué clientes dependen de ellos. Una salida o cambio de proveedor exige que todos esos controles se muevan en una secuencia comprobada.

La vía de abuso no termina en una dirección publicada. El informe debe autenticarse, asociarse a dirección y hora, preservar evidencia, proteger a terceros, coordinar la corrección y documentar el cierre. Los falsos positivos también cuestan. El registro ayuda a encontrar al responsable; no sustituye la investigación.

Rutas visibles y límites de la observación

La respuesta de prefijos anunciados de RIPE NCC mostraba 103.98.107.0/24 y 2001:df1:1780::/48.[15] El estado de enrutamiento informaba visibilidad para una ruta IPv4 y otra IPv6 entre los pares RIS consultados.[16] La coincidencia entre recursos registrados y anuncios observados es un control positivo.

No es una medición de extremo a extremo. Una ruta puede estar visible mientras falla un circuito de acceso, un resolvedor, una autenticación o una aplicación. Un colector puede perder una vista sin que todos los usuarios pierdan servicio. El diseño de monitorización debe mantener separadas la visibilidad BGP, la entrega de paquetes, el DNS, el acceso y la aplicación.

AS137491 aparecía como único vecino en el resultado usado.[17] La palabra vecino debe conservar su sentido observacional. No revela por sí sola tránsito, peering, cliente, respaldo o dirección comercial. Puede omitir relaciones privadas, rutas no preferidas, servidores de rutas y contratos. Una evaluación debe pedir diversidad física y contractual del servicio concreto.

Esa diversidad incluye conductos, edificios, energía, routers, proveedores y procedimientos. Dos enlaces pueden compartir un punto de fallo. Varias relaciones de red no garantizan que un acceso concreto tenga dos caminos. El último ejercicio de conmutación y sus resultados aportan más valor que contar vecinos públicos.

El /24 IPv4 observado dentro del /23 registrado exige coherencia de filtros y maxLength. Un sistema que solo conoce el agregado puede rechazar una ruta prevista. Una regla demasiado amplia puede permitir algo no aprobado. La fuente común de prefijos debe alimentar configuración, ROA, seguridad, monitorización y documentación.

IPv4 e IPv6 requieren paneles y procedimientos propios. Una familia puede tener ruta y la otra no; una aplicación puede publicar AAAA pero fallar detrás del cortafuegos. El soporte debe saber probar ambas y no cerrar el caso porque el mecanismo de preferencia cambió silenciosamente a IPv4.

RPKI reduce una incertidumbre concreta

Para 103.98.107.0/24, el validador encontró un ROA que cubre 103.98.106.0/23 y admite una longitud máxima /24 con origen AS136903.[18] La pareja IPv6 también devolvió valid.[19] El control permite diferenciar mejor una ruta autorizada de un origen o una longitud conflictivos.

RPKI no autentica todo el camino. No prueba que cada red aplique filtrado, que el origen autorizado esté libre de compromiso o que la aplicación responda. No mide latencia, pérdida, ancho de banda, DNS, DDoS ni restauración. Una ruta válida puede participar en una fuga o conducir a un servicio caído.

El mantenimiento empieza cuando cambia la intención. Una nueva longitud, un origen de respaldo o una migración deben actualizar ruta y ROA de forma coordinada. Si la ruta se adelanta, puede quedar inválida. Si el ROA queda demasiado amplio, autoriza más de lo necesario. La orden de despliegue, las comprobaciones y el retroceso deben estar acordados.

También hay una dependencia de autoridad. Una conexión de emergencia no sirve plenamente si nadie puede modificar la autorización. Cuentas, roles, recuperación y aprobación deben probarse antes de la crisis. Los registros de validación deben conservar prefijo, origen, ROA, hora y estado para explicar después qué cambió.

Capacidad técnica, fiabilidad del producto y resultado del cliente

Planet se presenta como proveedor de internet residencial y corporativo y de soluciones de TI.[1][2] Sus páginas enumeran fibra, capacidad dedicada, IP estática y asistencia para VPN.[3] Los paquetes incluyen velocidades, referencias a BDIX o CDN y condiciones de compartición.[4] La información de contacto y el documento tarifario añaden compromisos públicos.[5][7]

La existencia del AS, las direcciones y las rutas hace observable una parte de la capacidad. No demuestra el comportamiento de cada oferta. La fiabilidad necesitaría disponibilidad, pérdida, latencia, variación, rendimiento, congestión, tiempo de reparación y respuesta, con límites y períodos definidos.

Las fuentes no contienen esas series independientes. Una cifra de disponibilidad o restauración en una web sigue siendo una promesa. La evaluación debe conocer dónde se mide, qué se excluye, quién conserva el dato y qué remedio existe. Una media alta puede ocultar fallos cortos pero repetidos en el horario más importante.

El resultado del cliente es otra capa. Una conexión puede mantener una sucursal, voz, pagos, nube o copias de seguridad. No hay un caso atribuible en la evidencia. No debe sustituirse por una historia imaginada. El comprador puede aportar pruebas de aceptación y resultados de producción bajo controles adecuados.

Antes de contratar conviene acordar pruebas autorizadas de IPv4, IPv6, DNS, aplicaciones, capacidad, conmutación, seguridad y escalada. Esta investigación no realizó pruebas privadas ni referencias comparativas. Explica qué faltaría para transformar capacidad en fiabilidad demostrada.

El dominio como activo operativo

planet-itsolutions.com era el dominio activo de la web y el enlace de ISPAB.[1][8] Publicaba respuestas A, NS, MX y SPF en la observación del 2 de agosto. El dominio histórico del directorio devolvía NXDOMAIN. Eso describe una respuesta concreta, no la causa, duración o efecto sobre clientes.

Una migración de dominio cruza registrar, DNS, web, correo, certificados, cuentas, contratos, directorios, contactos y monitorización. Redirigir la web no reenvía correo. Cambiar una página no corrige automáticamente APNIC, ISPAB o documentos comerciales. Cada referencia residual necesita propietario y cierre.

El correo merece un plan especial. Un buzón antiguo puede dejar de recibir antes de que el remitente descubra el nuevo. Los roles críticos y los informes de abuso no deberían depender de una identidad retirada sin transición. También debe vigilarse que el dominio antiguo no pueda ser adquirido por un tercero.

El dominio actual separa varias autoridades: registrador, delegación, DNS, alojamiento web, MX y SPF. Un bloqueo de cuenta puede impedir corregir la zona aunque las rutas sigan visibles. Una avería web no implica retirada del AS136903. Las alertas deben identificar la capa exacta.

Cuatro bloques de coste operativo

Supervisión

El inventario debe incluir ASN, prefijos, anuncios, ROA, filtros, contactos, DNS, correo, licencia, proveedores, objetivos y dependencias. Cada control tiene una cadencia distinta. La ruta puede requerir alerta inmediata; un contacto, certificado o documento necesita revisión periódica. La evidencia debe conservar fuente, hora, valor y limitación.

Integración

Routers, ROA, filtros, sistemas de seguridad, DNS inverso, monitorización y contratos deben compartir la misma intención. Los proveedores aportan accesos y escaladas; los clientes aportan IP estáticas, VPN, cortafuegos y aplicaciones. Un cambio correcto para una parte puede romper una suposición de la otra. Las responsabilidades en el punto de demarcación deben estar escritas.

Mantenimiento

Rutas, filtros, contactos, credenciales, certificados, DNS, ofertas y paneles cambian. La doble pila duplica parte de ese trabajo. La identidad actual y la histórica deben revisarse. Los cambios e incidencias necesitan evidencia suficiente para reconstruir intención, aprobación, efecto y recuperación.

Excepciones

Una ruta urgente puede esperar el acceso RPKI. Un informe de abuso puede carecer de datos. DNS puede quedar bloqueado durante una transición. IPv4 puede recuperarse antes que IPv6. Toda excepción necesita clasificación, autoridad, vencimiento, retroceso y prueba de cierre. De lo contrario, una solución temporal se vuelve dependencia permanente.

Modos de fallo que deben convertirse en pruebas

  1. Contacto registrado obsoleto: el objeto sigue activo, pero nadie responde. Probar roles y recuperación fuera de banda.
  2. Ruta y ROA en desacuerdo: una nueva longitud u origen aparece inválido. Comparar intención, BGP y autorización.
  3. Retirada o visibilidad reducida: distinguir colector, política y servicio antes de atribuir una causa.
  4. Concentración no demostrada: un vecino visible no prueba ni descarta redundancia. Verificar caminos físicos y contratos.
  5. IPv4 e IPv6 divergen: probar cada familia en ruta, DNS, cortafuegos y aplicación.
  6. Autoridad DNS perdida: la zona parece correcta, pero la cuenta no puede recuperarse. Ensayar acceso, roles y exportación.
  7. Identidad histórica rota: clientes o terceros usan un dominio NXDOMAIN. Mantener un inventario de referencias.
  8. Escalada sin autoridad: soporte responde, pero no llega a quien puede cambiar ruta o proveedor. Definir severidad y decisión.
  9. Abuso ambiguo: preservar hora, dirección y evidencia; actuar de forma proporcional y documentar.
  10. Panel verde, servicio rojo: BGP y RPKI no sustituyen medición del circuito y la aplicación.
  11. Dependencia compartida: servicios distintos usan la misma cuenta, energía o instalación. Probar recuperación.
  12. Salida no ensayada: recursos, dominios y configuraciones no pueden separarse durante una crisis. Practicar antes.

No se afirma que Planet haya sufrido estos incidentes. Son escenarios derivados de fronteras de control observables y sirven para diseñar pruebas sin inventar arquitectura, clientes o resultados.

Compra, portabilidad y conclusión limitada

Una diligencia útil pide identidad contractual, perímetro, prefijos previstos, titulares, orígenes, ROA, diversidad, método de medición, contactos, último ejercicio y salida. Debe separar lo que controla Planet, lo que controla el cliente y lo que depende de otro proveedor.

La portabilidad incluye direcciones, filtros, autorizaciones, DNS, correo, certificados, equipos, monitorización, historiales y cooperación. Una dirección portable puede quedar bloqueada por cuentas o documentación. La salida debe probarse cuando aún es reversible.

La conclusión pública puede ser positiva y precisa. Planet está unido a una empresa de directorio, una identidad ISP, AS136903, recursos IPv4 e IPv6 visibles y autorizaciones de origen válidas. La web muestra productos y contactos. Es una base razonable para diligencia; no es una garantía de fiabilidad, soporte o éxito del cliente. El valor depende de la capacidad de reconciliar continuamente autoridad, configuración, promesa y resultado medido.

Fuentes

  1. Página principal de Planet Information Technology Solution.
  2. Página corporativa de Planet Information Technology Solution.
  3. Servicios de Planet Information Technology Solution.
  4. Paquetes de Planet Information Technology Solution.
  5. Contacto de Planet Information Technology Solution.
  6. Página del presidente de Planet Information Technology Solution.
  7. Documento tarifario alojado por la empresa.
  8. Registro de miembro de ISPAB.
  9. Lista BTRC de licencias ISP divisionales de 23 de diciembre de 2024.
  10. APNIC RDAP para AS136903.
  11. APNIC RDAP para ORG-PITS1-AP.
  12. APNIC RDAP para IRT-PITSL-BD.
  13. APNIC RDAP para 103.98.106.0/23.
  14. APNIC RDAP para 2001:df1:1780::/48.
  15. Prefijos anunciados observados por RIPE NCC.
  16. Estado de enrutamiento de RIPE NCC para AS136903.
  17. Vecinos ASN observados por RIPE NCC.
  18. Validación RPKI de 103.98.107.0/24.
  19. Validación RPKI de 2001:df1:1780::/48.

Observación adicional: las respuestas DNS públicas de los dominios actual e histórico se consultaron el 2 de agosto de 2026 y describen ese momento, no una disponibilidad prolongada.

Nota de imagen: el artículo utiliza una fotografía de cable de fibra óptica y conducto de Rubin Observatory / NSF / AURA, disponible en Wikimedia Commons bajo licencia CC BY 4.0. Es contexto genérico y no representa a Planet, su red, instalaciones, clientes ni resultados.