Хорошо знать, что 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). Интересно: /security/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
тогда как a +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