Jaką maksymalną liczbę adresów IP może posiadać rekord DNS?

30

Mam dziwny pomysł - pozwól wielu osobom / organizacjom hostować tę samą aplikację i niech wszystkie ich węzły będą dostępne za pośrednictwem jednej nazwy domeny. Ma to na celu, powiedzmy, naprawdę rozproszoną sieć społecznościową, w której użyteczność nie jest poświęcana (tzn. Użytkownicy nie muszą pamiętać adresów URL różnych dostawców, a następnie, gdy jeden dostawca przestaje działać, przełącz się na inny)

Aby to osiągnąć, pomyślałem, że można użyć rekordu DNS z wieloma adresami IP.

Ile adresów IP może pomieścić pojedynczy rekord DNS A? Ta odpowiedź mówi, że jest około 30, ale przypadek użycia jest inny. W powyższym scenariuszu nie dbam o to, czy dany dostawca buforuje tylko 30, o ile inny dostawca buforuje kolejne 30 i tak dalej.

Bozho
źródło
2
Czy bierzesz pod uwagę Anycast ?
Lie Ryan,
4
Dowiedziałem się jakiś czas temu, że jeśli kiedykolwiek będziesz musiał zapytać „Jaka jest maksymalna liczba X?” prawdopodobnie używasz go źle ...
LordOfThePigs,
Niekoniecznie;) Ale ogólnie tak
Bozho

Odpowiedzi:

78

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.

Za dużo zapisów

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:

dwa zapytania (Otwórz obraz w nowej karcie przeglądarki dla pełnego rozmiaru.)

nslookup

Zapytanie TCP

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.

Ryan Ries
źródło
15
Powoli .... klaskać ..... proszę pana.
mfinni
4
Aby dodać do tego, jeśli kwerendy A są sprawdzane za pośrednictwem BIND (który działa na większości serwerów DNS), przetasuje rekordy A i zwróci z tego pewną liczbę rekordów A. Ta pewna liczba jest zdefiniowana w MAX_SHUFFLEkodzie źródłowym BIND (domyślnie 32).
ub3rst4r
1
Z ciekawości, dlaczego nie poleciłbyś tego? Z pewnością jest to bardzo dziwna rzecz, ale oprócz złośliwych węzłów obsługujących żądania w „dobrej” domenie i nieudanych węzłów wciąż otrzymujących żądania, co jeszcze może pójść nie tak :-)
Bozho
Czy wrażenia użytkownika nie będą się zmieniać? Czy każdy węzeł jest kompletną repliką? Jak byś upewnił się, że dzieje się tak, jeśli są pod kontrolą innych ludzi? Jeśli się różnią, ludzie otrzymają dziś jedną stronę, a jutro inną. Osobiście doprowadziłoby mnie to do szału!
Brandon
18

Aby odpowiedzieć na postawione pytanie („ile adresów IP może pomieścić jeden rekord DNS A?”) Odpowiedź jest bardzo prosta: pojedynczy Arekord zawiera dokładnie jeden adres. Może być jednak wiele Arekordów dla tej samej nazwy.

Håkan Lindqvist
źródło
10

Każdy adres IPv4 zajmie 16 bajtów w odpowiedzi. Każdy adres IPv6 zajmie 28 bajtów w odpowiedzi.

Zdecydowanie zaleca się upewnienie się, że odpowiedź zmieści się w 512 bajtach. Pozwoliłoby to na około 25 adresów IPv4 i 14 adresów IPv6 (biorąc pod uwagę, że potrzebujesz również innych informacji w pakiecie). Dokładny limit zależy od długości nazwy domeny.

Jeśli masz zarówno 25 adresów IPv4, jak i 14 adresów IPv6, to liczysz na klientów żądających adresów IPv4 i IPv6 w osobnych zapytaniach. Gdyby klient poprosił o oba typy adresów w jednym zapytaniu (co jest rzadkie), musiałbyś pójść niżej.

Jeśli rozmiar odpowiedzi przekracza 512 bajtów, może nadal działać przez UDP, jeśli klient i serwer obsługują EDNS. Bez EDNS klient otrzymałby skróconą odpowiedź i musiałby ponowić próbę przez TCP. Zwiększa to komunikację z 1 do 4 rund. Co gorsza, czasami zdarzają się niepoprawne konfiguracje uniemożliwiające działanie DNS przez TCP.

Nawet jeśli możesz wcisnąć do odpowiedzi więcej niż 14 adresów bez powodowania problemów na warstwie DNS, jest mało prawdopodobne, aby była bardzo przydatna. Limit czasu wykorzystywany przez klienta przed rezygnacją z jednego adresu i przejściem do następnego jest często znaczny.

Konieczność choćby jednokrotnego oczekiwania na ten limit czasu może prowadzić do obniżenia komfortu użytkowania. Gdyby klient musiał przejść przez 14 adresów przed uzyskaniem odpowiedzi, użytkownik musiałby czekać 13 limitów czasu.

