Разрешение имён DNS

Путь разрешения начинается с nsswitch.conf — не с DNS.

/etc/nsswitch.conf — файл политик, который сообщает glibc, какие источники использовать для разрешения имён и в каком порядке.

grep ^hosts /etc/nsswitch.conf
# hosts:    files dns

# Значение:
# 1. files  → проверить /etc/hosts первым
# 2. dns    → затем запросить DNS (через /etc/resolv.conf или systemd-resolved)

# На Ubuntu 22.04+ с systemd-resolved:
# hosts:    files mdns4_minimal [NOTFOUND=return] dns
# mdns4_minimal обрабатывает .local-имена (Avahi/mDNS)
# [NOTFOUND=return] означает: если mdns говорит "не найдено" — остановиться,
# НЕ переходить к dns. Вот почему *.local-имена никогда не достигают DNS-сервера.

Приложение вызывает getaddrinfo("api.internal"). glibc читает nsswitch.conf и поочерёдно вызывает каждый источник, пока один не вернёт результат или авторитетное «не найдено».

/etc/hosts — первый источник в цепочке.

/etc/hosts — статический файл, проверяемый до любого сетевого запроса (когда files стоит первым в nsswitch.conf). Каждая строка сопоставляет IP одному или нескольким именам.

cat /etc/hosts
# 127.0.0.1   localhost
# 127.0.1.1   host-a
# ::1         localhost ip6-localhost ip6-loopback
# 10.0.0.20   db-primary db-primary.internal

# Добавить временное переопределение (полезно до распространения DNS):
echo '10.0.0.100  staging-api.internal' | sudo tee -a /etc/hosts

# Проверить немедленно (getent следует nsswitch, /etc/hosts побеждает):
getent hosts staging-api.internal
# 10.0.0.100  staging-api.internal

# Удалить запись когда закончишь — /etc/hosts не DNS,
# устаревшие записи сбивают с толку спустя месяцы

/etc/hosts — самое быстрое возможное переопределение имени. ОС читает его при каждом поиске — никакого кэша для сброса. Риск: записи накапливаются и конфликтуют с реальными DNS-записями спустя месяцы.

/etc/resolv.conf — какой DNS-сервер использовать.

Когда срабатывает источник dns, glibc читает /etc/resolv.conf для нахождения адреса сервера имён.

cat /etc/resolv.conf
# nameserver 127.0.0.53          ← заглушка systemd-resolved (Ubuntu по умолчанию)
# options edns0 trust-ad
# search internal.example.com    ← добавляется к неквалифицированным именам

# Или на Debian без systemd-resolved:
# nameserver 10.0.0.1            ← роутер/DNS-ретранслятор

# Директива search:
# При запросе "db-primary" (без точек) резолвер добавляет домен поиска:
# → сначала пробует "db-primary.internal.example.com"
# Если не находит — пробует "db-primary" как есть

# Проверить используемый резолвер:
resolvectl status   # на системах с systemd-resolved
# или
cat /run/systemd/resolve/resolv.conf  # реальная конфигурация upstream

Распространённая ловушка: /etc/resolv.conf является симлинком (lrwxrwxrwx /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf) на Ubuntu. Если инструмент вроде dhclient или openvpn перезапишет его обычным файлом, ты обходишь systemd-resolved и теряешь кэширование и функции split-DNS, не замечая этого.

systemd-resolved: заглушка на 127.0.0.53.

На Ubuntu 18.04+ и Debian 12+ systemd-resolved запускает локальную DNS-заглушку на 127.0.0.53:53. Все DNS-запросы от glibc идут туда; resolved обрабатывает кэширование, DNSSEC и маршрутизацию split-DNS к разным upstream по интерфейсу.

# Проверить статус:
systemctl status systemd-resolved

# Запросить заглушку напрямую:
dig @127.0.0.53 example.com

# Посмотреть upstream по интерфейсу:
resolvectl status
# Global
#   DNS Servers: 10.0.0.1
# Link 2 (ens3)
#   Current DNS Server: 10.0.0.1
#   DNS Servers: 10.0.0.1
#   DNS Domain: internal.example.com

# Сбросить кэш resolved (полезно при смене DNS-записи):
sudo resolvectl flush-caches

# Проверить разрешение имени и его источник:
resolvectl query db-primary.internal
# db-primary.internal: 10.0.0.20
#   -- Information acquired via protocol DNS ...

Resolved — не просто прокси; он ведёт таблицу маршрутизации DNS по интерфейсам. VPN-туннели могут подключать DNS-серверы для .vpn.internal без замены глобального резолвера — поэтому resolvectl status показывает разные DNS для разных интерфейсов.

getent hosts vs dig: ключевое различие.

# getent hosts следует полной цепочке nsswitch — тот же путь, что у приложения
getent hosts db-primary
# 10.0.0.20  db-primary

# dig говорит напрямую с сервером имён — обходит /etc/hosts и nsswitch полностью
dig db-primary
# ;; ANSWER SECTION:
# db-primary.    0  IN  A  10.0.0.20
# (или NXDOMAIN, если имя только в /etc/hosts — dig его не найдёт)

# Практическое правило:
# getent hosts — проверить то, что увидит приложение
# dig — проверить чистый DNS (обходя локальные переопределения)

# dig с явным сервером:
dig @127.0.0.53 db-primary.internal      # тест заглушки systemd-resolved
dig @10.0.0.1 db-primary.internal        # тест upstream напрямую

# Тип запроса (по умолчанию A/AAAA):
dig MX example.com
dig TXT example.com

Классическое расхождение: dig api.internal возвращает NXDOMAIN, но приложение работает, потому что имя в /etc/hosts. Или наоборот: dig api.internal возвращает IP, но приложение получает NXDOMAIN из-за устаревшей записи в /etc/hosts, которая перекрывает DNS.