Какой порт использует DNS? Порт 53 и когда не он

По какому порту работает DNS при обычном запросе?

Обычный запрос, из тех, что браузер отправляет десятки раз в минуту, уходит одним UDP-пакетом на порт 53 и так же возвращается обратно. RFC 1035 называет UDP «рекомендуемым методом для стандартных запросов в интернете», потому что ему не нужно рукопожатие: один пакет туда, один обратно, готово. Именно поэтому DNS кажется мгновенным, когда работает, и именно поэтому одного потерянного пакета достаточно, чтобы он показался сломанным: UDP не повторяет запрос за вас автоматически. Повтор берет на себя резолвер на вашем устройстве или роутере, обычно обращаясь ко второму настроенному серверу, если первый молчит.

Когда DNS использует TCP вместо UDP?

Две ситуации переводят DNS-обмен на TCP-порт 53. Первая - это передача зоны, когда вторичный сервер имен забирает у первичного полную копию зоны. RFC 1035 прямо говорит, что «UDP неприемлем для передачи зон», потому что этой операции нужен надежный, упорядоченный поток, а не единственный пакет без гарантий доставки. Вторая - это ответ, который не помещается в используемый размер UDP-сообщения. В этом случае сервер отправляет обрезанный UDP-пакет с установленным битом TC (truncated), а резолвер, соответствующий стандарту, замечает этот бит и заново отправляет тот же запрос по TCP, чтобы получить полный ответ. Такое поведение можно вызвать самостоятельно и увидеть полный ответ напрямую:

dig +tcp example.com

Повседневным запросам этот путь нужен редко, но он существует именно для того, чтобы DNS продолжал работать, когда ответ вырастает за пределы того, что помещается в один UDP-пакет, а это случается чаще, чем раньше.

Что за ограничение в 512 байт и что его изменило?

RFC 1035 зафиксировал размер UDP-сообщения в 512 байт, включая заголовок, но не считая заголовков IP и UDP. В 1987 году этого числа хватало с запасом, когда DNS-ответ был горсткой записей адресов. Оно перестало хватать, когда подписи DNSSEC, более длинные имена хостов и записи со множеством IP-адресов стали обычным делом, потому что подписанный ответ с записью RRSIG регулярно сам по себе превышает 512 байт.

RFC 6891, опубликованный в 2013 году, поднял потолок, не затрагивая сам протокол передачи: EDNS0 добавляет псевдозапись OPT, которая позволяет резолверу заявить «наибольший размер UDP-нагрузки, который может быть собран и доставлен в сетевом стеке запрашивающей стороны», и RFC предлагает 4096 байт как практическую отправную точку. Резолвер и сервер, оба поддерживающие EDNS0, могут обмениваться ответами в несколько раз больше старого предела в 512 байт в рамках одного UDP-пакета и переходить на TCP, только когда не хватает даже этого расширенного запаса. Почти каждый используемый сегодня резолвер, включая тот, что встроен в вашу операционную систему, по умолчанию поддерживает EDNS0, так что это улучшение уже произошло без каких-либо действий с вашей стороны.

Почему файрволы, пропускающие только UDP 53, создают реальные проблемы

Правило файрвола, написанное много лет назад и с тех пор ни разу не пересмотренное, часто гласит: «разрешить UDP-порт 53, все остальное, связанное с DNS, запретить». Это правило блокирует резервный переход на TCP, который нужен протоколу, а возникающий сбой легко диагностировать неправильно, потому что большинство запросов продолжают нормально работать. Отказывают только те, что вырастают за пределы лимита UDP, и отказывают они на первый взгляд случайным образом: домен обычно разрешается нормально, а потом внезапно упирается в таймаут, особенно когда задействована проверка DNSSEC, поскольку проверяющему резолверу нужно получить записи RRSIG и DNSKEY вместе с самим ответом, который он запрашивал.

На практике это означает, что зоны, подписанные DNSSEC, и любой набор записей с множеством значений (например, домен с десятком почтовых серверов) становятся ненадежными за файрволом, пропускающим только UDP, тогда как все остальное выглядит здоровым. Блокировка исходящего TCP-порта 53, целиком или только в одном направлении, это один из самых частых DNS-сбоев, устроенных своими же руками, и он редко проявляется при базовой проверке связности, потому что такая проверка обычно пробует только UDP.

