Jak powinny działać limity czasu DNS?

Niedawno miałem problem z tym, że zdalna usługa żądająca adresu IP mojego serwera (z hostowanym dostawcą DNS) odpowiadała:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Aktualizacja: wspomniana tutaj usługa zdalna to Let's Encrypt; zgłosiłem błąd w narzędziu do śledzenia problemów, co doprowadziło mnie na tę ścieżkę).

Podczas testowania w mojej sieci lokalnej mogłem zobaczyć, że czasami otrzymuję pustą odpowiedź DNS od hostowanego serwera DNS. Najwyraźniej jest to sporadyczne, ponieważ dzieje się tak tylko wtedy, gdy rekordy DNS nie znajdują się w pamięci podręcznej, a problem występuje tylko wtedy, gdy serwer DNS jest naprawdę zajęty.

Oto opis pustej wiadomości odpowiedzi Wireshark:

Oczywiście, ponieważ większość zapytań DNS i odpowiedzi są wysyłane przez UDP, lokalny program tłumaczący po prostu zaczeka chwilę na odpowiedź, a następnie się podda. Zastanawiam się teraz, czy istnieją wytyczne dotyczące czasów odpowiedzi DNS? Mój serwer DNS wzruszył ramionami i powiedział, że mój lokalny program tłumaczący zbyt wcześnie wysłał pustą odpowiedź. Nigdy wcześniej nie miałem tego problemu, ale jestem zaskoczony trybem awarii - pustą odpowiedzią DNS bez kodu błędu.

Czy ktoś zna jakieś wytyczne dotyczące tego, jak to powinno działać i kiedy / jak mogę udowodnić, że mój serwer DNS robi coś złego?

domain-name-system dns-hosting

— djc
źródło

Czy możesz zaktualizować pytanie, aby uzyskać więcej informacji o pustej odpowiedzi? Może to oznaczać wiele rzeczy w zależności od ustawionych flag i tego, jak wygląda sekcja autorytetu. Musielibyśmy zobaczyć wyniki dig/ nslookuplub sekcję Wireshark. ( tcpdumpnie będzie wystarczająco dobry) Jeśli używasz nslookup, wykonaj set debugnajpierw.

— Andrew B,

Mam plik pcap, ale nie jestem pewien, jak najlepiej go tutaj pokazać?

— djc

Otwórz go w Wireshark, kliknij pakiet, a następnie rozwiń informacje o protokole DNS. Rozwiń również podkategorie, a następnie opublikuj zrzut ekranu w swoim pytaniu za pomocą przycisku wstawiania obrazu. Możesz przyciąć zrzut ekranu do protokołu DNS.

— Andrew B,

Odpowiedzi:

Pusta odpowiedź, na którą patrzysz, to stan syntetyczny znany jako NODATA. NODATAi NXDOMAINoba wskazują, że nazwa nie istnieje, ale NXDOMAINdotyczy także wszystkich nazw poniżej wskazanego rekordu. NODATAinformuje, że albo ta nazwa jest powiązana z rekordami typu niepotrzebnego, albo że istnieją inne rekordy poniżej tego, o co prosisz. (tj. example.test.xavamedia.nl.)

Twoje jedzenie na wynos NODATAi NXDOMAINjest w tym kontekście faktycznie takie samo: zapis żądanej nazwy i typu nie istniał. Autorytatywny serwer nazw została osiągnięta dla wnioskowanej kategorii i on odpowiedział z powrotem twierdząc, że zapis tej nazwy i typu nie istnieje. To nie jest błąd komunikacji. Autorytatywny serwer powiedział, że nie ma danych. Bardziej niż prawdopodobne, że serwer, z którym rozmawiasz, już przetworzył to żądanie i negatywnie zapisał brak tego rekordu w ciągu ostatnich czterech godzin. (14400 sekund to ujemny interwał pamięci podręcznej zdefiniowany dla rekordu SOA dla xavamedia.nl.)