kasperd
źródło
2
Obecnie każdy DNS powinien obsługiwać EDNS. Limit 512 bajtów odpowiedzi DNS nie jest już praktyczny z powodu DNSSEC.
Barmar,
@Barmar Ale jeśli go włączysz, istnieje całkiem spore ryzyko, że twój serwer zostanie wykorzystany w atakach wzmacniających. Ostatnim razem, gdy sprawdziłem, zauważyłem, że wyłączenie binda było jedyną rzeczą, którą można było zrobić, aby złagodzić ataki wzmacniające. Dopóki EDNS nie zostanie rozszerzony o pole plików cookie, a obsługa tego zostanie szeroko wdrożona, nadal zalecane jest wyłączenie obsługi odpowiedzi większych niż 512 bajtów.
kasperd
1
Naprawdę nie przeszkadzam w wynikach wyszukiwania za wyłączenie EDNS jako najlepszej praktyki. Cytaty proszę? Ataki wzmacniające wykorzystujące serwery rekurencyjne będą miały miejsce bez względu na to, czy EDNS jest włączony, jeśli twoja sieć nie sprawdza poprawności adresu źródłowego. Nawet jeśli mówimy o autorytatywnym serwerze, staje się on istotny dopiero po skonfigurowaniu go do zwracania tak dużej ilości danych w jednej odpowiedzi, w którym momencie wyłączenie go nie pomoże.
Andrew B,
@AndrewB Nie pamiętam, gdzie przeczytałem to zalecenie. Przeczytałem wiele różnych zaleceń, jak unikać ataków wzmacniających i wszystkie są do kitu. Szkoda, że ​​EDNS nie wprowadził pliku cookie, który mógłby być skutecznym rozwiązaniem ataków wzmacniających za pomocą DNS. W mojej odpowiedzi zalecam unikanie umieszczania w zapytaniu tylu rekordów, że poleganie na innych włącza EDNS, aby odpowiedzi były skuteczne.
kasperd
@AndrewB Jeśli umieszczę w strefie więcej niż 512 bajtów rekordów A i upewnię się, że są one hostowane na autorytatywnym serwerze DNS, na którym włączono EDNS, może to stanowić problem dla użytkowników rekurencyjnych programów tłumaczących, które nie zezwalają na tak duże odpowiedzi. I dlatego zalecam obniżenie liczby rekordów A. Ponadto wyjaśniłem, dlaczego postrzegana korzyść z tak wielu rekordów A nie jest tak istotna.
kasperd
5

To, co opisujesz, nie jest szczególnie nowym pomysłem. Jak już wspomniano inne odpowiedzi, masz ograniczoną liczbę rekordów A w jednej odpowiedzi, ale to nic nie mówi o tym, ile rekordów A może być w sumie.

Możesz na przykład zaimplementować serwer DNS, który odpowiada na każde zapytanie o rekord A z losowym adresem IP. Zapytano wystarczająco dużo razy, co spowodowałoby 4294967296 unikalnych rekordów A: jeden dla każdego adresu IPv4.

Jak powiedziałem, nie jest to nowy pomysł. W rzeczywistości po części działa to, w jaki sposób działa Akamai (i prawdopodobnie wiele innych CDN). Rekord A, który uzyskasz dla dowolnej domeny Akamai, zależy od ich czarnoskórych serwerów DNS. Założę się, że odpowiedź zależy od dynamicznego równoważenia obciążenia i problemów geograficznych.

Na przykład wybrałem a338.g.akamaitech.net. Jeśli teraz popatrzę na to na moim komputerze, który korzysta z serwera nazw przypisanego do DHCP z 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

Co jeśli zapytam DNS 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

Założę się, że jeśli spróbujesz, założę się, że otrzymasz inną odpowiedź. Ile serwerów brzegowych ma Akamai obsługujących określone zasoby? Więcej niż dwa, założę się.

Phil Frost
źródło
Dzięki. Tak, wiem, że CDN działają w ten sposób, ale moim zdaniem mają one ograniczoną liczbę rekordów na subdomenę (2 w twoim przykładzie). Moje inne ostatnie pytanie dotyczy dokładnie sieci CDN i ich implementacji DNS :-)
Bozho,
2

Inni wspominali o tym szczegółowo, ale z praktycznego punktu widzenia twardym ograniczeniem jest limit wielkości pakietu UDP wynoszący 512 bajtów. Chociaż możliwe jest przełączenie na TCP po wykryciu obcięcia, w praktyce wielu / większość klientów tego nie zrobi (i prawdopodobnie nie powinni tego robić; dałoby to złe wrażenia dla użytkowników dla większości aplikacji, i oczekiwałbym tylko przeniesień stref lub innych wyszukiwania specjalnego przeznaczenia do obsługi TCP). Więc patrzysz na limit około 30 adresów dla IPv4 (rekordy A) i nieco mniej dla IPv6 (AAAA), ponieważ są one większe. Długość nazwy domeny ogranicza się do tego i jeszcze bardziej ograniczy liczbę.

