Запись назначения синонима каноническому имени «Canonical Name». Особенности использования синонимов при работе с NS и MX записями.

Здесь рассматриваются особенности применения синонимов доменных имен, которые задаются записью описания ресурсов CNAME. Разбираются основные ошибки при комбинировании записи определения синонимов с записями MX и NS.

Здесь рассматриваются особенности применения синонимов доменных имен, которые задаются записью описания ресурсов CNAME. Разбираются основные ошибки при комбинировании записи определения синонимов с записями MX и NS.

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

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

Запись CNAME определяет синонимы для реального (канонического) доменного имени машины, которое определено в записи типа A.

Имя в записи типа A называют каноническим именем машины. Формат записи CNAME можно определить следующим образом:

[nickname] [ttl] IN CNAME [host]

Поле nickname определяет синоним для канонического имени, которое задается в поле host.

Запись CNAME чаще всего используется для определения имен информационных сервисов Internet, которые установлены на хосте. Так следующий пример определяет синонимы, для компьютера, на котором установлены серверы протоколов http и gopher:

$ORIGIN polyn.kiae.su.
olga IN A 144.206.192.2
www IN CNAME olga.polyn.kiae.su.
gopher IN CNAME olga.polyn.kiae.su.

Директива управления $ORIGIN введена здесь только для определения текущего имени зоны. Две записи типа CNAME позволяют организовать доступ к серверам, используя имена, характерные для соответствующих Интернет-сервисов.

Именно такие синонимы и используются в описаниях зон при обращении к таким системам как Yahoo(www.yahoo.com) или Altavista (www.

altavista.digital.com).

Ниже приведен пример обращения к www.netscape.com:

> www.netscape.com
Server: IRIS.polyn.kiae.su
Address: 144.206.192.10

