Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Запись об адресе (address records) — это просто отображение имени в адрес. Таким образом, адресом ns.fishfood.com будет 172.66.1.1.

Вспомним, что для более осмысленного именования можно присваивать серверным хостам короткий псевдоним. В показанном примере службы World Wide Web пересылки файлов и gopher выполняются на той же машине, которая поддерживает доставку электронной почты. Запись для канонического имени (canonical name — CNAME ) определяет короткое имя для хоста и разрешает пользователям вводить www.fishfood.com, ftp.fishfood.com или gopher.fishfood.com .

Серверы обмена почтой (Mail Exchanger — MX) обеспечивают доставку в/из сети (см. главу 16). В файле существуют три записи MX, которые идентифицируют сервер MX для fishfood.com .

fishfood.com. IN MX 1 MAIL-RELAY

* IN MX 1 MAIL-RELAY

ns IN MX 1 MAIL-RELAY

Эти записи фактически указывают, что:

■ Почта, адресованная на некто@fishfood.com, должна быть доставлена на mail-relay.fishfood.com .

■ Подстановочный символ * позволяет пересылать почту, адресованную особым хостам, которые отсутствуют в списке DNS. Почта, адресованная на некто@любой_хост.fishfood.com , должна быть доставлена на mail-relay.fishfood.com .

■ Почта, адресованная на некто@ns.fishfood.com, должна быть передана по адресу mail-relay.fishfood.com.

Все это выглядит так, будто подстановочный символ должен полностью обеспечить обращение к ns.fishfood.com . Тогда зачем же нужен отдельный оператор? Правила для подстановочного символа гласят, что он может быть применен только к системам, не имеющим никаких других записей в базе данных DNS.

Числа, стоящие после MX, называются предпочтительными (preference numbers). Они будут рассмотрены в главе 16 при описании работы с электронной почтой.

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

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

Почему необходим обратный поиск и трансляция адресов в имена? Некоторые системные программы вызывают обратный поиск с целью улучшения вывода информации для администрирования. Например, показанный ниже вывод из программы netstat представляет все или часть имени хоста вместо IP-адресов:

> netstat -а

Active Internet connections (including servers )

Proto Recv-Q Send-Q Local Address Foreign Address (state)

Tcp 0 121 tigger.nntp c3po.4809 ESTABLISHED

Tcp 0 0 tigger.smtp news.std.com.1472 TIME_WAIT

Tcp 0 925 tigger.1176 sun3.nsfnet-rela.smtp ESTABLISHED

Tcp 0 0 tigger.pop-3 ringotty8.16284 TIME_WAIT

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

Вспомним, что адреса размещаются в специальном домене IN-ADDR.ARPA и дерево этого домена должно расширяться от наиболее общей части адреса к менее общей. При этом порядок номеров в каждом адресе становится обратным. Поэтому поддерево сети 172.66 называется 66.172.in-addr.arpa. На рис. 12.7 показан обратный поиск записи.

66.172.in-addr.arpa. IN SOA NS.FISHFOOD.COM. (

postmaster.FISHFOOD.COM.

94101101 ; serial

86400 ; refresh after 24 hours

7200 ; retry after 2 hours

2592000 ; expire after 30 days

345600 ; default TTL of 4 days

)

66.172.in-addr.arpa. IN NS NS.FISHFOOD.COM.

1.1 IN PTR NS.FISHFOOD.COM.

66.172.in-addr.arpa. IN NS NS2.FISHFOOD.COM.

100.1 IN PTR NS2.FISHFOOD.COM.

2.1 IN PTR MAIL-RELAY.FISHFOOD.COM.

Рис. 12.7.Таблица обратного просмотра

Элементы также будут обратными. Например, элементу 100.1 соответствует адрес 172.66.1.100.

Обмен сообщениями запросов и ответов между клиентом и серверами DNS имеет простой формат. Сервер добавляет информацию ответа к исходному запросу и посылает полученное сообщение обратно. На рис. 12.8 показан полный формат сообщения.

Рис. 12.8.Общий формат сообщения DNS

Секция заголовка содержит поля, представленные в таблице 12.2.

Таблица 12.2 Поля заголовка сообщения DNS

Запрос имеет поля, перечисленные в таблице 12.3. Обычно сообщение содержит единственный запрос. Но можно в общей секции объединить несколько различных запросов.

Таблица 12.3 Поля запросов DNS

Сам ответ, информация об авторитетности и дополнительные сведения структурированы так же, как и в запросе. Ответ состоит из последовательности записей о ресурсах, содержащих поля, показанные в таблице 12.4.

Таблица 12.4 Поля записей о ресурсах

Секция информации об авторитетности указывает авторитетные серверы имен для домена. Секция дополнительной информации предоставляет сведения, подобные IP-адресам авторитетных серверов имен.