Разное

Cname запись что это – запись — Почта для домена. Помощь

21.10.2018

CNAME запись в DNS настройка

CNAME запись в DNS позволяет задавать алиасы — фактически реализуя перенаправление всех запросов одного домена другому домену. Настройка CNAME производится на NS сервере, на который делегирован домен или в панели управления компании, предоставляющей услуги хостинга DNS.

 

 

CNAME — Canonical Name — запись задающая алиас. Рассмотрим принцип работы CNAME

При присутствии CNAME не будут учитываться никакие другие записи DNS.

 

host example.com

 

example.com A 124.124.124.124
example.com A 124.124.124.126
example.com MX 124.124.124.124
example.com CNAME example.ru

 

В приведенном примере записи типов A и MX не будут иметь силы потому, что задан алиас. При запросе к example.com и отсутствии в собственной ьазе необходимого значения DNS будет запрашивать у стоящего выше в иерархии сервера А-запись для example.ru и разрешая ее в IP адрес переадресовывать запрос на него.

Эту особенность CNAME всегда следует иметь в виду и не создавать для того же имени других записей.

 

CNAME часто задается для поддоменов — например:

test.example.com CNAME example.ru

 

 

 

Запись этого вида используется при выпуске SSL сертификатов. Добавляя запись, которую предлагает добавить сертификационный центр, владелец домена подтверждает право управления им. Как в качестве имени в записи, так и в качестве домена, на который перенаправляются запросы в этом случае используются длинные технические имена.

 

 

CNAME как и любая другая запись проверяется при помощи запроса к серверу с использованием утилит host и dig

 

host -t cname  _d25ca42cb704f144b5bc80ee3e8be779.example.com

_d25ca42cb704f144b5bc80ee3e8be779.example.com is an alias for 5d9678c35b6f432c4dee7641b066194f.c8d5d2a8d1216b60b9eda8b312ee167a.comodoca.com.

server-gu.ru

Запись назначения синонима каноническому имени «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 — статистика ошибок при конфигурации серверов системы доменных имен.

info.nic.ru

Типы DNS-записей | | Obu4alka.ru

Часто используемые DNS-записи

SOA-запись (Start of authority)
SOA-запись DNS определяет авторитетную информацию о доменном имени и зоне в целом.

A-запись (Address)
Эта запись указывает имя хоста и адрес IP определенного компьютера. По сути, любая система с подключением http/https должна иметь свою A-запись, чтобы по доменному имени определялся привязанный к нему IP-адрес.

NS-запись (Name Server)
Определяет сервер, который отвечает за выбранную вами зону. У каждого домена должна быть хотя бы одна NS-запись, хотя на самом деле их может быть несколько — вплоть до отдельной записи для любого указанного поддомена.

CNAME-запись (Name Alias)
Позволяет создавать отсылки к ранее созданным A-записям и PTR-записям. Чаще всего используется для того, чтобы тот же сайт был доступен под разными доменными именами, например, при создании «зеркал». Запись CNAME позволяет компьютеру иметь более чем одно имя хоста.

MX-запись (Mail Server)
DNS MX-запись сообщает различным почтовым программам о том, где находится нужный почтовый сервер. Без нее предназначенная для указанного домена почта не будет отправлена на IP-адрес из A-записи.

TXT-запись (Text)
Применяется для добавления комментария к выбранному домену. Иначе, чем как добавить TXT-запись в DNS (при его изменении), вы не сможете привязать текст произвольного содержания к домену.

SPF (Sender Policy Framework)
указывает сервера, которые могут отправлять почту от имени домена. Запись SPF вносят в TXT-запись домена.
Пример:

site.ru  IN TXT "v=spf1 a mx ip4:11.11.11.11 ~all"
  • v=spf1 — определяет версию используемой записи SPF;
  • a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A записи домена. Проще говоря с сервера, где размещен сайт;
  • mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
  • ip4:11.11.11.11 — разрешает приём почты с IP-адреса 11.11.11.11;
  • ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также можно использовать:
  • -all— отвергать
  • +all— пропускать
  • ?all— нейтральный режим.

