¿Cuál es el número máximo de IP que puede tener un registro DNS A?

Tengo una idea extraña: dejar que varias personas / organizaciones alojen la misma aplicación y que todos sus nodos sean accesibles a través de un solo nombre de dominio. Eso es para tener, digamos, una red social realmente distribuida, donde la usabilidad no se sacrifica (es decir, los usuarios no tienen que recordar diferentes URL de proveedores y luego, cuando un proveedor deja de funcionar, cambia a otro)

Para lograr eso, pensé que se puede usar un registro DNS con múltiples IP.

Entonces, ¿cuántas IP puede contener un solo registro DNS A? Esta respuesta dice que son alrededor de 30, pero el caso de uso allí es diferente. Para el escenario anterior, no me importaría si un ISP dado almacena en caché solo 30, siempre que otro ISP guarde en caché otros 30, y así sucesivamente.

Descargo de responsabilidad: Sin ofender, pero esta es una muy mala idea. No recomiendo que nadie haga esto en la vida real.

Pero si le das un laboratorio de TI aburrido, ¡cosas divertidas sucederán!

Para este experimento, utilicé un servidor DNS de Microsoft que se ejecuta en Server 2012 R2. Debido a las complicaciones de alojar una zona DNS en Active Directory, creé una nueva zona primaria llamada testing.com que no está integrada con AD.

Usando este script:

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

Procedí a crear, sin error, 65025 registros de host para el nombre testing.testing.com., literalmente con cada dirección IPv4 de 1.1.1.1 a 1.1.255.255.

Entonces, quería asegurarme de que podía romper 65536 (2 ^ 16 bits) el número total de registros A sin error, y podía, así que supongo que probablemente podría haber ido hasta 16581375 (1.1.1.1 a 1.255 .255.255,) pero no quería sentarme aquí y ver este script ejecutarse toda la noche.

Por lo tanto, creo que es seguro decir que no hay un límite práctico para la cantidad de registros A que puede agregar a una zona para el mismo nombre con diferentes IP en su servidor.

Pero, ¿realmente trabajar desde la perspectiva de un cliente?

Esto es lo que obtengo de mi cliente como lo ve Wireshark:

(Abra la imagen en una nueva pestaña del navegador a tamaño completo).

Como puede ver, cuando uso nslookup o ping desde mi cliente, automáticamente emite dos consultas: una UDP y una TCP. Como ya sabe, lo máximo que puedo meter en un datagrama UDP es 512 bytes, por lo que una vez que se excede ese límite (como 20-30 direcciones IP), uno debe usar TCP en su lugar. Pero incluso con TCP, solo obtengo un subconjunto muy pequeño de registros A para testing.testing.com. Se devolvieron 1000 registros por consulta TCP. La lista de registros A gira en 1 correctamente con cada consulta sucesiva, exactamente como esperaría que funcionara el DNS round-robin. Se necesitarían millones de consultas para resolver todos estos problemas.

No veo cómo esto te ayudará a hacer que tu red de medios sociales sea más escalable y resistente, pero de todos modos tienes tu respuesta.

Editar: en su comentario de seguimiento, pregunta por qué creo que esto es generalmente una mala idea.

• Digamos que soy un usuario promedio de Internet y me gustaría conectarme a su servicio. Escribo www.bozho.biz en mi navegador web. El cliente DNS en mi computadora recupera 1000 registros. Bueno, mala suerte, los primeros 30 registros de la lista no responden porque la lista de registros A no se mantiene actualizada, o tal vez hay una interrupción a gran escala que afecta una gran parte de Internet. Digamos que mi navegador web tiene un tiempo de espera de 5 segundos por IP antes de continuar y probar el siguiente. Así que ahora estoy sentado aquí mirando un reloj de arena giratorio durante 2 minutos y medio esperando que se cargue su sitio. Nadie tiene tiempo para eso. Y solo estoy asumiendo que mi navegador web o cualquier aplicación que use para acceder a su servicio incluso va a intentar más que las primeras 4 o 5 direcciones IP. Probablemente no lo hará.

