DNS: TTL, search-домены, записи

Срок жизни ответа

Резолвер - это служба, которая по имени находит адрес. Своих данных у неё нет: она спрашивает серверы, отвечающие за зону, и складывает ответ в кэш - память о недавних ответах, чтобы не спрашивать снова. Насколько долго его можно там держать, говорит само число в ответе - TTL (time to live). У нашего домена это 600 секунд.

Проверил, как это выглядит. Три замера с паузой в четыре секунды дали остаток 534, 530 и 526 секунд: ответ всё это время лежал в кэше, а счётчик тикал вниз. А сервер зоны на тот же вопрос неизменно отвечает полными 600 - у него счётчик не идёт. Когда остаток дойдёт до нуля, резолвер сходит за свежим ответом.

// Отсюда процедура переезда, а не надежда на удачу. За сутки до смены адреса срок опускают до минуты-пяти, ждут, пока по старому значению истекут все кэши, меняют запись, дожидаются перетекания трафика и возвращают обычный срок. Старый сервер держат живым, пока на него ещё идут запросы. И отдельно проверяют приложения, которые узнают адрес один раз при запуске и потом держат его в памяти: им никакой срок не указ, их надо перезапускать.

резолвер

служба, которая находит адрес по имени и кэширует ответ

TTL

сколько ответ разрешено хранить в кэше

зона

часть дерева имён, за которую отвечают конкретные серверы

Ответ «такого имени нет» и файл hosts

Отсутствие записи - тоже ответ, и он тоже кэшируется. Спросил несуществующее имя в нашей зоне: первый раз ответ NXDOMAIN пришёл за 36 миллисекунд, второй раз за 1. Сколько разрешено помнить, что имени нет, написано в служебной записи зоны SOA (start of authority): у нас это 300 секунд. Поэтому только что созданная запись иногда «не видна» ещё несколько минут, и это не поломка.

Вторая вещь, которая ломает разбор полётов, - файл hosts. Он сильнее любого сервера имён, потому что смотрят в него раньше. Проверил в контейнере: обычный резолв нашего домена даёт настоящий адрес 147.45.234.86, а тот же контейнер с одной подсунутой строкой в hosts уверенно отвечает 10.9.9.9.

// Из этой пары растёт половина историй «у меня работает, у тебя нет». Прежде чем винить сеть, стоит посмотреть, что вообще отвечает на имя на конкретной машине, и сравнить с тем, что отдаёт сервер зоны. Заодно полезно помнить: у одного имени бывает несколько разных записей - адрес, серверы имён зоны, почтовые серверы, текстовые. У нашего домена, например, четыре сервера имён и две почтовые записи с разным приоритетом.

NXDOMAIN

ответ «такого имени не существует»; тоже кэшируется

SOA

служебная запись зоны; в ней и срок хранения отрицательных ответов

файл hosts

локальный список соответствий; смотрят в него раньше сервера имён

search-домены: лишние вопросы перед правильным ответом

Резолвер читает настройки из /etc/resolv.conf. Там три интересные строки: nameserver - куда спрашивать, search - какие суффиксы дописывать к неполным именам, options ndots - сколько точек должно быть в имени, чтобы считать его полным и спросить как есть.

В кластере, то есть в группе машин, где сервисы разложены по своим отсекам, обычно стоит ndots со значением 5 и пара search-доменов. Значит, имя api.github.com с двумя точками считается неполным: сначала спросят api.github.com.svc.cluster.local, потом api.github.com.cluster.local, получат отказ на оба и только третьим вопросом спросят настоящее имя. Замерил в контейнере с такими настройками: 5,81 миллисекунды на попытку против 1,03 у того же имени с точкой на конце. Точка на конце означает «имя полное, не дописывай ничего».

// Пятикратная разница на каждом обращении к внешнему сервису - это заметно, когда обращений тысячи. Лечится точкой в конце имени в настройках приложения или своими настройками резолвера для конкретного приложения с меньшим значением ndots.

// Отдельное правило, о котором спрашивают: на вершине зоны, то есть на домене без поддомена, нельзя поставить псевдоним CNAME. Причина механическая: CNAME означает «у этого имени больше нет никаких своих записей», а на вершине зоны обязаны лежать SOA и записи серверов имён. Поэтому провайдеры дают свою замену, ALIAS, которая раскрывает цель на их стороне и отдаёт готовый адрес.

search-домены

суффиксы, которые резолвер дописывает к неполному имени

ndots

порог точек, после которого имя считают полным

вершина зоны

сам домен без поддомена; там уже есть служебные записи

Как отвечать: «Сменили адрес домена, но часть трафика сутки шла на старый сервер. Почему?»

Из-за срока хранения ответа. У каждой записи есть время, в течение которого её разрешено держать в кэше, и пока оно не вышло, резолверы провайдеров, операционные системы и сами приложения отдают старый адрес. Я это видел вживую: сервер зоны на каждый вопрос отвечает полным сроком, а локальный кэш отдаёт тот же ответ с убывающим счётчиком и в источник не ходит. Поэтому переезд готовят заранее: за сутки опускают срок до минуты-пяти, ждут истечения старых кэшей, меняют запись, дожидаются перетекания трафика и возвращают обычное значение. Старый сервер держат живым, пока на него идут запросы. И отдельно перезапускаю сервисы, которые узнают адрес один раз при старте: им срок хранения ничего не диктует.

Ответ объясняет механику, даёт готовую процедуру и вспоминает про клиентов, которые кэшируют адрес сами. Последнее обычно и оказывается тем самым хвостом на сутки.

На чём валятся

• −Меняют адрес, не снизив срок хранения заранее, и ждут переезда сутки.
• −Забывают, что ответ «имени нет» тоже кэшируется, и паникуют из-за новой записи.
• −Списывают медленный резолв на сеть, не заглянув в настройки резолвера.
• −Не проверяют файл hosts на машине, где «не работает».
• −Пробуют поставить псевдоним на вершину зоны и упираются в отказ.