PTR-запись (Reverse Address)
Связывает домен хоста с его IP в обратной зоне DNS, поэтому должен быть прописан для каждого хоста отдельно. Зачастую эта запись создается автоматически, но проверка никогда не помешает. При этом сама же обратная зона DNS допускает использование только трех типов записи — PTR, NS и CNAME.

CAA-запись(Certification Authority Restriction)
С помощью данной записи владелец домена указывает удостоверяющий центр, имеющий право выпускать SSL/TLS-сертификаты для указанного домена. Запись CAA в DNS позволяет избежать несанкционированной выдачи сертификата, что делается либо случайно, либо с целью фишинга или каких-либо другой атаки.

Редко используемые DNS-записи

LOC-запись (Location)
Подобный тип записи востребован среди крупных компаний и организаций, так как применяется для определения месторасположения хоста с указанием широты и долготы.

SRV-запись (Service Address)
Используется для ассоциации домена и названия сервиса с указанием протокола на хосте. Проще говоря, с ее помощью определяется размещение сервиса на хосте.

HINFO-запись (Host Information)
Позволяет получить данные об архитектуре и используемой ОС хоста, так как для хранения данных подобного вида используется именно такая запись.

DNAME-запись (Domain Name)
Псевдоним для домена

WKS-запись (Well Known Service)
Данный тип записи связывает с определенной зоной имя хостинга, номер порта и протокол сервиса. Зачастую используется на хостах, используемых в качестве почтовых серверов.

RP-запись (Responsible Person)
Этот тип позволяет получить данные отдельного человека или организации, ответственных за конкретно взятое доменное имя. По этой записи можно узнать e-mail ответственного лица.

KEY-запись (Public Key)
Используется довольно редко — для ассоциации ключа для некоторых хостингов и используется в IETF-протоколе DNS для минимизации риска атак с подменой самого DNS.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

obu4alka.ru

Введение в изучение и использование DNS-записей

Введение

Система доменных имен (DNS) это по сути телефонный справочник интернета. Вы набираете в адресной строке браузера apple.com, чтобы купить аксессуары к Iphone, но как ваш запрос находит сервер Apple с IP-адресом 17.172.224.47? Это делает для вас система доменных имен.

Если у вас небольшой бизнес в сети или вы ведете блог на WordPress, то вы, вероятно, уже сталкивались с настройкой записей A и CNAME. А если вы пытались перенести почту со своего сайта, то и с настройкой записи MX. И, возможно, какой-нибудь веб-сервис просил настроить TXT, чтобы работать с вашим сайтом. Для чего все это нужно и какие здесь сложности?

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

Серверы DNS

Когда вы покупаете доменное имя, ваш регистратор, как правило, конфигурирует для вас записи DNS по умолчанию и предоставляет серверы DNS для них. Вам необходим сервер DNS (обычно они используются в парах или тройках для надежности, например: ns1.yourregistrarserver.com, ns2.yourregistrarserver.com), чтобы сообщить каталогу DNS интернета IP-адрес вашего сервера.

Вот образец моих записей NS для сайта JeffReifman.com:

Все настройки, которые вы зададите, будут настроены и опубликованы в сети с помощью этих серверов.

Теперь перейдем к типам записей DNS, основной из них является A-запись.

Записи А

Если набрать в адресной строке jeffreifman.com, этот запрос будет направлен в каталог, в котором будет произведен поиск записи DNS соответствующей этому корню этого домена. Корень в данном случае означает без префикса www, то есть без поддомена, просто http://jeffreifman.com. Например, запись A корневого уровня может указывать на IP 107.164.32.96, значит, это тот адрес, по которому надо перейти.

Я долгие годы использовал сайт Kloth для проверки записей DNS, на самом деле таких сервисов много, например Google Dig или tools.keycdn.com.

