Протокол DNS
ОГЛАВЛЕНИЕ
Служба имен доменов или DNS
Служба наименований доменов – это то, что я называю общепринятым протоколом. Так много сказано о DNS, что это привело ко многим книгам, написанным исключительно о DNS, что это такое, и что DNS делает. В отличие от других протоколов уровня приложения, которые выполняют только одну функцию, DNS обеспечивает нормальное преобразование имени домена в IP адрес и другие вещи, такие как помощь в маршрутизации вашей почты. Я не думаю, что DNS вскоре превратится в протокол маршрутизации, но благодаря так называемым MX записям Ваша электронная почта может быть направлена на нужный почтовый сервер.
В этой серии статей о DNS мы охватим в целом структуру служб имен доменов. Затем мы рассмотрим немного больше о том, как DNS фактически работает через иерархическую структуру. Еще мы рассмотрим несколько примеров того, что называют исходными записями и RCODES, а также узнаем, что они значат, и как мы можем прервать их для просмотра. Мы это сделаем на пакетном уровне, чтобы дать вам знания, которые потребуются, если вы будете исследовать вашу сеть не пакетном уровне в ближайшем будущем. Просто запомните то, что я упоминал прежде, в этой серии статей рассмотрена действительно только малая часть особенностей DNS. Что я не буду охватывать, так это установку DNS в сети, и поиск неисправностей в ней. С этих слов давайте начнем исследование этого часто неоцененного протокола.
Скромное начало
Если вы системный администратор, то вы можете вспомнить, как все начиналось, как шел рост внутренних DNS и как это рассматривалось Microsoft. В Windows NT есть то, что называется LM Hosts файл. LMHosts файл содержит соответствия NetBIOS имен IP адресам. Это было сделано, чтобы облегчить задачу обнаружения компьютеров и сервисов, предлагаемых во внутренней сети. Затем быстро последовали WINS сервер, а затем Active Directory.
Единственная цель этих различных схем было преобразовать IP адрес в имя компьютера. Статическое преобразование IP адресов в компьютерные имена было актуально в истоках DNS, как нам это известно, сегодня. Возвращаясь в ранние дни сети ARPA, вы просто имели файл, на своем компьютере, со списком компьютеров и их именами. Тогда еще не было такой вещи как DNS в том представлении, в котором мы знаем ее сейчас. Это была, конечно же, не распределенная система, как сейчас, и в большинстве своем поддерживалась индивидуальными компьютерами. Мы ссылаемся на ARPA, чтобы у вас было понятие о том, как рождался Интернет. Содержание списка имен на каждом компьютере быстро стало непрактичным, по мере роста Интернета. Из-за этого появился DNS, такой, каким мы его знаем сейчас, и медленно начал разрастаться. Некоторые знают DNS как распределенную службу имен, и это довольно таки точный термин, для не одиночного компьютер содержащего список соответствия всех имен доменов IP адресам.
Вы видите, что на верху диаграммы, на которую я ссылался, находится корневой DNS сервер. Ниже корневого сервера домены верхнего уровня, как иллюстрируется .com .edu и .mil среди других. Несколько из этих доменов только для эксклюзивного использования в Соединенных Штатах, поскольку США это то место, где родился Интернет. В крайней левой части диаграммы вы видите .arpa. Это используется для «обратных поисков» DNS. В обратном поиске вы запрашиваете, чтобы IP адрес был преобразован в имя домена. Это то для чего используется arpa домен. Каждый, из уровней отображенных, на этой диаграмме содержит IP адреса DNS сервера выше его. Вы можете думать, что корневой DNS сервер содержит обширное количество входов, в действительности это не так.
Так что же на самом деле содержится в корневом DNS сервере? Хороший вопрос. В нем фактически содержится файл, называемый «файл корневой зоны». Этот файл содержит все имена и IP адреса для доверенных DNS серверов верхнего уровня иначе: TLD. Для примера, доменами верхнего уровня являются .com и .edu среди прочих. Как же формируется содержание корневых серверов имен? Это в значительной степени сделано людьми из IANA. Содержащаяся в этой ссылке исчерпывающая информация ответит на этот вопрос. Здесь же вы можете проверить назначение портов, так же как и назначение протоколов. Вы можете определенно рассматривать IANA как безусловный источник информации, так как они “Уполномочены назначать номера Интернет ”.
Возвращаясь к корневым DNS серверам. Фактически трафика, проходящего через корневые DNS серверы, нет как такового. Они не делают никакой фактической маршрутизации. Эти сервера, как упоминалось, просто содержат карту IP адресов доменов DNS серверов для верхнего уровня доменов. Раньше я упоминал, что DNS фактически очень большая «распределенная» служба имен. Также нет одного компьютера, который содержит список всей информации DNS. Было бы в значительной степени невозможно сделать так, или, по крайней мере, непрактично.
Во всяком случае, я не хочу копаться слишком глубоко в разложении DNS иерархии, так как есть много превосходных сайтов, которые занимаются только этим. Другая часть DNS имеет отношение к кэшированию непосредственно записей DNS. Чтобы взглянуть на DNS кэш на вашем домашнем компьютере, просто наберите следующую команду в строке DOS
ipconfig /displaydns
Это отобразит DNS записи, которые (при использовании вами Windows XP) XP resolver проверил перед отправкой DNS серверу Вашего Интернет провайдера, чтобы выполнить запрос, отправленный вами. В информации, которую Вы получили в результате выполнения вышеупомянутых команд в строке DOS, присутствует имя записи, тип записи, ttl значение кэшированной DNS записи (измеряется в секундах), длина данных, раздел, и, наконец, тип записи. Вы можете видеть образец вывода команды ipconfig /displaydns ниже. Хороший материал!
testlab-cs4
------------------------------------------------------
Record Name . . . . . : testlab-cs4
Record Type . . . . . : 1
Time To Live . . . . : 30318069
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :192.168.1.110
Номер типа записи, который вы видите выше, относится к «А» записи. Полный список номеров типов записей и их соответствие типам записей вы можете найти здесь.
DNS, Записи ресурсов и RCODE’s
Теперь мы знакомы со службой именования доменов на высоком уровне. Пришло время познакомится с некоторыми особенностями. К концу мы будем иметь представление приблизительно о так называемых записях ресурсов, и объясним, что они означают. Это будет сделано на примере пакетов так, чтобы мы могли просмотреть их, ведь недостаточно просто прочитать о них. Ниже мы рассмотрим записи ресурсов, в неопределенном порядке. На этой ноте давайте начнем!
Просмотрите, в пакетах ниже различные, не маршрутизированные IP адреса, а именно 192.168.1.200 и 192.168.1.100, которыми я заменил реальные IP адреса, которые были в пакетах. Наконец, я включил выборки RCODE’s и записей ресурсов, чтобы Вы познакомились с ними. Теперь давайте взглянем на наш первый пакет, который содержит RCODE.
Нет такого домена!
В течение вашего ежедневного серфинга по сети, случается, что ссылка, нажатая вами, не загружает запрошенную страницу. В реальном мире иногда веб сайты исчезают по разнообразным причинам. Имея это в виду DNS необходим способ, чтобы передать ответ клиенту, который первоначально сделал запрос. Это делается через DNS RCODE, то есть код ответа, известный как NX или несуществующий домен. Это означает буквально только то, что, нет такого домена, и он не может быть найден. Пожалуйста, обратите внимание, что я отрезал низ отмеченного пакета для краткости, и что в действительности длина пакета должна была быть 143 байта как отражено в поле “len 143”, выделенном ниже.
Итак, мы можем видеть, что DNS сервер, расположенный на 192.168.1.200 говорит 192.168.1.100 (кто первоначально, запрашивал DNS решение на домен), что домен, требовавший решения, не существует. Номер, что мы видим ниже, то есть 17165 - номер DNS транзакции, и позволяет клиенту, запрашивавшему DNS решение, следить за тем, какой ответ соответствует какому DNS запросу. В конце концов, ваш компьютер, вероятно, делает довольно немного запросов DNS решений, и наличие этого номера, позволяет ему следить за тем, что чему принадлежит.
11:00:06.289070 192.168.1.200.53 > 192.168.1.100.155: 17165 NXDomain 0/1/0 (115) (ttl 58, id 43899, len 143)
0x0000 4500 008f ab7b 0000 3a11 26d7 c0a8 01c8 E....{..:.&...e.
0x0010 c0a8 0164 0035 009b 007b 3410 430d 8183 .....5...{4.C...
0x0020 0001 0000 0001 0000 xxxx xxxx xxxx xxxx .........xxxxxxx
0x0030 xxxx xxxx xxxx xxxx xxxx 6e2d 6164 6472 .xxxxx.in-addr
0x0040 0461 7270 6100 000c 0001 c014 0006 0001 .arpa...........
Я хочу ответы!
Что мы видим, ниже – это ответ записи ресурса, он показан подчеркнутой частью. Определенно “A”, соответствует “A” записи ресурса. "А" запись используется, чтобы определить IP адрес. В нашем случае - IP адрес домена banner.paypopup.com. Из нижеследующего мы можем сделать вывод, что 192.168.1.100 выпустил “A? ” запрос, для получения IP адреса домена banner.paypopup. Эта запись ресурса весьма обычная, и в действительности вы увидели бы много таких записей при сниффинге (просмотре пакетов) вашего соединения во время серфинга. Снова, для краткости, я отрезал часть пакета.
11:00:09.511821 192.168.1.200.53 > 192.168.1.100.155: 17170 1/5/5 banner.paypopup.com. A 66.48.78.203 (242) (ttl 58, id 47434, len 270)
0x0000 4500 010e b94a 0000 3a11 1889 c0a8 01c8 E....J..:.....e.
0x0010 c0a8 0164 0035 009b 00fa 4ae2 4312 8180 .....5....J.C...
0x0020 0001 0001 0005 0005 0662 616e 6e65 7208 .........banner.
0x0030 7061 7970 6f70 7570 0363 6f6d 0000 0100 paypopup.com....
0x0040 01c0 0c00 0100 0100 000d 7200 0442 304e ..........r..B0N
Запись CNAME
CNAME представляет каноническое имя, и также является записью ресурса DNS, очень похожей на "A" запись ресурса, рассмотренную выше. Запись ресурса CNAME используется, чтобы показать истинное имя хоста компьютера. Однако может быть более одного имени домена, связанного с одним IP адресом. В сущности, компьютер может иметь целое множество псевдонимов, которые приводят к одному IP адресу, и именно поэтому используются записи CNAME. Для каждого псевдонима в базе DNS должны находиться CNAME записи.
11:00:11.484898 192.168.1.200.53 > 192.168.1.100.155: 17189 3/7/7 fpdownload.macromedia.com. CNAME fpdownload.macromedia.speedera.net., fpdownload.macromedia.speedera.net. A 216
.200.249.204, [|domain] (ttl 58, id 49656, len 375)
0x0000 4500 0177 c1f8 0000 3a11 0f72 c0a8 01c8 E..w....:..r..e.
0x0010 c0a8 0164 0035 009b 0163 16bb 4325 8180 .....5...c..C%..
0x0020 0001 0003 0007 0007 0a66 7064 6f77 6e6c .........fpdownl
0x0030 6f61 640a 6d61 6372 6f6d 6564 6961 0363 oad.macromedia.c
ServFail RCODE
Другой загадочный пакет, с которым вы можете столкнуться – это “ServFail”, который является RCODE точно так же как и NXDomain. ServFail говорит, что возможно была ошибка, полученная непосредственно от DNS сервера, или в течение отправления произошло превышение времени ожидания. Это в действительности говорит вам о том, что ваш DNS запрос не может быть выполнен должным образом, по всей вероятности из-за проблем со стороны сервера.
01:04:37.291738 192.168.1.200.53 > 192.168.1.100.649: [udp sum ok] 60301 ServFail 0/0/0 (33) (ttl 58, id 25184, len 61)
0x0000 4500 003d 6260 0000 3a11 7043 c0a8 01c8 E..=b`..:.pC..e.
0x0010 c0a8 0164 0035 0289 0029 1266 eb8d 8182 .....5...).f....
0x0020 0001 0000 0000 0000 0b6d 7966 756e 6e79 .........myfunny
0x0030 6d61 696c 0363 6f6d 0000 1c00 01 mail.com.....
На что похож DNS запрос?
Пока что мы рассмотрели довольно много DNS ответов, и еще должны фактически рассмотреть DNS запрос. Без дальнейшей суматохи давайте рассмотрим, что представляет из себя запрос. В подчеркнутой ниже части мы можем видеть “A? ” что означает, что 192.168.1.200 просит о записи ответа от 192.168.1.100. В сущности, он спрашивает о IP адресе для домена, указанного после “A? ”.
Мы можем видеть, что полная длина пакета 61 как подтверждает надпись “len 61”, которая также подчеркнута ниже. Также мы можем видеть, что мы имеем тридцать три байта данных в пакете, как отмечено в подчеркнутом ниже тексте “ (33) ”. Почему, спросите вы, есть неравенство между этими двумя числами? Хороший вопрос. Мы имеем полный размер пакета шестьдесят один и полезный размер данных тридцать три. Различие между ними - двадцать восемь байтов. Эти двадцать восемь байтов состоят из двадцати байтов для IP заголовка, и восьми байтов для UDP заголовка. Как только мы сложим эти цифры, мы сможем объяснить полный размер пакета - шестьдесят один байт.
09/06/2005 21:00:38.294185 192.168.1.200.32768 > 192.168.1.100.53: [udp sum ok] 56810 A? amextipe.opt.mr. (33) (DF) (ttl 254, id 27836, len 61)
0x0000 4500 003d 6cbc 4000 fe11 e2d4 c0a8 01c8 E..=l.@.........
0x0010 c0a8 0164 8000 0035 0029 64c8 ddea 0000 R.Z....5.)d.....
0x0020 0001 0000 0000 0000 0861 6d65 7874 6970 .........amextip
0x0030 6503 6f70 7402 6d72 0000 0100 01 e.opt.mr.....
Пакеты DNS
В предыдущих двух частях статьи мы рассмотрели DNS на довольно высоком уровне. Мы не углублялись в детали, необходимы для системного администратора, а сконцентрировались больше на понимании того, что этот протокол делает, и как он это делает. Позднее мы также посмотрели на то, как выглядит пакет DNS в сети, где он находится. В этой последней части статьи о DNS, мы рассмотрим заголовок пакета DNS. Это поможет вам лучше понять сам протокол, и то, как он работает.
Мои мысли по этому поводу, что возможность полностью разобрать пакет по частям придаст вам уверенность при работе с DNS. Это в свою очередь позволит вам приблизиться к любой проблеме в сети с пониманием сути дела. А уверенность такого типа придет лишь при полном понимании не только того, как работает протокол, но и того, как он выглядит в формате пакета.
Давайте разберем пакет на части!
Перед тем, как мы разберем упомянутый выше пакет на части, вам необходимо убедиться, что у вас есть SANS TCP/IPtcpdump flyer расположенный внизу страницы. Это позволит вам подойти к пакету DNS с минимумом затрат. Теперь у буду приводить комментарии по поводу пакета.
01:00:09.684739 192.168.1.200.53 > 192.168.1.100.616: [udp sum ok] 59930 NXDomain 0/1/0 (102) (ttl 58, id 55787, len 130)
0x0000 4500 0082 d9eb 0000 3a11 f873 c0a8 01c8 E.......:..s..e.
0x0010 c0a8 0164 0035 0268 006e ba41 ea1a 8183 .....5.h.n.A....
0x0020 0001 0000 0001 0000 0133 0234 3503 3139 .........3.45.19
0x0030 3103 3230 3605 646e 7362 6c05 736f 7262 1.206.dnsbl.sorb
0x0040 7303 6e65 7400 0001 0001 c019 0006 0001 s.net...........
0x0050 0000 0e10 002c 0772 626c 646e 7330 c01f .....,.rbldns0..
0x0060 0364 6e73 0469 7375 7803 636f 6d00 431c .dns.isux.com.C.
0x0070 e07e 0000 1c20 0000 1c20 0009 3a80 0000 .~..........:...
0x0080 0e10 ..
Я быстро пробегусь по всем полям, начиная с первой линии с права налево. На первой линии расположен временной штамп, это время, когда принимающий компьютер 192.168.1.100 получил этот DNS пакет.
Далее у нас есть IP адрес источника и порт источника: 192.168.1.200.53, следущий за направляющим символом, который означает как проходил диалог.
Далее идет [udp sum ok], означающий, что контрольная сумма udp правильна. Далее идет номер транзакции DNS - 59930. Он, как упоминалось ранее, используется, чтобы отследить DNS запросы и ответы инициатором запроса.
Далее мы видим RCODE NXDomain, что означает, что домен, разрешение которого мы запросили, не существует. Номера 0/1/0 означают, что у нас ноль записей с ответом, одна официальная запись и ноль дополнительных записей в этом пакете.
Далее у нас есть значение 102 в скобках. Это число данных DNS, содержащихся в этом пакете. Далее идет значение ttl равное 58, и IP ID равный 55787, и наконец, длина всего пакета, равная 130. Важно запомнить, что поле “len 130”, как видно выше в пакете, ссылается на длину всего пакета, и что он включает как заголовок протокола, так и данные, которые он представляет.
Мы не будем останавливаться на шестнадцатиричном значении, которое представляет заголовок IP и UDP.
Мы знаем, что наш заголовок IP заканчивается на байтах “0164”, как подчеркнуто в линии 0x0010. Согласно этому, мы знаем, что заголовок UDP начинается с байтов “0035” и заканчивается на байтах “ba41”. Из этого мы можем заключить, что наш заголовок DNS начнется с байта begin at byte “ea” что подчеркивается в линии 0x0010.
Теперь мы рассмотрим значения DNS заголовка. Если вы проверите ваш TCP/IP и tcpdump flyer, который вы загрузили, вы обратите внимание, что первое поле в заголовке DNS относится к номеру ID. Это поле занимает два байта или 16 бит. Вам необходимо выписать маленькую таблицу, наподобие той, что представлена ниже.
| 32768 | 16384 | 8192 | 4096 | 2048 | 1024 | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
Все, что нам необходимо теперь сделать, это взять два байта, представляемые символами “ea1a” и ввести их в калькулятор, который выполнит преобразование шестнадцатиричного значения к десятичному. В результате преобразования в действительности получите значение 59930 в пакете выше. Дальше – лучше, номер записи DNS совпадает.
Далее мы увидим, что следующие значения, как упоминалось в нашей таблице SANS, имеют набор различных значений. Мы видим, что большинство значений отражены в заголовке, который четко разбивается на часть байта или полного байта. В DNS у нас несколько значений содержится в одном байте. Поэтому нам необходима таблица, показанная выше.
Нам необходимо взять значение двух байтов “8183” и преобразовать их к десятичному числу. По этому десятичному числу мы сможем определить, какие значения установлены, а какие нет. Шестнадцатиричное значение 8183 или правильнее записать 0x8183 преобразуется к десятичному 33155.
Используя таблицу, мы начинаем делить 33155 на значения, содержащихся в двух байтовых полях, которые содержат значения вашей таблицы, т.е.: QR, Opcode, и т.д. Поэтому мы знаем, что задана первая позиция 32768, что соответствует ответу. Отняв от 33155 32768, мы получаем остаток 387.
Теперь, вычитаем от 387 ближайшее число из последовательности. В нашем случае это 256. Это значение также установлено, и мы получаем, что поле “Recursion Desired” или RD задано. Теперь мы получаем остаток 131. От этого значения мы отнимаем 128, согласно нашей таблице, которая говорит нам, что задано поле “Recursion Available”. Теперь, после вычитания у нас остается значение 3.
Теперь осталась сложная часть. Вы должны взять это десятичное значение 3 и посмотреть на ваше поле “Response code” в вашей таблице SANS, под заголовком DNS. Вы увидите, что это десятичное значение отображает, что установлено поле “Non-existent domain” или NXDomain RCODE. Мы можем видеть, что он располагается в заголовке этого пакета, что подтверждает NXDomain.
Согласно этим значениям, это просто способ использования аналогичной логики к остальным значениям в заголовке DNS. Как вы можете увидеть, это не намного сложнее, чем разбор обыкновенного пакета, что мы делали перед этим. Это было лишь немного более запутанным, когда мы рассматривали данные уровня приложения. Теперь вы успешно разобрали пакет DNS. А это умеют немногие люди! DNS, состоящую из трех частей, и я искренне надеюсь, что она была полезна для вас. Я всегда приветствую комментарии, поэтому напишите мне. До встречи!
Дон Паркер (Don Parker)