Часть записи ресурса в отклике DNS

205. Последние три поля в DNS сообщении это ответы (answers), полномочия (authority) и дополнительная информация (additional information), общий формат называется записью ресурса (RR - resource record). На рисунке 14.8 показан формат записи ресурса.

206.

207. Рисунок 14.8 Формат записи ресурса DNS.

208.

209. Имя домена (domain name) это имя, которому соответствуют следующие данные ресурса. Формат имени домена тот же, что мы описали ранее для поля имени запроса (query name) (рисунок 14.6).

210. Тип (type) указывает на один из типов кодов RR. Это то же самое, что и значения типа запроса (query type), которые мы описали раньше. Для данных Internet класс (class) обычно установлен в 1.

211. Поле время жизни (time-to-live) это количество секунд, в течение которых RR может быть кэширована клиентом. Обычно TTL RR равно 2 дням.

212. Длина записи ресурса (resource data length) указывает на количество данных ресурса (resource data). Формат этих данных зависит от типа (type). Для типа равного 1 (запись A) данные ресурса - это 4-байтный IP адрес. Сейчас мы описали основной формат DNS запросов и откликов.

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

214. Простой пример

215. Давайте посмотрим, как происходит общение между разборщиком и сервером DNS. Мы запустили клиента Telnet с хоста sun на хост gemini, подключившись к серверу времени:

216.

217.
sun % telnet gemini daytime
Trying 140.252.1.11... первые три строки вывода от Telnet клиента
Connected to gemini.tuc.noao.edu.
Escape character is '^]'.
Wed Mar 24 10:44:17 1993 вывод от сервера дневного времени
Connection closed by foreign host. вывод от Telnet клиента

218.

219. В этом примере мы указали разборщику на хосте sun (где запущен клиент Telnet) использовать сервер DNS на хосте noao.edu (140.252.1.54). На рисунке 14.9 показано взаимное расположение этих трех систем.

220.

221. Рисунок 14.9 Системы, используемые в примере работы DNS.

222.

223. Как мы уже упомянули ранее, разборщик является частью клиента. Он устанавливает контакт с сервером DNS, чтобы получить IP адрес, перед тем как будет установлено TCP соединение между Telnet и сервером времени.

224. На этом рисунке мы опустили подробности, описывающие, как происходит общение между sun и Ethernet сетью 140.252.1, которое в действительности осуществляется по SLIP каналу, потому что это не относится к нашим рассуждениям. Мы запустим tcpdump на SLIP канале, чтобы посмотреть, как происходит обмен пакетами между разборщиком и сервером DNS.

225. Файл /etc/resolv.conf на хосте sun сообщает разборщику о необходимости сделать следующее:

226.

227. sun % cat /etc/resolv.conf
nameserver 140.252.1.54
domain tuc.noao.edu

228.

229. Первая строка сообщает IP адрес DNS сервера - хоста noao.edu. Может быть указано до трех строк nameserver, таким образом, будет обеспечен запасной сервер на случай, если один из них выключен или недоступен. Строка domain содержит домен по умолчанию. Если искомое имя не является полным именем домена (не заканчивается точкой), к имени добавляется имя домена по умолчанию.tuc.noao.edu. Именно поэтому мы можем ввести telnet gemini вместо telnet gemini.tuc.noao.edu.

230. На рисунке 14.10 показан обмен пакетами между разборщиком и сервером DNS.

231.

232.
1 0.0 140.252.1.29.1447 > 140.252.1.54.53: 1+ A?
gemini.tuc.noao.edu. (37)

2 0.290820 (0.2908) 140.252.1.54.53 > 140.252.1.29.1447: 1* 2/0/0 A
140.252.1.11 (69)

233.

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

235.

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

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

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

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

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

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

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

243.

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

245.

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

247.

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

249.

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

251.

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

253. Вопрос возвращается в отклике.

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

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

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

257.

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

259.

260.

261.

262. Рисунок 14.11 Формат DNS отклика, соответствующий строке 2 на рисунке 14.10.

263.

264. Мы указали только имя хоста (gemini), а не полное имя домена (FQDN), однако клиент Telnet вывел именно полное имя домена. В данном случае клиент Telnet ищет имя, которое мы ввели, вызвав разборщик (gethostbyname), который возвращает IP адрес и FQDN. Затем Telnet выводит IP адрес, с которым он старается установить TCP соединение, и когда соединение установлено, печатает FQDN.