Вот образец запроса A-записи на Kloth:

Записи поддомена

Вы также можете сконфигурировать A-записи для различных поддоменов. Например, если вы хотите, чтобы http://www.yourwebsite.com/ указывал на тот же адрес, просто добавьте идентичную A-запись для поддомена www, теперь у корневого домена и поддомена будет одинаковый IP.

Недавно я сделал сайт http://fleethejungle.com/, чтобы помочь пользователям расстаться с компанией Amazon, приносящей вред Сиэттлу (об этом пишет даже New-York Times).

Скоро мы запустим соответствующие сайты на доменах, относящихся к конкретным городам (portland.fleethejungle.com), я рассчитываю расположить их на разных серверах, нам надо, что бы A-записи каждого поддомена вели на уникальный IP соответствующего сервера.

Записи wildcard

В конфигурацию DNS можно добавлять записи Wildcard (с помощью астериска *), позволяющие направлять весь трафик поддоменов на один IP. Например, если я хочу, разместить все поддомены городов на одном сервере, я сделаю так:

Записи wildcard облегчают привязку нескольких поддоменов к одному серверу.

Входная маршрутизация на сервере

Когда трафик прибывает на ваш сервер от маршрутизатора DNS, вы можете сконфигурировать обработку его на сервере. Вот образец моей конфигурации для корневого и www трафика:

<VirtualHost *:80>
    ServerName jeffreifman.com
    ServerAlias www.jeffreifman.com
    DocumentRoot /var/www/jeffreifman
    DirectoryIndex index.php
    <Directory /var/www/wpapps/>
      AllowOverride All
      Order Deny,Allow
      Allow from all
   </Directory>
</VirtualHost>

Я также продаю домены с динамическими расценками. Вот как Apache обрабатывает трафик для всех этих доменов и записей DNS.

<VirtualHost *:80>
    ServerName newscloud.com
    ServerAlias *acro.io
    ServerAlias *acroyoga.io
    ServerAlias *acupuncture.io
    ServerAlias *allmisses.com
    ServerAlias *amehzon.com
    ServerAlias *carestrategies.com
    ServerAlias *caringsitters.com
    ServerAlias *clipboards.io
    ServerAlias *commonbits.com
    ServerAlias *commonroad.com
    ServerAlias *commontunes.com
    ServerAlias *completelady.com
    ...

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

Записи CNAME

CNAME это по сути текстовый псевдоним для направления трафика домена и поддомена. Например, если вы сталкивались с настройкой сервиса типа WordPress или Tumblr, они могли предложить настроить домен именно с помощью записи CNAME, а A-записи c IP.

Я не часто использую Tumblr, но некоторое время я настроил для своего аккаунта адрес http://misc.jeffreifman.com/. Вот их инструкции для настройки кастомного доменного имени — они позволяют использовать A-записи или CNAME, я выбрал CNAME.

Вот запись DNS для misc.jeffreifman.com:

misc.jeffreifman.com   CNAME   domains.tumblr.com.

Примечание: обязательно ставьте точку в адресе CNAME.

Когда пользователь запросит misc.jeffreifman.com, DNS отправит его на domains.tumblr.com, а там уже будет найден IP 66.6.44.4.

Важным преимуществом записи CNAME является то, что если, например, в этом примере Tumblr сменит адрес своего сервера, вам не надо будет менять запись CNAME. Она останется прежней и Tumblr сможет управлять IP, изменяя A-запись на domains.tumblr.com.

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

Примечание: стандарты DNS технически не позволяют привязывать корневой домен к CNAME, например, jeffreifman.com CNAME domains.tumblr.com. Поэтому Tumblr предлагает сделать А-запись для корневых доменов. Однако, некоторые серверы DNS поддерживают это, так что вам имеет смысл проверить свой. Подробнее о CNAME-записях для корневого сервера можно прочитать в записи Джоша Стрэйнджа.

