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.