;; res_nmkquery(QUERY, www.netscape.com, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, id = 12635, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 5, authority records = 3, additional = 3

QUESTIONS:
www.netscape.com, type = A, class = IN
ANSWERS:
-> www.netscape.com
canonical name = netscape.com
ttl = 900 (15M)
-> netscape.com
internet address = 64.12.180.19
ttl = 900 (15M)
-> netscape.com
internet address = 64.12.180.22
ttl = 900 (15M)
-> netscape.com
internet address = 64.12.151.211
ttl = 900 (15M)

-> netscape.com
internet address = 64.12.151.215
ttl = 900 (15M)
AUTHORITY RECORDS:
-> netscape. com
nameserver = ns.netscape.com
ttl = 86400 (1D)
-> netscape.com
nameserver = ns1.netscape.com
ttl = 86400 (1D)
-> netscape.com
nameserver = ns2.netscape.com
ttl = 86400 (1D)
ADDITIONAL RECORDS:
-> ns.netscape.com
internet address = 198.95.251.10
ttl = 3600 (1H)
-> ns1.netscape.com
internet address = 149.174.213.7
ttl = 3600 (1H)
-> ns2.netscape.com
internet address = 207.200.73.80
ttl = 3600 (1H)

————
Name: netscape.com
Addresses: 64.12.180.19, 64.12.180.22, 64.12.151.211, 64.12.151.215
Aliases: www.netscape.com

>

Из отчета nslookup видно, что www.netscape.com является синонимом netscape.com, которая, в свою очередь, имеет несколько адресных записей. В авторитативной секции отклика указаны доменные имена серверов зоны netscape.com, а в дополнительной секции их IP-адреса.

Правда, при обращении к серверу протокола http, который является базовым для системы World Wide Web, изменение имени машины, с которой осуществляют обслуживание? может быть вызвано многими причинами: перенаправлением запроса на другой сервер, использование виртуального сервера и т. п.

При использовании записей типа CNAME следует проявлять осторожность. Некоторые администраторы рекомендуют вообще от нее отказаться и если нужно еще одно имя, то лучше указать еще одну A-запись для того же самого IP-адреса.

На самом деле, применение записей CNAME строго регламентировано в RFC 1034 и RFC 1912. Смысл применения CNAME — назначение синонима для канонического имени. Описание ресурсов для канонического имени и для синонима должны совпадать.

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

Администратору зоны следует понимать, как DNS работает с CNAME записями описания зоны. Поиск CNAME осуществляется только в том случае, если запросы другого типа, скажем поиск адресной записи, не дали положительного отклика. Т.е. сервер получает запрос к своей зоне на адресную запись; он не находит такой записи, но в описании зоны есть CNAME запись, которая соответствует запрашиваемому доменному имени; сервер на запрос возвращает эту запись и адресную запись, если последняя находится в описании этой же зоны. Если же CNAME ссылается на каноническое имя из другой зоны, то в отклике будет только CNAME.

Вот часть отчета nslookup, где указан запрос и ответ на него без секции данных секции авторитативности отклика сервера и дополнительной секции:

————
Got answer:
HEADER:
opcode = QUERY, id = 51763, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 2, additional = 2

QUESTIONS:
user.webstatistics.ru, type = A, class = IN
ANSWERS:
-> user. webstatistics.ru
canonical name = host.webstatistics.ru
ttl = 3 (3S)
-> host.webstatistics.ru

internet address = 144.206.192.63
ttl = 3 (3S)

Из этого отчета следует, что мы искали адресную запись для user.webstatistics.ru, но ее в описании зоны нет, поэтому сервер нашел CNAME и адрес для канонического имени синонима.

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

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

Вот пример из той же зоны, что и раньше, но мы в зоне реализовали цепочку CNAME:

;; res_nmkquery(QUERY, user1.

webstatistics.ru, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, id = 47112, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 3, authority records = 2, additional = 2

QUESTIONS:
user1.webstatistics.ru, type = A, class = IN
ANSWERS:
-> user1.webstatistics.ru
canonical name = user.webstatistics.ru
ttl = 3 (3S)
-> user.webstatistics.ru
canonical name = host.webstatistics.ru
ttl = 3 (3S)
-> host.webstatistics.ru
internet address = 144.206.192.63
ttl = 3 (3S)
AUTHORITY RECORDS:
-> webstatistics.ru
nameserver = ns.webstatistics.ru
ttl = 3600 (1H)
-> webstatistics.ru
nameserver = ns4.nic.ru
ttl = 3600 (1H)
ADDITIONAL RECORDS:
-> ns.webstatistics.ru
internet address = 144.206.192.60

ttl = 3600 (1H)
-> ns4.nic.ru
internet address = 194. 226.96.8
ttl = 19465 (5h34m25s)

————
Name: host.webstatistics.ru
Address: 144.206.192.63
Aliases: user1.webstatistics.ru, user.webstatistics.ru

Сервер (BIND версии 9) вернул нам правильный IP-адрес, перебрав цепочку CNAME.

На самом деле многие «глупые»(stub) клиенты не умеют работать с цепочками CNAME, и по это причине информационный ресурс, к которому обращаются по имени-синониму, будет не доступен.

Таким образом, не смотря на то, что в спецификации цепочки синонимов запрещены явным образом, в реальной жизни они могут появляться и появляются.

Наш пример показывает цепочку в одной зоне, но гораздо хуже межзонные цепочки. Межзонная цепочка CNAME плоха тем, что не отслеживает исчезновение адресной записи в другой зоне, за которую сервер, содержащий в своей зоне CNAME, не отвечает. Как итог — появление «подвешенных» CNAME записей.

Теперь вернемся к вопросу о том, что для доменного имени, которое является синонимом, может существовать только одна запись описания ресурса и эта запись — CNAME. Что происходит, когда это правило нарушается?

Первая распространенная ошибка, на которую указывают и все RFC и FAQ — использование CNAME в совокупности с NS записями. Рассмотрим пример (RFC 1912):

podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4

В данном случае для домена Podunk.xx. определено два сервера доменных имен ns1 и ns2, но одновременно указано, что Podunk.xx. — это синоним для канонического имени mary. Mary, ns1 и ns2 — это не полные имена. В нашем случае данное обстоятельство значения не имеет. BIND, встретив CNAME, обе записи NS проигнорирует, т.к. будет следовать соответствующим стандартам и рекомендациям.

На самом деле, можно усмотреть противоречие между тем, что было описано в алгоритме обработки CNAME записей и тем, что описано абзацем выше. Ведь при поиске NS мы найдем NS записи, и, следовательно, нам не будет выдана CNAME запись.

Все правильно, если NS записи будут загружены в память сервером доменных имен при его запуске. Но сервер проверяет при своем запуске корректность описания зоны. Он просто проигнорирует все записи, отличные от CNAME, которые содержат синоним в первом поле записи описания ресурсов.

Вот пример сообщения сервера для этого случая (BIND 9):

Oct 14 12:55:51 generate named[136]: dns_master_load: webstatistics.ru:21: zone.
webstatistics.ru: CNAME and other data
Oct 14 12:55:51 generate named[136]: zone webstatistics.ru/IN: loading master fi
le webstatistics.ru: CNAME and other data

А вот фрагмент описания зоны, на которую он ругается:

zone IN NS ns.wenstatistics.ru.
IN CNAME subzone
subzone IN A 144.206.192.61

BIND 9, найдя такую ошибку, в зоне вообще обслуживать ее не будет. Точнее говоря, если он ее уже обслуживает, то при перезагрузке (restart) он старое описание на новое в своих кэшах не заменить, а при начальном запуске его не загрузит.

На самом деле ситуация «CNAME на NS» часто встречается в том случае, когда хотят определить IP адрес для доменного имени зоны. Если быть более точным, то администратор хочет некоторому хосту в зоне присвоить то же имя, что и всему домену. Например, это нужно для обеспечения доступа к веб-серверу по именам www.kyky.ru и kyky.ru. В этом случае описание вида:

$TTL 3600
@ IN SOA ns.kyky.ru hostmaster.kyky.ru (
20021013 3h 30m 30d 3600 )
IN NS ns.kyky.ru.
IN NS ns.provider.ru.
IN CNAME server.kyky.ru.
server IN A 192.168.0.1
www IN CNAME server.kyky.ru.
ns IN CNAME server.kyky.ru.

будет ошибочным. Мы потеряем не только NS записи зоны kyky.ru, но и вообще все записи этой зоны. Правильным был бы следующий вариант:

$TTL 3600
@ IN SOA ns.kyky.ru hostmaster.kyky.ru (
20021013 3h 30m 30d 3600 )
IN NS ns.kyky.ru.
IN NS ns.provider.ru.
IN A 192.168.0.1
server IN A 192.168.0.1
ns IN A 192.168.0.1
www IN CNAME kyky.ru.

В принципе, вместо «kyky.ru.» в CNAME можно было бы указать и символ @.

Раз уж мы заговорили о символе «@», то следует заметить, что этот символ в поле nickname применяться не должен, т. к., фактически, тем самым утверждается, что текущее имя зоны — это синоним другого имени, и, следовательно, описание этой зоны следует проигнорировать.

Скорее всего, идея об использовании символа «@» в CNAME возникла при желании назначить имя зоны конкретному хосту, который имеет IP-адрес. Движение мысли в этом случае понятно: хост — это синоним зоны, поэтому мы и назначаем зоне IP-адрес через имя хоста. Если вдуматься, то такая логика неверна. Хост и домен — это совершенно разные понятия. Если вы хотите хосту, а точнее IP-адресу поставить в соответствие еще одно имя, то делать это следует посредством адресной записи, как в приведенном выше примере. При этом совершенно не имеет значения тот факт, что назначаемое имя — это имя зоны.

На самом деле, при исправлении описания зоны мы поправили еще одну запись. В первоначальном варианте имя ns.kyky.ru является синонимом для server.kyky.ru. Таким образом, в первоначальном варианте существовала недопустимая цепочка в рамках описания зоны, которую сервер может сам обнаружить. В новом варианте мы запись CNAME заменили на адресную запись.

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

Косвенно понятно, почему введен запрет. В конце концов, число серверов корневой зоны ограничено числом 13 по одной простой причине — размеру пакета UDP. На самом деле цепочки без конца и края также упрутся в то же ограничение, ведь в пакете нужно передавать и CNAME-ы и IP-адрес. Если изменять логику обработки запросов и заставлять клиента итеративно обращаться к серверу по CNAME цепочке, то где предел такого цикла обращений.

На самом деле есть еще одна причина запрета на использование CNAME для NS и MX, но прежде, чем ее назвать и обсудить, мы рассмотрим проблемы, связанные с совместным использованием MX и CNAME.

Трудность поиска ошибок этого сорта в том, что приходится работать с двумя информационными сервисами одновременно. Ошибки описания зоны проявляются не при поиске IP-адресов или доменных имен, а при доставке электронной почты.

Ошибки совместного применения CNAME и MX заключается в том, что в записи MX синоним используют как в первом поле MX, так и в последнем поле MX. Ни первое, ни второе делать не следует.

Первый вариант:

$ORIGIN kyky.ru
@ IN A 192.168.0.2
kuku IN CNAME kyky.ru.
IN MX 10 kyky.ru.

В данном случае, мы хотим отправлять почту на kuku.kyky.ru через kyky.ru. Правило запрета существования других записей описания ресурса для синонима кроме единственной CNAME записи, которая этот синоним и вводит, заставляет сервер проигнорировать MX.

Правильным бы было:

$ORIGIN kyky.ru
@ IN A 192.168.0.2
IN MX 10 kyky.ru.
kuku IN CNAME kyky.ru.

В данном случае, если почта отправляется на kuku.kyky.ru, то по CNAME сервер доменных имен возвращает kyky. ru адресную запись для kyky.ru. Почтовый клиент соединяется с этим IP-адресом и отправляет на него почту. Другое дело настройки почтового шлюза на kyky.ru. Если он не распознает имя kuku.kyky.ru как свое собственное, либо, если у него нет правил пересылки для kuku.kyky.ru, то возникнут проблемы с доставкой почты, но это уже не проблема DNS.

Теперь другой вариант. Синоним используется в последнем поле записи MX:

$ORIGIN kyky.ru
@ IN A 192.168.0.2
IN MX 10 kuku.kyky.ru.
kuku IN CNAME kyky.ru.

Этот случай аналогичен случаю использования в качестве имени сервера в NS записи синонима, заданного через CNAME. По этой причине мы сейчас возобновим обсуждение проблемы, начатое в части, касающейся NS записей.

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

Следовательно, клиент, который попадает при поиске MX или NS на синоним
Должен инициировать дополнительный запрос адресной записи. Особенность почтовых систем такова, что они такого запроса в большинстве случаев не инициируют. Как следствие — почта не может быть доставлена, если речь идет о MX записи.

Вот пример с записью NS:

> set debug
> set q=ns
> webstatistics.ru.
Server: [144.206.192.60]
Address: 144.206.192.60

;; res_nmkquery(QUERY, webstatistics.ru, IN, NS)
————
Got answer:
HEADER:
opcode = QUERY, id = 41793, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 0, additional = 1

QUESTIONS:
webstatistics.ru, type = NS, class = IN
ANSWERS:
-> webstatistics.ru
nameserver = ns. webstatistics.ru
ttl = 3600 (1H)
-> webstatistics.ru
nameserver = ns4.nic.ru
ttl = 3600 (1H)
ADDITIONAL RECORDS:
-> ns4.nic.ru
internet address = 194.226.96.8
ttl = 86297 (23h58m17s)

————
webstatistics.ru
nameserver = ns.webstatistics.ru
ttl = 3600 (1H)
webstatistics.ru
nameserver = ns4.nic.ru
ttl = 3600 (1H)
ns4.nic.ru
internet address = 194.226.96.8
ttl = 86297 (23h58m17s)
>

Мы запрашиваем NS для зоны webstatistics.ru. В качестве ответа получаем доменные имена серверов доменных имен, но ns.webstatistics.ru — это синоним для webstatistics.ru, поэтому его адресной записи в дополнительной секции отклика сервера доменных имен нет. Ниже представлен пример описания этой зоны:

$ORIGIN ru.
webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4. nic.ru.
IN A 144.206.192.60
$ORIGIN webstatistics.ru.
ns IN CNAME @
$ORIGIN nic.ru.
ns4 IN A 194.226.96.8

Любопытно, что при запуске BIND 9-ой версии не сообщил о некорректном применении CNAME.

Считается, что гораздо проще заставить администраторов соблюдать правила использования CNAME записей, чем пытаться исправить ошибки администратора за счет «умного» программного обеспечения.

На самом деле ошибка может проистекать из-за обычной невнимательности администратора.

Приведем пример правильного и неправильного использования записи CNAME:

$ORIGIN polyn.net.kiae.su.
olga IN A 144.206.192.2
IN MX 0 olga
IN MX 10 ns.polyn.kiae.su.
www IN CNAME olga.polyn.kiae.su.
gopher IN CNAME olga.polyn.kiae.su.

В данном случае записи типа CNAME указаны правильно, т.к. не мешают переадресации почты на машину olga.polyn.kiae.su. Но если их поменять местами с записями типа MX, то скорее всего почта работать не будет:

$ORIGIN polyn. net.kiae.su.
olga IN A 144.206.192.2
www IN CNAME olga.polyn.kiae.su.
gopher IN CNAME olga.polyn.kiae.su.
IN MX 0 olga
IN MX 10 ns.polyn.kiae.su.

В данном случае можно предположить, что при редактировании зоны администратор просто неаккуратно скопировал блоки записей. Результат — неправильное применение CNAME.

Теперь от грустного — ошибок, перейдем к особенностям применения CNAME. Случай, когда CNAME используется для простого определения синонимов, мы уже рассматривали. Теперь коснемся такого приема, как Round Robin алгоритм.

Обычно циклическую перестановку адресов рассматривают в контексте адресных записей и позиционируют как один из способов распределения нагрузки. На самом деле BIND можно настроить таким образом, что он позволит «тасовать» не только адресные записи. В частности это разрешено будет делать и для CNAME записей. При этом следует помнить, что строго говоря такое применение CNAME запрещено спецификациями.

Вот пример множественных адресных записей:

www. domain.ru. IN A 192.168.0.1
www.domain.ru. IN A 192.168.0.2
www.domain.ru. IN A 192.168.0.3

А вот его аналог для записей типа CNAME:

Server1.domain.ru. IN A 192.168.0.1
Server1.domain.ru. IN A 192.168.0.2
Server1.domain.ru. IN A 192.168.0.1
www.domain.ru. IN CNAME server1.domain.ru.
www.domain.ru. IN CNAME server2.domain.ru.
www.domain.ru. IN CNAME server3.domain.ru.

На первый взгляд большой разницы в том, что тасовать (адресные записи или CNAME записи), нет. И в том и в другом случае адреса ресурса циклически переставляются. На один запрос мы получаем один адрес, на другой — второй, и так далее по кругу.

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

Во втором случае в качестве отклика возвращаются CNAME записи. Это значит, что клиент в конечном итоге получает не список IP-адресов, а только один IP-адрес.

На самом деле рекомендуется все-таки не использовать «тасование» CNAME, тем паче, что в BIND 9 на выше приведенный пример будет получен при запуске сервера следующий отклик в логах:

Oct 13 18:03:15 generate named[136]: dns_master_load: webstatistics.ru:19:
www.domain.ru: multiple RRs of singleton type

Любопытно, что обслуживаться запросы по синониму будут. Просто из всех записей одного синонима будет выбрана последняя. Если же мы имеем дело со множественными адресными записями, и на их доменное имя существует синоним, то для запроса на этот синоним будет выдан список всех IP-адресов.

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

$ORIGIN ru.
Webstatistics 3600 IN SOA webstatistics.ru. paul.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.
IN A 144. 206.192.60
$ORIGIN webstatistics.ru.
ns 3600 IN A 144.206.192.60
$ORIGIN nic.ru.
ns4 IN A 194.226.96.8
$ORIGIN webstatistics.ru.
www 3 IN A 144.206.192.60
www 3 IN A 144.206.192.61
www 3 IN A 144.206.192.62
www 3 IN A 144.206.160.32
www1 IN CNAME ns.webstatistics.ru.
www1 IN CNAME www

В данном случае BIND версии 9 игнорирует первую запись CNAME, выдает выше приведенное сообщение в логе и поддерживает только последний CNAME.

Если теперь обратиться за IP-адресом www1.webstatistics.ru, то мы получим следующее (тестирование программой nslookup):

> set debug
> www1.webstatistics.ru.
Server: [144.206.192.60]
Address: 144.206.192.60

;; res_nmkquery(QUERY, www1.webstatistics.ru, IN, A)
————
Got answer:
HEADER:
opcode = QUERY, id = 33822, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 5, authority records = 2, additional = 2

QUESTIONS:
www1.webstatistics.ru, type = A, class = IN
ANSWERS:
-> www1.webstatistics.ru
canonical name = www.webstatistics.ru
ttl = 3 (3S)
-> www.webstatistics.ru
internet address = 144.206.192.60
ttl = 3 (3S)
-> www.webstatistics.ru
internet address = 144.206.192.61
ttl = 3 (3S)
-> www.webstatistics.ru
internet address = 144.206.192.62
ttl = 3 (3S)
-> www.webstatistics.ru
internet address = 144.206.160.32
ttl = 3 (3S)
AUTHORITY RECORDS:
-> webstatistics.ru
nameserver = ns.webstatistics.ru
ttl = 3600 (1H)
-> webstatistics.ru
nameserver = ns4.nic.ru
ttl = 3600 (1H)
ADDITIONAL RECORDS:
-> ns.webstatistics.ru
internet address = 144.206.192.60
ttl = 3600 (1H)
-> ns4.nic.ru
internet address = 194. 226.96.8
ttl = 79606 (22h6m46s)

————
Name: www.webstatistics.ru
Addresses: 144.206.192.60, 144.206.192.61, 144.206.192.62, 144.206.160.32
Aliases: www1.webstatistics.ru

>

На запрос адреса мы в основной секции отклика получаем CNAME и все адресные записи, в авторитативной секции получаем доменные имена серверов зоны (записи NS), а в дополнительной секции IP-адреса этих серверов доменных имен.

И в заключении о реальном масштабе ошибок, связанных с применением CNAME в системе доменных имен. Согласно исследованиям компании Men & Mice проведенным на 5000 случайно выбранных зонах домена com в августе 2002 года в 3.3%-ах случаев была зафиксирована ссылка в MX записи на синоним, т.е. неправильное совместное применение CNAME и MX.

Рекомендованная литература:

1. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
4. Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
5. D. Barr. RFC 1912. Common DNS Operational and Configuration Errors. 1996. (http://www.ietf.org/rfc/rfc1912.txt?number=1912)
6. R. Elz, R. Bush. RFC 2181. Clarifications to the DNS Specificatrion. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)

Полезные ссылки:

1. http://www.rscott.org/dns/cname.html — о способах верификации ошибок в описании зоны, относящихся к записям CNAME.
2. http://www.adminschoice.com/docs/dns_trouble_shooting.htm — пример правильного и неправильного употребления NS и CNAME.
3. http://support.microsoft.com/default.aspx?scid=KB;EN-US;q159310& — проблемы совмести dns. exe и BIND при обработке откликов NS и CNAME.
4. http://cr.yp.to/im/canme.html — обсуждается проблема работы с DNS программ sendmail и qmail. Основное внимание уделено работе с некорректными CNAME — записями.
5. http://www.acmebw.com/askmrdns/ — FAQ по системе доменных имен. На этот архив ссылаются и разработчики BIND. Вопросам некорректного использования CNAME посвящено около десятка страниц.
6. http://www.menandmice.com/6000/61_recent_survey.html — статистика ошибок при конфигурации серверов системы доменных имен.

Что такое каноническое имя (CNAME) и как оно работает?

ПоискWindowsServer

К

• Рахул Авати

Что такое каноническое имя?

Каноническое имя (CNAME) — это тип записи базы данных системы доменных имен (DNS), которая указывает, что доменное имя является псевдонимом или псевдонимом для другого доменного имени. Также называемый «настоящим именем», CNAME особенно важен, когда несколько служб запускаются с одного IP-адреса.

CNAME обычно используется вместо записи A, которая является типом записи DNS, которая показывает IP-адрес домена. Записи CNAME должны указывать на домен, а не на IP-адрес. Домен с записью CNAME может указывать на другой домен с записью CNAME или на домен с записью A.

Как работают канонические имена

Если субдомен «www» задан как псевдоним имени корневого домена, субдомен, такой как www.samplesite.techtarget.com , будет иметь запись CNAME, указывающую на корневой домен techtarget.com .

Итак, когда DNS-сервер выполняет поиск записей DNS для blog.samplesite.com, он запускает другой поиск DNS для techtarget.com, тем самым перезапуская запрос с использованием канонического имени. Затем он возвращает IP-адрес для techtarget.com через свою запись A. Итак, здесь techtarget.com — это каноническое или истинное имя samplesite. techtarget.com.

Если IP-адрес хоста изменяется, необходимо обновить только запись DNS A для корневого techtarget.com. Все записи CNAME, включая blog.techtarget.com, будут автоматически следовать любым изменениям, внесенным в корень.

Использование записей канонических имен

Вот несколько распространенных способов использования записей CNAME:

• для указания нескольких веб-сайтов, принадлежащих одному лицу или организации, на их основной веб-сайт;
• , чтобы предоставить отдельное имя хоста для различных сетевых служб, таких как протокол передачи файлов (FTP) или электронная почта, указывая каждое имя хоста на корневой домен;
• для предоставления субдоменов для каждого клиента в одном домене поставщика услуг и использования CNAME для указания субдомена на корневой домен клиента; и
• , чтобы зарегистрировать один и тот же домен в нескольких странах и указать каждую версию для конкретной страны на основной домен.

Одним из расширенных вариантов использования CNAME является несколько сетей доставки контента (CDN), набор географически распределенных и взаимосвязанных серверов, которые предоставляют кэшированный интернет-контент из сетевого расположения рядом с пользователем, чтобы ускорить его доставку.

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

DNS-обработка записей CNAME

Рассмотрим пример корневого домена techtarget.com. С записью CNAME пользователь, обращающийся к www.techtarget.com, относится к CNAME techtarget.com.

Для этого примера:

Имя	Тип	Значение
www. techtarget.com	CNAME	techtarget.com
techtarget.com	А	187.163.121.121

Вот как работает процесс разрешения DNS для записей CNAME: Запись A переводит доменное имя techtarget.com в соответствующий IP-адрес.

1. Браузер или сетевое устройство (клиент DNS) запрашивает определенный адрес www.techtarget.com. Таким образом создается DNS-запрос.
2. Этот запрос получен преобразователем DNS, который находит полномочный сервер имен, содержащий файл зоны DNS с соответствующими записями DNS для домена techtarget.com.
3. Запись CNAME возвращается клиенту.
4. Клиент DNS понимает, что www.techtarget.com является псевдонимом корневого домена techtarget.com, и выдает новый запрос DNS для techtarget.com.
5. Повторяется тот же процесс запроса, и преобразователь возвращает запись A для techtarget. com с его IP-адресом.
6. Клиент подключается к techtarget.com, используя свой IP-адрес.

Каноническое имя (CNAME) служит псевдонимом для доменных имен с общим IP-адресом. Например, на диаграмме «Searchsecurity.techtarget.com» является псевдонимом «Techtarget.com». Оба указывают на один и тот же IP-адрес.

Чем записи CNAME отличаются от записей A и записей псевдонимов

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

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

Запись псевдонима, как и запись CNAME, сопоставляет имя хоста с другим именем хоста. Но разница в том, что CNAME не разрешает другие записи DNS для того же имени хоста, в то время как запись псевдонима разрешает.

Кроме того, ALIAS напрямую возвращает IP-адрес и не требует от DNS-клиента разрешения другого имени хоста. Напротив, записи CNAME создают запрос на разрешение другого имени хоста. Вот почему ALIAS обычно работает лучше, чем CNAME.

Чем CNAME отличается от перенаправлений

Распространенным заблуждением является то, что запись CNAME — это то же самое, что перенаправление веб-протокола передачи гипертекста (HTTP). Однако это неверно, поскольку прямой связи между CNAME и перенаправлением HTTP нет.

Кроме того, настройка CNAME в DNS не приводит к автоматическому перенаправлению HTTP. Чтобы выполнить последнее, необходимо настроить сервер, отвечающий на HTTP-запрос, чтобы он возвращал соответствующий HTTP-ответ. Использование CNAME не гарантирует этого.

Схема работы DNS.

Ограничения на использование канонического имени

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

Например, предположим, что samplesite.techtarget.com указывает на каноническое имя techtarget.com. В то же время techtarget.com также указывает на каноническое имя samplesite.techtarget.com. В этом случае поиск будет продолжать сверять одно имя с другим в бесконечном цикле, что влияет на производительность и взаимодействие с пользователем.

Указание на запись CNAME ограничено как в записях сервера имен (NS), так и в записях почтового обмена (MX). Запись NS, указывающая, какой DNS-сервер является полномочным для этого домена, и запись MX, направляющая электронную почту на почтовый сервер, может указывать только на:

.

• запись A для IPv4
• запись AAAA для IPv6

Подобно записям A, записи AAAA позволяют клиентским устройствам узнавать IP-адрес доменного имени, а затем клиентское устройство подключается к веб-сайту и загружает его.

Другие ограничения на использование записей CNAME включают следующее:

• Он должен указывать только на другое доменное имя, а не на IP-адрес.
• Его нельзя разместить в корневом домене, так как корневой домен должен указывать на IP-адрес. Это помогает устранить возможность создания бесконечного цикла во время поиска имени.
• Домены электронной почты не должны иметь записи CNAME.
• Имя хоста, определенное в записи CNAME, не должно иметь других записей ресурсов типов A, MX и т. д.
• Не может сосуществовать с другой записью с тем же именем.

Наконец, указание записи CNAME на другую запись CNAME не ограничено. Однако для этого требуется несколько запросов DNS перед загрузкой домена. Поскольку это влияет на пользовательский опыт, это считается неэффективным и нежелательным. Чтобы избежать ненужного снижения производительности, CNAME должен как можно ближе указывать на целевое имя.

См. также: Как можно использовать алгоритмы генерации доменов для обхода блокировщиков рекламы? , Как хакеры используют домены Unicode для спуфинговых атак? и Настройка удаленных доменов для управления обменом сообщениями Exchange .

Последнее обновление: февраль 2022 г.

Продолжить чтение О каноническом имени (CNAME)

• Что такое захват поддомена и почему это важно?

• Почему защита уровня DNS имеет решающее значение для борьбы с киберпреступностью

• Как можно решить проблемы конфиденциальности DNS?

• 3 типа DNS-серверов и принцип их работы

• Namecheap совершенствует стратегию борьбы с вредоносными доменами

Углубленное изучение ИТ-операций и управления инфраструктурой

• полное доменное имя (FQDN)

  Автор: Кинза Ясар

• повторный DNS-запрос

  Автор: Рахул Авати

• Как создать и добавить запись SPF для проверки подлинности электронной почты

  Автор: Петр Лошин

• Научитесь выполнять резервное копирование и восстановление DNS

  Автор: Майк Канакос

Облачные вычисления

• Подходит ли вам облачная стратегия?

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

• Как использовать сценарии запуска в Google Cloud

  Google Cloud позволяет использовать сценарии запуска при загрузке виртуальных машин для повышения безопасности и надежности. Выполните следующие действия, чтобы создать свой…

• Когда использовать AWS Compute Optimizer и Cost Explorer

  AWS Compute Optimizer и Cost Explorer отслеживают, анализируют и оптимизируют затраты на облако. Сравните два инструмента, чтобы выбрать, какой из них …

Корпоративный настольный компьютер

• Сколько стоит лицензия Windows 11 для бизнеса?

  Существует множество подходов к лицензированию Windows 11 вместе с другим программным обеспечением и службами Microsoft для бизнеса, которые могут быть …

• Что включают в себя различные лицензии для Windows 11?

  Прежде чем организации перейдут на Windows 11, они должны определить наилучшие варианты лицензирования. Узнать о вариантах…

• Четыре ведущих поставщика программного обеспечения для унифицированного управления конечными точками в 2023 г. Программное обеспечение

  UEM имеет жизненно важное значение для помощи ИТ-специалистам в управлении всеми типами конечных точек, которые использует организация. Узнайте о некоторых ведущих поставщиках и о том, как …

Виртуальный рабочий стол

• Альтернативы Citrix, Microsoft и VMware для удаленной работы

  Многие организации будут использовать службы удаленных рабочих столов и виртуальных рабочих столов от Citrix, Microsoft и VMware, но есть много …

• Как исправить проблемы с подключением клавиатуры на удаленном рабочем столе

  Если клавиатура для удаленного рабочего стола не работает, системным администраторам потребуется выполнить следующие шаги, чтобы найти основную причину …

• Устранение проблем с компьютерной мышью на удаленном рабочем столе

  Запуск удаленного рабочего стола сопряжен со всевозможными аппаратными соображениями для ИТ-специалистов, в том числе с тем, как рабочий стол взаимодействует . ..

Запись CNAME — как это работает, альтернативы и расширенные варианты использования

Что такое запись CNAME?

Запись канонического имени (CNAME) используется в системе доменных имен (DNS) для создания псевдонима из одного доменного имени в другое доменное имя. Типичным примером является поддомен www, который предоставляется как псевдоним имени корневого домена — пользователи, обращающиеся к «www.example.com», относятся к корневому домену (или вершине зоны DNS) «example.com».

Несколько распространенных вариантов использования записей CNAME:

• Предоставление отдельного имени хоста для определенных сетевых служб, таких как электронная почта или FTP, и указание этого имени хоста на корневой домен
• Многие службы хостинга предоставляют субдомен для каждого клиента в домене поставщика услуг (например, company.hostname.com) и используют CNAME для указания на домен клиента (www.company.com).
• Регистрация одного и того же домена в нескольких странах и указание национальных версий на основной домен «. com»
• Указание с нескольких веб-сайтов, принадлежащих одной организации, на основной веб-сайт

Как система DNS обрабатывает записи CNAME

Записи DNS в приведенном выше примере будут выглядеть так:

CNAME из поддомена в родительский домен

ИМЯ ТИП ЗНАЧЕНИЕ
———————————- —————-
www.example.com. CNAME example.com.
example.com. A 192.162.100.100

Вторая запись — это запись A, которая переводит удобочитаемое доменное имя «example.com» в IP-адрес.

Процесс разрешения DNS для записей CNAME

1. Клиент DNS (например, браузер или сетевое устройство) запрашивает адрес www.example.com, и создается запрос DNS.
2. Преобразователь DNS получает запрос и находит полномочный сервер имен, на котором хранится файл зоны DNS с записями DNS для домена «example.com».
3. Запрос DNS разрешен, и запись CNAME возвращается клиенту.
4. Клиент понимает, что www. example.com — это всего лишь псевдоним реального адреса «example.com», и выдает новый DNS-запрос для «example.com»
5. Процесс повторяется, и преобразователь возвращает запись A для «example.com», содержащего IP-адрес.
6. DNS-клиент теперь подключается к «example.com», используя свой IP-адрес.

Примеры CNAME

CNAME из поддомена в поддомен

ИМЯ ТИП ЗНАЧЕНИЕ
—————————— ———————
old.example.com. CNAME new.example.com.
новый.example.com. A 192.162.100.101

CNAME из поддомена в другой корневой домен

ИМЯ ТИП ЗНАЧЕНИЕ
——————————————— ———————
прочее.example.com. CNAME www.other.com.

В этом примере имя A для «www.other.com» предоставляется в другом файле зоны DNS.

Ограничения на записи CNAME

• CNAME не может быть размещена на уровне корневого домена, поскольку корневой домен является точкой начала полномочий DNS (SOA), которая должна указывать на IP-адрес.
• Записи CNAME должны указывать на другое доменное имя, а не на IP-адрес.
• Имя хоста, определенное в записи CNAME, не должно иметь других записей ресурсов других типов (MX, A и т. д.), за исключением записей DNSSEC, таких как RRSIG и NSEC.
• Записи CNAME могут указывать на другие записи CNAME, но это не считается хорошей практикой, поскольку это неэффективно.
• Записи MX и NS никогда не должны указывать на псевдоним CNAME.
• Домены, которые используются для электронной почты, могут не иметь записи CNAME — это может привести к нежелательным результатам на разных почтовых серверах.

Записи CNAME и альтернативные типы записей

Запись CNAME обычно используется вместе с другими типами записей DNS — записями A и записями ALIAS.

Разница между A и CNAME

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

Разница между ALIAS и CNAME

Запись ALIAS, как и CNAME, также сопоставляет имя хоста с другим именем хоста. Однако запись ALIAS позволяет иметь другие записи DNS для одного и того же имени хоста, а CNAME — нет. Это позволяет применять ALIAS в корневом домене (вершине зоны DNS), что не разрешено для CNAME.

Кроме того, ALIAS имеет лучшую производительность, чем CNAME, поскольку не требует от DNS-клиента разрешения другого имени хоста — он напрямую возвращает IP-адрес. Однако записи ALIAS также должны выполнять рекурсивный поиск за кулисами, что может повлиять на производительность.

Связанные записи — умная альтернатива CNAME

Платформа DNS следующего поколения NS1 поддерживает проприетарный тип записи DNS, который называется Linked Record . NS1

Multi-CDN: расширенный вариант использования CNAME

Распространенным способом развертывания сетей доставки контента (CDN) является добавление адреса CDN в качестве записи CNAME для исходного сервера, на котором размещается контент веб-сайта. Таким образом, любой, кто обращается к ресурсам на исходном сервере, перенаправляется в CDN.

Благодаря технологии DNS следующего поколения одна и та же запись CNAME позволяет перенаправлять пользователей в одну из нескольких CDN на основе динамических параметров.

Платформа DNS может быть осведомлена об атрибутах CDN, таких как текущая нагрузка, географическое расположение ближайшей точки присутствия (PoP), пропускная способность или даже стоимость. Когда пользователь ищет исходный сервер и перенаправляется на адрес CNAME, этот адрес динамически изменяется на CDN, который может обеспечить наилучшее взаимодействие с конечным пользователем.

NS1 — это управляемая DNS-платформа следующего поколения, которая может динамически направлять пользователей на наиболее оптимальный сервер CDN (или любой другой сервер в этом отношении) на основе:

• Цепочек фильтров, которые дают вам сотни способов настроить ответы DNS для каждого пользователя на основе обширных параметров, описывающих возможности и производительность целевой системы.