В этом материале
Разрешить только UDP 53 недостаточно для полноценной DNS-связности. DNS использует и TCP; блокировка этого транспорта может проявляться лишь для части запросов или ответов. Проверяйте оба протокола и применённую NetworkPolicy, а не ограничивайтесь одним успешным коротким lookup.
Разрешить только 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 сетевой плагин.
Сопоставьте UDP и TCP
RFC 7766 требует поддержку TCP для полной реализации DNS. Он может использоваться не только для zone transfer: крупные и обрезанные ответы также связаны с переходом на TCP. Не задавайте правило «весь DNS всегда только UDP», даже если простые имена сейчас работают. В то же время не объявляйте любой DNS timeout доказательством блокировки TCP: resolver, upstream и потери UDP остаются отдельными гипотезами, которые нужно проверить измерением.
Разберите частичный отказ
В учебной политике разрешён UDP 53 к resolver, а TCP не разрешён. Короткий ответ проходит, другая операция требует TCP и задерживается. В тестовом Pod выполните разрешённые диагностические запросы обоими транспортами к одному resolver. Сохраните коды ответа, время и соответствующие CNI observations. Синтетический пример показывает, почему частичная успешность недостаточна; он не утверждает, что каждый большой ответ обязательно будет передан конкретным путём при любой конфигурации.
| Тест | Что сравнивать |
|---|---|
| UDP к resolver | Доставка и ответ первого транспорта |
| TCP к тому же адресу | Установка соединения и ответ |
| Без policy на стенде | Контрольная связность среды |
| С policy на стенде | Реальный эффект выбранных правил |
Исправьте 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; hardware security.