Ani w tym przypadku, NXDOMAINani NODATA same w sobie nie spowodują przekroczenia limitu czasu, ale biblioteka resolvera prawdopodobnie przejdzie odtąd do dołączania sufiksu wyszukiwania DNS, co z kolei może spowodować przekroczenie limitu czasu dla autorytatywnych serwerów DNS domeny wyszukiwania.

Należy zauważyć, że nic z tego nie wyjaśnia, dlaczego napotkałeś SERVFAILodpowiedź, patrząc w górę mysql.xavamedia.nl.. Wskazuje to na problem z tym, że serwer rekurencyjny otrzymuje odpowiedź od autorytatywnych serwerów. Albo serwer autorytatywny odpowiedział SERVFAIL, serwer rekurencyjny nie mógł dotrzeć do żadnego z autorytatywnych serwerów lub serwer rekurencyjny stwierdził, że zwrócone dane są nieprawidłowe. Nie można tego udowodnić na podstawie podanych informacji.

— Andrew B.
źródło

Dziękujemy za szczegółową odpowiedź! Niektóre rzeczy są nadal niejasne: jeśli odpowiedź NODATA zostanie zainicjowana przez autorytatywny serwer, mój hosting DNS ma problem, ponieważ domeny te istniały przez długi czas (na mocy rekordu A z dziką kartą). Więc moje drugie pytanie brzmi: jak mogę udowodnić, czy autorytatywny serwer zrobił coś złego?

— djc

NODATAW przechwytywanie pakietów jest dowodem. Istotne pytanie brzmi: „dlaczego autorytatywny serwer odpowiedział i powiedział, że taki rekord nie istnieje?” . Niestety trudno jest naciskać, chyba że można to udowodnić za pomocą bezpośrednich wyszukiwań w stosunku do autorytatywnych serwerów (eliminując możliwość wzruszenia ramion i obwiniania operatorów serwerów rekurencyjnych), pamiętając, że tylko jedna z tych trzech osób może czasami zachowywać się niewłaściwie.

— Andrew B

NODATAOznacza nazwa nie istnieje, ale nie posiada rekord typu żądanie. Np. Prosisz o Azapis, ale ma on tylko MXzapis. Może się to również zdarzyć, jeśli nazwa dotyczy węzła pośredniego w hierarchii DNS i nie ma własnych rekordów.

— Barmar

@Barmar Tak, tutaj mówi się, że autorytatywny serwer zgłasza brak tej nazwy rekordu + pary typów, a djc wyraża dezorientację w związku z rekordem wieloznacznym, który był obecny od pewnego czasu.

— Andrew B,

Mój komentarz jest skierowany do pierwszego punktu „NODATA i NXDOMAIN wskazują, że nazwa nie istnieje”. NXDOMAINoznacza, że nazwa nie istnieje, NODATAoznacza, że nazwa istnieje, ale żądany typ rekordu nie istnieje.

— Barmar

Nie znam żadnych konkretnych wytycznych oprócz tych określonych w sekcji „6.1.3.3 Wydajne wykorzystanie zasobów” RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77

Określono wartość limitu czasu „nie mniej niż 5 sekund”. RFC stwierdza również, że tymczasowe awarie powinny być buforowane. Ma to na celu zapobieganie nadmiernej liczbie żądań DNS, jeśli klienci naruszą sekcję 2.2 RFC. W tej sekcji stwierdzono, że klienci powinni czekać „rozsądną” ilość czasu między kolejnymi próbami w przypadku miękkich awarii.

Istnieje również wątek Stackoverflow na ten temat, ale nie zawiera on znacznie więcej informacji poza pewnymi obserwacjami w świecie rzeczywistym. /programming/3036054/ideal-timeout-period-for-dns-lookup

To wszystko, co mogę powiedzieć na ten temat. Jeśli ktoś jeszcze ma coś do dodania, byłbym również zainteresowany.

— Janek Bevendorff
źródło