Вывод команды tcpdump для запроса

Рисунок 14.10 Вывод команды tcpdump для запроса на сервер DNS на хосте gemini.tuc.noao.edu.

Мы проинструктировали tcpdump не печатать имена доменов для IP адресов источника и назначения каждой IP датаграммы. Вместо этого он печатает 140.252.1.29 для клиента (разборщик) и 140.252.1.54 для сервера DNS. Порт 1447, используемый клиентом, это порт, назначаемый динамически, а 53 это заранее известный порт DNS сервера. Если tcpdump постарается напечатать имена вместо IP адресов, ему придется обратиться к тому же DNS серверу (осуществляя запрос указателя), что может привести к нежелательному выводу.

Начиная со строки 1, поле после двоеточия (1+) означает, что поле идентификации равно 1, а знак плюс обозначает, что установлен флаг RD (требуется рекурсия). Мы видим, что по умолчанию разборщик требует рекурсию.

Следующее поле, A?, означает, что тип запроса - A (мы хотим получить IP адрес), а маркировка вопроса обозначает, что это запрос (не ответ). Затем печатается имя запроса: gemini.tuc.noao.edu.. Разборщик добавляет последнюю точку к имени запроса, указывая на то, что это абсолютное имя домена.

Длина пользовательских данных в UDP датаграмме составляет 37 байт: 12 байт - заголовок фиксированного размера (рисунок 14.3), 21 байт - имя запроса (рисунок 14.6) и 4 байта - тип запроса и класс запроса. То что UDP датаграмма имеет нечетную длину напоминает нам, что в DNS сообщениях не используются биты заполнения.

Строка 2 в выводе команды tcpdump это ответ от DNS сервера, где 1* в поле идентификации со звездочкой обозначает, что установлен флаг AA (авторитетный ответ). (Мы ожидали от сервера именно этого, так как первичный сервер для домена noao.edu имеет полное представление об именах внутри этого домена.)

Вывод 2/0/0 показывает количество записей ресурсов в трех последних полях с переменной длиной отклика: 2 ответ RR, 0 полномочия RR и 0 дополнительные RR. Команда tcpdump печатает только первый ответ, который в данном случае имеет тип A (IP адрес) со значением 140.252.1.11.

Почему мы получили два ответа на наш запрос? Потому что хост gemini имеет несколько интерфейсов. Поэтому возвращено два IP адреса. Другое полезное средство, использующее DNS, - это программа host. Она позволяет нам отправить запрос на DNS сервер и посмотреть что вернется. Если мы запустим эту программу, то увидим два IP адреса для хоста gemini:

sun % host gemini
gemini.tuc.noao.edu A 140.252.1.11
gemini.tuc.noao.edu A 140.252.3.54

Первый ответ на рисунке 14.10 и первая строка вывода команды host - IP адрес, принадлежащий той же подсети (140.252.1), что и запрашивающий хост. В этом нет ничего странного. Если сервер DNS и хост, отправляющий запрос, находятся в той же самой сети (или подсети), BIND сортирует результаты таким образом, чтобы адреса, принадлежащие общей сети, появлялись в первую очередь.

Мы также можем получить доступ к хосту gemini с использованием другого адреса, однако это будет не так эффективно. С использованием traceroute в этом примере можно увидеть, что обычный путь от подсети 140.252.1 к 140.252.3 не проходит через хост gemini, а проходит через другой маршрутизатор, который подключен к обеим сетям. В данном случае, если мы получим доступ к gemini через другой IP адрес (140.252.3.54), все пакеты потребуют еще одной дополнительной пересылки. Мы вернемся к этому примеру и рассмотрим более подробно причины, по которым используется альтернативный маршрут, в разделе "Дополнительные примеры" главы 25, где мы сможем использовать SNMP, чтобы посмотреть таблицу маршрутизации маршрутизатора.

Существуют и другие программы, предоставляющие простой интерактивный доступ к DNS. Программа nslookup поставляется с большинством реализаций DNS. Глава 10 [Albitz and Liu 1992] подробно описывает эту программу. Программа dig (Domain Internet Groper) это еще одна общедоступная программа, с помощью которой можно отправить запросы на DNS сервера. Программа doc (Domain Obscenity Control) - shellовский скрипт, который использует dig и диагностирует поведение доменов, отправляя запросы на соответствующие DNS сервера и осуществляя простой анализ откликов. В приложении F подробно рассказано, как можно получить эти программы.

И последняя деталь, на которую необходимо обратить внимание в этом примере, это размер UDP данных в отклике: 69 байт. Чтобы объяснить эту величину, надо знать две вещи.

Вопрос возвращается в отклике.
При отправке отклика с именами доменов может быть использовано множество повторов. Поэтому используется схема сжатия. И действительно, в нашем примере имя домена gemini.tuc.noao.edu появляется трижды. Схема сжатия довольно проста. Везде, где в имени домена появляется метка, используется единственный байт-счетчик (который находится в диапазоне от 0 до 63), у которого два старших бита установлены в 1. Это 16-битный указатель, а не 8-битный байт-счетчик. Следующие 14 байт в указателе определяют смещение следующей метки в DNS сообщении. (Смещение первого байта в поле идентификации равно 0.) Мы специально сказали, что этот указатель может появиться там, где появляется метка, а не только там, где появляется полное имя домена, однако возможно, что указатель будет иметь как форму полного имени домена, так и всего лишь окончательной части имени. (Это потому, что окончательные метки в именах заданных доменов часто бывают идентичны.)

На рисунке 14.11 показан формат DNS отклика, что соответствует строке 2 на рисунке 14.10. Здесь показаны IP и UDP заголовки, чтобы напомнить о том, что DNS сообщения обычно инкапсулируются в UDP датаграммы. Мы специально показали байты счетчики в метках имен доменов в вопросе. Два возвращенных ответа одинаковы, за исключением различных IP адресов. В этом примере каждый указатель в ответе имеет значение 12, что является смещением от начала DNS заголовка полного имени домена.

И последнее, на что необходимо обратить внимание, это вторая строка из вывода команды Telnet, которая повторена здесь:

sun % telnet gemini daytime мы напечатали только gemini
Trying 140.252.1.11 ...
Connected to gemini.tuc.noao.edu. однако в выводе клиента Telnet появился FQDN

Содержание раздела