Основные инструменты DNS


В FreeBSD есть несколько инструментов для проверки информации DNS. Поскольку большинство серверов DNS работают по протоколу передачи дейтаграмм пользователя (User Datagram Protocol, UDP — глава 6), вы не можете применить telnet и непосредственно обратиться к серверу, как в случае с электронной почтой и веб-сервисом (о них речь пойдет позже). Доступ к информации DNS можно получить только с помощью host(1) и dig(1).

Команда host(1)

Для быстрого получения IP-адреса хоста применяйте команду host(1). Например, адрес веб-страницы моего издателя можно получить так:

# host www.nostarch.com
www.nostarch.com has address 72.32.92.4

Это, пожалуй, самый простой вид запроса к DNS: «Вот тебе имя хоста, верни его IP-адрес». Другие, на первый взгляд, довольно простые запросы могут привести к более сложному результату:

Этот пример показывает, что один и тот же хост может иметь несколько псевдонимов — в данном случае имя www.cnn.com в действительности является псевдонимом хоста cnn.com (1).

На самом деле, у хоста cnn.com восемь отдельных IP-адресов (2) (в примере они не показаны). Здесь мы также видим почтовые серверы, которые занимаются обработкой электронной почты для cnn.com (3).

Введя в веб-броузере адрес http://www.nostarch.com, пользователь, фактически, направляет веб-броузер на машину с именем www.nostarch.com за ее веб-страницей по умолчанию. Броузер отправляется по единственному IP-адресу, указанному для этой машины. Когда запрашивается адрес http://www.cnn.com, распознаватель выбирает один из IP-адресов этой машины и передает его броузеру. Подобным образом почтовые серверы отправляют электронную почту одному из хостов, идентифицированных как серверы обработки почты данного домена. Приложениям требуется не только IP-адрес, но IP-адрес имеет очень большое значение. Не найдя компьютер, на котором находится веб-страница, вы не получите эту страницу!

Углубляемся в детали

Команда host(1) довольно полезна, но она, безусловно, не предоставляет подробную информацию. Кроме того, вы не знаете, откуда взялись данные — из кэша на локальной машине, или же сервер имен добыл их на сервере, ответственном за этот домен. Программа dig(1) — это стандартная программа для нахождения подробной информации DNS. (Другой инструмент, nslookup(1), долго был популярен, но устарел и сейчас практически не используется.) У dig есть множество ключей, которые позволяют выявлять различные неполадки, связанные со службой имен. Здесь рассмотрены основные возможности этой программы.

Базовая форма ее вызова включает имя «dig» и имя хоста. Например, чтобы найти сведения о веб-сервере моего издателя, можно ввести такую команду:

Как много строк! Но обычно с помощью программы dig(1) ищут источник проблем, а в этом случае лучше узнать больше, чем меньше. Проанализируем информацию.

Прежде всего, строки, начинающиеся точкой с запятой, являются комментариями, которые не имеют прямого отношения к ответу, но могут содержать немаловажную информацию. Например, первая строка сообщает версию программы dig (1). Во второй строке представлены ключи, которые применяет dig (2). Поскольку в командной строке ключи не были указаны, dig выполняется с ключами по умолчанию.

Далее следует первый фрагмент интересующей нас информации: откуда программа dig получила ответ (3). Элемент status (4) содержит важное слово NOERROR, подтверждающее, что запрос был выполнен без ошибок. Если слова NOERROR нет, то что-то не так. Типичные ошибки: NXDOMAIN (домен не существует) или SERVFAIL (сервер имен знает о существовании этого домена, но не имеет никакой информации о нем).

Раздел QUESTION

В разделе QUESTION (5) приводится фактический запрос, выполненный программой dig. В данном примере раздел запроса выглядит так:

;www.nostarch.com.       IN       A

Первая строка начинается точкой с запятой, то есть перед нами комментарий. Это текст запроса к службе DNS в формальном представлении. Сначала dig подтверждает, что была запрошена информация об имени www.nostarch.com, но что означает IN A? DNS может обслуживать различные системы имен, а не только IP-адреса и имена хостов в стиле Интернета. Комбинация символов IN указывает, что это система имен Интернета — все имена доменов принадлежат к классу IN. Завершается запрос описанием его типа — в данном случае запрашивался адрес (A). У нас есть имя хоста, и мы хотим получить его адрес. Тип PTR (pointer — ссылка) мог бы означать запрос на обратное разрешение имени в DNS (когда имеется IP-адрес и по нему требуется получить имя хоста). При работе с dig вам будут встречаться и другие типы запросов.

Раздел ANSWER

Раздел ANSWER (6) содержит полученную информацию.

www.nostarch.com.       2550  IN       A      72.32.92.4

