Действительно ли это верно, что сервер имен должен ответить на запросы по TCP?

это должно поддерживать TCP и UDP - TCP для размеров ответов> 512 байтов (который включал бы зональные передачи) (согласно материалу, который я считал, так или иначе. Я обычно включаю TCP и UDP для NS, который я выполняю...),

TCP только требуется и обычно только используется, когда долгий ответ требуется. Могут быть негативные воздействия. Зональные передачи сделаны по TCP, поскольку они являются большими, и должны быть надежными. Разрешение TCP с недоверяемых серверов является одним способом гарантировать, что только маленькие ответы даны.

С введением ответов DNS со знаком было требование для ослабления 512-байтового предела ответам UPD. EDNS0 обеспечивает механизм для более длительных ответов UDP. Отказ позволить DNS по TCP, очень вероятно, повредит безопасную реализацию DNS.

Совершенно возможно выполнить сервер DNS, который только имеет порт UDP 53 открытых для Интернета. Доступ TCP к коллегам DNS требуется, но это - маленький список хостов.

Существует более новый RFC596, который теперь требует TCP для полной реализации DNS. Это нацелено на конструкторов. Документы конкретно не обращаются к операторам, но предупреждают, что не разрешение TCP может привести ко многим сценариям отказа. Это детализирует большое разнообразие отказов, которые могут закончиться, если DNS по TCP не поддерживается.

Были обсуждения использования TCP для предотвращения нападений усиления DNS. TCP имеет свои собственные риски отказа в обслуживании, но распределение является более трудным.

Приятно знать, что RFC говорят по этому поводу, и у нас уже есть хороший авторитетный ответ по этому поводу, но для практических целей я нахожу совет от профессора Дэниела Дж. Бернстайна, Доктор философии, автор DJBDNS, довольно занимательно.

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

Когда отправляются TCP-запросы?

Если вы находитесь в одной из следующих ситуаций, вам необходимо настроить DNS-сервер для ответа на запросы TCP:

• Вы хотите опубликовать наборы записей размером более 512 байт. (Это почти всегда ошибка.)
• Вы хотите разрешить передачу исходящей зоны, например, на сторонний сервер.
• Родительский сервер отказывается делегировать вам имя, пока вы не настроите службу TCP.

Если вы не находитесь ни в одной из этих ситуаций, вам не нужно предоставлять службу TCP, и вам не следует ее настраивать. DNS-over-TCP намного медленнее, чем DNS-over-UDP, и по своей сути гораздо более уязвим для атак типа «отказ в обслуживании». (Это также относится к BIND.)

Обратите внимание, что он опускает явное упоминание DNSSEC; причина в том, что, согласно DJB, DNSSEC попадает в категорию «всегда ошибка». См. https://cr.yp.to/djbdns/forgery.html для получения дополнительной информации. DJB имеет альтернативный стандарт, называемый DNSCurve - http://dnscurve.org/ , который уже был независимо принят некоторыми поставщиками (например, OpenDNS). Интересно: https://security.stackexchange.com/questions/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-принятие .

Обратите внимание, что если приведенная выше документация по настройке DJBDNS является каким-либо указанием на его функции, похоже, что он поддерживает только AXFR для TCP. Поскольку многие провайдеры все еще используют DJBDNS, они вряд ли будут поддерживать DNS через TCP без дополнительных усилий.

P.S. Обратите внимание, что DJB на самом деле практикует то, что проповедует. Его собственные серверы (1) действительно запускают DNSCurve, (2) не отвечают должным образом на TCP. Только + notcp будет успешным (что по умолчанию):

% 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

, тогда как + tcp завершится ошибкой (очевидно, с другим сообщением об ошибке, в зависимости от того, какой из его серверов будет выбран ):

% 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