Прежде чем соединиться с API, приложение трижды спросило DNS о несуществующих именах. Сценарий отказа: растёт время исходящих вызовов, дежурный подозревает внешний сервис, но TCP SYN к нему ещё не отправлен. Задержка накопилась при разрешении имени. Покупать дополнительные реплики CoreDNS до разбора запросов — оплачивать последствия собственной конфигурации. В Pod с ClusterFirst обычно стоит ndots:5; собственный дефолт glibc — 1. Для api.example.com resolver сначала перебирает search. Если там три суффикса и каждый возвращает NXDOMAIN, получаем три бесполезных запроса и один полезный на каждый запрашиваемый тип записи. Это четырёхкратный объём, а не универсальное «утроение». A/AAAA, повторы и кэш меняют фактический счёт. Настройки описаны в документации Kubernetes и resolv.conf(5). Проверка: kubectl exec POD -- cat /etc/resolv.conf, затем kubectl exec POD -- getent ahosts api.example.com. В сетевом namespace Pod снимайте tcpdump -ni any -nn -vv 'port 53': нужны QNAME, типы записей и интервалы ответов. В CoreDNS сопоставляйте прирост corednsdnsrequeststotal и ответы NXDOMAIN. На ноде проверяйте sysctl net.netfilter.nfconntrackcount net.netfilter.nfconntrackmax и дельты drop/insertfailed через conntrack -S. Лишние DNS-пакеты сами по себе не доказывают переполнение conntrack. Перебор суффиксов выполняет resolver в userspace; ядро обслуживает получившийся трафик. Исправление проверяйте на одном workload: dnsConfig.options с name: ndots и value: "1", затем пересоздание Pod и повторный замер. Сначала проверьте используемые короткие имена сервисов: порядок поиска изменится. Для диагностического сравнения выполните getent ahosts api.example.com. — завершающая точка исключает search. Быстрые NXDOMAIN не обязаны давать заметную задержку; таймауты и очередь превращают лишний трафик в отказ. Разбор эксплуатации: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=ndots-5-v-resolv-conf-kak-defoltnaya