R ..
źródło
1
Masz całkowitą rację, że istnieje wiele źle zachowujących się klientów i resolverów, którzy nie obsługują poprawnie odpowiedzi DNS, które nie pasują do jednego datagramu UDP, ale porzuć pomysł, że tylko transfery stref lub nietypowe żądania wymagają większych rozmiarów odpowiedzi. Z Twojej odpowiedzi wyraźnie nie korzystasz z walidacji DNSSEC, ale wiele osób nie jest (ani DNSSEC nie jest jedynym powodem, dla którego potrzebne są większe odpowiedzi, ale jest to bardzo ważna).
Michael McNally
@MichaelMcNally: DNSSEC nie jest przeznaczony (przynajmniej nie przez implementatorów, opartych na wątkach na listach mailingowych glibc, w których byłem zaangażowany) do użycia w punktach końcowych (aplikacje wyszukujące DNS), ale na lokalnym rekurencyjnym serwerze nazw, który będzie robił wyszukiwania w imieniu aplikacji. Dlatego nawet przy konfiguracji DNSSEC nie ma powodu, aby oczekiwać, że aplikacje będą mówić DNS przez TCP. UDP działa idealnie dobrze.
R ..
1

Krótka odpowiedź: około 25 rekordów A mieści się w pakiecie UDP. Poza tym DNS przełączy się na TCP i nie będzie tak szybki. Będziesz mieć również problemy z klientami, którzy nie używają usług rozpoznawania nazw DNS zdolnych do wybrania „najbliższego” adresu IP. Ponadto w przypadku Wi-Fi i urządzeń mobilnych „najbliższy” często nie będzie właściwym serwerem.

Dłuższa odpowiedź:

Nie rób tego Lepszym sposobem byłoby skonfigurowanie indywidualnych rekordów CNAME dla każdego użytkownika wskazującego odpowiedni serwer. Załóżmy, że masz dwa serwery server-fi server-rużywasz IMAP. Skonfiguruj klienta IMAP każdej osoby, tak aby nazwa serwera to USERNAME.imap.example.com, gdzie „USERNAME” jest zastąpione ich e-mailową nazwą użytkownika. Teraz możesz przenosić ludzi między serwerami bez konieczności ponownej konfiguracji klienta poczty e-mail.

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.

Jednak jeśli to zrobisz, WYSOKIE WYSOKIE POLECAM, że rekordy DNS są generowane automatycznie z bazy danych użytkowników. Chcesz się upewnić, że w miarę tworzenia i usuwania kont rekordy DNS również są tworzone i usuwane. W przeciwnym razie skończy się bałagan i dużo zamieszania.

Widziałem to w firmach z dosłownie tysiącami użytkowników, a ponieważ sprawy zostały zautomatyzowane, świat wygląda bardzo dobrze.

TomOnTime
źródło
0

Jak zauważyli inni, jest to straszny pomysł do użytku w świecie rzeczywistym.

W prawdziwym świecie istnieją niespełniający wymagań klienci i programy tłumaczące, które mają problemy z odpowiedziami, które nie mieszczą się w jednym datagramie UDP, i istnieją zapory ogniowe, które będą egzekwować określone, ale niezgodne z protokołem pomysły dotyczące limitów wielkości wiadomości DNS.

I nawet jeśli możesz liczyć na ogromną odpowiedź w każdym przypadku (czego zdecydowanie nie możesz) jest jeszcze jeden powód, dla którego jest to bardzo zły pomysł. Im większy jest rozmiar odpowiedzi DNS, tym bardziej kuszący jest ładunek do ataków odbiciowych, ponieważ zapewniasz ogromny współczynnik wzmocnienia. W tym typie ataku typu „odmowa usługi”, który jest powszechny w systemie DNS, zapytanie UDP jest wysyłane do otwartego programu rekurencyjnego. Adres źródłowy zapytań UDP jest zazwyczaj łatwo sfałszowany, a atakujący ustawia źródło zapytania na adres IP zamierzonego celu. Osiągnięto dwa pożądane (dla atakującego) efekty: po pierwsze - stosunkowo niewielki wysiłek wysyłania z ich strony (z małej sfałszowanej kwerendy) skutkuje stosunkowo dużym strumieniem niepożądanego ruchu docierającego do celu (jest to współczynnik wzmocnienia), a po drugie - rzeczywiste źródło ataku jest ukryte przed celem; cel zna tylko adresy rekurencyjnych przeliczników używanych jako reflektory.

Michael McNally
źródło
0

Ciekawy punkt historycznych ciekawostek na ten temat. W latach 90. AOL rozszerzył swoje rekordy DNS, tak że zapytanie MX zwróci> 512 bajtów. Naruszyło to RFC, zepsuło wiele serwerów SMTP (popularnym wówczas qmailem) i spowodowało wiele problemów głowy sysadminów. Poprawka wymagała łatania lub dodawania tras statycznych.

Nie wiem, jaka jest obecna sytuacja, ale kilka lat temu, kiedy ostatnio dotknąłem qmail'a, łatki były nadal na swoim miejscu.

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

Coops
źródło