RFC, który wymaga, aby serwery DNS odpowiadały na nieznane żądania domeny

Mój rejestrator domen i DNS zapewniają obecnie ignorowanie żądań DNS do nieznanych domen. Przez ignorowanie mam na myśli czarne dziury i nigdy nie odpowiada, co powoduje, że moi klienci DNS i biblioteki resolvera ponawiają próbę, wycofują się, a na koniec limit czasu.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Badając inne popularne usługi nazw domen, widzę, że takie zachowanie jest dość wyjątkowe, ponieważ inni dostawcy zwracają RCODE 5 (ODMOWIONY):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Wszystkie zwracają coś takiego:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

lub

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Zwrot REFUSEDlub NXDOMAINnatychmiastowe jest właściwe IMHO, w przeciwieństwie do po prostu upuszczenia żądania na piętrze serwerowni.

Kiedy skarżę się do mojego dostawcy na brak odpowiedzi jego serwerów, proszą mnie o zacytowanie RFC, które naruszają ich serwery. Wiem, że to dziwne, że proszą mnie o udowodnienie, że ich serwery powinny odpowiadać na wszystkie żądania, ale niech tak będzie.

Pytania :

• Zastrzegam sobie, że jeśli nie ma zduplikowanych identyfikatorów żądań lub odpowiedzi DOS, serwer powinien zawsze odpowiadać na żądanie. Czy to jest poprawne?
• Jakie RFC i konkretną sekcję powinienem zacytować, aby potwierdzić moje zastrzeżenie?

Dla mnie źle jest nie odpowiadać na zapytanie DNS. Większość klientów wycofuje się, a następnie retransmituje to samo zapytanie na ten sam serwer DNS lub inny serwer. Nie tylko spowalniają klientów, ale również powodują, że to samo zapytanie jest wykonywane ponownie przez ich własne lub inne serwery, w zależności od autorytatywnych serwerów nazw i wpisów NS.

W RFC 1536 i 2308 widzę wiele informacji na temat negatywnego buforowania ze względu na wydajność i aby zatrzymać retransmisję tego samego zapytania. W 4074 widzę informację o zwróceniu pustej odpowiedzi z kodem RCODE 0, więc klient wie, że nie ma informacji ipv6, które powinny spowodować, że klient zapyta o RR, co jest kolejnym przykładem pustej odpowiedzi.

Ale nie mogę znaleźć dokumentu RFC, który mówi, że serwer DNS powinien odpowiedzieć na żądanie, prawdopodobnie dlatego, że jest to dorozumiane.

Konkretny problem występuje, gdy migruję swoją domenę (i powiązane rekordy DNS) na ich serwery lub pierwsze X minut po zarejestrowaniu nowej domeny w ich usłudze. Pomiędzy momentem, w którym zmieniają się autorytatywne serwery nazw (co jest teraz cholernie szybkie), jest opóźnienie, a ich serwery zaczynają obsługiwać moje rekordy DNS. W tym czasie klienci DNS uważają, że ich serwery są wiarygodne, ale nigdy nie odpowiadają na żądanie - nawet za pomocą REFUSED. Rozumiem opóźnienie, które jest w porządku, ale nie zgadzam się z decyzją, aby nie odpowiadać na żądania DNS. Dla przypomnienia, rozumiem, jak obejść te ograniczenia w ich systemie, ale nadal współpracuję z nimi, aby ulepszyć ich usługi, aby były bardziej zgodne z protokołem DNS.

Dzięki za pomoc.

Edytować:

W ciągu kilku miesięcy od opublikowania tego i skontaktowania się z moim dostawcą zmienili swoje serwery, aby wrócić NXDOMAINdo nieznanych domen.

Rada Shane'a jest poprawna. Brak migracji danych z jednego wiarygodnego serwera na inny przed zainicjowaniem przełączenia jest zaproszeniem do wyłączenia. Niezależnie od tego, co stanie się od tego momentu, jest to przerwa zainicjowana przez osobę, która zamieniła rekordy NS. To wyjaśnia, dlaczego więcej osób nie składa tej skargi do twojego dostawcy.

To powiedziawszy, to wciąż interesujące pytanie, więc odpowiem na to.

Podstawowa funkcjonalność serwerów DNS jest objęta dokumentami RFC 1034 i RFC 1035 , które łącznie tworzą STD 13 . Odpowiedź musi albo pochodzić z tych dwóch RFC, albo być wyjaśniona w późniejszym RFC, który ją aktualizuje.

Zanim przejdziemy dalej, istnieje ogromna pułapka poza zakresem DNS, którą należy wywołać: oba te RFC są wcześniejsze niż BCP 14 (1997), dokument wyjaśniający język MAJ, MUSI, POWINIEN, itp.

• Standardy opracowane przed sformalizowaniem tego języka MOGĄ używać jasnego języka, ale w kilku przypadkach nie. Doprowadziło to do rozbieżnych wdrożeń oprogramowania, masowego zamieszania itp.
• STD 13 jest niestety winny interpretacji w kilku obszarach. Jeśli język nie jest pewny w obszarze działania, często konieczne jest znalezienie wyjaśniającego RFC.

Na marginesie, zacznijmy od tego, co ma do powiedzenia RFC 1034 §4.3.1 :

• Najprostszy tryb dla serwera jest nierekurencyjny, ponieważ może odpowiadać na zapytania przy użyciu tylko informacji lokalnych: odpowiedź zawiera błąd, odpowiedź lub odesłanie do innego serwera „bliższego” odpowiedzi. Wszystkie serwery nazw muszą implementować zapytania nierekurencyjne.

...

Jeśli usługa rekurencyjna nie jest wymagana lub nie jest dostępna, odpowiedź nierekurencyjna będzie jedną z następujących czynności:

