Disclaimer: nessuna offesa, ma questa è una pessima idea. Non consiglio a nessuno di farlo nella vita reale.
Ma se dai a un ragazzo IT annoiato un laboratorio, accadranno cose divertenti!
Per questo esperimento, ho usato un server DNS Microsoft in esecuzione su Server 2012 R2. A causa delle complicazioni legate all'hosting di una zona DNS in Active Directory, ho creato una nuova zona primaria denominata testing.com che non è integrata con AD.
Usando questo 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
}
}
}
Ho proceduto a creare, senza errori, 65025 record host per il nome testing.testing.com., con letteralmente ogni indirizzo IPv4 dall'1.1.1.1 all'1.1.255.255.
Quindi, volevo assicurarmi di poter superare 65536 (2 ^ 16 bit) numero totale di record A senza errori, e potrei, quindi suppongo che probabilmente avrei potuto arrivare fino al 16581375 (dall'1.1.1.1 al 1.255 .255.255), ma non volevo sedermi qui e guardare questa sceneggiatura girare tutta la notte.
Quindi penso che sia sicuro affermare che non esiste un limite pratico al numero di record A che è possibile aggiungere a una zona con lo stesso nome con IP diversi sul server.
Ma sarà davvero lavorare dal punto di vista di un cliente?
Ecco cosa ottengo dal mio cliente visto da Wireshark:
(Apri l'immagine in una nuova scheda del browser per ingrandirla.)
Come puoi vedere, quando utilizzo nslookup o il ping dal mio client, genera automaticamente due query: una UDP e una TCP. Come già sapete, il massimo che posso inserire in un datagramma UDP è di 512 byte, quindi una volta superato tale limite (come 20-30 indirizzi IP), è necessario utilizzare TCP. Ma anche con TCP, ho solo un piccolo sottoinsieme di record A per testing.testing.com. Sono stati restituiti 1000 record per query TCP. L'elenco dei record A ruota di 1 correttamente con ogni query successiva, esattamente come ci si aspetterebbe dal funzionamento del DNS round robin. Ci vorrebbero milioni di domande per completare il robin in tutti questi modi.
Non vedo come questo ti aiuterà a rendere la tua rete di social media estremamente scalabile e resiliente, ma c'è comunque la tua risposta.
Modifica: nel tuo commento di follow-up, chiedi perché penso che questa sia generalmente una cattiva idea.
Supponiamo che io sia un utente medio di Internet e vorrei collegarmi al tuo servizio. Digito www.bozho.biz nel mio browser web. Il client DNS sul mio computer ottiene 1000 record. Bene, sfortuna, i primi 30 record dell'elenco non rispondono perché l'elenco dei record A non è aggiornato, o forse c'è un'interruzione su larga scala che colpisce un pezzo di Internet. Supponiamo che il mio browser abbia un timeout di 5 secondi per IP prima di andare avanti e provare quello successivo. Quindi ora sono seduto qui a fissare una clessidra rotante per 2 minuti e mezzo in attesa che il tuo sito si carichi. Nessuno ha tempo per quello. E sto solo supponendo che il mio browser o qualsiasi altra applicazione che utilizzo per accedere al tuo servizio tenterà persino di più dei primi 4 o 5 indirizzi IP. Probabilmente no.
Se hai utilizzato lo scavenging automatico e consenti aggiornamenti non convalidati o anonimi alla zona DNS nella speranza di mantenere aggiornato l'elenco dei record A ... immagina quanto sarebbe insicuro! Anche se hai progettato un sistema in cui i client necessitavano di un certificato TLS client che ti avevano ricevuto in anticipo per aggiornare la zona, un client compromesso in qualsiasi parte del pianeta avvierà una botnet e distruggerà il tuo servizio. Il DNS tradizionale è precariamente insicuro com'è, senza procurarsi il crowdsourcing.
Enorme utilizzo e spreco della larghezza di banda. Se ogni query DNS richiede 32 kilobyte o più di larghezza di banda, questo non si ridimensionerà affatto.
Il round robin DNS non sostituisce il corretto bilanciamento del carico. Non fornisce alcun modo per recuperare da un nodo che scende o diventa non disponibile nel mezzo delle cose. Istruirai i tuoi utenti a fare un ipconfig / flushdns se il nodo a cui erano connessi si spegne? Questo tipo di problemi sono già stati risolti da cose come GSLB e Anycast.
Eccetera.