265. Пауза между вводом команды Telnet и печатью IP адреса, вызвана тем, что разборщик устанавливает контакт с DNS сервером, чтобы преобразовать имя в IP адрес. Пауза между выводом Trying и Connected to, вызвана установлением TCP соединения между клиентом и сервером, а не DNS.

266. Запросы указателя

267. Для понимания работы DNS важно знать, как обрабатываются запросы указателя - задан IP адрес, возвращается имя (или имена), соответствующее этому адресу.

268. Во-первых, вернемся к рисунку 14.1 и рассмотрим домен верхнего уровня arpa, а также домен in-addr, находящийся ниже. Когда организация вступает в Internet и получает часть простраства имен DNS, как, например, noao.edu, она также получает право на часть пространства имен in-addr.arpa, соответствующее ее IP адресам в Internet. В данном случае noao.edu - это сеть класса B с идентификатором 140.252. Уровень дерева DNS ниже in-addr.arpa должен быть первым байтом IP адреса (140 в данном примере), следующий уровень это следующий байт IP адреса (252), и так далее. Однако помните, что имена пишутся, снизу-вверх по дереву DNS. Это означает, что DNS имя хоста sun с IP адресом 140.252.13.33 будет 33.13.252.140.in-addr.arpa.

269. Мы должны написать 4 байта IP адреса задом наперед, потому что полномочия делегируются на основе идентификаторов сетей: первый байт адрес класса A, первый и второй байты адреса класса B, а первый, второй и третий байты это адреса класса C. Первый байт IP адреса должен быть непосредственно под меткой in-addr, однако полные имена доменов (FQDN) пишутся снизу вверх по дереву. Если бы FQDN писались сверху вниз, DNS имя для IP адреса было бы arpa.in-addr.140.252.13.33, однако в этом случае FQDN для хоста должно быть edu.noao.tuc.sun.

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

271. Однако встретиться с доменом in-addr.arpa и переставленными байтами в IP адресе можно только тогда, когда мы общаемся с DNS непосредственно, используя, такие программы как host или просматривая пакеты с использованием tcpdump. При работе приложения, разборщик (gethostbyaddr) обычно воспринимает IP адрес и возвращает информацию о хосте. Перестановка байтов и добавление домена in-addr.arpa осуществляется разборщиком автоматически.

Пример

273. Давайте воспользуемся программой host, чтобы осуществить поиск указателя, и при этом просмотрим с использованием tcpdump как происходит обмен пакетами. Мы используем те же начальные установки как на рисунке 14.9, запустив программу host на хосте sun с тем же самым сервером DNS noao.edu. Мы указали IP адрес нашего хоста svr4:

274.

275. sun % host 140.252.13.34
Name: svr4.tuc.noao.edu
Address: 140.252.13.34

276.

277. Так как единственный аргумент в командной строке это IP адрес, программа host автоматически генерирует запрос указателя. На рисунке 14.12 показан вывод команды tcpdump.

278.

279.
1 0.0 140.252.1.29.1610 > 140.252.1.54.53: 1+ PTR?
34.13.252.140.in-addr.arpa. (44)

2 0.332288 (0.3323) 140.252.1.54.53 > 140.252.1.29.1610: 1* 1/0/0 PTR
svr4.tuc.noao.edu. (75)

280.

281. Рисунок 14.12 Вывод tcpdump для запроса указателя.

282.

283. Из строки 1 видно, что идентификатор равен 1, установлен флаг требования рекурсии (знак плюс), и тип запроса это PTR. (Вспомним, что марка вопроса обозначает, что это запрос, а не отклик.) Размер данных составляет 44 байта, из которых 12 байт - DNS заголовок, 28 байт - 7 меток в имени домена, и 4 байта это тип запроса и класс запроса.

284. В отклике установлен бит авторитетного ответа (звездочка) и содержится одна запись ресурса (RR) ответа. Тип RR это PTR, а данные ресурса содержат имя домена.

285. От разборщика к серверу DNS в качестве запроса указателя передается не 32-битный IP адрес, а имя домена 34.13.252.140.in-addr.arpa.