Система доменных имен: настройка и ускорение отклика

Система доменных имен: настройка для скорости и защиты

Сервис жив, контейнеры зеленые, healthcheck доволен. Пользователь получает DNS_PROBE_FINISHED_NXDOMAIN.

Система доменных имен — это не декоративная запись в панели регистратора. Это распределенная инфраструктура, через которую браузер вообще узнает, куда отправлять HTTP-запрос. Здесь есть иерархия серверов, кэши, BGP-маршрутизация, TTL, резервные NS и вполне реальные точки отказа. Один неверный A-record способен выключить сайт быстрее, чем любой кернел-паник.

Проблема обычно выглядит так:

dig example.com

;; connection timed out; no servers could be reached

Или хуже:

example.com. 86400 IN A 192.0.2.17

IP уже переехал. Кэш еще живет сутки. Пользователь — нет.

Как система доменных имен доводит запрос до IP

DNS не превращает имя в адрес одним магическим вызовом. Рекурсивный DNS-запрос проходит через несколько уровней. Браузер обращается к локальному резолверу операционной системы, система — к рекурсивному DNS-серверу провайдера или публичному резолверу. Если нужного ответа нет в кэше, резолвер начинает разбор иерархии.

Упрощенно цепочка выглядит так:

1. Рекурсивный резолвер проверяет собственный кэш.

2. Если записи нет, он обращается к корневой DNS-зоне.

3. Корневой сервер указывает, где искать доменную зону верхнего уровня: .com, .net, .ru и так далее.

4. Сервер зоны верхнего уровня возвращает авторитетные NS для конкретного домена.

5. Рекурсивный резолвер спрашивает авторитетный DNS-сервер о записи A, AAAA, MX, CNAME или другом типе.

6. Полученный ответ кладется в кэш на срок, заданный TTL.

7. Клиент получает IP и начинает уже не DNS-, а сетевое соединение с веб-сервером.

Корневых DNS-серверов принято считать 13. Это 13 логических адресов и идентификаторов, а не 13 физических машин в тринадцати комнатах. Все эти корневые серверы используют Anycast. Поэтому один и тот же IP анонсируется через BGP множеством физических экземпляров, распределенных по разным точкам присутствия.

Это важная разница. Anycast не выбирает сервер по линейке на карте. BGP выбирает маршрут на основе сетевой топологии и своих метрик. Ближайший физически узел может оказаться не ближайшим сетево. Интернет не обязан уважать геометрию. Он уважает таблицы маршрутизации, пока те не решат иначе.

Что происходит на каждом уровне

Корневая зона не знает IP вашего сайта. Ей не положено. Она знает, какие серверы отвечают за зоны верхнего уровня.

Серверы .com тоже не обязаны знать, где лежит приложение. Они знают делегацию домена: какие NS обслуживают example.com.

Авторитетный DNS уже отвечает за конкретную зону. Например:

• example.com A 203.0.113.10
• www.example.com CNAME example.com
• mail.example.com MX 10 mx.example.com
• api.example.com AAAA 2001:db8::10

На практике клиент может получить ответ не от авторитетного сервера, а от кэша рекурсивного резолвера. Это и ускоряет работу, и создает неприятную инерцию при изменениях. Если запись закэширована на 86 400 секунд, то обновить ее в панели сейчас не значит увидеть новый IP у всех пользователей сейчас.

DNS ускоряет только этап поиска адреса. Если приложение отвечает пять секунд, настройка Anycast не превратит его в быстрый сервис.

Рекурсивный запрос: где тратится время

Для пользователя DNS выглядит как одна операция. Для инженера это несколько сетевых переходов, проверок и таймеров. При холодном кэше резолверу приходится идти по иерархии. При теплом кэше он может вернуть ответ почти сразу.

На время ответа влияют:

• расстояние и сетевой маршрут до рекурсивного резолвера;
• наличие записи в кэше;
• доступность авторитетных NS;
• задержка между резолвером и авторитетной инфраструктурой;
• корректность IPv4- и IPv6-маршрутов;
• потери UDP-пакетов и переход на TCP;
• DNSSEC-проверки, если для зоны включена криптографическая валидация;
• ошибки конфигурации, из-за которых резолвер делает дополнительные запросы или получает SERVFAIL.

