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

2004 г

Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

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

Здесь рассматриваются особенности применения синонимов доменных имен, которые задаются записью описания ресурсов 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 (5h24m25s)


------------
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.

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

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

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

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

Назад Оглавление Вперед