🥷 Как работает DNS в Linux. Часть 2: уровень приложений и языков программирования 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 системной библиотеке (soc