Проверять нужно не только ping. Он проверяет ICMP, а не полноценный путь DNS. Базовый инструмент — dig.

dig example.com A

dig example.com AAAA

dig example.com NS

dig @1.1.1.1 example.com A

dig +trace example.com

Последняя команда полезна для просмотра цепочки от корня до авторитетного сервера. Она не моделирует поведение каждого пользователя, но показывает, на каком уровне начинается проблема.

Типичный вывод, который стоит читать, а не просто копировать в тикет:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18421

;; ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

example.com. 300 IN A 203.0.113.10

Здесь NOERROR означает, что DNS-сервер успешно обработал запрос. ANSWER: 1 — запись найдена. Число 300 — оставшееся или исходное время кэширования в секундах, в зависимости от того, где и как получен вывод. Если вместо этого виден SERVFAIL, надо искать проблему в авторитетной зоне, DNSSEC, делегации или доступности NS. NXDOMAIN означает, что имя не существует в текущем представлении DNS. Это уже не просто медленный ответ.

Для диагностики полезно сравнивать несколько резолверов:

dig @1.1.1.1 example.com A

dig @8.8.8.8 example.com A

dig @9.9.9.9 example.com A

Но разные ответы не означают автоматически, что один резолвер сломан. Один мог обновить кэш, другой еще хранит старую запись в пределах TTL. Отдельный случай — провайдерские резолверы, которые могут иметь собственные ограничения кэширования и неидеально соблюдать заявленную модель TTL.

Anycast: как убрать лишнюю задержку

Unicast DNS строится проще: IP ведет к одному конкретному серверу или к ограниченному набору адресов. Если пользователь находится далеко от этой точки, каждый запрос проходит длинный сетевой путь. Для авторитетного DNS это особенно неприятно: именно он отвечает за первичный источник данных, и при холодном кэше рекурсивный резолвер должен до него добраться.

Anycast позволяет анонсировать один и тот же IP с нескольких площадок. BGP направляет запрос к узлу, который с точки зрения маршрутизации выглядит наиболее доступным. Если один узел исчезает, маршрут к нему можно убрать, а трафик уйдет к другому экземпляру.

Схема полезна в трех случаях:

1. Географически распределенная аудитория. Пользователи из разных регионов получают шанс попасть на более близкую DNS-точку.

2. Отказоустойчивость. Выход одной площадки не обязан выключать весь сервис.

3. Снижение сетевой задержки. Для холодных запросов уменьшается путь до авторитетного DNS.

В материалах о DNS часто приводят сравнение: для Anycast-резолвера Cloudflare 1.1.1.1 задержка может быть около 11 мс, тогда как у традиционной Unicast-схемы встречаются значения порядка 50–150 мс. Это не универсальный бенчмарк для любого клиента. Маршрут зависит от провайдера, региона, пиринга и текущего состояния сети. Но направление понятно: распределенный узел обычно выигрывает у единственного удаленного сервера.

Anycast не заменяет резервные DNS-серверы

Один Anycast-IP — не вся отказоустойчивость. Если за ним лежит один кластер с общей ошибкой конфигурации, вы получили распределенный способ раздавать одну и ту же поломку.

Для домена нужны как минимум авторитетные NS, размещенные так, чтобы отказ одной площадки, сети или провайдера не выбил всю делегацию. В идеальном мире они находятся в разных сетях и, по возможности, используют независимые точки присутствия. В реальном мире часто встречается два NS с одним hostname, в одном дата-центре и под управлением одной панели. Это не резервирование. Это два ярлыка на один костыль.

При выборе DNS-провайдера нужно смотреть не на красивую карту мира, а на эксплуатационную модель:

Anycast должен быть частью архитектуры, а не заклинанием из презентации. Если зона неправильно делегирована, Anycast не спасет. Если серверы не отвечают по UDP и TCP на 53-м порту, красивый анонс IP бесполезен. Если в зоне битая DNSSEC-подпись, распределенная ошибка будет распределенно возвращать SERVFAIL.

TTL: скорость изменений против стабильности кэша

TTL задается в секундах и определяет, как долго рекурсивный резолвер и промежуточные кэши могут использовать полученную запись без нового запроса к авторитетному серверу.