Другим сценарием использования записей CNAME является использование CNAME с сервисами CDN, как я описал в статье о KeyCDN. Я настроил облачные поддомены c1, c2, c3, c4, привязав их все к зеркалу на jr-faf.kxcdn.com.

Что происходит, когда вы меняете записи DNS

Записи DNS для корневого домена и поддоменов, как правило, не зависимы друг от друга. Изменение A-записи корневого домена не влияет на существующий адрес CNAME поддомена. Однако недавно я регистрировался на сервисе сетевой безопасности Incapsula и обнаружил, что он требует две А-записи для одного корневого домена — это может сделать все более сложным. Другими словами, технически у вас может быть несколько А-записей для одного домена, что может породить конфликты.

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

Мой регистратор предложил мне использовать https://www.whatsmydns.net/ для визуального отчета о распространении моего DNS в различных областях. Ниже есть скриншот, который я сделал при смене сервера своего сайта — изменения затребовали несколько часов.

На иллюстрации ниже показаны DNS-серверы, захватившие мои последние изменения:

Записи MX

Теперь перейдем к записям MX. Эти записи сообщают системе DNS, куда слать все приходящие вам email. Поэтому, если я купли домен StarWars.io и захочу получать почту по адресу [email protected], мне надо сделать две вещи.

Во-первых, мне нужно зарегистрироваться на почтовом сервисе типа Google Apps или FastMail, чтобы разместить там почту. Во-вторых, мне надо сконфигурировать записи MX так, чтобы почта шла на эти серверы.

Например, так будет выглядеть конфигурация Google Apps:

Priority    Mail Server
1   ASPMX.L.GOOGLE.COM.
5   ALT1.ASPMX.L.GOOGLE.COM.
5   ALT2.ASPMX.L.GOOGLE.COM.
10   ALT3.ASPMX.L.GOOGLE.COM.
10   ALT4.ASPMX.L.GOOGLE.COM.

А для FastMail так:

in1-smtp.messagingengine.com (first, priority=10)
in2-smtp.messagingengine.com (second, priority=20)

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

Многие пользователи используют MX Toolbox для просмотра записей MX, но это может сделать и любой другой сервис просмотра DNS.

Смена провайдера Email и перенос почты

Записи MX инструктируют систему DNS куда отправлять сегодняшнее письмо — ваше письмо сохранится в облачной базе данных вашего провайдера почты. Если вы хотите перенести все имеющиеся сообщения, вам надо использовать инструменты для миграции почты или возможности вашей почтовой программы. И, конечно, вам надо обновить записи M, добавив нового провайдера почты.

В течение процесса обновления DNS письма могут приходить на старый адрес.

Смена записи MX не повредит содержимое вашего старого хранилища почты, просто новые письма перестанут туда поступать.

Записи TXT

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

Например, Google может попросить вас добавить такую запись:

jeffreifman.com TXT google-site-verification=Ih8iC4iSOcBSkk

На моем сайте jeffreifman.com есть три записи TXT:

jeffreifman.com TXT "keybase-site-verification=qG2zMYf_hw2sXUCgtYWk"
jeffreifman.com TXT "v=spf1 include:spf.efwd.regsrvrs.com ~all"
jeffreifman.com TXT "google-site-verification=blTgEw5QFSx5M"

База ключей, подготовленная мной для цикла статей о PGP и шифровании использует записи TXT для верификации моего сайта и меня, с помощью моих публичных ключей.

Вы также можете использовать записи TXT для того, чтобы сообщать о серверам, детектирующим спам, что ваш почтовый сервер пересылает только законные письма, как это я сделал на примере выше с записью SPF. Сервисы типа Mailgun используют записи SPF и DKIM при массовой рассылке.

Записи AAAA

Когда IP-адреса в интернете закончатся, мы неторопливо перейдем на имена IPv6. подробнее об этом вы можете узнать из статьи о запуске IPV6.

