glibc
Хотя официально считается, что glibc не реализует полноценный DNS-кэш (в отличие от демонов вроде systemd-resolved, dnsmasq или nscd), в её реализации резолвера есть несколько механизмов, которые действуют как очень простое и ограниченное кэширование или оптимизация запросов.
— Во-первых, используется NSS (Name Service Switch), который может быть сконфигурирован для работы с nscd, systemd-resolved или другими кэширующими компонентами. Например, с помощью следующей директивы в файле nsswitch.conf:
hosts: files resolved myhostnameГде вместо resolved также может быть и nscd. Хотя nscd — отдельный демон, он поставляется вместе с glibc в большинстве дистрибутивов и тесно интегрирован с ней.
Когда nscd запущен и настроен (часто включен по умолчанию для passwd, group, hosts), библиотеки glibc (getaddrinfo, gethostbyname) будут обращаться к нему первыми. Nscd кэширует ответы до истечения их TTL. Кэширование в этом случае происходит вне самой библиотеки glibc, но glibc использует этот кэш прозрачно для приложения.
🔍 В реализации DNS-резолвера внутри glibc (в файле resolv/res_query.c и др.) содержатся оптимизации, такие как повторное использование сокета и игнорирование TTL при повторных запросах внутри одного вызова, которые можно рассматривать в качестве некого микро-кэша в контексте одного вызова функции разрешения. Эти оптимизации не сохраняют результаты между разными вызовами getaddrinfo или между разными процессами и действуют только в рамках одного системного вызова функции.
— Модули NSS (особенно files) кэшируют данные из статических файлов. Например, nss-files (работающий в том числе с /etc/hosts) по сути "кэширует" содержимое этих файлов в памяти процесса после их первого чтения (до перезагрузки процесса или вызова, инвалидирующего кэш NSS). Это не DNS-кэширование в чистом виде, но влияет на процесс разрешения имен, в котором участвует DNS.
Java
Java поддерживает встроенный DNS-кэш с гибкими настройками времени жизни записей.
Особенности работы
Без использования Security Manager (начиная с Java 11 - это поведение по умолчанию):
- положительные ответы кэшируются на 30 секунд (максимум, даже если DNS-сервер указал больший TTL);
- отрицательные ответы (NXDOMAIN) — 10 секунд.
С использованием Security Manager:
- положительные ответы кэшируются бесконечно (риск устаревших записей);
- отрицательные ответы не кэшируются.
Управление
Настройки указываются в свойствах JVM. TTL в секундах для успешных запросов:
networkaddress.cache.ttl=60
TTL для неудачных запросов (NXDOMAIN):
networkaddress.cache.negative.ttl=10
Варианты значений:
0 — отключить кэширование;
-1 — кэшировать бессрочно (только для положительных ответов).
Способы настройки
1. Аргументы JVM:
java -Dnetworkaddress.cache.ttl=60 -jar app.jar
2. В коде (глобально для JVM):
Security.setProperty("networkaddress.cache.ttl", "60");
Go
Go использует две модели резолвинга:
- через cgo — вызывает системный getaddrinfo() (включая NSS). Работает через системные настройки (/etc/nsswitch.conf, /etc/resolv.conf);
- Pure Go resolver — реализует собственный DNS клиент, минуя системные библиотеки.
Выбор резолвера:
GODEBUG=netdns=go # встроенный резолвер с кэшем
GODEBUG=netdns=cgo # через системный getaddrinfo()При использовании Pure Go резолвера Go реализует in-memory DNS-кэш внутри процесса. Этот кэш хранит успешные (A, AAAA, CNAME) и отрицательные (NXDOMAIN) ответы, соблюдая их TTL. Кэш имеет фиксированный размер (реализует эвристику LRU), хранится в памяти процесса и разделяется между горутинами внутри этого процесса, но не разделяется между разными процессами или экземплярами приложений.
Python
По умолчанию модуль socket и большинство стандартных библиотек (включая requests, urllib3) используют системный вызов getaddrinfo() и не имеют встроенного кэша DNS.
•
requests → использует urllib3, который делегирует разрешение DNS системной библиотеке (socket.getaddrinfo()), без кэширования.