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

Я занимаюсь настройкой мониторинга DNS-серверов нескольких крупных веб-хостов. Моя цель состоит в том, чтобы сравнить время отклика их серверов DNS, отслеживая их реакцию на пинг.

В процессе я обнаружил, что серверы имен Bluehost не отвечают на ping. Я попытался получить больше информации, запустив Pingdom DNS Check на bluehost.com, и он выдал следующую ошибку:

Сервер имен ns1.bluehost.com (74.220.195.31) не отвечает на запросы через TCP.

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

Я хотел бы знать следующее:

• Насколько верно приведенное выше утверждение?
• Каковы последствия того, что сервер имен не отвечает на запросы по TCP?

Диагностический текст из Pingdom является точным. TCP не только для зонных передач.

Реализации сервера DNS являются в настоящее время «требуется» (в так же , как любой RFC требует ничего) для поддержки TCP, в RFC 5966 , «DNS транспорта через TCP - Требования к реализации».

Обратите внимание , что это требование о реализации серверного программного обеспечения, это не строго относится к работе любого сервера - оперативная практика не распространяется.

Тем не менее, если ваши конкретные DNS-серверы не настроены на поддержку TCP или если он заблокирован, то в результате долгосрочного эффекта будет невозможна правильная поддержка DNSSEC. Точно так же любые другие данные DNS, из-за которых ответы превышают 512 байт, могут быть заблокированы.

Отказ от ответственности: я написал, что RFC.

РЕДАКТИРОВАТЬ RFC 5966 теперь заменен RFC 7766

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

Хорошо знать, что 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

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