По какому порту происходит обращение к DNS-серверу

Обращение к DNS-серверу: порты UDP/53 и TCP/53

Клиенты обращаются к DNS-серверам по двум основным портам: UDP порт 53 и TCP порт 53. Выбор протокола и порта зависит от типа и размера запроса.

Стандартный порт UDP/53

В подавляющем большинстве случаев (более 90% запросов) используется UDP (User Datagram Protocol) на порту 53.

Причины преобладания UDP:

• Низкие накладные расходы: UDP — это протокол без установления соединения. Нет «рукопожатия» (handshake), что делает запросы быстрее.
• Эффективность для малых запросов: Типичный DNS-запрос (например, запрос адреса A-записи для example.com) и ответ умещаются в один пакет UDP (до 512 байт, согласно оригинальному стандарту RFC 1035).
• Минимизация нагрузки: Отсутствие необходимости поддерживать состояние соединения для тысяч одновременных запросов снижает нагрузку как на клиентов, так и на серверы.

Пример простого DNS-запроса по UDP с помощью dig:

# Запрос A-записи для ya.ru через UDP (по умолчанию)
dig ya.ru

# Можно явно указать UDP (флаг +notcp)
dig ya.ru +notcp

В выводе команды dig вы можете увидеть строку ;; Query time: ... msec, которая демонстрирует скорость выполнения запроса, характерную для UDP.

Когда используется TCP порт 53?

TCP (Transmission Control Protocol) на порту 53 задействуется в строго определённых сценариях, обеспечивающих надёжность передачи больших объёмов данных.

Основные случаи использования TCP:

1. Размер ответа превышает 512 байт.

    Если ответ на запрос не помещается в один UDP-пакет, сервер обрезает его и устанавливает в ответе специальный флаг **`TC (Truncated) — бит усечения`**. Увидев этот флаг, DNS-клиент обязан повторить запрос, используя TCP, чтобы получить полный ответ.
    Это часто происходит при запросе **DNS-записей типа TXT** (например, для SPF, DKIM, DMARC), **SRV-записей** или когда возвращается множество A/AAAA записей для одного домена.

1. Зоны передачи (Zone Transfer, AXFR/IXFR).

    Вторичные (slave) DNS-серверы запрашивают у первичных (master) полную (AXFR) или инкрементальную (IXFR) копию зоны. Этот процесс всегда использует TCP из-за большого объёма передаваемых данных и требований к надёжности.

1. Требования современных стандартов (RFC 7766).

    Актуальный стандарт **RFC 7766** предписывает использовать TCP для начального запроса, если известно, что ответ будет большим (например, при использовании **DNSSEC**). Подписанные криптографически ответы (RRSIG-записи) значительно увеличивают размер пакета.

Пример запроса с принудительным использованием TCP в dig:

# Запрос TXT-записей (которые могут быть большими) через TCP
dig google.com TXT +tcp

# Запрос полной зоны (только для администраторов сервера)
dig @primary.ns.server example.com AXFR +tcp

Процесс взаимодействия и практические аспекты

Типичный алгоритм работы DNS-клиента (резолвера):

1. Клиент отправляет запрос к DNS-серверу по UDP/53.
2. Если в ответе установлен флаг TC, или если клиент заранее знает о необходимости TCP (например, для DNSSEC-валидации), он повторяет тот же запрос по TCP/53.
3. Сетевое оборудование (брандмауэры) обязано разрешать исходящие подключения как на UDP/53, так и на TCP/53. Блокировка TCP/53 приводит к невозможности получения больших ответов и является распространённой ошибкой конфигурации безопасности.

Важное замечание о DNSSEC: Использование расширения DNSSEC для проверки целостности и аутентичности данных сделало ответы значительно объёмнее, что увеличило долю запросов, автоматически переходящих на TCP.

Выводы

Таким образом, обращение к DNS-серверу — это двухэтапный процесс, начинающийся с быстрого UDP-запроса и при необходимости переключающийся на надёжный TCP для гарантированной доставки полных данных. Понимание этой механики критически важно для сетевых инженеров, DevOps/SRE-специалистов и архитекторов безопасности при диагностике проблем с разрешением имён, настройке брандмауэров и проектировании отказоустойчивых DNS-инфраструктур.