Рано или поздно каждый упирается в эту стену. Ваш CDN или платформа даёт вам хост — что-то вроде your-app.platform.example — и говорит «направьте свой домен сюда через CNAME». Вы идёте добавлять CNAME для yourdomain.com, а ваш DNS-провайдер отказывается. Или принимает — и ваша почта перестаёт работать. Или предлагает нечто под названием ALIAS-запись, которую никто никогда не объяснял.
Дело не в том, что ваш провайдер придирается. Это правило 1987 года, которое до сих пор управляет всем, и как только вы поймёте, почему оно существует, вся эта категория проблем перестаёт быть загадочной.
Три типа записей, кратко
A-запись. Сопоставляет имя с IPv4-адресом. yourdomain.com → 203.0.113.5. Вот и всё. Самая простая вещь, которую делает DNS.
AAAA-запись. То же самое, для IPv6. Всё, что верно для A-записей, верно и здесь.
CNAME-запись. Сопоставляет имя с другим именем. www.yourdomain.com → your-app.platform.example. Это псевдоним, и он действительно полезен: когда платформа меняет свои IP-адреса, вам ничего не нужно делать. Вы указали на их имя, а они управляют тем, что за ним стоит.
Эта косвенность — вся ценность. Она же — источник ограничения.
Правило, которое всё ломает
Вот правило, простым языком:
Имя, у которого есть CNAME-запись, не может иметь никаких других записей.
Не «не должно». Не может. Это указано в оригинальных RFC по DNS и подтверждено позже. CNAME не означает «также известен как» — он означает «это имя является тем именем, спрашивайте там». Как только резолвер видит CNAME, он полностью отказывается от исходного имени и перезапускает поиск с целевого имени. Любая другая запись, находящаяся на исходном имени, по определению недостижима, поэтому спецификация вообще запрещает её существование.
Теперь примените это к вашему корневому домену.
Ваш апекс зоны — yourdomain.com без ничего перед ним — обязан иметь записи. Не опционально. Каждая зона обязана иметь SOA-запись и NS-записи на своём апексе. Именно они делают её зоной. Без них нечего обслуживать.
Итак:
- Апекс обязан иметь SOA и NS-записи.
- CNAME не может сосуществовать с другими записями.
- Следовательно, апекс не может иметь CNAME.
Это и есть всё объяснение. Это не ограничение вашего провайдера и не устаревшая причуда, которую нужно исправить. Это арифметика. И это также означает, что если бы вы каким-то образом всё же навязали CNAME своему апексу, вы бы одновременно уничтожили свои MX-записи, свою SPF TXT-запись и записи верификации домена — все они тоже живут на апексе.
Именно поэтому www.yourdomain.com прекрасно работает как CNAME. Это не апекс. У него нет SOA, нет NS и ничего другого, что обязано там существовать. Он свободен быть псевдонимом.
Так что же такое ALIAS-запись?
Провайдерам надоело это объяснять, поэтому они построили обходной путь. Вы увидите его под несколькими именами:
- ALIAS (Route 53, DNSimple и другие)
- ANAME (некоторые провайдеры)
- CNAME flattening (Cloudflare)
Это одна и та же идея. Ни одна из них не является настоящим типом DNS-записи. Нет ALIAS ни в одном RFC, и ни один резолвер нигде не знает, что это такое.
Что происходит на самом деле: вы настраиваете ALIAS на своём апексе, указывающий на хост. Когда приходит запрос, ваш DNS-провайдер разрешает это имя сам, в реальном времени, и возвращает полученные IP-адреса как обычные A-записи. Клиент видит обычную A-запись и ни о чём не подозревает. Косвенность произошла на стороне сервера, ещё до того, как кто-то спросил.
Это чистое решение реальной проблемы, и в большинстве случаев это правильный ответ. Но оно не бесплатно.
Разрешение имени происходит из местоположения вашего DNS-провайдера, а не вашего пользователя. Это компромисс, о котором никто не упоминает. Если целевой хост использует GeoDNS или CDN-маршрутизацию — а он почти наверняка использует, обычно именно поэтому вы указываете на хост, а не на IP — то он возвращает разные адреса в зависимости от того, кто спрашивает. С обычным CNAME цепочку проходит резолвер пользователя, поэтому CDN видит нечто близкое к пользователю и возвращает ближайший edge-узел. С ALIAS цепочку проходит ваш DNS-провайдер, поэтому CDN видит вашего DNS-провайдера и возвращает edge-узел рядом с ним.
Результат — сайт, который работает, но направляет часть пользователей не в тот регион. Провайдеры смягчают это, выполняя разрешение из множества локаций и передавая информацию о подсети клиента, с переменным успехом. Стоит знать, что этот механизм существует, потому что иначе фраза «CDN отправляет моих пользователей на другой континент» остаётся глубоко непонятной.
Поведение TTL — решение провайдера, а не ваше. Они синтезируют ответ, поэтому сами выбирают, как долго его кэшировать и как часто перепроверять цель. Если у цели меняется IP, скорость, с которой вы это заметите, зависит от их реализации.
Оно не переносится. ALIAS — это специфичная для провайдера настройка. Перенесите свою зону в другое место, и она не переедет вместе с вами — вам придётся настраивать её заново на том диалекте, который использует новый провайдер, или обнаружить, что он вообще этого не поддерживает.
Ещё два правила CNAME, которые постоянно нарушают
MX- и NS-записи никогда не должны указывать на CNAME. Цель MX- или NS-записи должна быть именем с адресной записью — A или AAAA. Указание MX на CNAME прямо запрещено, а последствия непоследовательны, а не однозначны: некоторые почтовые серверы всё равно это учитывают, другие отклоняют, так что почта доставляется от одних отправителей и не доставляется от других без очевидной закономерности.
Это правило больно бьёт, потому что выглядит работающим. Ваши собственные тесты проходят. Часть отправителей не может до вас достучаться, и вы узнаёте об этом спустя недели.
Цепочки CNAME разрешены, но обходятся дорого. CNAME может указывать на имя, которое само является CNAME. Каждое звено — ещё один круговой запрос, прежде чем кто-либо получит адрес, и резолверы ограничивают, сколько звеньев они будут проходить, прежде чем сдаться. Два перехода обычно нормально. Цепочки, построенные указанием на вендора, который указывает на другого вендора, который указывает на CDN, становятся медленными и хрупкими, и ломаются так, что это выглядит как перемежающиеся проблемы DNS.
Если вы когда-либо не уверены, насколько глубока цепочка на самом деле, DNS-запрос показывает каждое звено — полную цепочку от вашего имени до конечного адреса, которая часто длиннее, чем кто-либо предполагал.
Выбор на практике
| Ситуация | Использовать |
|---|---|
| У вас стабильный IP-адрес | A-запись |
| Поддомен, указывающий на платформу или CDN | CNAME |
| Апекс, указывающий на платформу или CDN | ALIAS / ANAME / flattening |
| Апекс, а у провайдера нет ALIAS | Редирект apex → www, CNAME на www |
| Цель MX или NS | Только A-запись. Никогда не CNAME |
Четвёртая строка — старая школа, и она всё ещё абсолютно верна: обслуживайте редирект на апексе, разместите реальный сайт на www, и сделайте CNAME для www. Множество крупных сайтов делают именно так. Это стоит один редирект и обходит всю проблему целиком.
Мысленная модель
CNAME — это не указатель, который можно повесить рядом с чем-то ещё. Это редирект для всего имени целиком — а имя, которое было перенаправлено, не может одновременно быть почтовым назначением, апексом зоны или чем-либо ещё.
Всё остальное следует из этого. Апекс не может быть CNAME, потому что апекс обязан быть чем-то ещё. ALIAS существует, потому что это неудобно. У ALIAS есть особенности геолокации, потому что кто-то другой выполняет поиск от вашего имени. MX не может указывать на CNAME, потому что редирект — это не адрес.
Одно правило, несколько следствий — и спустя достаточно времени вам больше не нужно каждый раз выводить его заново. Когда что-то отказывается принимать CNAME, первый вопрос: что ещё обязано существовать на этом имени? Ответ почти всегда — и есть объяснение.