Jak działa powrót serwera nazw DNS?

14

Mamy dwa serwery DNS wymienione w naszym rekordzie NS. Ostatniej nocy jeden z naszych serwerów DNS przestał działać. Zgodnie z oczekiwaniami niektóre serwery DNS nie rozwiązały naszych nazw hostów. Zakładałem, że będzie to tymczasowe i zacznie działać po wygaśnięciu TTL naszych rekordów NS (1 godzina).

Ponad godzinę później wciąż otrzymywałem limity czasu DNS z komputerów stacjonarnych korzystających z serwerów Earthlink, Verizon i OpenDNS. Testowałem, aby sprawdzić, czy inny serwer DNS odpowiada:

dig @ns2.example.com www.example.com +short

To zadziałało.

Moje pytania:

  1. Czy ktoś ma odpowiedź na pytanie, dlaczego inne serwery DNS nie uderzały w nasz inny serwer DNS nawet po wygaśnięciu TTL?
  2. Czy serwery DNS wolą główny serwer DNS domeny (z SOArejestru)?
  3. Czy istnieje jakiś algorytm służący do wybierania serwera nazw z dostępnych rekordów NS? Zakładam, że jest to specyficzne dla implementacji, ale być może istnieją tu pewne standardy.
Belmin Fernandez
źródło
TTL nie ma z tym nic wspólnego. Ponieważ nie zmieniono żadnych zapisów, nie ma to istotnego wpływu.
David Schwartz
Ach, teraz to widzę. Doh
Belmin Fernandez

Odpowiedzi:

17

To niefortunne podrażnienie. Wiele serwerów DNS ma zwiększyć niezawodność, ale w praktyce często ma to efekt odwrotny.

Problem polega na tym, że klient czeka tak długo tylko na odpowiedź, a serwer czeka tyle samo czasu. Załóżmy, że masz dwa serwery DNS, A i B. Powiedz, że A działa, a B zawiódł. To się stało:

  1. Klient łączy się z serwerem nazw Z i prosi go o informacje. Z wybiera B i wysyła zapytanie.

  2. Klient przekroczył limit czasu, ponieważ serwer nazw Z nie odpowiedział.

  3. Klient próbuje serwer nazw Y. Y wybiera B i wysyła zapytanie.

  4. Serwer nazw Z kończy limit czasu i próbuje A. Otrzymuje prawidłową odpowiedź, ale klient już nie czeka.

  5. Klient przekroczył limit czasu, ponieważ serwer nazw Y nie odpowiedział.

  6. Klient poddaje się, ponieważ oba serwery nazw nie odpowiadają.

  7. Serwer nazw Y limit czasu i próbuje A. Otrzymuje prawidłową odpowiedź, ale klient już nie czeka.

I nie ma dobrego rozwiązania. Im dłużej czekasz, aby zobaczyć, czy serwer nazw odpowiada, tym dłużej musisz czekać, ponieważ serwer nazw, na który czekasz, czeka dłużej. Prawdopodobnie problem polegał na tym, że Y i Z nie poddawali się B wystarczająco szybko.

Zasadniczo, jeśli któryś z serwerów nazw nie działa, niektórzy klienci, po prostu pechowi, przekroczą limit czasu, ponieważ próbowali tylko tych złych.

Z drugiej strony, jeśli masz dwa serwery nazw, a jeden zawiedzie, około 75% serwerów nazw otrzyma odpowiedź, zamiast 0%.

David Schwartz
źródło
Rozumiem, co masz na myśli. Eek. Więc nameserver ( Z) klienta nie buforuje, który serwer nazw, którego ostatnio używał, działał?
Belmin Fernandez
1
Niektóre serwery nazw to robią, a czasem to pomaga. Często zależy to od dokładnego sposobu, w jaki serwer nazw zawiódł. Musisz pamiętać, że to wszystko na szczycie UDP, więc brak odpowiedzi (nawet po retransmisji lub dwóch) nie świadczy o tym, że coś jest nie tak z serwerem nazw.
David Schwartz
Przeczytałem w mojej kopii DNS i BIND (Paul Albitz i Cricket Lui, O'Rielly p278), że serwery Bind 8.2.3 wybierają serwer, który reaguje najszybciej z listy spedytorów, co oznacza, że ​​jeśli serwer na liście zawiedzie, to jest prawie automatycznie upuszczany. Bind 9 jeszcze tego nie implementuje, odpytuje serwery przesyłania dalej w kolejności listy. Czy ktoś wie, czy to się zmieniło?
Jaydee
Dla wyjaśnienia, dla osób mniej zaznajomionych z konfiguracjami DNS (zrozumienie tego zajęło mi trochę czasu) serwery nazw DNS Z i Y w tym przykładzie są najprawdopodobniej rekurencyjnymi serwerami nazw opartymi na sieci klienta, np. Serwery DNS zapewniane przez dostawcę usług internetowych swoim klientom za pośrednictwem DHCP. Problem pojawia się, gdy te serwery mają dłuższą wartość limitu czasu niż klient DNS (np. System operacyjny urządzenia).
Jordan Rieger