Я занимаюсь настройкой мониторинга DNS-серверов нескольких крупных веб-хостов. Моя цель - сравнить время отклика их DNS-серверов, отслеживая их реакцию на пинг.
В процессе я обнаружил, что серверы имен Bluehost не отвечают на пинг. Я попытался получить больше информации, запустив Проверка DNS Pingdom на bluehost.com и возникла следующая ошибка:
Сервер имен ns1.bluehost.com (74.220.195.31) не отвечает на запросы по TCP.
Сервер имен не смог ответить на запросы, отправленные по TCP. Вероятно, это связано с неправильной настройкой сервера имен или с неправильной настройкой фильтрации в брандмауэре. Это довольно распространенное заблуждение, что DNS не нуждается в 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). Представляет интерес: 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 без дополнительных усилий.
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
TCP требуется только и обычно используется только тогда, когда требуется длинный ответ. Могут быть негативные воздействия. Зональные передачи выполняются по TCP, поскольку они велики и должны быть надежными. Запрет на использование TCP с ненадежных серверов - это один из способов гарантировать получение только небольших ответов.
С введением подписанных ответов DNS появилось требование ослабить ограничение в 512 байт для ответов UPD. EDNS0 предоставляет механизм для более длинных ответов UDP. Неспособность разрешить DNS через TCP с большой вероятностью нарушит безопасную реализацию DNS.
Вполне возможно запустить DNS-сервер, на котором для Интернета открыт только UDP-порт 53. Требуется TCP-доступ к одноранговым узлам DNS, но это небольшой список хостов.
Есть новее RFC596 теперь для полноценной реализации DNS требуется TCP. Это нацелено на разработчиков. Документы конкретно не касаются операторов, но предупреждают, что запрет на использование TCP может привести к ряду сценариев сбоя. В нем подробно описывается широкий спектр сбоев, которые могут возникнуть, если DNS через TCP не поддерживается.
Были дискуссии об использовании TCP для предотвращения атак с усилением DNS. TCP имеет свои собственные риски отказа в обслуживании, но распространять его труднее.