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

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

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

http://cr.yp.to/djbdns/tcp.html (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-adoption.

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

PS Обратите внимание, что на самом деле 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

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 есть свои риски отказа в обслуживании, но распространение сложнее.