Мы запросили информацию для хоста www.nostarch.com, поэтому первым указано имя. Далее следует число 2550 — это время жизни (Time-To-Live, TTL) данной информации. Наш локальный сервер имен может удерживать эту информацию в кэше в течение последующих 2250 секунд (примерно 42 минуты). По истечении этого времени локальный сервер имен удалит запись из кэша. Если кто-то еще раз запросит эту же информацию, локальный сервер DNS отправится за новым ответом. Пара символов IN означает данные Интернета, а А — что это адрес. В конце указан IP-адрес хоста www.nostarch.com — 72.32.92.4.

Раздел AUTHORITY

Для получения IP-адреса www.nostarch.com необходимо пройти по цепочке авторитетных серверов имен. В разделе AUTHORITY (7) перечислены серверы имен, ответственные за домен, — в нашем случае ns1.laughingsquid.net и ns2.laughingsquid.net. Информация о www.nostarch.com будет находиться в кэше в течение 2550 секунд. И снова это адреса Интернета (IN).

Раздел ADDITIONAL

Наконец, в разделе ADDITIONAL (8) dig перечисляет IP-адреса всех хостов, представленных вместе с интересующим нас хостом. Программа dig определила авторитетные серверы имен для домена nostarch.com, но нам могут потребоваться IP-адреса этих серверов, чтобы в будущем выполнять DNS-запросы на получение информации о домене nostarch.com. Информация об авторитетных серверах имен получена, но обратите внимание на значение TTL — оно намного больше, чем то же значение в оригинальном запросе. Этот ответ будет храниться в кэше 171 750 секунд (48 часов). По истечении этого времени ваш локальный сервер имен удалит эти записи из кэша и снова обратится к корневому серверу имен за информацией об авторитетных серверах DNS для домена nostarch.com.

Запустите dig несколько раз с разными доменами и проанализируйте ее вывод.

Поиск имен хостов с помощью dig

Предположим, вы знаете IP-адрес и хотите выяснить связанное с ним имя хоста (как, например, по телефонному номеру определить его владельца). Это типичная задача в Интернете — скажем, пользователь с какого-то IP-адреса то и дело обращается к вашему веб-серверу, а вы хотите узнать, кто он такой и что ему нужно. Найти имя позволит обратный поиск (reverse lookup) с помощью ключа -x команды dig. Поскольку большая часть вывода при этом практически совпадает с результатам прямого поиска, рассмотрим только существенные различия.

Одно из наиболее очевидных отличий: сам запрос (1) выглядит несколько необычно. Что за строка 4.92.32.72.in-addr.arpa? При обратном поиске компоненты IP-адреса упорядочиваются в обратном порядке и помещаются в домен in-addr.arpa.

Кроме того, мы хотим получить запись типа PTR (2), а не А. Тип PTR означает, что требуется определить имя хоста по известному IP-адресу.

Мы знаем, что имени www.nostarch.com соответствует IP-адрес 72.32.92.4, но обратный поиск позволяет получить более корректное имя этого хоста — squid14.laughingsquid.net (3). Во многом это напоминает пример с телефонными номерами, когда одним номером может пользоваться целая семья, но зарегистрирован он на кого-то одного.

В общем случае результаты прямого и обратного поиска должны соответствовать друг другу, но поскольку один IP-адрес может соответствовать нескольким хостам сразу, запись типа А может не соответствовать записи типа PTR. Имя www.nostarch.com отображается в IP-адрес 72.32.92.4, но адрес 72.32.92.4 отображается в имя squid14.laughingsquid.net. Вполне очевидно, что запись типа А для имени squid14.laughingsquid.net должна указывать на IP-адрес 72.32.92.4. Если имя хоста, полученное при обратном поиске, не имеет соответствующей записи при прямом, это означает, что сервер DNS настроен неправильно. Инструменты, опирающиеся на DNS, такие как TCP wrappers (при определенных настройках), будут отвергать запросы на соединения от таких систем. Это можно наблюдать в домашних сетях, построенных на основе технологии ADSL, где по IP-адресу кабельного модема можно получить имя его владельца. Ниже в этой главе мы познакомимся с инструментами, которые автоматически проверяют соответствие результатов прямого и обратного поиска в DNS.

Ключи dig

Для получения полного списка ключей обратитесь к странице руководства dig(1), а ниже я приведу самые полезные. Я наиболее часто использую ключи для обращения к какому-то конкретному серверу и запрещающие рекурсию.

Запрос конкретного сервера имен

По умолчанию dig запрашивает первый сервер имен, указанный в /etc/resolv.conf. Однако при устранении неполадок может возникнуть потребность обратиться к какому-то конкретному серверу имен. Для этого при запуске dig следует указать в командной строке ключ @. Например, чтобы спросить у dns1.wideopenwest.com, что он знает о домене nostarch.com, введите такую команду:

# dig nostarch.com @dns1.wideopenwest.com

Вывод этой команды довольно похож на вывод, представленный в предыдущем примере, за исключением того, что вы увидите ссылки на сервер имен dns1.wideopenwest.com. При выявлении неполадок необходимо тщательно сравнить эту информацию с результатами, выдаваемыми локальным сервером имен. Если данные от двух разных серверов имен противоречивы, это может дать ключ к разгадке.