Распространенные значения:

• 60–300 секунд — период миграции или частых изменений;
• 3600–86400 секунд — стабильные записи, которые меняются редко.

Выбор зависит от характера записи. Для A и AAAA фронтенда при планируемом переезде нужен один подход. Для MX, NS и инфраструктурных записей — другой. Нельзя бездумно выставлять маленький TTL всему домену: это увеличивает количество запросов к авторитетной инфраструктуре и делает систему зависимее от ее доступности.

Высокий TTL дает кэширование и снижает нагрузку. Низкий TTL дает более быструю реакцию на изменение. Бесплатного варианта нет. DNS тоже выставляет счет, просто иногда не в рублях, а в количестве аварийных звонков.

Как переносить IP без DNS-лотереи

Допустим, сайт переезжает с 203.0.113.10 на 203.0.113.20.

Нормальная последовательность выглядит так:

1. За 24–48 часов до миграции снизить TTL нужных записей до 60–300 секунд.

2. Поднять новый сервер и проверить приложение напрямую по новому IP.

3. Настроить firewall, TLS, reverse proxy, мониторинг и healthcheck до переключения DNS.

4. Проверить ответы авторитетных NS.

5. Изменить A и AAAA, если используется IPv6.

6. Наблюдать трафик, ошибки приложения, сертификаты и обращения к старому адресу.

7. После стабилизации вернуть TTL к рабочему высокому значению.

Ключевой момент: снижение TTL за пять минут до переезда не помогает кэшам, которые уже получили старое значение на сутки. Новая настройка TTL начинает работать для новых ответов после того, как старые кэши истекут.

И еще одна неприятная деталь. TTL — рекомендация для кэширования, а не телепорт записи. Некоторые резолверы и сетевые устройства могут иметь собственные ограничения. Поэтому нельзя обещать, что значение 5 секунд мгновенно обновит DNS у всех пользователей.

Если меняются NS-серверы у регистратора, добавляется еще один слой инерции. Распространение данных делегации обычно занимает от 6 до 48 часов. На практике часть клиентов увидит обновление раньше, часть позже. В этот период старые и новые авторитетные серверы должны быть настроены согласованно. Иначе один пользователь получает новый IP, а другой — старую зону. Для отладки это выглядит как случайность. На самом деле это кэш.

Низкий TTL не ускоряет уже закэшированный ответ. Он только ограничивает срок жизни следующего кэша.

Где оптимизация DNS действительно работает

DNS редко является главным источником задержки загрузки страницы. После получения IP браузер еще должен установить TCP-соединение, выполнить TLS handshake, отправить HTTP-запрос, дождаться backend и получить ресурсы. Но DNS становится заметным в трех сценариях: холодный кэш, большое количество доменов и глобальная аудитория с неудачной маршрутизацией.

Сократить количество лишних имен

Каждый внешний домен может означать отдельный DNS-запрос. Шрифты, аналитика, CDN, платежный виджет, карты и рекламные скрипты создают собственную цепочку зависимостей. Один новый SaaS-сервис редко ломает архитектуру сразу, но постепенно страница превращается в каталог чужих DNS-зон.

Это не аргумент за отказ от CDN или внешних сервисов. Это аргумент за инвентаризацию. Если домен используется только одним старым скриптом, который никто не помнит, его сетевой вклад стоит оценить. Не каждый запрос надо оптимизировать вручную, но каждый лишний внешний dependency должен быть известен команде.

Не строить цепочки CNAME без причины

www может указывать на CNAME, который ведет на другое имя, а то — еще на одно. Каждый дополнительный переход усложняет резолвинг и диагностику. Цепочка может быть оправдана для CDN или управляемой платформы. Но когда она появляется просто потому, что так было проще кликнуть в панели, это обычный костыль.

Проверка:

dig www.example.com CNAME

dig www.example.com A

dig +trace www.example.com

Если имя неожиданно проходит через несколько внешних зон, команда должна понимать зачем. Иначе однажды внешний провайдер изменит делегацию, а локальная панель продолжит показывать зеленую галочку.

Проверять IPv6 отдельно

