Uwaga: Bez obrazy, ale to naprawdę zły pomysł. Nie polecam nikomu robić tego w prawdziwym życiu.
Ale jeśli dasz znudzonemu IT pracownikowi laboratorium, wydarzy się coś śmiesznego!
Do tego eksperymentu użyłem serwera Microsoft DNS działającego na serwerze 2012 R2. Z powodu komplikacji związanych z hostowaniem strefy DNS w usłudze Active Directory utworzyłem nową strefę podstawową o nazwie testing.com, która nie jest zintegrowana z usługą AD.
Za pomocą tego skryptu:
$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
}
}
}
Zacząłem bezbłędnie tworzyć rekordy hosta 65025 dla nazwy testing.testing.com., z dosłownie każdym adresem IPv4 od 1.1.1.1 do 1.1.255.255.
Następnie chciałem się upewnić, że mogę przebić się przez 65536 (2 ^ 16 bitów) całkowitej liczby rekordów A bez błędów, i mogłem, więc zakładam, że prawdopodobnie mogłem przejść do 16581375 (od 1.1.1.1 do 1.255) .255.255), ale nie chciałem tu siedzieć i patrzeć, jak skrypt działa przez całą noc.
Myślę więc, że można bezpiecznie powiedzieć, że nie ma praktycznego ograniczenia liczby rekordów A, które można dodać do strefy o tej samej nazwie i różnych adresach IP na serwerze.
Ale czy rzeczywiście zadziała z perspektywy klienta?
Oto, co otrzymuję od mojego klienta oglądanego przez Wireshark:
(Otwórz obraz w nowej karcie przeglądarki dla pełnego rozmiaru.)
Jak widać, kiedy używam nslookup lub ping od mojego klienta, automatycznie wysyła dwa zapytania - jedno UDP i jedno TCP. Jak już wiesz, najbardziej mogę wcisnąć do datagramu UDP 512 bajtów, więc po przekroczeniu tego limitu (np. 20-30 adresów IP) należy zamiast tego użyć TCP. Ale nawet w przypadku TCP otrzymuję tylko niewielki podzbiór rekordów A do testowania.testing.com. 1000 rekordów zostało zwróconych na zapytanie TCP. Lista rekordów A obraca się odpowiednio o 1 z każdym kolejnym zapytaniem, dokładnie tak, jak można oczekiwać od działania DNS w systemie round-robin. Obejrzenie wszystkich tych elementów wymagałoby milionów zapytań.
Nie rozumiem, w jaki sposób pomoże ci to stworzyć ogromnie skalowalną i odporną sieć mediów społecznościowych, ale jest na to odpowiedź.
Edycja: W kolejnym komentarzu pytasz, dlaczego moim zdaniem jest to zły pomysł.
Załóżmy, że jestem przeciętnym użytkownikiem Internetu i chciałbym połączyć się z Twoją usługą. W przeglądarce internetowej wpisuję www.bozho.biz. Klient DNS na moim komputerze otrzymuje 1000 rekordów. Cóż, nieszczęście, pierwsze 30 rekordów na liście nie odpowiada, ponieważ lista rekordów A nie jest aktualizowana, a może nastąpiła awaria na dużą skalę, która wpływa na fragment Internetu. Powiedzmy, że moja przeglądarka ma limit czasu wynoszący 5 sekund na adres IP, zanim przejdzie do następnego i spróbuje następnego. Więc teraz siedzę tutaj i wpatruję się w wirującą klepsydrę przez 2 i pół minuty, czekając na załadowanie witryny. Nikt nie ma na to czasu. I po prostu zakładam, że moja przeglądarka internetowa lub jakakolwiek aplikacja, której używam do uzyskania dostępu do twojej usługi, spróbuje nawet użyć więcej niż pierwszych 4 lub 5 adresów IP. Prawdopodobnie nie będzie.
Jeśli korzystasz z automatycznego oczyszczania i zezwalasz na niezweryfikowane lub anonimowe aktualizacje strefy DNS w nadziei, że lista rekordów A będzie świeża ... wyobraź sobie, jak niepewna byłaby to sytuacja! Nawet jeśli zaprojektowałeś jakiś system, w którym klienci potrzebowali wcześniej otrzymanego od ciebie certyfikatu TLS w celu aktualizacji strefy, jeden skompromitowany klient w dowolnym miejscu na świecie uruchomi botnet i zniszczy twoją usługę. Tradycyjny system DNS jest niepewnie niepewny, bez pozyskiwania go przez tłum.
Ogromne wykorzystanie przepustowości i marnotrawstwo. Jeśli każde zapytanie DNS wymaga 32 kilobajtów lub więcej przepustowości, to wcale nie będzie dobrze skalować.
Round-robin DNS nie zastępuje prawidłowego równoważenia obciążenia. Nie zapewnia żadnego sposobu na odzyskanie po awarii jednego węzła lub niedostępności w środku rzeczy. Czy zamierzasz poinstruować użytkowników, aby wykonali polecenie ipconfig / flushdns, jeśli węzeł, z którym byli połączeni, ulegnie awarii? Tego rodzaju problemy zostały już rozwiązane przez takie rzeczy jak GSLB i Anycast.
Itp.