DNS

Зачем DNS

Машины общаются по IP-адресам. Люди их запоминают плохо. DNS — это телефонный справочник: имя -> IP.

Без DNS пришлось бы хардкодить IP во все ссылки и письма, а при смене сервера обновлять их везде. DNS даёт устойчивый слой имён поверх изменяющихся адресов.

Как идёт резолв

Браузер хочет открыть www.example.com. Что происходит:

1. /etc/hosts — локальные переопределения. Порядок источников задаёт /etc/nsswitch.conf, и files (то есть hosts) обычно стоит до dns, поэтому запись в /etc/hosts перебивает любой DNS.
2. Локальный кеш resolver/ОС — «видел такое имя недавно?» Если да и TTL живой, вернули из кеша. Не нашли?
3. DNS-resolver из /etc/resolv.conf — идём к нему. Обычно это роутер, корпоративный DNS или публичный (8.8.8.8, 1.1.1.1).
4. Recursive resolver делает работу сам:
   • спрашивает корневые серверы: "кто знает про .com?",
   • спрашивает TLD-сервер .com: "кто знает про example.com?",
   • спрашивает authoritative-сервер example.com: "какой IP у www.example.com?",
   • возвращает ответ + TTL, кеширует у себя.
5. Браузер получил IP, открывает TCP-соединение.

В реальности почти всегда срабатывает кеш — кто-то на твоём resolver'е уже спрашивал это имя минуту назад.

Типы записей

Главные, которые встретишь в работе:

Тип	Что хранит	Зачем
A	IPv4-адрес	example.com → 93.184.216.34
AAAA	IPv6-адрес	example.com → 2001:db8::1
CNAME	алиас на другое имя	www.example.com → example.com
MX	почтовый сервер	куда слать почту на @example.com
TXT	произвольный текст	SPF, DKIM, DMARC, проверка владения доменом
NS	name server	какие DNS-серверы отвечают за зону
PTR	обратный резолв (IP -> имя)	logging, фильтры

CNAME — тонкое место: по RFC 1034 CNAME не может сосуществовать с другими записями на том же имени. А на корне зоны (example.com, без префикса) всегда есть обязательные SOA и NS, поэтому apex-CNAME запрещён. Облачные провайдеры обходят это через виртуальный ALIAS/ANAME, который снаружи выглядит как A-запись.

TXT-записи нагружают много чем сразу. Типичный домен имеет 5+ TXT: SPF (v=spf1 ...), DKIM (открытый ключ почтовой подписи), DMARC (v=DMARC1; p=reject; ...), плюс верификации Google, Yandex, и т.д.

TTL и кеш

Каждая запись приходит с TTL (time-to-live) в секундах. Это сколько resolver'у можно её кешировать. Типичные значения:

• TTL 60-300с — для часто меняющихся записей (балансировщики, CDN).
• TTL 3600 (час) — стандарт по умолчанию.
• TTL 86400 (день) — для статичных записей.

Перед миграцией (смена IP, переезд почты) TTL заранее снижают до 60-300с за сутки-двое, чтобы старые ответы быстрее протухли. После миграции возвращают обратно.

dig

dig example.com                 # A-запись + полный ответ
dig example.com +short          # только адрес
dig example.com MX              # MX-записи
dig example.com TXT             # TXT-записи
dig @8.8.8.8 example.com        # спросить конкретный resolver
dig +trace example.com          # пройти всю цепочку резолва от root

dig +trace — полезен, когда есть подозрение, что один из resolver'ов отдаёт устаревший кеш или что-то ломается на этапе делегирования.

Старый аналог nslookup ещё встречается, но dig информативнее.

dig не входит в базовую установку: на Debian и Ubuntu он приезжает с пакетом bind9-dnsutils, на RHEL и Rocky — с bind-utils. На чужом сервере, куда ничего не поставить, простую проверку «резолвится ли имя» делает getent hosts: он идёт по тому же пути, что и приложения, через /etc/nsswitch.conf.

$ getent hosts example.com
93.184.216.34   example.com

/etc/resolv.conf и /etc/hosts

/etc/resolv.conf — где написано, к какому DNS обращаться. Минимальный вид:

nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com

search — дописывает суффикс к коротким именам: db превратится в db.example.com.

На Ubuntu и Debian править этот файл руками бесполезно. Там /etc/resolv.conf — симлинк на файл systemd-resolved, внутри один nameserver 127.0.0.53: локальная заглушка, которая уже сама знает настоящие серверы. Правки затрёт при следующем обновлении сетевых настроек.

$ ls -l /etc/resolv.conf
/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
$ resolvectl status         # какие серверы используются на самом деле

Реальные адреса DNS показывает resolvectl status, а менять их надо там, откуда их берёт systemd-resolved: в netplan, NetworkManager или /etc/systemd/resolved.conf.

/etc/hosts — локальные переопределения, обходящие DNS совсем. Самые частые случаи:

127.0.0.1   localhost
::1         localhost
192.168.1.50  legacy-server

Полезно для дев-стенда, проверки перед DNS-миграцией ("давай посмотрим, как ляжет, если у клиента будет уже новый IP"), отладки.

Ловушка: TTL и "у меня DNS не работает"

Сменил IP в DNS — кому-то всё ещё открывается старый сервер. Не магия — это TTL и кеш где-то по цепочке: ОС, браузер, resolver провайдера, его upstream, корпоративный кеш.

Что делать:

• очистить локальный кеш ОС (sudo resolvectl flush-caches на современных Linux, sudo systemd-resolve --flush-caches на старых, ipconfig /flushdns на Windows, sudo dscacheutil -flushcache на macOS),
• проверить, что resolver не врёт: dig @1.1.1.1 example.com - обращение в обход локального,
• подождать TTL. Если у тебя был TTL 3600, до часа недодоступности у части клиентов норма.

Профилактика: снижай TTL за сутки до миграции, а не в день её проведения.

Что важно запомнить

DNS превращает имя в IP, кешируется на каждом уровне.

A/AAAA для IP, CNAME для алиаса, MX для почты, TXT для проверок и SPF.

TTL — сколько кешировать ответ. Перед миграцией снижаем заранее.

dig — инструмент диагностики, dig @8.8.8.8 host спрашивает конкретный resolver.

/etc/hosts обходит DNS целиком — полезно для дев-стенда.

В следующем уроке — HTTP и HTTPS, в котором живут 90% твоего сетевого трафика.