• Autorytatywny błąd nazwy wskazujący, że nazwa nie istnieje.

• Tymczasowe wskazanie błędu.

• Niektóre kombinacje:

  RR, które odpowiadają na pytanie, wraz ze wskazaniem, czy dane pochodzą ze strefy, czy są buforowane.

  Odwołanie do serwerów nazw, które mają strefy bliższe przodkom nazwy niż serwer wysyłający odpowiedź.

• RR, które według serwera nazw okażą się przydatne dla requestera.

Język tutaj jest dość ostry. Nie ma „powinno być”, ale „będzie”. Oznacza to, że wynik końcowy musi być 1) zdefiniowany na powyższej liście lub 2) dozwolony w późniejszym dokumencie na torze standardów, który zmienia funkcjonalność. Nie znam żadnego takiego słownictwa dotyczącego ignorowania prośby i powiedziałbym, że to na deweloperach spoczywa obowiązek znalezienia języka, który obala badania.

Biorąc pod uwagę częstą rolę DNS w scenariuszach nadużyć sieciowych, nie można powiedzieć, że oprogramowanie serwera DNS nie zapewnia pokręteł do selektywnego upuszczania ruchu na podłogę, co technicznie byłoby naruszeniem tego. To powiedziawszy, albo nie są to domyślne zachowania, albo bardzo konserwatywne; przykładem może być użytkownik wymagający od oprogramowania usunięcia określonej nazwy ( rpz-drop.) lub przekroczenia określonych progów liczbowych (BIND max-clients-per-query). Z mojego doświadczenia wynika, że ​​oprogramowanie całkowicie zmienia domyślne zachowanie wszystkich pakietów w sposób naruszający standard, chyba że opcja ta zwiększa tolerancję dla starszych produktów naruszających standard. Nie o to chodzi w tym przypadku.

Krótko mówiąc, ten RFC może zostać naruszony według uznania operatorów, ale zwykle odbywa się to z pewną precyzją. Niezwykle rzadkie jest całkowite pominięcie sekcji standardu, co jest wygodne, szczególnie gdy profesjonalny konsensus (przykład: BCP 16 §3.3 ) myli się na korzyść tego, że niepożądane jest generowanie niepotrzebnego obciążenia systemu DNS jako całości. Mając to na uwadze, niepotrzebne próby usunięcia wszystkich żądań, dla których nie ma wiarygodnych danych, są mniej niż pożądane.

Aktualizacja:

Biorąc pod uwagę, że niepożądane jest rzucanie zapytań na podłogę, @Alnitak powiedział nam, że obecnie istnieje Projekt BCP szczegółowo omawiający ten temat. Używanie tego jako cytatu jest nieco przedwczesne, ale pomaga wzmocnić konsensus wspólnoty zgodny z tym, co jest tu wyrażane. W szczególności:

O ile serwer nazw nie jest atakowany, powinien odpowiadać na wszystkie zapytania skierowane do niego w wyniku kolejnych delegacji. Ponadto kod nie powinien zakładać, że nie ma delegacji na serwer, nawet jeśli nie jest skonfigurowany do obsługi strefy. Uszkodzone delegacje są częstym zjawiskiem w DNS, a odbieranie zapytań o strefy, dla których serwer nie jest skonfigurowany, niekoniecznie oznacza, że ​​serwer jest atakowany. Operatorzy strefy nadrzędnej powinni regularnie sprawdzać, czy delegujące rekordy NS są zgodne z rekordami strefy delegowanej, i poprawiać je, gdy nie są to [RFC1034]. Gdyby odbywało się to regularnie, przypadki przerwanych delegacji byłyby znacznie niższe.

Ta odpowiedź zostanie zaktualizowana, gdy zmieni się status tego dokumentu.

Kiedy przenosisz autorytatywny DNS dla domeny do nowego dostawcy, zawsze (zawsze!) Przetestuj jawnie w stosunku do nowego dostawcy (i upewnij się, że wysyłają dokładne, skonfigurowane rekordy) przed zmianą informacji o rejestracji domeny (whois) wskazać nowe autorytatywne serwery DNS.

Z grubsza kroki, które podejmiesz:

1. Skonfiguruj wszystko w nowym dostawcy DNS. Powinieneś utworzyć i wypełnić wszystkie strefy.

2. Upewnij się, że nowe autorytatywne serwery działają poprawnie. Zapytaj ich wprost:

   dig @new-ns.example.com mydomain.com
   

   Jak brzmi z twojego pytania, że ​​nie odpowiadają na te zapytania? Ale powiedziałeś „nieznane domeny”, które nie powinny być w tym momencie, powinny być w pełni skonfigurowane w ich systemie (i odpowiadać skonfigurowanymi rekordami).

   Ale, jeśli mają już skonfigurowany domenę w ich systemie, musi być odpowiadając poprawnych zapisów w tym momencie. Jeśli nie, oznacza to, że strefa nie jest poprawnie hostowana i powinieneś na nią krzyczeć; to, czy odpowiada na domenę, której nie skonfigurował, powinno być nieistotne. (Jeśli nadal coś mi brakuje, powiedz mi).

3. Przełączaj autorytatywne serwery nazw u swojego rejestratora domen (whois), pozostawiając starego dostawcę DNS działającego i działającego, dopóki ruch nie będzie już na nim uderzał (daj mu co najmniej 24 godziny).

Jeśli nowy dostawca absolutnie nie może zapełnić rekordów przed dokonaniem zmiany, wtedy ich reakcja naprawdę nie będzie miała znaczenia - skierowanie użytkowników do autorytatywnej, która całkowicie odmówi zapytania, spowoduje przestoje w domenie tak samo, jakbyś był nie otrzymując żadnej odpowiedzi.