CoreDNS захлебнулся именами, которых нет. Типовой сценарий отказа: растут DNS QPS, NXDOMAIN и задержка приложения; поверхностный диагноз — «не хватает DNS-реплик». Но запрос к внешнему API ещё не дошёл до TCP: клиент занят перебором поисковых суффиксов. Покупка дополнительных нод превращает ошибку конфигурации в регулярный платёж. Важная поправка: ndots:5 — типовая настройка Kubernetes, у glibc по умолчанию ndots:1. Для api.example.com двух точек недостаточно: сначала search, потом исходное имя. При трёх суффиксах, NXDOMAIN на каждом и успешном внешнем ответе получаем четыре запроса одного типа вместо одного. Утроение получается при двух суффиксах, а не автоматически от числа 5. A/AAAA, кэши и повторы меняют итоговый счёт. Поведение описано в resolv.conf(5), конфигурация Pod — в документации Kubernetes. Улики собираем внутри проблемного Pod: cat /etc/resolv.conf и getent ahosts api.example.com; DNS снимаем в его сетевом namespace командой tcpdump -ni any -s0 -vv 'port 53'. Считаем QNAME и типы, сопоставляем с NXDOMAIN и задержкой CoreDNS. На ноде проверяем sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max, conntrack -S и nstat -az UdpInErrors UdpRcvbufErrors. Нужны приросты drop/insert_failed и UDP-ошибок за интервал: повышенный QPS сам по себе не доказывает переполнение conntrack. Суффиксы приписывает резолвер в userspace, ядро обслуживает получившийся трафик. Исправление проверяем на одном workload: dnsConfig.options с name: ndots и value: "1", затем сравниваем запросы на одно разрешение имени и задержку при одинаковой нагрузке. Проверяем межпространственные имена service.namespace: порядок поиска изменится. Завершающая точка в абсолютном DNS-имени исключает search, но её поддержку нужно проверить в приложении. Автоскейлер не обязан финансировать непрочитанный resolv.conf. https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=ndots-5-v-resolv-conf-kak-defoltnaya