DNS через TLS и DNS через HTTPS: разные порты, те же запросы

Два более новых транспорта передают те же DNS-запросы и ответы, но полностью уходят с порта 53. DNS через TLS, определенный в RFC 7858, оборачивает каждый запрос в TLS-сессию на TCP-порту 853, выбранном так, чтобы сетевой оператор все еще мог видеть, что используется DoT (и блокировать его), даже не расшифровывая трафик, поскольку сам номер порта уже служит явным сигналом.

DNS через HTTPS, определенный в RFC 8484, идет дальше. Он отправляет DNS-запросы как обычные HTTPS-запросы на порту 443, том же самом, на котором работает любой другой сайт, который вы посещаете, и RFC прямо называет «возможность смешивать трафик DoH с другим HTTPS-трафиком в одном соединении» намеренным свойством. В этом весь смысл DoH: сеть, которая фильтрует только по порту, не может отделить DNS-запрос от любого другого HTTPS-запроса, потому что это один и тот же протокол на одном и том же порту. Chrome, Firefox и Edge теперь по умолчанию могут отправлять DNS именно так, поэтому блокировка «порта 53» в сети больше не гарантирует, что вы заблокировали DNS. Она гарантирует, что вы заблокировали классический транспорт; браузер с включенным DoH продолжает разрешать имена через 443 в любом случае.

Что за mDNS на порту 5353?

Multicast DNS - это другой протокол, носящий похожее название. RFC 6762 определяет его как устройства, «отправляющие DNS-подобные UDP-запросы и ответы через IP-мультикаст на UDP-порт 5353», адресованные мультикаст-группе 224.0.0.251 (или ее эквиваленту в IPv6, FF02::FB), а не конкретному серверу. Центрального сервера имен здесь вообще нет: каждое устройство в сегменте локальной сети слушает порт 5353 и отвечает за собственное имя. Именно так принтер или умная колонка становятся доступны как device.local без того, чтобы кто-то настраивал для них DNS-запись. По замыслу он ограничен локальным сегментом и никак не связан с разрешением публичного доменного имени, так что трафик mDNS никогда не выходит за пределы вашего роутера.

Как проверить, доступен ли порт 53

Начните с прямого запроса к заведомо рабочему резолверу, который покажет, работают ли вообще обычные UDP-запросы:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Если это работает, а вы подозреваете, что заблокирован путь резервного перехода на TCP, принудите TCP и сравните:

dig +tcp example.com @1.1.1.1

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

Часто задаваемые вопросы

Нужно ли открывать TCP 53 вместе с UDP 53?

Да, для исходящего трафика к резолверу. Файрвол, который пропускает только UDP 53, нормально обработает большинство запросов, а затем непредсказуемо откажет на более крупных, обычно подписанных DNSSEC, ответах, которым нужен резервный переход на TCP.

Блокирует ли блокировка порта 53 весь трафик DNS?

Уже не всегда. Она блокирует классический транспорт UDP/TCP. DNS через HTTPS работает на порту 443 и выглядит как любой другой HTTPS-запрос, а DNS через TLS работает на собственном порту 853, так что браузер или приложение с любым из них включенным продолжает разрешать имена.

DNS через HTTPS - это тот же протокол, что и обычный DNS?

Запросы и ответы это те же самые DNS-записи и коды, определенные RFC 1035. Меняется только транспорт: вместо необработанного UDP- или TCP-пакета на порту 53, тот же самый запрос оборачивается в HTTPS-запрос на порту 443.

Почему dig иногда использует TCP без явного указания?

Когда UDP-ответ возвращается обрезанным, с установленным битом TC, клиент, соответствующий стандарту, автоматически заново отправляет запрос по TCP, чтобы получить полный ответ. Чаще всего это видно на доменах с включенным DNSSEC или с большим числом записей одного типа.

mDNS на порту 5353 - это то же самое, что DNS моего провайдера?

Нет. mDNS работает только в пределах вашего локального сегмента сети, у него нет центрального сервера, и он разрешает такие имена, как device.local, для устройств в том же сегменте. К разрешению публичного домена вроде example.com он не имеет никакого отношения.

Какой размер полезной нагрузки EDNS0 нормален сегодня?

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