¿Podría un servidor de nombres resolver direcciones IP dinámicamente en función de alguna estrategia?

11

Hemos registrado algunos servidores de nombres para la resolución de DNS para nuestro sitio web que se implementa en varios centros de datos.

Nuestra estrategia actual de resolución de DNS es que, en función de las diferentes direcciones IP del cliente, el servidor de nombres devolverá diferentes direcciones IP para el mismo dominio. Por ejemplo, si la dirección IP del cliente es de América del Norte, el servidor de nombres devolverá una dirección IP que es la dirección IP de nuestro centro de datos de América del Norte.

Pero la dirección IP del cliente a veces no es la dirección IP real de los usuarios. Puede ser una dirección IP de DNS que pertenece a un ISP o un servidor proxy. Por otro lado, si uno de nuestros centros de datos está inactivo, queremos que nuestro servidor de nombres excluya esa dirección IP que pertenece al centro de datos bloqueado. Así que esperamos poder obtener una estrategia más dinámica para nuestra resolución de DNS. ¿Hay una solución para eso?

networking  domain-name-system 
— yifan
fuente
Esto suena como un caso para anycast.
— Ron Maupin el
1
@RonMaupin Cabe señalar que para realizar cualquier difusión, uno debe tener una asignación de bloqueo de dirección de proveedor independiente y, lo que es más importante, ejecutar BGP para anunciar los prefijos de cada centro de datos. Ese es un nivel completamente nuevo de operaciones y no es algo con lo que muchas compañías "orientadas al contenido" tendrían experiencia. La solución basada en DNS parece mucho más fácil.
— IPX
@IPX, me imagino que una empresa con centros de datos en todo el mundo, como parece en la pregunta, tendrá un direccionamiento independiente del proveedor y su propio número AS. Con eso, anycast es gratis y fácil.
— Ron Maupin el
1
@RonMaupin si la compañía del OP realmente operaba múltiples centros de datos en todo el mundo, entonces sí, pero probablemente no estarían haciendo una pregunta relativamente simple aquí. Apuesto a que simplemente ubican su propio HW contratado en varios centros de datos comerciales y realmente no se preocupan por las operaciones de red avanzadas. Eso es lo que he visto que muchas empresas medianas hacen por redundancia. Si ese es el caso, DNS es la respuesta, no el enrutamiento .
— IPX
@IPX, lo que deduzco de la pregunta es que la compañía tiene centros de datos en todo el mundo, y si un centro de datos falla, el tráfico dirigido debe dirigirse a un centro de datos diferente (" si uno de nuestros centros de datos está caído ... . "). Simplemente respondí la pregunta como se me preguntó, en lugar de tratar de adivinar sobre el alojamiento de terceros, y también hacemos algo de eso, pero aún tenemos nuestro propio direccionamiento independiente del proveedor y el número de AS utilizado para emparejar con los ISP. Eso permite la negociación de contratos y el cambio de ISP sin interrupción de red de direccionamiento.
— Ron Maupin

Respuestas:

16

Parece que quieres anycast. Ese es el tipo de cosas que usan sitios como Google. Tiene una única dirección (resuelta por DNS) para todos sus sitios web y permite que el protocolo de enrutamiento de Internet (BGP) dirija a los usuarios al sitio más cercano (mediante el protocolo de enrutamiento). Si un sitio deja de funcionar, BGP coloca automáticamente el siguiente sitio más cercano en la tabla de enrutamiento de Internet.

El ejemplo clásico es 8.8.8.8para DNS. Se resuelve en diferentes ubicaciones en todo el mundo, y si una ubicación se cae, se dirige a la siguiente ubicación más cercana.

La respuesta no es DNS, es enrutamiento.

— Ron Maupin
fuente
2
Anycast normalmente no es útil para protocolos basados ​​en TCP, porque los paquetes que pertenecen a la misma conexión pueden ir a diferentes servidores.
— Paŭlo Ebermann
2
@ PaŭloEbermann que no es un problema cuando lo hace con el enrutamiento BGP, ya que las rutas generalmente no cambian cuando se anuncian (solo cambios menores)
— Ferrybig
2
@ PaŭloEbermann Puede hacer cualquier transmisión a través de equilibradores de carga basados ​​en DSR siempre que todos sus equilibradores de carga acuerden cómo elegir backends.
— kasperd el
3
@ PaŭloEbermann, eso es un error. Todo el tráfico de un host irá a un servidor, a menos que ese servidor se caiga, entonces el tráfico se dirigirá a un servidor diferente. Sí, eso interrumpiría la conexión TCP, pero ese sería el caso cada vez que el servidor al que está conectado se caiga. Anycast no es un tipo de cosa de todos contra todos. El enrutamiento es determinista, por lo que cualquier difusión es determinista.
— Ron Maupin
2
El enrutamiento de @RonMaupin Anycast no es tan estable como implica. Y Google no usa ninguna difusión de la manera que usted dice. Si desea saber cómo Google realmente hace esto, eche un vistazo a la página 227 del Libro de trabajo de confiabilidad del sitio publicado por Google. En resumen, la capa de equilibrio de carga detrás del enrutamiento anycast compensa los cambios inevitables en el enrutamiento que de otro modo romperían las conexiones TCP.
— kasperd el
9

