ALIAS/ANAME для apex: как подружить корневой домен с CDN и балансировщиками

Почему на apex запрещён CNAME и откуда берётся проблема

Классический DNS накладывает важное ограничение: на уровне zone apex (корня зоны, то есть записи для самого домена) не может быть записи CNAME. Это закреплено в спецификациях: на корне обязательно присутствуют SOA и NS, а CNAME конфликтует с ними по семантике. В результате связка «корневой домен → внешний хостнейм» стандартными средствами недоступна.

Современные CDN и управляемые load balancer чаще всего предоставляют точку входа в виде FQDN (например, xyz.example.net) и не закрепляют за вами статические A/AAAA. Это удобно для их масштабирования и отказоустойчивости, но усложняет привязку именно корня домена. Поддомены типа www легко привязать CNAME, а вот для apex нужен другой подход.

Что такое ALIAS/ANAME и flattening

Рынок выработал несколько эквивалентных по идее решений: записи ALIAS, ANAME и механизм «CNAME flattening». Они решают одну задачу — позволить в корне домена указывать «чужой» хостнейм (например, CDN или LB) и при этом отдавать клиентам конечные A/AAAA, как будто у вас прописаны реальные IP.

Ключевая деталь: «разворачивание» целевого имени в IP выполняет сам авторитативный DNS‑провайдер. Когда резолвер запрашивает A или AAAA для вашего apex, провайдер в реальном времени (или с кэшем) резолвит целевой FQDN и возвращает клиенту уже итоговые IP‑адреса. В результате:

• Клиент и кэширующие резолверы видят обычные A/AAAA на корне — совместимость сохраняется.
• Менять ничего на стороне CDN/LB не нужно: вы по‑прежнему указываете их «именной» endpoint.
• TTLs и подписи при DNSSEC контролирует авторитетная зона, которая синтезирует ответы.

Нюанс в терминологии:

• ALIAS и ANAME — псевдозаписи, доступные у ряда провайдеров DNS.
• «CNAME flattening» — не новая запись, а внутренняя логика провайдера, которая «сплющивает» CNAME в A/AAAA на выдаче. Для вас это выглядит как «CNAME на apex работает», но на проводах уходит уже набор IP.

TTL и кэширование

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

• Снижение TTL на целевом имени (у CDN/LB) ускоряет обновление IP на выходе flattening.
• Ваш apex TTL влияет на то, как долго ответ будет жить у рекурсивных резолверов конечных пользователей.
• Некоторые провайдеры позволяют настраивать собственный «минимальный» и «максимальный» TTL для результатов flattening.

DNSSEC и подпись синтезируемых ответов

При включённом DNSSEC авторитативный провайдер подписывает ответы своей зоной. При этом он не «подписывает» данные CDN/LB как таковые, а подписывает синтезированный набор A/AAAA в вашей зоне. Это критически важно: не у всех провайдеров flattening и ALIAS/ANAME совместимы с DNSSEC. Перед миграцией убедитесь, что ваш провайдер умеет корректно подписывать такие ответы, а также следит за актуальностью подписи при изменении целевого набора IP.

Сценарии: apex с CDN и load balancer

CDN

Частая задача: сделать так, чтобы корневой домен обслуживался CDN, который выдал вам имя вида client-id.cdnvendor.net. На www — просто CNAME, а на корень — ALIAS/ANAME на это имя. Дальше провайдер DNS развернёт этот FQDN в текущий набор edge‑IP, и клиенты будут подключаться напрямую к CDN.

На что обратить внимание:

• Если CDN использует геораспределённые ответы с учётом EDNS Client Subnet, flattening может «снять» геопривязку, потому что авторитативный провайдер резолвит запись со своей локации. Некоторые провайдеры поддерживают многоузловой резолвинг и учитывают географию, но это нужно проверять.
• Проверяйте наличие AAAA, если ваш сайт доступен по IPv6. Не все CDN выдают AAAA для конкретного тарифа/региона.
• Контролируйте TTL: при резких сменах пула IP у CDN маленькие TTL ускорят переключение пользователей.

