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?
dig/nslookuplub sekcję Wireshark. (tcpdumpnie będzie wystarczająco dobry) Jeśli używasznslookup, wykonajset debugnajpierw.Odpowiedzi:
Pusta odpowiedź, na którą patrzysz, to stan syntetyczny znany jako
NODATA.NODATAiNXDOMAINoba wskazują, że nazwa nie istnieje, aleNXDOMAINdotyczy 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
NODATAiNXDOMAINjest 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 dlaxavamedia.nl.)Ani w tym przypadku,
NXDOMAINaniNODATAsame 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.źródło
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.NODATAOznacza nazwa nie istnieje, ale nie posiada rekord typu żądanie. Np. Prosisz oAzapis, ale ma on tylkoMXzapis. 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.NXDOMAINoznacza, że nazwa nie istnieje,NODATAoznacza, że nazwa istnieje, ale żądany typ rekordu nie istnieje.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.
źródło