Lo que necesita es exactamente lo que ofrece el servicio DNS de Amazon Route53 :

No es necesario que aloje su sitio web en AWS para poder usar Route53, funcionará felizmente con los servicios implementados en centros de datos privados.

A menos que sea un precio de Facebook o Google, tampoco debería ser un problema, a partir de $ 0,40 por millón de solicitudes (ver detalles de precios ).

Espero que ayude :)

— MLu
fuente
¿Alguna vez ha utilizado productos que no sean de Amazon para esto?
— pollitos
@chicks no, no lo he hecho. Siempre tiendo a usar la mejor herramienta para el trabajo y Route53 cumple con los requisitos en la mayoría de los casos. Sin embargo, si buscas en Google algo como "servicio de geo dns" obtendrás algunas opciones. Rápidamente miré algunos, pero parecen bastante caros (alrededor de $ 50 / mes, mucho más de lo que probablemente gastaría con AWS Route53).
— MLu
2
Ampliaría mi perspectiva un poco más antes de llamar a la primera herramienta que encontré la mejor herramienta para la mayoría de los casos. Route53 podría ser el mejor para todos, pero ¿cómo podría saber si no ha intentado nada más?
— pollitos
-1

Tuve esta idea y comencé a codificarla, pero nunca terminé ya que la necesidad se evaporó primero.

El servidor DNS tiene los nombres de host y las direcciones MAC de todas las máquinas en su LAN y una forma de comunicarse con ellos. Cuando recibe una solicitud de una máquina que conoce, envía un ARP inverso para la dirección IP dada la dirección MAC y usa la respuesta para construir la respuesta DNS.

Esto no tiene nada que ver con lo que está tratando de hacer, pero ilustra el punto. En teoría, un servidor DNS puede codificarse para llevar a cabo cualquier esquema novedoso que desee resolver nombres a direcciones IP.

La pregunta real parece ser cómo obtener la dirección IP del cliente para decidir dónde enviarlos. Este es un pequeño problema de XY. Lo que realmente desea es que el ISP del cliente se geolocalice, y puede obtenerlo al hacerlo directamente desde la dirección IP que realiza la solicitud, suponiendo que no sea 8.8.4.4 o algún otro servicio de redireccionamiento de DNS. En mi opinión, la mejor solución para los redireccionadores de DNS es ignorar el problema y realizar una geolocalización autorreferente (es decir, desde el servidor DNS intenta localizar la dirección IP de llamada) y redirigir adecuadamente. Vea aquí cómo geolocalizar: /programming/2574542/location-detecting-techniques-for-ip-addresses

Realmente no quieres ninguna transmisión aquí sino algo más cuerdo. Anycast tiene la molesta propiedad de que puede redirigir paquetes en el medio de su flujo TCP causando confusión masiva.

Ron Maupin afirma que anycast es de ruta confiable para TCP. Aquí está el traceroute que muestra lo contrario:

 3  cr1-rhe-a-be153.bb.as11404.net (174.127.183.14)  20.657 ms  20.763 ms  19.660 ms
 4  cr1-che-b-be-2.as11404.net (192.175.29.161)  22.550 ms  23.562 ms  23.538 ms
 5  * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108)  24.409 ms  38.083 ms
 6  72.14.222.146 (72.14.222.146)  40.038 ms  39.106 ms  39.125 ms
 7  108.170.242.225 (108.170.242.225)  37.930 ms 108.170.243.1 (108.170.243.1)  35.434 ms 108.170.242.225 (108.170.242.225)  33.694 ms
 8  209.85.240.249 (209.85.240.249)  33.476 ms 108.170.232.65 (108.170.232.65)  31.683 ms 108.170.234.155 (108.170.234.155)  30.754 ms
 9  google-public-dns-b.google.com (8.8.4.4)  30.491 ms  28.644 ms  25.718 ms

Si intenta geolocalizar las direcciones IP aguas arriba de la manera obvia, ambas están en Wichita. Esto no es correcto por lo que bastará una simple demostración de física.

El rango de 8.8.4.4 se mide a 30 ms, de los cuales los primeros 18 ms son la penalización local (el salto 3 es el enrutador local de mi ISP). Mi distancia a Wichita es de 1297 millas. Por lo tanto, el tiempo mínimo de ida y vuelta es (1297 * 2 millas / 225,000 kilómetros por segundo (velocidad de la luz en el vidrio)) que es 18.55ms. Por lo tanto, no debería obtener una respuesta más rápida que 28 ms, pero recibí una en 25 ms.

Los paquetes llegan a Google por dos rutas BGP diferentes. BGP no eligió el más cercano.

— joshudson
fuente
— yifan
Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
— Ward - Restablece a Monica
Moví todos los comentarios al chat, pero como había muchos y algunos se movieron automáticamente, no estoy seguro de si el chat posterior los tiene todos. En cualquier caso, una discusión adicional sobre la validez de esta respuesta y cómo funcionan los enrutadores, etc., no debería estar en los comentarios, manténgala en una de las salas de chat. Cualquier comentario adicional aquí será eliminado.
— Ward - Restablece a Monica
-2

Lo que necesita podría lograrse con alguna combinación de DNS anycast y RFC-7871.

— Edheldil
fuente
1
Más detalles mejorarían su respuesta
— Dave M
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.