Оптимизация DNS в Linux: ускорили резолвинг на 80% для 50 серверов

Компания «КлаудСофт» — разработчик SaaS-платформы для автоматизации бизнес-процессов. Инфраструктура: 50 серверов Ubuntu 22.04 в двух дата-центрах, 12 микросервисов на Go и Python, трафик — 15 000 HTTP-запросов в секунду.

Клиент обратился к нам с проблемой: P99-латентность API выросла с 200 мс до 800 мс за последние два месяца без видимых изменений в коде. Внутренняя команда добавляла серверы, но это не помогало. Мы провели аудит и обнаружили, что 65% времени ответа уходит на DNS-резолвинг внутренних и внешних доменов.

Корень проблемы оказался в непонимании того, как именно работает DNS в Linux — это не «просто запрос к серверу», а многоуровневый процесс с множеством подводных камней. Подробнее о нашей экспертизе — на itfresh.ru.

Прежде чем оптимизировать, нужно понять, как приложение преобразует доменное имя в IP-адрес. Вопреки распространённому заблуждению, это не просто «отправить UDP-пакет на DNS-сервер». Цепочка вызовов:

Приложение (curl, Go-сервис, Python-скрипт)
    ↓
getaddrinfo()  — функция стандартной C-библиотеки
    ↓
NSS (Name Service Switch)  — определяет источники резолвинга
    ↓
libnss_dns.so / libnss_files.so  — загружаемые модули
    ↓
libresolv  — формирует DNS-пакеты
    ↓
DNS-сервер  — отвечает на запрос

Практически все современные Linux-приложения — от curl до systemd — используют функцию getaddrinfo() для преобразования доменных имён. Эта функция возвращает список структур addrinfo с IP-адресами, типами сокетов и протоколами.

Мы начали с инструментальной диагностики DNS-резолвинга на проблемных серверах. Первый инструмент — strace для анализа системных вызовов при запросе curl:

# Трассировка DNS-резолвинга curl
$ strace -e trace=network,write curl -o /dev/null -s https://api.external-service.com

# Вывод (ключевые строки):
connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7
connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.2")}, 16) = 0
sendmmsg(7, ...) = 2    # Отправляем A и AAAA запросы
poll([{fd=7, events=POLLIN}], 1, 5000) = 1
recvfrom(7, ..., 2048, 0, ...) = 56    # Получаем ответ
recvfrom(7, ..., 65536, 0, ...) = 114  # Дополнительные записи
connect(8, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("203.0.113.45")}, 16) = 0

Здесь видно полный процесс: попытка подключения к NSCD (кэширующий демон, отсутствует), создание UDP-сокета, отправка запросов, получение ответов. Задержка на этапе poll() показывала время ожидания ответа от DNS-сервера.

Часть сервисов «КлаудСофт» работала в Alpine-контейнерах, которые используют библиотеку musl вместо glibc. Поведение DNS-резолвинга кардинально отличается:

Мы обнаружили, что Alpine-контейнеры с musl отправляли DNS-запросы последовательно (A, затем AAAA), не поддерживали options rotate для балансировки между DNS-серверами и не кэшировали результаты. Это удваивало количество DNS-запросов по сравнению с glibc-системами.

Конфигурация /etc/resolv.conf на серверах клиента была дефолтной — без каких-либо оптимизаций:

# До оптимизации — /etc/resolv.conf
nameserver 10.0.0.2
search cloudsoft.local

Мы оптимизировали каждый параметр:

# После оптимизации — /etc/resolv.conf
nameserver 10.0.0.2
nameserver 10.0.0.3
nameserver 8.8.8.8
search cloudsoft.local
options timeout:1 attempts:2 rotate ndots:2 single-request-reopen

Самый значительный прирост дало внедрение локального DNS-кэширования. Без кэша каждый HTTP-запрос к внешнему API требовал полный цикл DNS-резолвинга (2-50 мс). При 15 000 запросов в секунду это генерировало огромную нагрузку на DNS-серверы и добавляло задержку к каждому запросу.

При аудите мы обнаружили, что некоторые языки программирования имеют собственные DNS-резолверы, которые полностью игнорируют системные настройки.

Go по умолчанию использует встроенный Pure Go DNS-резолвер, который читает /etc/resolv.conf напрямую, минуя NSS и getaddrinfo(). Это означает, что настройки NSS, NSCD-кэш и /etc/nsswitch.conf не действуют:

# Принудительное использование CGO-резолвера в Go
# (задействует getaddrinfo() и системный кэш)
export GODEBUG=netdns=cgo

# Или в коде
import _ "unsafe" // для CGO
import "net"

func init() {
    // Принудительно используем cgo resolver
    net.DefaultResolver.PreferGo = false
}

Python модуль dns.resolver из dnspython также имеет собственный резолвер, минуя системный. Стандартный socket.getaddrinfo() использует системный резолвер:

# Python: системный резолвер (правильно)
import socket
result = socket.getaddrinfo('api.example.com', 443)

# Python: прямой DNS (минует кэш!)
import dns.resolver
answers = dns.resolver.resolve('api.example.com', 'A')

На сервисах «КлаудСофт» мы обнаружили, что 3 Go-сервиса использовали Pure Go резолвер и не попадали в системный кэш, генерируя тысячи лишних DNS-запросов.

После комплексной оптимизации DNS на всех 50 серверах мы провели замеры:

Основной выигрыш дало локальное кэширование (снижение DNS-запросов на 96%) и исправление конфигурации Go-сервисов (переход на CGO-резолвер с использованием системного кэша). Настройка resolv.conf обеспечила корректный failover и сократила worst-case с 30 до 6 секунд.

Проект был выполнен за 1 неделю командой из 2 инженеров ITFresh без даунтайма для сервисов клиента.