Wymuś żądania DNS usługi przesyłania dalej do trybu TCP

Skonfigurowałem serwer DNS na SLES10 (obecnie powiązanie 9.6) na serwerze multi-homed. Na ten serwer można wysyłać zapytania ze wszystkich sieci wewnętrznych i zapewnia odpowiedzi dla wszystkich sieci wewnętrznych. Mamy dwie oddzielne strefy „master” DNS. Każda z tych stref obsługiwana jest przez wiele autorytatywnych serwerów Windows-DNS.

Teraz mój serwer linux jest drugorzędnym serwerem DNS dla jednej z tych stref (prywatna strefa wewnętrzna) i działa jako forwarder dla drugiej strefy (publiczna strefa wewnętrzna).

Do niedawna ta konfiguracja działała bez problemów. Teraz dostaję - po zapytaniu publicznej strefy wewnętrznej (np. Przez hostpolecenie klienta Linuksa) komunikat o błędzie

;; Obcięty, ponawianie próby w trybie TCP

zrzut wireshark ujawnił przyczynę tego: Pierwsze zapytanie wychodzi w trybie UDP, odpowiedź nie pasuje do UDP (z powodu długiej listy autorytatywnych NS), a następnie jest ponawiana w trybie TCP, dostarczając poprawną odpowiedź.

Teraz pytanie: czy mogę skonfigurować moje wiązanie, aby przeszukiwało forwardery w trybie TCP bez uprzedniej próby UDP?

Aktualizacja: Próbuję swoich sił w ASCII-art ...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+

— Nils
źródło

przydatny byłby mały schemat tego - staram się dowiedzieć, który serwer jest z twojego opisu.

— Alnitak,

nieco lepiej, chociaż nadal nie jest jasne, pomiędzy dokładnie hostami, na których uruchamiasz to hostpolecenie, a tym, jakie zapytanie jest wysyłane.

— Alnitak,

Klienci żądają za pośrednictwem SLES10 wpisów ze strefy publicznej wewnętrznej. Strefa prywatna wewnętrzna nie ucierpi - ponieważ są tam tylko 2 wpisy NS.

— Nils,

a klienci są zwykłymi programami do rozpoznawania kodów pośredniczących?

— Alnitak,

sugerujemy dodanie minimal-responses: yesdo konfiguracji BIND na SLES 10 - może to zmniejszyć rozmiary odpowiedzi. W każdym razie większość normalnych zapytań nie przekroczy limitu 512 bajtów.

— Alnitak,

Odpowiedzi:

Po pierwsze, nie nazwałbym tego błędem, a jedynie komunikatem informacyjnym.

Po drugie, serwery DNS zawsze odpowiedzą na zapytania UDP (przynajmniej BIND, nie mogę znaleźć opcji wyłączenia UDP), a klienci zawsze (?) Spróbują najpierw wysłać zapytanie UDP (na przykład w resolv.conf nie ma opcji, aby to zmienić ani w JVM) - jeśli mieszczą się w pakiecie UDP (zazwyczaj żądania)

Jeśli masz konkretny przypadek użycia, możesz określić użycie TCP, np. W skrypcie powłoki użyj „dig + tcp” lub „host -T” do rozstrzygania, a także możesz używać wywołań systemowych „sethostent / gethostbyname / endhostent” (patrz man strona), aby wymusić TCP w innych przypadkach.

Jeśli naprawdę chcesz spróbować zablokować UDP, jedyną dostępną opcją jest reguła iptable, ale nie jestem pewien, czy ta konfiguracja zadziałałaby. Spodziewam się, że rozpoznawanie DNS po prostu się nie powiedzie.

— Dan Andreatta
źródło

nominalnie korzyść z wydajności wynika ze znajomości a priori, że zapytanie UDP zakończy się niepowodzeniem, i najpierw spróbowania przez TCP. Dyskusja na ten temat znajduje się w RFC 5966.

— Alnitak,

@Alnitak i ja chcielibyśmy uzyskać tę korzyść.

— Nils,

@Nils, więc musimy dowiedzieć się, dlaczego EDNS najwyraźniej nie działa ...

— Alnitak,

Nie mam specjalnego przypadku użycia - klienci będą korzystać z biblioteki tłumaczącej - ale każde żądanie i każda odpowiedź przejdzie przez sieć dwa razy - nie podoba mi się to.

— Nils,

@Nils, problem polega na tym, że klient decyduje się na UDP / TCP, ale serwer znał rozmiar odpowiedzi.

— Dan Andreatta

Twój serwer BIND powinien używać EDNS (patrz RFC 2671), aby zezwolić na pakiety UDP dłuższe niż 512 bajtów.

options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

Powinno to pozwolić na odzyskanie dużego zestawu NS przez UDP, bez wymagania narzutu połączenia TCP w przypadku innych mniejszych zapytań.

Należy jednak pamiętać, że w rzeczywistości są to wartości domyślne. Jeśli EDNS nie jest używany, coś go blokuje lub serwery odbierające opcje EDNS nie obsługują tego.

Pamiętaj też, że hostnie obsługuje EDNS. Jest całkiem możliwe, że twoje zapytania -> zapytania serwera już korzystają z EDNS i po prostu nie widzisz tego, gdy próbujesz z lokalnym klientem.

Spróbuj dig +bufsize=4096 @server hostname Azamiast używać host.

— Alnitak
źródło

Kto powinien tego używać? Czy zarówno mój serwer, jak i moi spedytorzy ze strefy „public Internal”?

— Nils,

Jaki jest sens wysyłania pełnej listy NS w odpowiedzi?

— Nils,

@ Brak protokołu DNS wymaga, aby pełny zestaw wpisów pasujących do tej samej krotki (QNAME, QTYPE i QCLASS) były niepodzielne (inaczej „RRset”)

— Alnitak

czy możesz wskazać mi RFC dotyczące tego zestawu RR?

— Nils,

Host Actaully korzysta ze standardowej biblioteki tłumaczącej, a na mojej stacji roboczej obsługuje EDNS0. Aby sprawdzić, czy żądania określają EDNS0, uruchom „tcpdump -x port 53”, a zrzut szesnastkowy powinien zawierać (pod koniec, w dodatkowej sekcji) sekwencję 0029 1000 0000 8000 0000, która jest binarną reprezentacją OPT RR.

— Dan Andreatta