• Si utilizó la búsqueda automática y permitió actualizaciones no validadas o anónimas de la zona DNS con la esperanza de mantener actualizada la lista de registros A ... ¡solo imagine lo inseguro que sería! Incluso si diseñó algún sistema donde los clientes necesitaban un certificado TLS de cliente que obtuvieron de usted de antemano para actualizar la zona, un cliente comprometido en cualquier parte del planeta iniciará una botnet y destruirá su servicio. El DNS tradicional es precariamente inseguro tal como es, sin que sea fuente de multitud.

• Uso y desperdicio de ancho de banda enorme. Si cada consulta DNS requiere 32 kilobytes o más de ancho de banda, eso no va a escalar en absoluto.

• DNS round-robin no sustituye el equilibrio de carga adecuado. No proporciona forma de recuperarse de un nodo que se cae o no está disponible en medio de las cosas. ¿Va a indicar a sus usuarios que hagan un ipconfig / flushdns si el nodo al que estaban conectados se cae? Este tipo de problemas ya han sido resueltos por cosas como GSLB y Anycast.

• Etc.

Para responder la pregunta como se dijo ("¿cuántas IP puede contener un solo registro DNS A?") La respuesta es muy simple: un solo Aregistro contiene exactamente una dirección. Sin embargo, puede haber múltiples Aregistros para el mismo nombre.

Cada dirección IPv4 ocupará 16 bytes en la respuesta. Cada dirección IPv6 ocupará 28 bytes en la respuesta.

Se recomienda encarecidamente que se asegure de que la respuesta se ajuste a 512 bytes. Eso permitiría unas 25 direcciones IPv4 y 14 direcciones IPv6 (teniendo en cuenta que también necesita alguna otra información en el paquete). El límite exacto depende de la longitud de su nombre de dominio.

Si tiene 25 direcciones IPv4 y 14 direcciones IPv6, entonces cuenta con los clientes que solicitan direcciones IPv4 e IPv6 en consultas separadas. Si el cliente solicita ambos tipos de direcciones en una sola consulta (lo cual es raro), entonces tendría que ir más abajo.

Si el tamaño de respuesta supera los 512 bytes, aún puede funcionar a través de UDP si el cliente y el servidor admiten EDNS. Sin EDNS, el cliente recibiría una respuesta truncada y tendría que volver a intentarlo a través de TCP. Esto aumenta la comunicación de 1 a 4 viajes de ida y vuelta. Pero aún peor, a veces hay configuraciones erróneas que impiden que DNS sobre TCP funcione.

Incluso si pudiera incluir más de 14 direcciones en la respuesta sin causar problemas en la capa DNS, es poco probable que sea muy útil. El tiempo de espera utilizado por el cliente antes de renunciar a una dirección y pasar a la siguiente es a menudo significativo.

Tener que esperar ese tiempo de espera incluso una vez puede conducir a una mala experiencia del usuario. Si el cliente tuviera que pasar por 14 direcciones antes de obtener una respuesta, el usuario tendría que esperar 13 tiempos de espera.

Lo que estás describiendo no es una idea especialmente nueva. Como otras respuestas ya han cubierto, usted está limitado en cuántos registros A puede tener en una respuesta, pero eso no dice nada sobre cuántos registros A podría haber en total.

Podría, por ejemplo, implementar un servidor DNS que responda cualquier consulta para un registro A con una IP aleatoria. Consultado suficientes veces, esto daría como resultado 4294967296 registros A únicos: uno para cada dirección IPv4.

Como dije, esta no es una idea nueva. De hecho, es en parte cómo funciona Akamai (y probablemente muchos otros CDN). El registro A que obtienes para cualquier dominio de Akamai está determinado por sus servidores DNS de magia negra. Apuesto a que la respuesta que obtienes depende del equilibrio dinámico de carga y las preocupaciones geográficas.

Por ejemplo, elegí a338.g.akamaitech.net. Si miro eso en mi computadora ahora mismo, que usa un servidor de nombres asignado por DHCP de Comcast:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

¿Qué pasa si le pregunto al DNS de Google?

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