Запрет рекурсии

По умолчанию для получения ответа сервер имен выполняет рекурсивный запрос. Иногда это нежелательно, например, когда нужно узнать лишь, что имеется в кэше этого сервера и к какому другому серверу он обратился бы за получением ответа на запрос. Часто бывает полезно выполнить рекурсию самостоятельно, особенно при выявлении неполадок. Чтобы запретить рекурсию, в командной строке следует указать ключ +norecurse. Попробуйте использовать этот ключ, обращаясь к локальному серверу имен за информацией о домене, к которому перед этим не было никаких обращений. Если информация об этом домене имеется в кэше сервера имен, результаты будут очень похожи на те, что приводились в предыдущем примере. В противном случае вы получите примерно следующее:

Обратите внимание: сразу вслед за разделом QUESTION (1) идет раздел AUTHORITY (2). Здесь отсутствует раздел ANSWER (ответ). Ответа нет, потому что у сервера имен нет ответа. Вместо этого он отсылает к авторитетным серверам имен для домена .com (3), которые находятся в домене gtld-servers.net. В разделе ADDITIONAL (дополнительная информация) приводятся IP-адреса этих серверов. Примечательно, что некоторые из этих серверов имеют адреса в формате IPv6 (4), помимо стандартных адресов IPv4. Если система не поддерживает адреса IPv6, она не будет их использовать.

Отсылая к серверам имен домена .сот, данный сервер как бы говорит: «Не знаю, спросите у этих парней». Вы попросили свой сервер имен не выполнять рекурсивный запрос, он так и поступил.

Чтобы запросить один из предложенных серверов имен домена .com, следует указать выбранный сервер в командной строке и опять использовать ключ +norecurse.

# dig www.absolutefreebsd.com @a.gtld-servers.net +norecurse

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

in-addr.arpa

У записей типа PTR есть существенный недостаток — информация в них указывается в обратном порядке. Сервер DNS проверяет компоненты имени справа налево. При поиске хоста с именем www.absolutefreebsd.com сервер имен сначала отыскивает сервер имен, обслуживающий домен .com. Затем в домене .com отыскивается сервер имен для домена absolutefreebsd.com, а затем уже www.absolutefreebsd.com. Самый крупный элемент находится справа. Основной сервер домена .com перенаправляет запрос серверу имен поддомена absolutefreebsd, то есть моему серверу, а он в свою очередь отыскивает адрес конкретной машины www.

В IP-адресах самый крупный элемент находится слева. Возьмем IP-адрес 72.32.92.4. Первое число можно сравнить с целым доменом .com. Все IP-адреса, принадлежащие блоку 72, распределяются Американским бюро регистрации номеров Интернета (American Registry for Internet Numbers, ARIN). В свою очередь ARIN передает право распоряжаться блоком адресов 72.32 конкретной компании-провайдеру. Эта компания передает блок адресов 72.32.92 клиенту, который присваивает адрес 72.32.92.4 конкретной машине. Концепция передачи права распоряжаться блоками адресов проста, но происходит слева направо — в противоположном направлении тому, как распределены имена хостов.

IP-адрес, записанный в прямом порядке, очень легко перепутать с IP-адресом, записанным в обратном порядке, поэтому в DNS используется специальный домен, который указывает, что IP-адрес, записан в обратном порядке. К перевернутым IP-адресам справа добавляется строка in-addr.arpa. (Причины такого расположения уходят корнями в прошлое; они довольно скучны и здесь рассматриваться не будут.) В результате наш адрес 72.32.92.4 превращается в 4.92.32.72.in-addr.arpa.

Тогда почему бы не оставить прямую запись IP-адреса и не использовать строку in-addr.arpa для обозначения обратного запроса DNS? Хороший вопрос! Дело в том, что предыдущий запрос достаточно прост, потому что поиск производится в весьма ограниченной области. Однако если вы владеете блоком адресов 72.32.92.0/24*, возможно, вам придется запросить информацию целиком обо всей области, которой распоряжается компания-провайдер, то есть информацию о 92.32.72.in-addr.arpa. Точно так же можно запросить информацию о целом блоке 72.32/16, или 32.72.in-addr.arpa, и даже о блоке 72.in-addr.arpa. Каждый такой запрос подразумевает проверку значительного пространства — аналогично запуску dig .com. Вам, скорее всего, никогда не понадобится запускать dig .com, однако это потребуется инженерам, обслуживающим магистрали Интернета. Именно они и пишут такие программы. Один из недостатков профессиональных инструментов заключается в том, что в первую очередь они адресованы профессионалам.

Быстрый и грубый поиск

Если вам срочно нужна приблизительная информация DNS, программа host(1) сама выполнит обратное преобразование. То же самое сделает программа dig с ключом -x. Пусть запись in-addr.arpa не смущает вас.

Комментарии запрещены.