Если вы решили поддерживать адресацию IPv6, вам надо сконфигурировать запись AAAA:

Сейчас большинство переходов с IPv4 на IPv6 происходит тихо и незаметно. Со временем, когда глобальное потепление убьет последнего полярного медведя, А-записи станут реликтовыми, а записи АААА основными записями DNS.

prgssr.ru

CNAME-запись домена

CNAME-запись определяет отображение псевдонима в каноническое имя узла.

Пример:
www IN CNAME regup.ru.
some IN CNAME regup.ru.

В данном примере субдомены www и some сделаны псевдонимами сайта regup.ru, таким образом содержимое www.site.ru и some.site.ru будет идентично regup.ru.

CNAME-запись можно создавать только для субдоменов, т.е. запись вида ‘@ IN CNAME site.ru.’ создавать нельзя, поскольку сам домен не может быть псевдонимом другого домена.

Панель управления R01

1. Для добавления CNAME-записи убедитесь в доступе(иконки домена) к DNS-сервису:

Доступ разрешён. Для доступа к редактированию CNAME-записи нажмите на синюю квадратную иконку(MX|A)

Доступ запрещен, домен делегирован на сторонние ns-адреса, обратитесь в службу поддержки хостинг провайдера который предоставил вам DNS-сервис

2. Формат добавления:

Хост(имя поддомена) CNAME Значение(имя домена)

3. Простой пример:

Прописать bbb.test.ru как псевдоним aaa.test.ru можно следующей записью:
bbb.test.ru. CNAME aaa.test.ru. — добавленная запись

regup.ru

Различие между DNS-записями А, CNAME, ALIAS и URL

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

Прежде чем углубляться в детали нужно знать, что А и CNAME записи это стандартные DNS-записи, в то время как АЛИАС и URL это настраиваемые DNS записи, которые предоставляются вашим DNS-хостингом или регистратором в качестве дополнительной опции.

В чем разница

  • А запись направляет hostname или домен на один или несколько IP, когда IP-адрес известен и стабильно работает.
  • CNAME запись направляет имя или домен на другое имя или домен. Использовать стоит только в тех случаях если нет других DNS-записей на этом хостнейме или домене в противном случае остальные записи не будут учитываться и отвечать.
  • ALIAS направляет имя на другое имя, но в то же время данная запись может сосуществовать с другими записями без конфликта.
  • URL перенаправляет запрос к имени на другое имя используя 301 HTTP-редирект.

Правила, которые стоит запомнить:

  • Записи A, CNAME и АЛИАС резолвятся и отдают по доменному имени IP-адрес. В тоже время URL запись наоборот переадресовывает запрос по доменному имени к пункту назначения, а именно на другое имя или другой URL. URL запись это эффективный и простой способ перенаправить одно имя на другое, к примеру, www.novall.net на novall.net .
  • А запись должна быть направлена на IP-адрес, а CNAME и ALIAS должны быть направлены на другой домен или хост.

Какие записи и в каких ситуациях лучше использовать

  • Используйте А запись, в случаях когда вы точно знаете, что определённый IP закреплён за определённой машиной или сервером.
  • Используйте CNAME запись в тех случаях когда вам нужно направить доменное имя на другое доменное имя и у вас нет необходимости в других DNS-записях (таких как MX записи для работы почты и т.д.) для этого домена.
  • Используйте ALIAS когда вам нужно направить одно доменное имя на другое но при этом вы планируете использовать и другие DNS-записи.
  • Используйте URL запись когда вам нужно выполнить редирект (переадресацию или сменить адрес) с одного доменного имени на другое.

И ЗАПОМНИТЕ ВАМ НИКОГДА НЕ СТОИТ ИСПОЛЬЗОВАТЬ CNAME ЗАПИСЬ НА ГЛАВНОМ ДОМЕНЕ (например для такого главного домена как novall.net).

(Просмотрено 7 861 раз, 4 просмотров сегодня)

novall.net

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *