CNAME-запись

канонического имени ( CNAME ) Запись — это тип записи ресурса в системе доменных имен (DNS), которая сопоставляет одно доменное имя (псевдоним) с другим ( каноническим именем). ^[1]

Это может оказаться удобным при запуске нескольких служб (например, FTP-сервера и , веб-сервера каждый из которых работает на разных портах) с одного IP-адреса . Например, можно использовать записи CNAME, чтобы указать ftp.example.com и www.example.com на запись DNS для example.com , которая, в свою очередь, имеет запись A , указывающую на IP-адрес. Затем, если IP-адрес когда-либо изменится, нужно будет записать это изменение только в одном месте в сети: в записи DNS A для example.com .

Записи CNAME всегда должны указывать на другое доменное имя, а не непосредственно на IP-адрес.

Подробности

Записи DNS CNAME указаны в RFC 1034 и разъяснено в разделе 10 РФК 2181 .

Записи CNAME обрабатываются особым образом в системе доменных имен и имеют ряд ограничений на их использование. Когда преобразователь DNS обнаруживает запись CNAME при поиске обычной записи ресурса, он перезапускает запрос, используя каноническое имя вместо исходного имени. Однако если преобразователю специально указано искать записи CNAME, вместо перезапуска запроса возвращается каноническое имя (правая часть). Каноническое имя, на которое указывает запись CNAME, может находиться в любом месте DNS, будь то локальный или удаленный сервер в другой зоне DNS .

Например, если есть зона DNS следующего вида:

NAME                    TYPE   VALUE
--------------------------------------------------
bar.example.com.        CNAME  foo.example.com.
foo.example.com.        A      192.0.2.23

при поиске записи A для бара. example.com выполняется, преобразователь увидит запись CNAME и перезапустит поиск foo.example.com , а затем вернет 192.0.2.23.

Возможная путаница

С помощью записи CNAME можно указать имя, например « bar.example.com », на « foo.example.com ». По этой причине во время обычного обсуждения « bar.example.com. » (левая) часть записи DNS может быть неправильно идентифицирована как «CNAME» или «CNAME». Однако это неточно. Каноническое (настоящее) имя « bar.example.com » — « foo.example.com ». Поскольку CNAME означает каноническое имя, в правой части находится фактическое «CNAME»; на той же стороне, что и адрес «А».

Эта путаница конкретно упоминается в RFC 2181 «Разъяснения к спецификации DNS». Левая метка — это псевдоним правой части (части RDATA), которая является (или должна быть) каноническим именем. ^[2] Другими словами, запись CNAME выглядит так:

bar.example.com.        CNAME  foo.example.com.

можно прочитать как:

« bar.example.com » — это псевдоним канонического имени (CNAME) « foo.example.com ». Клиент запросит « bar.example.com », и ответ будет « foo.example.com ».

Ограничения

Записи CNAME всегда должны указывать на другое доменное имя, а не на IP-адрес.
Если запись CNAME присутствует в узле, никаких других данных присутствовать не должно; это гарантирует, что данные канонического имени и его псевдонимов не могут различаться. (RFC 1034, раздел 3.6.2, RFC 1912, раздел 2.4). Исключение составляет случай DNSSEC , и в этом случае могут быть записи, связанные с DNSSEC, такие как RRSIG, NSEC и т. д. (RFC 2181, раздел 10.1). , когда используется
Записей CNAME, которые указывают на другие записи CNAME, следует избегать из-за их недостаточной эффективности, но они не являются ошибкой. ^[3] Таким образом, возможно создание неразрешимых циклов с записями CNAME, например:
```
foo.example.com.  CNAME  bar.example.com.
bar.example.com.  CNAME  foo.example.com.
```
запись CNAME не может присутствовать в вершине зоны. RFC 1034, раздел 4.2.1 ^[4] требует записи SOA в вершине зоны и раздела 3.6.2 RFC 1034. ^[5] требует, чтобы другие записи не присутствовали, если присутствует запись CNAME. Поэтому запись CNAME не может появиться в вершине зоны.
Записи CNAME, обслуживаемые записями DNAME, могут вызывать рекурсивные циклы в старых преобразователях. ^{[ нужны разъяснения ]}
Записи MX и NS никогда не должны указывать на псевдоним CNAME (раздел 10.3 RFC 2181). Так, например, зона не должна содержать такие конструкции, как:
```
example.com.      MX     0   foo.example.com.
foo.example.com.  CNAME  host.example.com.
host.example.com. A      192.0.2.1
```
Домены, используемые в командах SMTP MAIL и RCPT, могут не иметь записи CNAME. ^[6] На практике это может сработать, но на разных почтовых серверах может вести себя по-разному и иметь нежелательные последствия. ^[7]

запись DNAME

Запись DNAME или запись имени делегирования определяется RFC 6672 (исходный RFC 2672 устарел). Запись DNAME обеспечивает перенаправление (псевдоним) для поддерева дерева доменных имен в DNS. То есть все имена, заканчивающиеся определенным суффиксом, перенаправляются в другую часть DNS. Напротив, запись CNAME создает псевдоним для одного имени, а не для его поддоменов. Как и в случае с записью CNAME, поиск DNS будет продолжен путем повторной попытки поиска с новым именем. Сервер имен синтезирует запись CNAME, чтобы фактически применить запись DNAME к запрошенному имени — CNAME для каждого узла поддерева имеет тот же эффект, что и DNAME для всего поддерева.

Например, если есть зона DNS следующего вида:

foo.example.com.        DNAME  bar.example.com.
bar.example.com.        A      192.0.2.23
xyzzy.bar.example.com.  A      192.0.2.24
*.bar.example.com.      A      192.0.2.25

Поиск записи A для foo.example.com нет записи не вернет никаких данных, поскольку DNAME не является CNAME и непосредственно в foo A.

Тем не менее, поиск xyzzy. foo .example.com будет сопоставлен с DNAME и вернет запись A для xyzzy. bar .example.com — 192.0.2.24; если бы запись DNAME была записью CNAME, этот запрос вернул бы имя, которое не найдено.

Наконец, запрос foobar.foo.example.com будет сопоставлен с DNAME и возвратит 192.0.2.25.

запись ANAME

Некоторые управляемые платформы DNS реализуют нестандартный ALIAS. ^[8] или АНАМ ^[9] тип записи. Эти псевдозаписи управляются администраторами DNS, как записи CNAME, но публикуются и разрешаются (некоторыми) DNS-клиентами, такими как записи A. Записи ANAME обычно настраиваются так, чтобы указывать на другой домен, но при запросе от клиента отвечают IP-адресом. Хотя типы записей ANAME были отправлены на стандартизацию, ^[10] существуют и другие несоответствующие реализации, поэтому они могут делать все, что выберет владелец платформы DNS, в том числе существовать на вершине зоны и существовать для доменов, получающих почту.

Основное преимущество записей ANAME перед записями CNAME заключается в том, что их можно использовать в вершине зоны , в то время как преобразователь, соответствующий стандартам, не будет рассматривать доменные имена с записями CNAME как вершину зоны. ^[11] Кроме того, хотя DNS-клиенту требуется как минимум два запроса для преобразования CNAME в запись A в IP-адрес, ANAME перенесет второй и последующие запросы на сервер. Если DNS-сервер может разрешить запись A и кэшировать запрошенный IP-адрес более эффективно и с меньшей задержкой, чем его DNS-клиенты, тогда DNS-клиент сможет разрешить запрос быстрее.

Тип записи ANAME был представлен в IETF в качестве проекта стандарта. Однако срок действия последнего проекта документа истек в январе 2020 года. ^[10] и был заменен рядом предложений, самое последнее из которых касается типов записей SVCB и HTTPS. ^[12]

См. также

Ссылки

^ Мокапетрис, П. (ноябрь 1987 г.). «RFC 1035 — Доменные имена — реализация и спецификация» . Рабочая группа по интернет-инжинирингу . Проверено 16 марта 2019 г.
^ «RFC 2181: Разъяснения к спецификации DNS» . IETF . Июль 1997 года . Проверено 9 марта 2011 г.
^ Мокапетрис, П. (ноябрь 1987 г.). «RFC 1034 — Доменные имена — концепции и возможности» . Рабочая группа по интернет-инжинирингу . Проверено 15 июля 2019 г.
^ Мокапетрис, П. (ноябрь 1987 г.). «RFC 1034, раздел 4.2.1» . Проверено 15 июля 2019 г.
^ Мокапетрис, П. (ноябрь 1987 г.). «RFC 1034, раздел 3.6.2» . Проверено 15 июля 2019 г.
^ Брейден, Р. (октябрь 1989 г.). «RFC1123 — ПОЧТА — SMTP и RFC-822» . Проверено 23 июля 2020 г.
^ Бернштейн, диджей «Записи CNAME в почте» . Проверено 3 июня 2011 г.
^ «АЛИЯС Рекордс» . Проверено 26 июля 2019 г.
^ «АНАМЭ Рекордс» . Проверено 24 сентября 2022 г.
^ Jump up to: ^а ^б «Псевдонимы DNS для конкретных адресов (ANAME)» . 08.07.2019 . Проверено 26 июля 2019 г.
^ Голдласт, Сюзанна; Алмонд, Кэти. «CNAME на вершине зоны» . База знаний ISC с открытым исходным кодом . Консорциум Интернет-систем . Проверено 8 апреля 2023 г.
^ Шварц, Б.; Бишоп, М.; Нигрен, Э. (11 марта 2023 г.). «Привязка службы и спецификация параметров через DNS (DNS SVCB и HTTPS RR)» . Проверено 8 апреля 2023 г.

Внешние ссылки

RFC 1912 неверен – анализ ограничений CNAME Мэн Вен Вонга
RFC 2219 – Использование псевдонимов DNS для сетевых служб

[1] Мокапетрис, П. (ноябрь 1987 г.). «RFC 1035 — Доменные имена — реализация и спецификация» . Рабочая группа по интернет-инжинирингу . Проверено 16 марта 2019 г.

[2] «RFC 2181: Разъяснения к спецификации DNS» . IETF . Июль 1997 года . Проверено 9 марта 2011 г.

[RFC1034-3] Мокапетрис, П. (ноябрь 1987 г.). «RFC 1034 — Доменные имена — концепции и возможности» . Рабочая группа по интернет-инжинирингу . Проверено 15 июля 2019 г.

[4] Мокапетрис, П. (ноябрь 1987 г.). «RFC 1034, раздел 4.2.1» . Проверено 15 июля 2019 г.

[5] Мокапетрис, П. (ноябрь 1987 г.). «RFC 1034, раздел 3.6.2» . Проверено 15 июля 2019 г.

[RFC1123-6] Брейден, Р. (октябрь 1989 г.). «RFC1123 — ПОЧТА — SMTP и RFC-822» . Проверено 23 июля 2020 г.

[DJB_CNAME-7] Бернштейн, диджей «Записи CNAME в почте» . Проверено 3 июня 2011 г.

[8] «АЛИЯС Рекордс» . Проверено 26 июля 2019 г.

[9] «АНАМЭ Рекордс» . Проверено 24 сентября 2022 г.

[ietf-aname-10] Jump up to: ^а ^б «Псевдонимы DNS для конкретных адресов (ANAME)» . 08.07.2019 . Проверено 26 июля 2019 г.

[11] Голдласт, Сюзанна; Алмонд, Кэти. «CNAME на вершине зоны» . База знаний ISC с открытым исходным кодом . Консорциум Интернет-систем . Проверено 8 апреля 2023 г.

[12] Шварц, Б.; Бишоп, М.; Нигрен, Э. (11 марта 2023 г.). «Привязка службы и спецификация параметров через DNS (DNS SVCB и HTTPS RR)» . Проверено 8 апреля 2023 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]