Czy to prawda, że ​​serwer nazw musi odpowiadać na zapytania przez TCP?

Jestem w trakcie konfigurowania monitorowania serwerów DNS kilku dużych hostów internetowych. Moim celem jest porównanie czasów odpowiedzi serwerów dns poprzez śledzenie ich odpowiedzi na ping.

W trakcie tego procesu odkryłem, że serwery nazw Bluehost nie odpowiadają na ping. Próbowałem uzyskać więcej informacji, uruchamiając Pingdom DNS Check na bluehost.com i spowodowało to następujący błąd:

Serwer nazw ns1.bluehost.com (74.220.195.31) nie odpowiada na zapytania przez TCP.

Serwer nazw nie odpowiedział na zapytania wysłane przez TCP. Jest to prawdopodobnie spowodowane nieprawidłowym skonfigurowaniem serwera nazw lub nieprawidłowym filtrowaniem w zaporze. Jest to dość powszechne błędne przekonanie, że DNS nie potrzebuje TCP, chyba że zapewniają transfery stref - być może administrator serwera nazw nie wie, że TCP zwykle jest wymagany.

Chciałbym wiedzieć, co następuje:

• W jakim stopniu powyższe stwierdzenie jest prawdziwe?
• Jakie są konsekwencje, że serwer nazw nie odpowiada na zapytania przez TCP?

Tekst diagnostyczny z Pingdom jest dokładnie poprawny. TCP służy nie tylko do przesyłania stref.

Implementacje serwera DNS są teraz „wymagane” (w takim stopniu, w jakim każdy RFC wymaga czegoś) do obsługi TCP, zgodnie z RFC 5966 , „Transport DNS przez TCP - Wymagania implementacyjne”.

Należy pamiętać, że jest to wymóg implementacji oprogramowania serwera, nie dotyczy on ściśle działania jakiegokolwiek serwera - praktyka operacyjna nie jest objęta.

To powiedziawszy, jeśli twoje konkretne serwery DNS nie są skonfigurowane do obsługi TCP lub jeśli są zablokowane, to efektem długoterminowym będzie niemożność prawidłowego wsparcia DNSSEC. Podobnie wszelkie inne dane DNS, które powodują, że odpowiedzi przekraczają 512 bajtów, mogą być blokowane.

zrzeczenie się odpowiedzialności: Napisałem to RFC.

EDYCJA RFC 5966 została teraz zastąpiona przez RFC 7766

powinien obsługiwać TCP i UDP - TCP ma rozmiar odpowiedzi> 512 bajtów (co obejmuje transfery stref) (tak czy inaczej, zgodnie z tym, co przeczytałem. Zazwyczaj włączam TCP i UDP dla NS, które uruchamiam ...)

Dobrze jest wiedzieć, co mówią RFC na ten temat, i mamy już na to dobrą, autorytatywną odpowiedź, ale dla celów praktycznych uważam radę prof. Dr. J. J. Bernsteina, autora DJBDNS, dość zabawną.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

Kiedy wysyłane są zapytania TCP?

Jeśli znajdujesz się w jednej z poniższych sytuacji, musisz skonfigurować serwer DNS, aby odpowiadał na zapytania TCP:

• Chcesz opublikować zestawy rekordów większe niż 512 bajtów. (To prawie zawsze błąd).
• Chcesz zezwolić na transfer stref wychodzących, na przykład na serwer innej firmy.
• Serwer nadrzędny odmawia przekazania Ci nazwy, dopóki nie skonfigurujesz usługi TCP.

Jeśli nie znajdziesz się w żadnej z tych sytuacji, nie musisz świadczyć usługi TCP i nie powinieneś jej konfigurować. DNS-over-TCP jest znacznie wolniejszy niż DNS-over-UDP i jest z natury znacznie bardziej podatny na ataki typu „odmowa usługi”. (Dotyczy to również BIND.)

Zauważ, że pomija wyraźną wzmiankę o DNSSEC; powodem jest to, że według DJB DNSSEC należy do kategorii „zawsze błąd”. Więcej informacji na stronie https://cr.yp.to/djbdns/forgery.html . DJB ma alternatywny standard o nazwie DNSCurve - http://dnscurve.org/ - który został już niezależnie przyjęty przez niektórych dostawców (np. OpenDNS). Interesujące: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

Należy zauważyć, że jeśli powyższa dokumentacja dotycząca konfiguracji DJBDNS wskazuje na jej funkcje, wydaje się, że obsługuje ona tylko AXFR dla TCP. Ponieważ wielu dostawców nadal korzysta z DJBDNS, jest mało prawdopodobne, aby obsługiwali DNS przez TCP bez dodatkowych wysiłków.

PS Zauważ, że DJB faktycznie ćwiczy to, co głosi. Jego własne serwery (1) uruchamiają DNSCurve, (2), nie odpowiadają poprawnie na TCP. Tylko +notcpsukces się powiedzie (co jest domyślne):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, podczas gdy a +tcpzawiedzie (najwyraźniej z innym komunikatem o błędzie, w zależności od tego, który z jego serwerów zostanie wybrany):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

TCP jest wymagany tylko i zwykle używany tylko wtedy, gdy wymagana jest długa odpowiedź. Mogą wystąpić negatywne skutki. Przesyłanie stref odbywa się za pośrednictwem protokołu TCP, ponieważ są duże i muszą być niezawodne. Nie zezwalanie na TCP z niezaufanych serwerów jest jednym ze sposobów zapewnienia, że ​​podane zostaną tylko małe odpowiedzi.

Wraz z wprowadzeniem podpisanych odpowiedzi DNS pojawił się wymóg rozluźnienia limitu 512 bajtów na odpowiedzi UPD. EDNS0 zapewnia mechanizm dłuższych odpowiedzi UDP. Brak zezwolenia na DNS przez TCP najprawdopodobniej spowoduje uszkodzenie bezpiecznej implementacji DNS.

Zupełnie możliwe jest uruchomienie serwera DNS, który ma tylko port UDP 53 otwarty do Internetu. Wymagany jest dostęp TCP do peerów DNS, ale jest to mała lista hostów.

Istnieje nowsza wersja RFC596, która wymaga teraz protokołu TCP do pełnej implementacji DNS. Jest to skierowane do implementatorów. Dokumenty w szczególności nie dotyczą operatorów, ale ostrzegają, że niedozwolenie TCP może spowodować szereg scenariuszy awarii. Wyszczególnia wiele różnych awarii, które mogą wystąpić, jeśli DNS przez TCP nie jest obsługiwany.

Dyskutowano na temat korzystania z protokołu TCP w celu zapobiegania atakom wzmacniającym DNS. TCP ma własne ryzyko odmowy usługi, ale dystrybucja jest trudniejsza.