# Часть DNS-запросов не проходит: зачем разрешать TCP и UDP 53

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

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-dns-udp-tcp-policy/
Language: ru

Разрешить только UDP 53 недостаточно для полноценной DNS-связности. DNS использует и TCP; блокировка этого транспорта может проявляться лишь для части запросов или ответов. Проверяйте оба протокола и применённую NetworkPolicy, а не ограничивайтесь одним успешным коротким lookup.

## Определите реальный DNS endpoint

Сохраните resolv.conf Pod, адрес nameserver и путь до cluster DNS. Если применяется NodeLocal DNSCache или иной слой, адрес и политика могут отличаться от прямого обращения к CoreDNS Service. Проверьте namespace labels и selectors в egress rules. NetworkPolicy работает при поддержке соответствующего CNI, поэтому наличие YAML не подтверждает применение правил. Для расследования важно связать конкретный workload, адрес и реализующий policy сетевой плагин.


[Официальный источник 1](https://www.rfc-editor.org/rfc/rfc7766.html).

## Сопоставьте UDP и TCP

RFC 7766 требует поддержку TCP для полной реализации DNS. Он может использоваться не только для zone transfer: крупные и обрезанные ответы также связаны с переходом на TCP. Не задавайте правило «весь DNS всегда только UDP», даже если простые имена сейчас работают. В то же время не объявляйте любой DNS timeout доказательством блокировки TCP: resolver, upstream и потери UDP остаются отдельными гипотезами, которые нужно проверить измерением.


[Официальный источник 2](https://kubernetes.io/docs/concepts/services-networking/network-policies/).

## Разберите частичный отказ

В учебной политике разрешён UDP 53 к resolver, а TCP не разрешён. Короткий ответ проходит, другая операция требует TCP и задерживается. В тестовом Pod выполните разрешённые диагностические запросы обоими транспортами к одному resolver. Сохраните коды ответа, время и соответствующие CNI observations. Синтетический пример показывает, почему частичная успешность недостаточна; он не утверждает, что каждый большой ответ обязательно будет передан конкретным путём при любой конфигурации.

| Тест | Что сравнивать |
| --- | --- |
| UDP к resolver | Доставка и ответ первого транспорта |
| TCP к тому же адресу | Установка соединения и ответ |
| Без policy на стенде | Контрольная связность среды |
| С policy на стенде | Реальный эффект выбранных правил |


[Официальный источник 3](https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/).

## Исправьте scope правила

Разрешите необходимые DNS протоколы к подходящим endpoints с учётом CNI и архитектуры resolver. Не открывайте весь egress ради проверки одной зависимости в рабочем кластере. После исправления проверьте, что selectors не разрешили доступ соседним namespace по ошибке. Порядок policy rules нельзя трактовать как обычный firewall first-match: Kubernetes NetworkPolicy имеет свою модель объединения разрешений. Сверяйте итоговый результат всех применимых политик для исходного Pod.

## Сохраните воспроизводимый тест

После изменения повторите оба транспорта и нужные внутренние/внешние имена. Отдельно проверьте, что запреты на посторонние направления сохраняются. Артефакт содержит resolver path, policy selectors, CNI version и наблюдения по TCP/UDP. Такой тест пригодится при смене DNS слоя или сетевого плагина. Успешное разрешение одного имени подтверждает только этот опыт, а полноценная рабочая зависимость требует также последующего TLS и соединения с целевым сервисом.

Связанные разборы: [network and uptime](/ru/journal/network-and-uptime/); [hardware security](/ru/journal/hardware-security/).