CNAME (Canonical Name) — запись, задающая псевдоним: имя A указывает, что оно является алиасом другого (канонического) имени. При запросе имени с CNAME авторитативный сервер возвращает CNAME-запись, и резолвер продолжает поиск уже под каноническим именем.

Формат (zone-файл):

www.example.com. 3600 IN CNAME target.example.net.

Как работает (резолв):

  1. Клиент/резолвер запрашивает www.example.com.
  2. Сервер возвращает CNAME www.example.com -> target.example.net.
  3. Резолвер автоматически запрашивает A/AAAA (или другие нужные) записи для target.example.net.
  4. В результате клиент получает конечный A/AAAA (и кешируются и CNAME, и конечные записи — каждая со своим TTL).

Ключевые ограничения и правила (важно):

  • CNAME не может сосуществовать с другими RR (кроме DNSSEC-записей типа RRSIG/NSEC). Нельзя иметь одновременно CNAME и, скажем, MX, TXT, A и т.п. для одного и того же имени.
  • CNAME нельзя ставить на “apex” (зону верхнего уровня / root записи), потому что apex содержит NS и SOA — и CNAME не может сосуществовать с ними. Для этого используют провайдерские ALIAS/ANAME или A/AAAA.
  • MX/NS targets не должны указывать на CNAME. По спецификациям считается неверным, если запись MX или NS указывает на имя, которое является CNAME; это приводит к некорректному поведению и проблемам совместимости.
  • Избегайте длинных цепочек CNAME. Каждая дополнительная переадресация увеличивает задержку и шанс ошибки; также возможны циклы — избегайте их.

Типичные сценарии использования:

  • Алиас для CDN: www.example.com CNAME cdn.provider.net, при этом провайдер обслуживает cdn.provider.net. Провайдер должен корректно обслуживать TLS/SNI для кастомного имени.
  • Удобство миграции: временно направить множество поддоменов на новое имя без правки их A/AAAA.
  • Упрощение внутренней структуры: app.internal CNAME app-prod.example.net.

Влияние на TLS/HTTPS и почту:

  • TLS: если клиент обращается к www.example.com, сертификат сервера должен покрывать www.example.com, даже если по DNS это CNAME на CDN. CDN должен обслуживать правильный сертификат (обычно через SNI или выдачу сертификата для пользовательского домена).
  • Почта: нельзя делать так, чтобы MX указывал на имя, которое само является CNAME — это нарушает практики и может приводить к отказу доставки.

Практические рекомендации:

  • Не используйте CNAME в зоне apex; используйте ALIAS/ANAME/ANAME-подобные фичи у DNS-провайдера, если нужно псевдоним на корневом имени.
  • Не комбинируйте CNAME с другими записями для того же имени.
  • Минимизируйте длину CNAME-цепочек; избегайте циклов.
  • При использовании CNAME к CDN проверьте, что CDN поддерживает ваш домен с корректным TLS/SNI и что он не ломает почту (MX).

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

  • dig +short CNAME www.example.com
  • dig www.example.com — увидите сначала CNAME, затем A/AAAA.
  • dig +trace www.example.com — полезно, чтобы увидеть, как резолвится цепочка через делегирование.
  • Для отладки CDN/TLS нужно дополнительно проверять порт 443 и SNI (например, openssl s_client -connect host:443 -servername www.example.com).