En las soluciones DNS geográficas clásicas, las decisiones suelen tomarse según la dirección IP del resolver DNS. Cuando un usuario recurre a un resolver público remoto, sin embargo, el sistema DNS ve la ubicación del resolver y no la posición real del usuario. Como resultado, un usuario en Turquía puede ser dirigido a un centro de datos en la región equivocada o a un PoP innecesariamente distante.
El routing de capa única, solo por país, también es insuficiente para la mayoría de los escenarios empresariales. Dentro del mismo país, distintos operadores, distintos ASNs, distintas ciudades o distintos bloques de red privados pueden requerir cada uno un routing separado. Necesidades como peering de telco, cumplimiento, latencia, selección de PoP tipo CDN y routing de campañas exigen una granularidad más fina.
Usar una API GeoIP online para las decisiones geográficas introduce un riesgo adicional. Enviar el contexto de consulta DNS a un servicio externo puede crear problemas para la residencia de datos y la privacidad de las consultas. Que una capa de decisión de tráfico crítica como GTM dependa de una API externa también es un punto débil para la continuidad operativa.
El modelo correcto es soportar la información de subred del cliente, tomar las decisiones geográficas usando bases de datos offline en el dispositivo y extender las reglas de topología más allá del nivel de país para incluir ciudad, ASN y CIDR. Producir una respuesta final controlada mediante registros de fallback cuando no se encuentre coincidencia debería formar parte del mismo modelo.
TR7 DNS Geographic Routing entrega exactamente esto: EDNS Client Subnet, reglas de topología en cinco dimensiones, bases de datos GeoIP offline y selección de registros basada en selector llevan las respuestas DNS más cerca del contexto real del usuario.
TR7 implementa decisiones DNS geográficas mediante subred del cliente, topología multidimensional, GeoIP offline y un pipeline de selección basado en Lua.
Con el soporte de EDNS Client Subnet, la decisión DNS deja de estar ligada únicamente a la IP del resolver. Las decisiones geográficas se toman a partir de la subred real del cliente, habilitando una selección de DC o PoP más precisa.
TR7 puede definir reglas en red/CIDR, país, ciudad, continente y ASN. Cada regla puede escribirse con comportamiento normal o de negación.
Las decisiones geográficas se toman usando las bases de datos ASN, City y Country almacenadas localmente en el dispositivo. El contexto de consulta DNS nunca se envía a un servicio GeoIP externo.
TR7 evalúa las reglas de topología en orden y selecciona los candidatos de registro coincidentes mediante lógica de selector. Pueden construirse distintas estrategias de distribución con comportamientos all, closest, round-robin, weighted o random.
DNS Geographic Routing produce respuestas DNS basadas en país, ciudad, ASN y CIDR con la precisión de la subred del cliente.
TR7 puede tener en cuenta la información de subred del cliente en lugar de depender de la IP del resolver. Esto reduce el riesgo de que los clientes que usan resolvers públicos sean dirigidos a la región equivocada. Las decisiones DNS geográficas se acercan más a la red real del usuario. Esto es especialmente crítico para una selección precisa de DC en servicios con tráfico de usuario global.
La granularidad por país permite producir respuestas DNS diferentes según el código de país del cliente. La selección de centro de datos puede adaptarse a Europa, Turquía, Oriente Medio o un país específico. El control por país es importante para instituciones financieras, organizaciones del sector público y entornos con requisitos de residencia de datos. Los códigos de país se normalizan para una coincidencia más consistente.
La granularidad por continente permite dirigir clientes a distintos grupos de registros a nivel de continente. Pueden definirse conjuntos separados de PoP o DC para Europa, Asia, Norteamérica u otras regiones. Este enfoque ofrece una solución simple cuando no se requiere el detalle por país pero importa la proximidad regional. Es útil en escenarios de SaaS global y entrega de contenido.
La granularidad por ciudad asocia usuarios de ciudades específicas a registros distintos. Pueden producirse landing pages, PoP de borde o respuestas de centro de datos separadas para Estambul, Ankara u otras ciudades. Esto es útil para campañas locales, cumplimiento a nivel de ciudad u objetivos de distribución de tráfico de baja latencia. La información de ciudad se evalúa usando la base de datos GeoIP offline.
La granularidad de red/CIDR permite definir respuestas DNS personalizadas para bloques de red IPv4 o IPv6 específicos. Las subredes de clientes empresariales, redes de partner, rangos de operadora privados o bloques de acceso interno pueden separarse de esta forma. El routing a nivel CIDR es más determinista que por país o ciudad. Es potente para endpoints por cliente o para selección de DC de peering.
La granularidad por ASN selecciona una respuesta DNS basándose en el operador o propietario de red al que está conectado el cliente. Pueden devolverse registros de DC separados para operadores de telco específicos, redes ISP o preferencias de peering de CDN. Este enfoque genera valor donde distintos operadores dentro del mismo país tienen calidad de red distinta. El tráfico se enruta según la topología real de red en lugar de una frontera nacional.
El comportamiento de negación puede aplicarse a cualquier regla de topología. Esto permite reglas inversas como "cada país excepto este", "cada ASN excepto este" o "cada red excepto este CIDR". La lógica de exclusión es útil para enforcement, separación de acceso, entrega de IP alternativa o escenarios de exclusión de regiones de alto riesgo. Los operadores pueden construir tanto políticas de coincidencia como de exclusión.
Si la regla de topología geográfica no produce candidatos de registro, puede activarse fallbackRecords. Estos registros pueden representar un DC por defecto, un servicio de mantenimiento o un endpoint global. El comportamiento de fallback garantiza una respuesta controlada de último recurso en lugar de una respuesta DNS vacía o inesperada. Esto es especialmente importante para regiones nuevas o coincidencias GeoIP ausentes.
TR7 puede definir políticas de topología independientes para cada registro. Bajo el mismo dominio, los registros A, los registros AAAA o registros de servicio distintos pueden operar con decisiones geográficas distintas. Esto permite aplicar estrategias de routing distintas a distintos componentes de aplicación bajo un único dominio. Los operadores gestionan el comportamiento de topología a nivel de registro en lugar de globalmente.
Una coincidencia geográfica puede producir múltiples candidatos de registro. TR7 puede entonces seleccionar entre esos candidatos usando comportamientos de selector como all, closest, round-robin, weighted round-robin, random o weighted random. El filtrado geográfico y la distribución de carga se combinan así en la misma cadena. Por ejemplo, puede aplicarse selección ponderada entre dos DCs del mismo país.
Las bases de datos ASN, City y Country se almacenan en el dispositivo y las decisiones geográficas se toman localmente. El contexto de consulta DNS nunca se envía a una API GeoIP externa. Esto es una ventaja importante para organizaciones con expectativas de privacidad de consulta y residencia de datos. El flujo de actualización debería planificarse por separado; el comportamiento de la página se basa en el modelo de decisión offline.
El valor TTL de cada registro DNS afecta al comportamiento del routing geográfico. Un TTL más corto ofrece ventajas para cambios de política rápidos y failover; un TTL más largo reduce la carga sobre la caché del resolver. Al diseñar routing geo, el TTL, la salud de los DCs y los objetivos de distribución de tráfico deben planificarse conjuntamente. El operador fija el balance entre rendimiento y velocidad de cambio.
El routing geográfico DNS se opera junto con los tipos de regla de topología, campos normalizados, comportamiento de renderizado de CIDR, lógica de fallback y límites de ejecución de Lua.
El pipeline de decisión de topología usa los tipos de regla network, country, city, continent y ASN. Cada tipo de regla puede evaluarse con comportamiento positivo o de negación. Esta estructura permite combinar múltiples dimensiones de decisión geográfica dentro del mismo registro.
Los códigos de país y continente se ponen en minúsculas antes de la comparación. Esto evita que diferencias de mayúsculas y minúsculas en distintas fuentes rompan coincidencias. Los valores normalizados hacen la autoría de política más consistente.
Las reglas de red evalúan IP y CIDR conjuntamente. Si no se especifica CIDR, puede usarse el comportamiento de precisión por IP para IPv4. Este modelo permite que tanto bloques de red privados como objetivos IP únicos se gestionen dentro de la misma estructura de política.
TR7 puede tomar decisiones geográficas usando bases de datos ASN, City y Country. Estas tres fuentes de datos forman la base de las decisiones por ASN, ciudad, país y continente. Como las bases de datos residen en el dispositivo, las decisiones en tiempo de ejecución no dependen de un servicio externo.
Si la evaluación de topología no produce candidatos de registro, se comprueba fallbackRecords. Si existe un fallback, puede producirse una respuesta final con estado failSafe. Si no se ha definido un fallback, puede producirse una respuesta DNS vacía o estándar — por lo tanto se recomienda un plan de fallback para todos los registros de producción.
La selección de topología se ejecuta a través de un pipeline de decisión basado en Lua. Los límites de ejecución y los intervalos de health check ayudan a mantener las decisiones DNS deterministas y controladas. Debe considerarse el impacto de rendimiento para conjuntos de reglas muy complejos.
Pueden devolverse distintos registros de DC de peering para distintas redes de operador en Turquía. La regla de topología por ASN ayuda a dirigir a usuarios dentro del mismo país a un camino de red más preciso.
Pueden definirse distintos objetivos de cumplimiento o residencia de datos para países como Alemania, Francia o Italia. La regla por país devuelve el registro de DC adecuado según el país del cliente.
Los servicios globales pueden dirigir clientes al PoP o grupo de centros de datos más adecuado a nivel de continente. Las reglas por continente y el comportamiento de selector pueden combinarse para una distribución regional de carga.
Con el flag de negación, pueden devolverse distintos registros a clientes fuera de países, ASNs o CIDRs específicos. Este modelo es útil para enforcement, licencias, cumplimiento o separación de regiones de alto riesgo.
Puede devolverse una IP de landing page personalizada a usuarios de ciudades como Estambul o Ankara. La regla por ciudad proporciona routing preciso a nivel DNS para escenarios de marketing y entrega de servicios locales.
Routing geográfico DNS con EDNS Client Subnet, reglas de topología en cinco dimensiones y GeoIP offline. Hagamos un recorrido en vivo sobre su propia infraestructura.