BookinglyTech News
Redes y nube

Reportan fallos de resolución DNS pública por el enlace de Etisalat en Dubái

Un administrador describe que con Etisalat la conectividad IP y el DNS interno funcionan, pero los dominios públicos no resuelven. Al cambiar a DU, todo vuelve a funcionar sin tocar nada.

2 min de lecturar/networking0 vistas

Un administrador de redes con oficina en Dubái ha descrito un comportamiento raro en su salida a internet: cuando el tráfico sale por Etisalat, la conectividad IP funciona y el DNS interno resuelve, pero los dominios públicos no. Cuando mueve el mismo tráfico al enlace de DU, todo vuelve a funcionar sin tocar la configuración de clientes, servidores ni cortafuegos.

El montaje es el habitual en una sede con dos operadores: un FortiGate con dos enlaces, Etisalat y DU, y los clientes apuntando a los resolvers internos alojados en la red troncal de AWS como primarios. Como respaldo están configurados resolvers públicos: 8.8.8.8, 8.8.4.4 y 1.1.1.1.

Con Etisalat el cuadro es este: un ping a 8.8.8.8 responde, así que hay conectividad IP; los dominios internos resuelven contra los servidores propios; google.com no resuelve. Con DU, las tres cosas funcionan. El cambio de operador es lo único que se toca.

Qué acota el síntoma

El propio reporte descarta varias capas. No es una caída del enlace, porque hay conectividad. No es enrutamiento hacia la red interna, porque se alcanzan los resolvers de AWS. No es configuración del cliente ni del FortiGate, porque cambiar de operador lo arregla sin modificar nada. Lo que queda es el camino del tráfico DNS hacia resolvers públicos cuando sale por Etisalat.

Ahí se acaba el material. No hay capturas, ni salida de dig o nslookup, ni trazas que digan si la consulta sale, si la respuesta vuelve o si vuelve manipulada. Tampoco hay confirmación del operador ni un diagnóstico cerrado. Los sospechosos clásicos en un cuadro así —un problema de MTU en la ruta, un resolver transparente del operador, filtrado del puerto 53— no aparecen verificados en lo publicado, y conviene no darlos por buenos sin una prueba que los sostenga.

La cosa tiene gracia para quien administra sedes fuera de España: un fallo así no lo detecta el ping ni el chequeo de enlace, que seguirán en verde. Lo detecta el usuario que no puede abrir nada, y solo para nombres públicos. Si tu diseño usa resolvers públicos como respaldo del DNS interno, este escenario te deja sin resolución externa sin que la monitorización de conectividad se entere. Queda por ver de quién es el problema: del operador, del equipo en el borde o de algo más acotado.