Наличие AAAA заставляет часть клиентов пытаться подключаться по IPv6. Если IPv6-маршрут объявлен, но сервис на нем не работает, пользователь может получить задержку до перехода на IPv4 или полный таймаут в зависимости от клиента и сетевой среды.

Проверять нужно оба ответа:

dig example.com A

dig example.com AAAA

И отдельно тестировать доступность приложения по IPv6. Запись AAAA — это не знак готовности. Это обещание клиенту: по этому адресу сервис работает. Если обещание ложное, удаление записи иногда полезнее героического дебага сетевого стека в пятницу вечером.

Безопасность DNS: зона не должна быть открытой книгой

Скорость без контроля превращается в ускоренную доставку неправильных данных. DNS-инфраструктура должна защищать как саму зону, так и канал управления ею.

DNSSEC защищает целостность ответа

DNSSEC добавляет цифровые подписи к DNS-данным. Резолвер с включенной валидацией может проверить, что ответ соответствует подписанной зоне и не был подменен по пути. Это не шифрование запроса. DNSSEC не скрывает, какое имя запрашивает клиент. Его задача — проверка подлинности и целостности данных.

При включении DNSSEC появляется дополнительная ответственность. Нужно следить за ключами, подписями, сроками их действия и корректностью цепочки доверия. Ошибка в DS-записи у регистратора или просроченная подпись способны превратить рабочую зону в SERVFAIL для валидирующих резолверов.

Диагностика:

dig example.com DNSKEY

dig example.com DS

dig +dnssec example.com A

В ответе наличие флагов и записей еще не доказывает, что вся цепочка настроена правильно. Проверяется именно связка от родительской зоны до авторитетного ответа.

Защитить авторитетные серверы от рекурсии

Авторитетный DNS для публичной зоны не должен превращаться в открытый рекурсивный резолвер. Если сервер отвечает на рекурсивные запросы всему интернету, он может использоваться для DNS amplification-атак. Режимы authoritative и recursive разделяют не для красоты конфигурационного файла.

Рекурсивные серверы должны принимать запросы только от разрешенных сетей, VPN или внутренних клиентов. Авторитетные NS должны отдавать публичные данные зоны, но не выполнять произвольный поиск имен от лица любого источника.

Минимальный набор эксплуатационных мер:

• закрыть рекурсию для внешних клиентов;
• ограничить административный доступ по ACL и ключам;
• разделить публичную и внутреннюю DNS-зоны;
• ограничить перенос зоны через AXFR/IXFR доверенными адресами;
• включить rate limiting там, где это поддерживает инфраструктура;
• мониторить SERVFAIL, NXDOMAIN, рост запросов и изменения NS;
• хранить конфигурацию зоны в резервной копии и в системе контроля версий;
• включить двухфакторную аутентификацию для регистратора и DNS-панели.

Особенно опасны случайные zone transfer. Если AXFR доступен из интернета, любой желающий может получить внутренние имена, адреса сервисов и структуру инфраструктуры. Это не всегда мгновенная уязвимость, но это бесплатная карта для следующего этапа разведки.

Отдельно контролировать регистратор

DNS-зона и делегация у регистратора — разные уровни. Можно идеально настроить A-запись, но если у домена сменились NS, пользователи будут обращаться вообще не туда.

Контроль домена включает:

• список текущих NS;
• статус блокировки домена;
• контактные данные и доступ к аккаунту;
• историю изменений;
• настройки DNSSEC и DS;
• резервный способ восстановления доступа.

Регистрировать домен на личную почту сотрудника, который ушел в отпуск на полгода, — архитектура уровня rm -rf без проверки текущего каталога.

Практический разбор аварии

Сценарий типовой. Команда переносит сайт на новый IP. Через час часть пользователей уже видит новый сервер, часть продолжает попадать на старый. В мониторинге два разных результата.

Сначала проверяем авторитетные NS:

dig @ns1.example-dns.net example.com A

dig @ns2.example-dns.net example.com A

Если ответы различаются, проблема не в распространении DNS как абстрактной стихии. Проблема в том, что авторитетные серверы обслуживают разные данные или один из них не обновился.

Затем проверяем рекурсивные резолверы:

dig @1.1.1.1 example.com A

dig @8.8.8.8 example.com A

dig @9.9.9.9 example.com A