Apuesto a que si lo intentas, apuesto a que obtendrás una respuesta diferente. ¿Cuántos servidores perimetrales tiene Akamai al servicio de un recurso en particular? Más de dos, apuesto.

Otros lo han mencionado como un detalle, pero desde un punto de vista práctico, el límite rígido es el límite de tamaño de paquete UDP de 512 bytes. Si bien es posible cambiar a TCP cuando se detecta el truncamiento, en la práctica muchos / la mayoría de los clientes no lo harán (y posiblemente no deberían hacerlo; daría una mala experiencia de usuario para la mayoría de las aplicaciones, y solo esperaría transferencias de zona u otros búsquedas especiales para soportar TCP). Entonces, está buscando un límite de alrededor de 30 direcciones para IPv4 (registros A) y algo menos para IPv6 (AAAA) ya que son más grandes. La longitud del nombre de dominio se reduce a esto y limitará aún más el número.

La respuesta corta: unos 25 registros A caben en un paquete UDP. Más allá de eso, DNS cambiará a TCP y no será tan rápido. También tendrá problemas con los clientes que no están utilizando resolvers DNS capaces de elegir la IP "más cercana". Además, con wifi y dispositivos móviles, el "más cercano" a menudo no será el servidor adecuado.

Respuesta más larga:

No hagas eso. Una mejor manera sería configurar registros CNAME individuales para cada usuario que apunte al servidor apropiado. Supongamos que tiene dos servidores server-fy los server-rutiliza para IMAP. Configure el cliente IMAP de cada persona con el nombre del servidor como USERNAME.imap.example.com donde "USERNAME" se reemplaza por su nombre de usuario de correo electrónico. Ahora puede mover personas entre servidores sin tener que volver a configurar su cliente de correo electrónico.

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

Sin embargo, si hace esto, le recomiendo que genere los registros DNS automáticamente a partir de una base de datos de usuarios. Desea asegurarse de que a medida que se crean y eliminan cuentas, los registros DNS también se crean y eliminan. De lo contrario, terminarás con un desastre y mucha confusión.

He visto esto en compañías con literalmente miles de usuarios y, dado que las cosas estaban automatizadas, el mundo está muy bien.

Como otros han señalado, es una idea terrible para el uso en el mundo real.

En el mundo real, hay clientes y solucionadores no conformes que tienen problemas con las respuestas que no pueden caber dentro de un solo datagrama UDP, y hay cortafuegos que impondrán ideas específicas pero no compatibles con el protocolo sobre los límites de tamaño de los mensajes DNS.

E incluso si pudieras contar con tu gran respuesta en todos los casos (que no puedes enfáticamente) hay otra razón por la que esta es una muy mala idea. Cuanto mayor sea el tamaño de la respuesta de DNS, más tentador es como carga útil para los ataques de reflexión porque proporciona un gran factor de amplificación. En este tipo de ataque de denegación de servicio, que es común en DNS, se envía una consulta UDP a un resolutor recursivo abierto. La dirección de origen de las consultas UDP generalmente se falsifica fácilmente, y el atacante establece el origen de la consulta en la IP de su destino previsto. Se logran dos efectos deseables (para el atacante): primero: un esfuerzo de envío relativamente pequeño de su parte (a partir de una pequeña consulta falsificada) da como resultado un torrente relativamente grande de tráfico no deseado que llega al objetivo (este es el factor de amplificación), y segundo: la fuente real del ataque está oculta del objetivo; el objetivo solo conoce las direcciones de los resolvers recursivos que se usan como reflectores.

Punto interesante de curiosidades históricas sobre este tema. En los años 90, AOL expandió sus registros DNS de tal manera que una consulta MX devolvería> 512 bytes. Esto violó RFC, rompió muchos servidores SMTP (qmail era popular en ese momento) y causó muchos dolores de cabeza a los administradores de sistemas. La corrección requería parches o agregar rutas estáticas.

No sé cuál es la situación actual, pero hace unos años, cuando toqué por última vez qmail, los parches todavía estaban en su lugar.

http://www.gossamer-threads.com/lists/qmail/users/30503