Если вы активно управляете кэшем, пригодится практическое руководство про версионирование кэша в CDN.

Управляемые балансировщики (load balancer)

Многие облачные балансировщики фронтируют сервис именем типа lb-XXXX.provider.net. Они динамически меняют IP, масштабируются, а иногда ещё и регионально маршрутизируют трафик. Для apex применяем тот же подход — ALIAS/ANAME на этот FQDN. Это сохраняет все преимущества управляемого LB, и ваш корневой домен корректно указывает на актуальные адреса.

Тонкости:

• Проверьте, не требует ли LB hostname SNI в TLS. На практике это прозрачно: клиент подключается к IP из ответа, а сервер видит исходный Host и SNI домена. Проблем нет, если у LB загружен соответствующий сертификат. Оформите или перенесите SSL-сертификаты заранее.
• Если у вас активен sticky session на L7, изменение пула IP из‑за обновления flattening может кратковременно «раскачать» распределение сессий. В продакшне это обычно некритично, однако имеет смысл держать разумные TTL.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Совместимость и подводные камни

Соседство записей на apex

На корне домена часто нужны MX, TXT (SPF, проверка домена у внешних сервисов), CAA. ALIAS/ANAME с ними совместимы, потому что наружу всё равно уходит A/AAAA, а не CNAME. Это одно из ключевых преимуществ по сравнению с попытками поставить «настоящий» CNAME на apex (что невозможно). Про SPF, DKIM и DMARC подробно — в статье записи для аутентификации почты.

Геораспределение и точность выдачи

Flattening делается на стороне авторитативного провайдера. Если CDN/LB отдают разный набор IP в зависимости от географии или EDNS Client Subnet, результат может оказаться неидеальным для всех клиентов. Решения:

• Выбирать провайдера DNS, который резолвит целевое имя с нескольких геоточек и синтезирует ответы ближе к запросившему резолверу.
• Использовать географические политики непосредственно на уровне вашего провайдера DNS (например, GeoDNS), если это поддерживается и уместно.

Длина цепочки и устойчивость

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

DNSSEC

Запускайте flattening только у провайдера, который официально поддерживает DNSSEC для ALIAS/ANAME. Иначе вы рискуете получить несовместимый набор записей: подписи будут некорректны или отсутствовать. После включения проверьте ответы командой с флагом +dnssec и убедитесь, что выдаются валидные RRSIG на синтезируемые A/AAAA.

IPv6

Некоторые сервисы по умолчанию не публикуют AAAA. Если аудитория частично в сетях, где IPv6 предпочтителен, отсутствие AAAA ухудшит латентность (Happy Eyeballs, дополнительные попытки) и может снизить доступность в отдельных средах. Контролируйте наличие AAAA на целевом имени и периодически проверяйте выдачу вашего apex.

Пошаговое внедрение на продакшне

1) Инвентаризация текущей зоны

Зафиксируйте, что сейчас находится на apex: A/AAAA, MX, TXT, CAA, параметры SOA. Сохраните экспорт зоны — пригодится для отката. Если это новый проект, заранее оформите регистрацию доменов и подготовьте стартовую зону.

2) Проверка возможностей DNS‑провайдера

Убедитесь, что ваш провайдер поддерживает ALIAS/ANAME или flattening именно на zone apex и при включённом DNSSEC. Уточните, как он управляет TTL при синтезе, есть ли ограничения по размеру ответа и по количеству IP, и как устроено кэширование результатов.

3) Подготовка целевого FQDN

Определите целевой хостнейм CDN или load balancer. Проверьте, какие записи он публикует (A, AAAA), и какие TTL выставлены. Если целевой сервис поддерживает несколько регионов и вы ожидаете геопривязку, проверьте, как меняется выдача из разных локаций.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

4) Снижение TTL перед переносом

Чтобы мигрировать без простоя, заранее уменьшите TTL на текущих A/AAAA в зоне до 60–300 секунд и подождите как минимум старый TTL, чтобы кэши обновились. Это сократит «хвост» клиентов, которые ещё видят старые IP.