Смотрим TTL:

dig example.com A +noall +answer

Если один резолвер возвращает старый адрес с TTL 7200, он имеет право продолжать это делать в пределах кэширования. Если прошло больше двух часов, а ответ не меняется, начинаем проверять локальные особенности резолвера и промежуточные кэши. Не начинаем с обвинения браузера. Браузер редко является самым интересным виновником.

Потом проверяем старый и новый IP напрямую:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

curl -I --resolve example.com:443:203.0.113.20 https://example.com/

Эта проверка минует DNS, но сохраняет нужный Host и TLS SNI. Так можно понять, работает ли приложение на обеих площадках и не забыта ли конфигурация виртуального хоста.

Если новый сервер отвечает 200, а старый отдает ошибку, его нельзя просто выключать сразу после смены записи. Часть мира еще законно будет приходить на старый адрес. На время миграции старый backend должен либо обслуживать запросы, либо отдавать контролируемый ответ, либо проксировать трафик на новый узел.

Что логировать

В DNS-мониторинге полезны не только доступность порта 53 и статус процесса. Нужны:

• время ответа от нескольких регионов;
• ответы A, AAAA, NS, MX;
• доля SERVFAIL и NXDOMAIN;
• расхождения между авторитетными NS;
• срок действия DNSSEC-подписей;
• изменения NS и DS;
• состояние BGP-анонсов для Anycast-инфраструктуры;
• рост объема запросов и аномальные шаблоны.

Лог без контекста мало полезен:

query: example.com A -> timeout

Нужны источник, тип запроса, сервер, транспорт, время и результат. Иначе расследование превращается в гадание по одному красному графику.

Конфигурация должна быть воспроизводимой

DNS-панель удобна до первого массового изменения. Дальше выясняется, что единственная копия зоны живет в голове администратора и нескольких скриншотах. Так не работает.

Зону нужно экспортировать, хранить в резервной копии и проверять перед публикацией. Формат зависит от используемого DNS-сервера или провайдера, но принцип одинаковый: изменения должны быть видимыми, повторяемыми и откатываемыми.

Перед миграцией фиксируют:

• текущие A и AAAA;
• авторитетные NS;
• TTL всех изменяемых записей;
• MX и записи почтовой защиты;
• TXT для SPF, DKIM, DMARC и верификаций сервисов;
• CNAME для CDN и внешних платформ;
• DNSSEC-состояние;
• адреса старых и новых серверов.

Отдельный риск — забытые TXT-записи. Их удаление может не повлиять на главную страницу, но сломать отправку почты, верификацию домена или автоматическое продление сертификата. Сайт визуально жив. Бизнес уже отправляет письма в пустоту.

Команды, которые стоит держать под рукой

Финальная проверка перед изменением:

1. dig example.com NS — получить список авторитетных серверов.

2. dig @ns1.example-dns.net example.com SOA — проверить SOA и серийный номер зоны.

3. dig @ns2.example-dns.net example.com SOA — сравнить серийный номер на втором NS.

4. dig example.com A +noall +answer — увидеть адрес и TTL.

5. dig example.com AAAA +noall +answer — не забыть про IPv6.

6. dig +trace example.com — пройти делегацию от корня до зоны.

7. dig +dnssec example.com A — проверить наличие DNSSEC-данных.

8. curl -I --resolve example.com:443:203.0.113.20 https://example.com/ — проверить новый сервер в обход DNS.

9. host -t MX example.com — убедиться, что почта не исчезла вместе с веб-переездом.

10. date -u — зафиксировать время изменения. Да, это банально. Через сутки в аварийном чате банальности внезапно становятся полезными.

Система доменных имен работает хорошо, когда ее почти не замечают. Для этого нужны распределенные авторитетные NS, осмысленный Anycast, TTL под конкретный сценарий, отдельная проверка IPv6, DNSSEC без шаманства и резервные копии зоны.

Главный вывод неприятно простой: DNS нельзя чинить только в момент миграции. Его нужно наблюдать постоянно. Любая запись должна иметь владельца, назначение и понятный план отката. И да — делайте бэкапы зоны, конфигурации регистратора и ключевых секретов. Рано или поздно кто-нибудь все равно нажмет не ту кнопку.