Детектив сбоя: приложение в K3s начинает сыпать таймаутами, CoreDNS уходит в CPU под 90 процентов, conntrack растет, внешние резолверы фиксируют всплеск NXDOMAIN. Поверхностный мониторинг обвиняет сеть и провайдера DNS. Реальность в resolv.conf пода: options ndots:5 и три search domain от неймспейса кластера. glibc считает любое имя с менее чем пятью точками относительным и сначала перебирает все суффиксы: svc.cluster.local, cluster.local, узел, и только потом идет наружу. На один логический запрос мы получаем 8-12 фактических, умноженных на A плюс AAAA. Проверка: tcpdump -i any port 53 на ноде, grep ndots /etc/resolv.conf внутри пода, метрика coredns_dns_requests_total по rcode NXDOMAIN резко выше NOERROR. Лечение локальное и скучное: в Deployment добавить dnsConfig options name ndots value 2, для внешних FQDN с точкой в конце вообще один запрос. После фикса QPS к CoreDNS упал в три раза, p99 резолва с 480 мс до 12 мс, conntrack перестает пухнуть от бессмысленного UDP. Никакой магии BBR и тюнинга сети здесь не было. Разбор подобных дефолтов ядра и glibc, которые ломают прод в три часа ночи: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=ndots-5-v-resolv-conf-kak-defoltnaya