5) Добавление ALIAS/ANAME на apex

Создайте на корне домена запись ALIAS или ANAME на целевой FQDN. Не удаляйте текущие A/AAAA сразу — часть провайдеров позволяет временно сосуществовать псевдозапись и явно заданные IP, но финальная выдача должна идти из одного источника. Если провайдер не разрешает совместное существование, переключайтесь в «окно» с низкими TTL.

6) Валидация выдачи

После распространения изменений проверьте выдачу с разных резолверов и регионов. Смотрите, что apex отдаёт набор A/AAAA, соответствующий целевому FQDN, и что ответы подписаны, если включён DNSSEC. Обратите внимание на размер ответа: при большом числе IP возможен переход на TCP — это нормально.

7) Постепенное повышение TTL

Если выдача стабильна и мониторинг не фиксирует проблем, можно повысить TTL до рабочих значений (обычно 900–1800 секунд для корня, если часто меняющийся CDN не диктует иного). Это снизит нагрузку на авторитативный DNS и улучшит кэш‑хитрейт у рекурсоров.

8) Наблюдение и алерты

Добавьте проверки: периодический dig к вашим NS с контролем, что IP у apex соответствуют целевому FQDN, что присутствуют AAAA, что время ответа не аномально выросло. Полезно алертить на изменение числа адресов или резкое падение TTL со стороны целевого сервиса.

Примеры и проверки

Проверка, что на корне домена выдаются A/AAAA, а не CNAME:

dig +short A example.com
93.184.216.34

dig +short AAAA example.com
2606:2800:220:1:248:1893:25c8:1946

Проверка DNSSEC‑подписей на выдачу:

dig +dnssec example.com A

; <<>> DiG 9.x <<>> +dnssec example.com A
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; В ANSWER должен быть RRSIG для A

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

Частые вопросы

Можно ли просто оставить A/AAAA на корне и периодически обновлять IP CDN/LB вручную? Теоретически — да, практически это приводит к ошибкам и окнам недоступности, особенно если провайдер часто меняет пул адресов. ALIAS/ANAME автоматизируют синхронизацию.

Будет ли работать почта и верификации у сторонних сервисов? Да. MX и TXT живут параллельно с ALIAS/ANAME на корне, поскольку наружу уходит набор A/AAAA, а не CNAME. Ограничений, характерных для настоящего CNAME на apex, тут нет.

Как поступать с www? Для www удобен обычный CNAME на тот же целевой FQDN, что и у apex, либо на сам apex, если провайдер корректно «сплющивает» цепочку. Часто ещё включают редирект с www на корень или наоборот на уровне веб‑сервера/балансировщика.

Что с редиректами и HSTS? Это уже уровень приложения/веб‑сервера. ALIAS/ANAME лишь обеспечивает корректное разрешение имени в адрес.

Чеклист перед продакшен‑переключением

• Провайдер поддерживает ALIAS/ANAME или flattening на apex с DNSSEC.
• TTL на текущих A/AAAA снижен заранее, есть план отката и экспорт зоны.
• Определён целевой FQDN CDN/LB, проверены его A/AAAA и TTL, глубина цепочки минимальна.
• Тестовая зона или непиковое окно для переключения, включён мониторинг ответов.
• После внедрения проведена валидация: ответы, подписи, наличие AAAA, размер ответа, латентность.
• TTL возвращён к рабочим значениям, добавлены алерты на изменения.

Итоги

ALIAS/ANAME и CNAME flattening — стандартный способ «подружить» корневой домен с сервисами, которые предоставляют точку входа в виде имени, а не статических IP. При корректной настройке вы получаете совместимость со всеми клиентами и почтовой инфраструктурой, сохраняете DNSSEC, не теряете преимущества CDN и управляемых балансировщиков и уменьшаете риск ручных ошибок. Критично выбрать провайдера, у которого flattening реализован надёжно и предсказуемо, и соблюдать гигиену TTL, мониторинга и откатов.