TCP-IP крупным планом

Адреса групп

На рисунке 12.2 показан формат IP адреса класса D.

Фильтрация, которая осуществляется

Рисунок 12.1 Фильтрация, которая осуществляется стеком протоколов, когда принимается фрейм.

В настоящее время большинство интерфейсов могут быть сконфигурированы таким образом, чтобы принимать фреймы, IP адрес которых является групповым адресом или групповым адресом какой-либо подгруппы. В групповом адресе Ethernet младший бит старшего байта установлен в единицу. В шестнадцатиричном представлении этот бит выглядит следующим образом: 01:00:00:00:00:00. (Мы можем считать, что широковещательный адрес Ethernet ff:ff:ff:ff:ff:ff это особый случай группового адреса Ethernet.)

Когда сетевая плата получает фрейм, она передает его в драйвер устройства. (Сетевая плата может отбросить фрейм только в том случае, если не сошлась контрольная сумма Ethernet.) Дополнительная фильтрация осуществляется драйвером устройства. Во-первых, тип фрейма должен принадлежать соответствующему протоколу (IP, ARP и так далее). Во-вторых, может быть осуществлена дополнительная групповая фильтрация, чтобы проверить, принадлежит ли хост к адресуемой группе.

Затем драйвер устройства передает фрейм следующему уровню, например, IP, если фрейм является IP датаграммой. IP также осуществляет фильтрацию, основанную на проверке IP адресов источника и назначения, и, в свою очередь, передает датаграмму следующему уровню (например TCP или UDP, если все в порядке).

Каждый раз когда UDP получает датаграмму от IP, он осуществляет фильтрацию, основанную на номере порта назначения, а иногда и на номере порта источника. Если указанный порт не обслуживается в текущий момент каким-либо процессом, датаграмма отбрасывается, и генерируется ICMP сообщение о недоступности порта. (TCP осуществляет подобную фильтрацию, основанную на своих номерах портов.) Если в UDP датаграмме обнаружена ошибка контрольной суммы, UDP молча ее отбрасывает.

Проблема широковещательных запросов заключается в том, что хосты, которые совсем не заинтересованы в получении этих запросов, должны их обрабатывать. Представьте себе приложение, которое должно обрабатывать широковещательные запросы UDP. Если на кабеле находится 50 хостов, но только из них 20 участвуют в работе этого приложения, в каждый момент времени один из 20 посылает широковещательный запрос UDP, при этом остальные 30 хостов должны обработать этот запрос, который проходит весь путь по стеку протоколов до UDP уровня, прежде чем датаграмма будет отброшена. UDP датаграмма отбрасывается этими 30-ю хостами, потому что порта назначения не обслуживается каким-либо процессом.

Основная задача групповых запросов - уменьшить загрузку хостов, не учавствующих в работе определенного приложения. Хост может принадлежать к одной или нескольким группам. Если это возможно, сетевая плата сообщает, к какой группе принадлежит хост, после чего сетевой платой принимаются только фреймы определенной группы.

Формат IP адреса класса D.

Рисунок 12.2 Формат IP адреса класса D.

В отличие от трех других классов IP адресов (A,B и C), форматы которых приведены на рисунке 1.5, 28 бит, отведенные под групповой идентификатор, не подвергаются дальнейшему делению.

Групповой адрес (multicast group address) состоит из четырех старших бит, установленных в 1110, и идентификатора группы. В десятичном виде групповые адреса находятся в диапазоне от 224.0.0.0 до 239.255.255.255.

Некоторое количество хостов, просматривающих определенный групповой IP адрес, называется группой хостов (host group). Группа хостов может объединять хосты в разных сетях. Членство в группе динамическое - хост может вступать в группу и выходить из группы по собственному желанию. Не существует ограничений на количество хостов в группе, и хост не должен принадлежать к группе, чтобы послать сообщение в эту группу.

Некоторые адреса групп назначаются как заранее известные адреса от IANA (Internet Assigned Numbers Authority). В этом случае группа считается постоянной группой хостов (permanent host group). Заранее известные групповые адреса приведены в последних RFC назначенных номеров (Assigned Numbers RFC). Обратите внимание на то, что постоянным в данном случае является групповой адрес, а не членство в группе.

Например, 224.0.0.1 означает "все системы в этой подсети", а 224.0.0.2 означает "все маршрутизаторы в этой подсети". Групповой адрес 224.0.1.1 предназначен для сетевого протокола времени (NTP - Network Time Protocol), 224.0.0.9 для RIP-2 (глава 10, раздел "RIP Version 2") и 224.0.1.2 для SGI (Silicon Graphics) dogfight приложений.

Краткие выводы

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

Существуют четыре типа широковещательных адресов: ограниченный, широковещательный адрес сети, широковещательный адрес подсети и широковещательный адрес всех подсетей. Наиболее распространенный - широковещательный адрес подсети. Ограниченный широковещательный адрес обычно используется системой только в случае загрузки из сети.

Проблемы возникают, когда делается попытка послать широковещательный запрос через маршрутизаторы, чаще всего из-за того, что маршрутизатор не знает маску подсети в сети назначения. Результат зависит от того, какого типа широковещательный адрес, от параметров конфигурации и так далее.

IP адреса класса D называются групповыми адресами. Они преобразовываются в адреса Ethernet путем помещения их 23 младших битов в фиксированный Ethernet адрес. Подобное сопоставление не является уникальным, поэтому требуется дополнительная фильтрация одним из протоколов.

Ограниченный широковещательный запрос

Ограниченный широковещательный адрес (limited broadcast address) - это адрес 255.255.255.255. Он может быть использован в качестве адреса назначения для IP датаграмм в процессе конфигурации хоста, когда хост может не знать собственной маски подсети и даже своего IP адреса.

Датаграмма, направляющаяся на ограниченный широковещательный адрес, никогда (ни при каких условиях) не будет перенаправлена маршрутизатором. Она может существовать только на локальном кабеле.

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

Большинство BSD систем воспринимают 255.255.255.255 как адрес широковещательного адреса первого интерфейса, который был сконфигурирован, и не позволяют послать датаграмму на все подключенные интерфейсы, поддерживающие широковещательную адресацию. И действительно, два приложения, которые посылают UDP датаграммы на каждый интерфейс, это routed (глава 10, раздел "Демоны маршрутизации в Unix") и rwhod (сервер BSD клиента rwho). Оба этих приложения проходят через похожую процедуру запуска, чтобы определить все интерфейсы хоста и те, которые поддерживают широковещательную адресацию. Широковещательный адрес сети, соответствующий этому интерфейсу затем используется как адрес назначения для датаграмм, которые посылаются в этот интерфейс.

Требования к хостам Host Requirements RFC не определяют, должен ли хост, имеющий несколько интерфейсов, посылать ограниченный broadcast на все свои интерфейсы.

Преобразование групповых адресов в адреса Ethernet

IANA владеет блоком Ethernet адресов, которые в шестнадцатиричном представлении выглядят как 00:00:5e. Это старшие 24 бита Ethernet адреса, означающие, что блок включает адреса в диапазоне от 00:00:5e:00:00:00 до 00:00:5e:ff:ff:ff. IANA отвела половину этого блока для групповых адресов. Установлено правило, что первый байт Ethernet адреса равный 01 указывает на групповой адрес. Это означает, что Ethernet адреса, соответствующие групповым адресам IP, должны находиться в диапазоне от 01:00:5e:00:00:00 до 01:00:5e:7f:ff:ff.

Приведенные здесь выражения используют стандартную последовательность битов для Internet, для сетей CSMA/CD или Token bus, а именно такую, как биты располагаются в памяти. Это как раз то, с чем сталкивается большинство программистов и системных администраторов. IEEE документация использует порядок бит, который используется при передаче. Assigned Numbers RFC предоставляет дополнительные подробности о различиях между этими представлениями.

Подобное расположение позволяет 23 битам в Ethernet адресе соответствовать идентификатору группы IP. В процессе преобразования адресов 23 младших бита идентификатора группы помещаются в 23 бита Ethernet адреса. (См. рисунок 12.3.)

Старшие 5 бит в идентификаторе группы игнорируются, так как они не уникальны. Каждому Ethernet адресу соответствует 32 различных идентификатора группы. Например, групповой адрес 224.128.64.32 (в шестнадцатиричном представлении e0.80.40.20) и 224.0.64.32 (в шестнадцатиричном представлении e0.00.40.20) оба будут трансформированы в Ethernet адрес 01:00:5e:00:40:20.

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

Примеры широковещательных запросов

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

Во-первых, приложение должно поддерживать широковещательные запросы. Если мы запустим

sun % ping 255.255.255.255
/usr/etc/ping: unknown host 255.255.255.255

то есть постараемся послать запрос на локальный кабель, это не сработает. Однако проблема здесь заключена в самом приложении (ping). Большинство приложений, которые воспринимают как цифровые IP адреса (в десятичном выражении), так и имена хостов, вызывают функцию inet_addr (3), чтобы конвертировать строку чисел в 32-битный двоичный IP адрес, и если это не удалось, воспринимают строку символов как имя хоста. Эта библиотечная функция возвращает код ошибки -1 если в строке обнаружен символ, отличный от цифры или десятичной точки, в случае ограниченного широковещательного адреса (255.255.255.255) также выдается код -1. Большинство программ, которые воспринимают символьную строку как имя хоста, обрабатывают его с использованием DNS (глава 14) и ограничиваются выводом ошибки, такой как "неизвестный хост" (unknown host).

Даже если мы исправим эту ошибку в программе ping, результаты будут все равно не такими как хотелось бы. Из шести протестированных систем, только одна генерировала широковещательные пакеты в локальный кабель. Большинство ищут IP адрес 255.255.255.255 в таблице маршрутизации, в конце концов находят маршрут по умолчанию и посылают персональный пакет на маршрутизатор по умолчанию. Естественно, такой пакет уничтожается.

В подобном случае необходимо использовать широковещательные запросы, направленные в подсеть. И действительно, в разделе "ICMP запрос и отклик маски адреса" главы 6 мы посылали датаграммы на IP адрес 140.252.13.63 для нижнего Ethernet в нашей тестовой сети и получали отклики от всех хостов Ethernet. Широковещательный адрес, направленный в подсеть, соответствует каждому интерфейсу, именно этот адрес используется командой ifconfig (глава 3, раздел "Команда ifconfig"). Если мы пошлем ping на этот адрес, результат будет таким, как мы хотели:

sun % arp -a ARP кэш пуст

sun % ping 140.252.13.63
PING 140.252.13.63: 56 data bytes
64 bytes from sun (140.252.13.33): icmp_seq=0. time=4. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=172. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=192. ms

64 bytes from sun (140.252.13.33): icmp_seq=1. time=1. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=52. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=1. time=90. ms

^? введен символ прерывани
----140.252.13.63 PING Statistics----
2 packets transmitted, 6 packets received, -200% packet loss
round-trip (ms) min/avg/max = 1/85/192

sun % arp -a снова проверяем ARP кэш
svr4 (140.252.13.34) at 0:0:c0:c2:9b:26
bsdi (140.252.13.35) at 0:0:c0:6f:2d:40

IP определяет, что адрес назначения (140.252.13.63) - это широковещательный адрес, направленный в подсеть, и посылает датаграммы на широковещательный адрес канального уровня.

Мы упоминали в разделе "ICMP запрос и отклик маски адреса" главы 6, что этот тип широковещательных запросов означает обращение ко всем хостам локальной сети, включая отправителя. Из примера видно, что мы получили отклик от отправляющего хоста sun и от всех остальных хостов, находящихся на кабеле.

В этом примере показан ARP кэш перед и после того, как был запущен ping на широковещательный адрес. Это сделано для того, чтобы показать взаимосвязь между рассылкой широковещательных запросов и состоянием ARP. ARP кэш пуст перед запуском ping, и заполнен по окончании. (В кэше находится по одной записи на каждый хост, находящийся на кабеле и ответивший на эхо запрос.) Как заполнился кэш, раз мы сказали, что Ethernet фрейм посылается на широковещательный адрес канального уровня 0xffffffff? Отправка этих фреймов хостом sun не требует ARP.

Если мы посмотрим работу ping с использованием tcpdump, то увидим, что получатели широковещательных фреймов генерируют ARP запрос на sun, перед тем как отправить отклик. Причем, надо отметить, что каждый отклик персональный. Мы говорили в разделе "Примеры ARP" главы 4, что получатель ARP запроса (sun в данном примере) обычно добавляет IP адрес и аппаратный адрес запрашивающего в свой ARP кэш, и отправляет ARP отклик. Это делается из предположения, что если запрашивающий послал нам пакет, мы, возможно, в будущем захотим послать что-нибудь и ему.

Использование ping - это особый случай, потому что подобный тип программного интерфейса, (который в большинстве Unix реализаций называется "символьный сокет" (raw socket)), всегда позволяет послать датаграмму на широковещательный адрес. Что если мы воспользуемся приложением, которое не поддерживает широковещательные запросы, как, например, TFTP? (Мы опишем TFTP более подробно в главе 15.)

bsdi % tftp запускаем клиента
tftp> connect 140.252.13.63 указываем IP адрес сервера
tftp> get temp.foo и пытаемся получить файл с сервера
tftp: sendto: Permission denied
tftp> quit прекращение работы клиента

Здесь мы получаем ошибку мгновенно, при этом в кабель ничего не посылается. Это объясняется тем, что сокеты API не позволяют процессу отправлять UDP датаграммы на широковещательный адрес, если процесс специально не заявил, что он планирует использовать широковещательные запросы. Это сделано для того, чтобы предотвратить ошибочное указание широковещательного адреса пользователем (именно так, как поступили мы в данном случае), тогда как приложение не предназначено для рассылки широковещательных запросов.

Для сокет API, приложение должно установить опцию сокет SO_BROADCAST перед отправкой UDP датаграммы на широковещательный адрес. Однако, не все системы применяют это ограничение. Некоторые реализации позволяют любому процессу отправлять UDP датаграммы широковещательным образом, причем не требуют от процесса, чтобы он объявлял об этом. Другие имеют более строгие ограничения и требуют, чтобы процесс имел привилегии суперпользователя, чтобы использовать широковещательную рассылку.

Следующий вопрос заключается в том, перенаправляются ли широковещательные пакеты. Некоторые ядра и маршрутизаторы имеют опцию, которая позволяет включить или выключить эту характеристику. (См. приложение Е.)

Если мы включим характеристику перенаправления широковещательных пакетов на маршрутизаторе bsdi и запустим ping с хоста slip, то увидим, что bsdi перенаправляет широковещательные запросы, направленные в подсеть. Перенаправление направленных широковещательных запросов означает, что маршрутизатор воспринимает входящие датаграммы как персональные, определяет, что адрес назначения это направленный широковещательный адрес одного из его интерфейсов, и затем перенаправляет датаграммы в соответствующую сеть, используя широковещательный адрес канального уровня.

slip % ping 140.252.13.63
PING 140.252.13.63 (140.252.13.63): 56 data bytes
64 bytes from 140.252.13.35: icmp_seq=0 ttl=255 time=190 ms
64 bytes from 140.252.13.33: icmp_seq=0 ttl=254 time=280 ms (DUP!)
64 bytes from 140.252.13.34: icmp_seq=0 ttl=254 time=360 ms (DUP!)

64 bytes from 140.252.13.35: icmp_seq=1 ttl=255 time=190 ms
64 bytes from 140.252.13.33: icmp_seq=1 ttl=254 time=270 ms (DUP!)
64 bytes from 140.252.13.34: icmp_seq=1 ttl=254 time=360 ms (DUP!)

^? введен символ прерывания
--- 140.252.13.63 ping statistics ---
3 packets transmitted, 2 packets received, +4 duplicates, 33% packet loss
round-trip min/avg/max = 180/273/360 ms

Мы видим, что это работает. Также мы видим, что программа ping в BSD проверяет отслеживает повторные номера последовательности и помечает их как DUP!. Это обычно означает, что пакет был каким-либо образом продублирован, однако здесь именно это и должно было произойти, так как запросы были отправлены на широковещательный адрес.

Этот тест можно запустить с более удаленного хоста (от той сети, к которой направляется широковещательный запрос). Мы запустили ping с хоста vangogh.cs.berkeley.edu (который находится на расстоянии 14 пересылок от нашей сети), и это также будет работать, если маршрутизатор sun сконфигурирован таким образом, чтобы перенаправлять направленные широковещательные запросы. В данном случае IP датаграммы (переносящие ICMP эхо запросы) перенаправляются каждым маршрутизатором, встречающимся им на пути, как обычные датаграммы. Никто из них не знает, что в действительности это направленные широковещательные запросы. И последний маршрутизатор, netb, думает, что пакеты предназначены хосту с идентификатором равным 63, и перенаправляет их на sun. В этом месте sun определяет, что IP адрес назначения в действительности это широковещательный адрес подключенного интерфейса, и передает датаграммы в виде широковещательных запросов канального уровня для этой сети.

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

Рассылка групповых сообщений

Рассылка групповых сообщений IP предоставляет приложениям два сервиса. Доставка к нескольким пунктам назначения. Существует множество приложений, которые доставляют информацию нескольким адресатам, например, диалоговые конференции, распространение почты или новостей. Если групповая адресация не используется, эти типы сервисов вынуждены использовать TCP (при этом осуществляется доставка отдельной копии на каждый пункт назначения). Даже при существовании групповой формы сообщений, некоторые приложения все-таки используют TCP из-за его надежности. Запрос от клиента к серверу. Например, бездисковая рабочая станция старается определить положение сервера загрузки. В настоящее время это осуществляется с использованием широковещательных запросов (как мы увидим в случае с BOOTP в главе 16), однако решение с использованием групповых запросов может уменьшить загруженность хостов, которые не предоставляют этот сервис.

В этом разделе мы рассмотрим групповые адреса, а в следующей главе рассмотрим протоколы, которые используют групповую адресацию хостов и маршрутизаторов (IGMP).

Широковещательные запросы

На рисунке 3.9 показаны четыре различные формы широковещательных адресов IP. Сейчас мы опишем их более подробно.

Широковещательные запросы в сетях FDDI и Token Ring

Сети FDDI используют ту же схему преобразования между IP адресами класса D и 48-битными FDDI адресами [Katz 1990]. Сети Token ring обычно используют отличную систему сопоставления из-за ограничений, которые накладываются на большинство управляющих устройств Token ring [Pusateri 1993].

Широковещательный запрос, направленный во все подсети

Широковещательный адрес всех подсетей (all-subnets-directed broadcast address), также требует знания маски подсети в сети назначения. Только в этом случае можно определить различие между широковещательным адресом всех подсетей и широковещательным адресом сети. И идентификатор подсети, и идентификатор хоста, в данном случае, устанавливаются в единицы. Например, если маска подсети назначения 255.255.255.0, то IP адрес 128.1.255.255 это широковещательный запрос, направленный во все подсети. Однако, если сеть не разбита на подсети, это широковещательный запрос, направляемый в сеть.

В настоящее время такой тип широковещательных запросов считается устаревшим [Almquist 1993]. В настоящее время используются групповые запросы, а не широковещательные запросы, направленные во все подсети.

[Almquist 1993] отмечает, что в RFC 922 требуется, чтобы широковещательные запросы, направленные во все подсети, посылались во все подсети, однако не все маршрутизаторы это поддерживают. И это хорошо, так как неверно сконфигурированый хост, без собственной маски подсети, будет посылать эти "локальные" широковещательные запросы во все подсети. Например, если хост с IP адресом 128.1.2.3 не имеет установленной маски подсети, его широковещательный адрес по умолчанию устанавливается в 128.1.255.255. Однако, если маска подсети должна быть определена как 255.255.255.0, то широковещательные запросы от неправильно сконфигурированного хоста появятся во всех подсетях.

Первая широкораспространенная реализация TCP/IP, в системе 4.2BSD (1983 год), использовала для широковещательных адресов идентификатор хоста, установленного во все нули. Один из самых ранних примеров обращения к широковещательным IP адресам это IEN 212 [Gurwitz and Hinden 1982], и именно здесь было определено использовать широковещательные IP адреса с идентификаторами хостов, установленными во все единицы. (IEN это Internet Experiment Notes, непосредственный предшественник RFC.) В RFC 894 [Hornig 1984] говорится, что 4.2BSD использует нестандартный широковещательный адрес, однако в RFC 906 [Finlayson 1984] замечается, что тогда не существовало стандарта Internet для широковещательных адресов. При редакции RFC была сделана сноска на RFC 906, где говорилось об отсутствии стандарта на широковещательные адреса, однако очень рекомендовалось использовать широковещательные адреса с идентификаторами хоста, установленными во все единицы. К тому же, Berkeley начал использовать все единичные биты для широковещательного адреса, начиная с 4.3BSD (1986 год), однако некоторые операционные системы (и что интересно, даже SunOS 4.x) продолжали использовать нестандартные широковещательные адреса до начала 90-х.

Широковещательный запрос в подсеть

Широковещательный адрес подсети (subnet-directed broadcast address) имеет идентификатор хоста, установленный в единицы, однако определенный идентификатор подсети. Для того, чтобы классифицировать адрес как широковещательный адрес подсети, необходимо знать маску подсети. Например, если маршрутизатор получил датаграмму, с адресом назначения 128.1.2.255, можно считать, что это широковещательный запрос, направленный в подсеть, если сеть класса В 128.1 имеет маску подсети 255.255.255.0, однако это не широковещательный запрос, если маска подсети 255.255.254.0 (0xfffffe00).

Широковещательный запрос в сеть

В широковещательном адресе сети (net-directed broadcast) идентификатор хоста устанавливается во все единичные биты. Широковещательный адрес для сети класса А, имеет вид netid.255.255.255, где netid это идентификатор сети класса А.

Маршрутизаторы должны перенаправлять широковещательные запросы, направляемые в сеть, однако должна присутствовать опция, позволяющая отключить это перенаправление.

Соответствие между IP адресами

Рисунок 12.3 Соответствие между IP адресами класса D и групповыми адресами Ethernet.

Существует два варианта реализации групповой адресации в сетевых платах, использующиеся в локальных сетях. Одни осуществляют групповую фильтрацию, основанную на значении аппаратного группового адреса, что означает, что некоторые нежелательные фреймы могут пройти. В другом случае имеется небольшое фиксированное количество групповых адресов, принимаемых платой, при этом, если хосту необходимо принять больше групповых адресов, чем поддерживается, интерфейс должен быть помещен в режим "разных групп" (multicast promiscuous). Однако, оба типа интерфейсов все еще требуют, чтобы драйвер устройства осуществлял проверку на предмет того, необходимо ли дальше обрабатывать принятый фрейм. Даже если интерфейс осуществляет идеальную групповую фильтрацию (основанную на 48-битном аппаратном адресе) фильтрация все еще необходима, так как сопоставление IP адресов класса D и 48-битных аппаратных адресов осуществляется не один к одному. Однако, если абстрагироваться от несовершенства преобразования адресов и аппаратной фильтрации, групповая адресация все же лучше, чем широковещательная.

Осуществить групповой запрос в единственную физическую сеть довольно просто. Отправляющий процесс указывает IP адрес назначения, который является групповым адресом, драйвер устройства конвертирует это в соответствующий Ethernet адрес и отправляет. Принимающие процессы должены указать своим IP модулям, что они хочет получать датаграммы, предназначенные определенному групповому адресу, и драйвера устройств должен каким-либо образом получать эти групповые фреймы. Все это называется "вступлением в группу". (Причина, по которой мы использовали выражение "принимающие процессы" во множественном числе, объясняется тем, что обычно существует несколько получателей, которым предназначено групповое сообщение, либо на одном, либо на разных хостах.) Когда групповая датаграмма получена хостом, копия доставляется всем процессам, которые принадлежат к группе. Это отличается от UDP, где единственный процесс получает входящую персональную UDP датаграмму. Несколько процессов на одном хосте могут принадлежать к одной группе.

Однако сложности растут как снежный ком, когда группа распространяется на несколько сетей, и групповые пакеты должны проходить через маршрутизаторы. Маршрутизаторам необходимо знать, принадлежат ли какие-либо хосты в данной физической сети к определенной группе. Для определения этого, существует протокол, называемый протоколом группового управления Internet (IGMP - Internet Group Management Protocol). Этому протоколу полностью посвящена следующая глава.

Упражнения

Упражнения

Увеличивается ли сетевой траффик (загрузка сети) в случае широковещательных запросов? Представьте 50 хостов в Ethernet: 20 запускают TCP/IP, а 30 используют какое-либо другое семейство протоколов. Как широковещательные запросы от одного семейства протоколов обрабатываются хостами, использующими другое семейство протоколов? Вы зашли терминалом на Unix систему, с которой раньше никогда не работали, и хотите найти широковещательный адрес, направленный в подсеть, для всех подключенных интерфейсов, которые поддерживают широковещательные сообщения. Как это можно сделать? Если Вы запустили ping на широковещательный адрес с большим размером пакетов, как в примере: sun % ping 140.252.13.63 1472
PING 140.252.13.63: 1472 data bytes
1480 bytes from sun (140.252.13.33): icmp_seq=0. time=6. ms
1480 bytes from svr4 (140.252.13.34): icmp_seq=0. time=84. ms
1480 bytes from bsdi (140.252.13.35): icmp_seq=0. time=128. ms
это работает, однако увеличение размера пакета на 1 байт приведет к следующей ошибке:
sun % ping 140.252.13.63 1473
PING 140.252.13.63: 1473 data bytes
sendto: Message too long
Что произошло?
Повторите упражнение 6 главы 10, представив себе 8 RIP сообщений, направляемых с помощью групповой адресации вместо широковещательной (представьте, что используется RIP Version 2). Что изменится? Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Введение

Введение

В главе 1 мы упомянули, что существуют три типа IP адресов: персональный (unicast), широковещательный (broadcast) и групповой (multicast) . В этой главе мы обсудим широковещательные и групповые адреса более подробно.
Широковещательные и групповые запросы применимы только к UDP, подобные типы запросов позволяют приложению послать одно сообщение нескольким получателям. TCP - протокол, ориентированный на соединение, с его помощью устанавливается соединение между двумя хостами (по указанному IP адресу) с использованием одного процесса на каждом хосте (который идентифицируется по номеру порта).
Представьте себе несколько хостов в Ethernet сети. Каждый Ethernet фрейм содержит Ethernet адрес источника и назначения (48 бит). И обычно каждый фрейм предназначается одному получателю. Адрес назначения, указывающий на один интерфейс, - называется персональным (unicast). Остальные хосты, присутствующие на кабеле, не участвуют в общении между двумя хостами (если не учитывать то, что все хосты находятся все-таки на одном кабеле).
Однако иногда возникает необходимость послать фрейм всем хостам, находящимся на кабеле, - это называется широковещательной рассылкой (broadcast). Мы видели это, когда рассматривали ARP и RARP. Групповая адресация логически находится между персональной и широковещательной: фрейм должен быть доставлен определенному количеству хостов, которые принадлежат к группе.
Для того чтобы понять принцип широковещательной и групповой адресации, необходимо отметить, что на каждом хосте происходит фильтрация, каждый раз когда фрейм проходит по кабелю. На рисунке 12.1 показано как это происходит.
Во-первых, сетевая плата просматривает каждый фрейм, который передается по кабелю, и определяет, необходимо ли принять этот фрейм и доставить его в драйвер устройства. Обычно сетевая плата принимает только те фреймы, адрес назначения которых совпадает с аппаратным адресом интерфейса или с широковещательным адресом. В дополнение, большинство интерфейсов могут находиться в смешанном режиме, когда она принимает копию каждого фрейма. Этот режим используется, например, программой tcpdump.

Детали реализации

В протоколе существуют некоторые аспекты, которые улучшают его производительность. Во-первых, когда хост посылает исходный IGMP отчет (когда первый процесс вступил в группу), не существует гарантии, что этот отчет будет доставлен (так как используется средство доставки IP). Позже отправляется еще один отчет. Время, когда будет отправлен следующий отчет, выбирается хостом случайным образом, причем значение времени находится в диапазоне от 0 до 10 секунд.

Когда хост получает запрос от маршрутизатора, он не отвечает сразу же, а откладывает ответы на более позднее время. (Мы используем множественное число "ответы", потому что хост должен послать один отчет для каждой группы, которая содержит одного или несколько членов.) Так как несколько хостов могут отправить отчет для одной и той же группы, каждый отправляет свой отчет с задержкой, выбранной случайным образом. Также обратите внимание на то, что все хосты подключенные к одной физической сети получают все отчеты от других хостов, находящихся в той же группе, потому что адрес назначения отчета (см. рисунок 13.3) - это групповой адрес. А это, в свою очередь, означает, что если хост отложил момент отправки отчета, однако получил копию того же самого отчета от другого хоста, ответ может быть отменен. Это объясняется тем, что групповому маршрутизатору нет необходимости знать, сколько хостов принадлежит к группе - ему достаточно знать, что по крайней мере один хост принадлежит к группе.

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

Формат полей IGMP сообщения.

Рисунок 13.2 Формат полей IGMP сообщения.

Поле версии IGMP (IGMP version) установлено в 1. Поле тип IGMP (IGMP type) устанавливается в 1 для запроса, посылаемого групповым маршрутизатором, и в 2 для ответа, отправляемого хостом. Контрольная сумма (checksum) рассчитывается так же, как контрольная сумма ICMP.

Групповой адрес (group address) это IP адрес класса D.. В запросе поле группового адреса устанавливается в 0. В отчете оно содержит групповой адрес. Мы расскажем более подробно об этом в следующих разделах, когда будем говорить о том, как функционирует IGMP.

Протокол IGMP

Вступление в группу

Фундаментальной концепцией для работы группы является то, что процесс вступает в группу с определенным интерфейсом хоста. (Мы используем термин процесс, который обозначает программу, которая запущена операционной системой.) Членство в группе динамическое - со временем процесс может как вступать, так и выходить из группы.

Естественно, процесс должен иметь возможность вступить в группу с указанным интерфейсом. Процесс также может покинуть группу, в которую он до этого вступил. Для вступления в группу и выхода из группы требуется, чтобы какой-либо API на хосте поддерживал групповую рассылку. Мы используем выражение "интерфейс", потому что членство в группе связано с интерфейсом. Процесс может вступить в одну и ту же группу с разных интерфейсов.

Релиз IP, поддерживающий групповую рассылку в Berkeley Unix Стэндфордского университета, детализирует эти изменения сокетов API. Эти изменения также присутствуют в Solaris 2.x и описаны в страницах помощи ip(7).

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

Группа всех хостов (All-Hosts)

На рисунке 13.3 мы видели, что IGMP запрос от маршрутизатора отправляется на IP адрес назначения 224.0.0.1. Этот адрес называется адресом группы всех хостов (all-hosts). Он имеет отношение ко всем хостам и маршрутизаторам подключенным к физической сети и поддерживающим групповую адресацию. Каждый хост автоматически вступает в эту группу со всеми интерфейсами, которые поддерживают групповую адресацию, при инициализации интерфейса. О членстве в этой группе никогда не сообщается (рассылкой отчетов).

IGMP отчеты и запросы.

Рисунок 13.3 IGMP отчеты и запросы.

Мы поговорим о поле TTL позже в этом разделе.

IGMP сообщение

На рисунке 13.2 показан формат 8-байтового IGMP сообщения.

IGMP запросы и отчеты

IGMP сообщения используются групповыми маршрутизаторами, чтобы поддерживать членство в группах для каждой сети, физически подключенной к маршрутизатору. Существуют следующие правила. Хост отправляет первый IGMP отчет, когда первый процесс вступает в группу. Если несколько процессов на данном хосте вступили в одну и ту же группу, отправляется только один отчет, в тот момент, когда процесс первый раз вступил в группу. Отчет посылается на тот же интерфейс, с которым процесс вступил в группу. Хост не посылает отчет, когда процесс выходит из группы, даже когда последний процесс вышел из группы. Хост знает, что в этой группе больше нет членов, поэтому когда он получает следующий запрос (следующий шаг), он не отправляет отчет. Групповой маршрутизатор отправляет IGMP запрос с регулярными интервалами, чтобы выяснить, принадлежат ли процессы каких-либо хостов к каким-либо группам. Маршрутизатор послает один запрос на каждый интерфейс. Групповой адрес в запросе установлен в 0, так как маршрутизатор ожидает приход одного отклика от хоста для каждой группы, к которой от хоста принадлежит один или несколько членов. Хост отвечает на IGMP запрос посылкой одного IGMP отчета для каждой группы, которая содержит хотя бы один процесс.

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

На рисунке 13.3 показаны два типа IGMP сообщений, отчеты, отправленные хостом, и запросы, отправленные маршрутизатором. Маршрутизатор опрашивает каждый хост, чтобы тот идентифицировал каждую группу для данного интерфейса.

Инкапсуляция IGMP сообщения в IP датаграмму.

Рисунок 13.1 Инкапсуляция IGMP сообщения в IP датаграмму.

На то, что в IP датаграмме находится IGMP сообщение, указывает величина в поле протокола равная 2.

Краткие выводы

Групповая рассылка это способ разослать сообщения нескольким получателям. Для многих приложений это вариант предпочтительней, нежели рассылка широковещательных запросов, так как с помощью групповой рассылки можно уменьшить загруженность хостов, которые не заинтересованы в принятии сообщений. Простой протокол, определяющий принадлежность хостов к группе (IGMP), - это краеугольный камень, на котором строится групповая адресация.

Групповая адресация в локальной сети или в соседних, соединенных между собой локальных сетях, использует технику, которую мы описали в этой главе. Так как рассылка широковещательных запросов обычно ограничивается одной локальной сетью, групповые запросы могут быть использованы вместо широковещательных для различных предложений, которые в настоящее время используют широковещательные запросы.

Однако, для глобальных сетей проблема групповых запросов до сих пор до конца не решена. [Deering and Cheriton 1990] предлагает расширение существующих протоколов маршрутизации для поддержки групповых запросов. В разделе 9.13 [Perlman 1992] обсуждаются некоторые проблемы, связанные с групповыми запросами в глобальных сетях.

[Casner and Deering 1992] описывает доставку звуковой информации для IETF конференций по Internet с использованием групповых запросов и виртуальной сети, которая называется MBONE (групповая магистраль).

Поле времени жизни

На рисунке 13.3 мы видели, что поле TTL в отчете и запросе установлено в 1. Это напоминает обычное TTL поле в IP заголовке. Групповая датаграмма с TTL исходно равным 0 не "уйдет" дальше своего хоста. По умолчанию групповые датаграммы рассылаются с TTL равным 1. Это позволяет датаграммам распространяться только в своей подсети. Значение TTL больше единицы может быть установлено групповым маршрутизатором.

Обратитесь к разделу "Типы сообщений ICMP" главы 6, где говорится, что ICMP ошибка никогда не генерируется в ответ на датаграмму, направляемую на групповой адрес. Групповые маршрутизаторы не генерируют ICMP ошибку "время истекло" (time exceeded), когда значение TTL становится равным 0.

Обычно, пользовательский процесс не заботится о значении исходящего TTL. Одно исключение, пожалуй, программа Traceroute (см. главу 8), принцип работы которой основан как раз на изменении значения поля TTL. Однако, приложения, которые работают с групповой адресацией, должны иметь возможность установить исходящее поле TTL. Это означает, что программный интерфейс должен предоставлять эту возможность пользовательским процессам.

Путем увеличения TTL приложение может осуществить расширенный поиск (expanding ring search) конкретного сервера. В этом случае первая групповая датаграмма посылается с TTL равным 1, если ответ не получен, посылается датаграмма с TTL равным 2, затем 3 и так далее. В этом случае приложение определяет положение ближайшего сервера в количествах пересылок.

Специальный диапазон адресов 224.0.0.0 - 224.0.0.255 отводится для приложений, которые не будут рассылать групповые запросы дальше чем на одну пересылку. Групповые маршрутизаторы не должны перенаправлять датаграммы с такими адресами назначения, вне зависимости от TTL.

Пример

Пример

Сейчас, когда мы рассмотрели некоторые особенности групповой адресации IP, давайте посмотрим на то, как рассылаются сообщения. Мы добавили поддержку групповой адресации IP на хосте sun, а также воспользовались некоторыми тестовыми программами, которые присутствуют в программном обеспечении, работающем с групповой адресацией.
Во-первых, мы используем модифицированную версию команды netstat, которая сообщает о членстве в группах для каждого интерфейса. (Стандартный вывод netstat -ni для этого хоста приводится в разделе "Команда netstat" главы 3.) Ниже мы выделили строки, имеющие отношение к группам, жирным шрифтом:

sun % netstat -nia
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
le0 1500 140.252.13. 140.252.13.33 4370 0 4924 0 0
224.0.0.1
08:00:20:03:f6:42
01:00:5e:00:00:01
sl0 552 140.252.1 140.252.1.29 13587 0 15615 0 0
224.0.0.1
lo0 1536 127 127.0.0.1 1351 0 1351 0 0
224.0.0.1

Так как указана опция -n, IP адреса печатает в цифровом формате (а не в виде имен), -i печатает статистику по интерфейсам, и -a предоставляет отчет о всех сконфигурированных интерфейсах.
Вторая строка в выводе для le0 (Ethernet) сообщает о том, что этот интерфейс принадлежит к группе 224.0.0.1 (группа "все хосты"), а через одну строку показан соответствующий Ethernet адрес: 01:00:5e:00:00:01. Это как раз то, что мы и ожидали для Ethernet адреса. Подобное соответствие описано в разделе "Рассылка групповых сообщений" главы 12. Мы видим, что два других интерфейса, которые поддерживают рассылку групповых сообщений, канал SLIP - sl0 и loopback интерфейс lo0, также принадлежат к группе всех хостов.
Для маршрутизации групповых датаграмм используется обычная таблица маршрутизации. Пункты, помеченные жирным шрифтом, показывают все датаграммы для 224.0.0.0, отправлены в Ethernet:

sun % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 32 le0
127.0.0.1 127.0.0.1 UH 1 381 lo0
140.252.1.183 140.252.1.29 UH 0 6 sl0
default 140.252.1.183 UG 0 328 sl0
224.0.0.0 140.252.13.33 U 0 66 le0
140.252.13.32 140.252.13.33 U 8 5581 le0

Если Вы сравните эту таблицу маршрутизации с той, которую мы показали в разделе "Принципы маршрутизации" главы 9 для маршрутизатора sun, то увидите, что единственным отличием является запись для группы.
А сейчас запустим тестовую программу, которая позволит вступить в группу для определенного интерфейса. (Вывод этой тестовой программы не приводится.) Мы вступили в группу 224.1.2.3 с интерфейсом Ethernet (140.252.13.33). Исполнение netstat показывает, что ядро вступило в группу Ethernet адресом, как мы и ожидали. Отличия от предыдущего вывода команды netstat приведены жирным шрифтом:

sun % netstat -nia
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
le0 1500 140.252.13. 140.252.13.33 4374 0 4929 0 0
224.1.2.3
224.0.0.1
08:00:20:03:f6:42
01:00:5e:01:02:03
01:00:5e:00:00:01
sl0 552 140.252.1 140.252.1.29 13862 0 15943 0 0
224.0.0.1
lo0 1536 127 127.0.0.1 1360 0 1360 0 0
224.0.0.1

Здесь снова показан вывод для двух других интерфейсов, sl0 и lo0, из чего видно, что в группу вступил только один интерфейс.
На рисунке 13.4 показан вывод команды tcpdump, соответствующий процессу вступления в группу.

1 0.0 8:0:20:3:f6:42 1:0:5e:1:2:3 ip 60:
sun > 224.1.2.3: igmp report 224.1.2.3 [ttl 1]

2 6.94 (6.94) 8:0:20:3:f6:42 1:0:5e:1:2:3 ip 60:
sun > 224.1.2.3: igmp report 224.1.2.3 [ttl 1]

Пример работы группового маршрутизатора

Давайте продолжим предыдущий пример, однако сейчас запустим демон групповой маршрутизации на хосте sun. В данном случае нас интересуют не детали реализации протоколов групповой маршрутизации, а то, как происходит обмен IGMP запросами и отчетами. Даже несмотря на то, что демон групповой маршрутизации запущен только на одном хосте, и только этот (единственный) хост поддерживает групповую адресацию (sun), групповые запросы и отчеты перемещаются по Ethernet.

Перед стартом демона маршрутизации мы вступили в другую группу: 224.9.9.9. На рисунке 13.5 показан вывод.

1 0.0 sun > 224.0.0.4: igmp report 224.0.0.4

2 0.00 ( 0.00) sun > 224.0.0.1: igmp query
3 5.10 ( 5.10) sun > 224.9.9.9: igmp report 224.9.9.9

4 5.22 ( 0.12) sun > 224.0.0.1: igmp query
5 7.90 ( 2.68) sun > 224.1.2.3: igmp report 224.1.2.3
6 8.50 ( 0.60) sun > 224.0.0.4: igmp report 224.0.0.4
7 11.70 ( 3.20) sun > 224.9.9.9: igmp report 224.9.9.9

8 125.51 (113.81) sun > 224.0.0.1: igmp query
9 125.70 ( 0.19) sun > 224.9.9.9: igmp report 224.9.9.9
10 128.50 ( 2.80) sun > 224.1.2.3: igmp report 224.1.2.3
11 129.10 ( 0.60) sun > 224.0.0.4: igmp report 224.0.0.4

12 247.82 (118.72) sun > 224.0.0.1: igmp query
13 248.09 ( 0.27) sun > 224.1.2.3: igmp report 224.1.2.3
14 248.69 ( 0.60) sun > 224.0.0.4: igmp report 224.0.0.4
15 255.29 ( 6.60) sun > 224.9.9.9: igmp report 224.9.9.9

Упражнения

Упражнения

Мы сказали, что хосты рассылают IGMP отчеты со случайными задержками. Как можно убедиться, что в локальной сети два хоста не генерируют отчет с одинаковой случайной задержкой? В [Casner and Deering 1992] сказано, что UDP не имеет двух характеристик, необходимых для посылки звуковой информации по MBONE: определение изменения порядка движения пакетов и определение дублированных пакетов. Как Вы можете добавить эти возможности в UDP? Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Введение

Введение

В разделе "Рассылка групповых сообщений" главы 12 приводится общее описание групповой адресации IP и описывается, как IP адреса класса D преобразуются в Ethernet адреса. Мы кратко упомянули, как осуществляется групповая рассылка в сети, состоящей из одного физического кабеля, однако отложили на потом рассмотрение вопроса, что происходит при групповой адресации в нескольких сетях и каким образом групповые датаграммы проходят через маршрутизаторы.
В этой главе мы рассмотрим протокол управления группами Internet (IGMP - Internet Group Management Protocol), который используется хостами и маршрутизаторами, для того чтобы поддерживать групповую рассылку сообщений. Он позволяет всем системам физической сети знать, какие хосты в настоящее время объединены в группы и к каким группам они принадлежат. Эта информация необходима для групповых маршрутизаторов, именно так они узнают, какие групповые датаграммы необходимо перенаправлять и на какие интерфейсы. IGMP определен в RFC 1112 [Deering 1989].
Как и ICMP, IGMP является частью IP уровня. Так же как ICMP, IGMP сообщения передаются в IP датаграммах. В отличие от других протоколов, которые мы уже рассмотрели, IGMP имеет сообщение фиксированного размера, без необязательных данных. На рисунке 13.1 показана инкапсуляция IGMP сообщения в IP датаграмму.

Вывод команды tcpdump при вступлении хоста в группу.

Рисунок 13.4 Вывод команды tcpdump при вступлении хоста в группу.

Строка 1 соответствует моменту, когда хост вступает в группу. Следующая строка - это задержанный отчет, который, как мы говорили, отправляется с некоторой случайной задержкой (до 10 секунд).

В этих двух строках показаны аппаратные адреса, чтобы убедиться в том, что адрес назначения Ethernet это корректный групповой адрес. Также стоит убедиться в том, что IP адрес источника это один из соответствующих адресов sun, а IP адрес назначения это групповой адрес. Адрес, сообщенный в отчете, - это тот же групповой адрес.

И в заключение, необходимо отметить, что значение TTL установлено в 1, как было указано ранее. Команда tcpdump печатает TTL в квадратных скобках, когда его значение равно 0 или 1. Это потому, что TTL обычно больше, чем эти значения. В случае групповой адресации мы ожидаем увидеть множество IP датаграмм с TTL равным 1.

Из этого вывода видно, что групповой маршрутизатор должен воспринимать все групповые датаграммы на всех своих интерфейсах. Маршрутизатор не имеет представления, в какую группу должен вступить хост.

Вывод команды tcpdump за время работы демона маршрутизации.

Рисунок 13.5 Вывод команды tcpdump за время работы демона маршрутизации.

Мы не включили Ethernet адреса в этот вывод, потому что уже убедились в том, что они именно такие, какие должны быть. Также мы удалили весь вывод, посвященный TTL равным 1, потому что они также соответствуют ожидаемым.

В строке 1 показан момент старта демона маршрутизации. Он отправляет отчет о том, что вступил в группу 224.0.0.4. Групповой адрес 224.0.0.4 - это заранее известный адрес и используется протоколом групповой маршрутизации вектора расстояний (DVMRP - Distance Vector Multicast Routing Protocol). Это протокол используется в настоящее время для групповой маршрутизации. (DVMRP описан в RFC 1075 [Waitzman, Partridge, and Deering 1988].)

При старте демон посылает запрос (строка 2). IP адрес назначения в запросе 224.0.0.1 (все хосты), как показано на рисунке 13.3.

Первый отчет (строка 3) приходит примерно через 5 секунд, для группы 224.9.9.9. Это единственный отчет, принятый перед тем, как был отправлен следующий запрос (строка 4). Два запроса (строки 2 и 4) отправляются с небольшим промежутком в момент старта демона, так как он пытается построить групповую таблицу маршрутизации.

В строках 5, 6 и 7 мы видим по одному отчету для каждой группы, к которой принадлежит хост sun. Обратите внимание, что принят отчет от группы 224.0.0.4, в дополнение к двум группам, в которые мы вступили, потому что в то время пока работает демон, он принадлежит к этой группе.

Следующий запрос в строке 8 появляется через 2 минуты после предыдущего запроса. В ответ на него также приходит три отчета (строки 9, 10 и 11). В этот раз отчеты приходят в другом порядке, так как время между приходом запроса и отправкой отчета выбирается случайным образом.

И последний запрос, отправляется примерно через 2 минуты после предыдущего запроса, и снова получены ожидаемые отклики.

3-Символьные общие домены.

Рисунок 14.2 3-символьные общие домены.

Иногда считается, что 3-символьные общие домены используются только организациями Соединенных Штатов, а 2-символьные домены стран всеми остальными, однако это не так. Существуют неамериканские организации в основных доменах, и множество организаций в Соединенных Штатах находятся в домене страны .us. (RFC 1480 [Cooper and Postel 1993] описывает домен .us более подробно.) Единственные общие домены, которые закреплены за Соединенными Штатами, это .gov и .mil.

Многие 2-символьные домены стран второго уровня, очень похожи на основные домены: .ac.uk, например, принадлежит академическим институтам, а .co.uk коммерческим организациям Великобритании.

Одна важная характеристика DNS, не показанная на рисунке 14.1, это передача ответственности внутри DNS. Не существует организации, которая бы управляла и обслуживала все дерево в целом и каждую метку в отдельности. Вместо этого, одна организация (NIC) обслуживает только часть дерева (домены верхнего уровня), а ответственность за определенные зоны передает другим организациям.

Зона (zone) это отдельно администрируемая часть дерева DNS. Например, домен второго уровня noao.edu это отдельная зона. Многие домены второго уровня поделены на меньшие зоны. Например, университет может поделить свою зону на подзоны по факультетам, а компания может поделить себя на зоны по принципу деления на филиалы или отделы.

Если Вы знакомы с файловой системой Unix, то обратите внимание, что деление дерева DNS на зоны очень напоминает деление на логические файловые системы физических дисковых разделов. Однако мы не можем сказать, основываясь на рисунке 14.1, под чьим руководством находятся зоны, также как мы не можем по подобному рисунку сказать, какие директории в файловой системе находятся в определенном дисковом разделе.

С того момента, как выбрана организация или персона, которая несет ответственность за управление зоной, эта организация или персона должна организовать несколько серверов DNS (name servers) для этой зоны. Как только в зоне появляется новая система, администратор этой зоны помещает имя и IP адрес нового хоста в базу данных сервера DNS. В небольших университетах, например, один человек может делать это каждый раз при появлении новой системы, однако в больших университетах ответственность должна быть распределена (например, по департаментам), так как один человек не может осуществлять эту работу в целом.

Сервер DNS, скажем, обслуживает одну зону или несколько зон. Человек, который несет ответственность за зону, администрирует основной сервер DNS (primary name server) для этой зоны и один или несколько вторичных серверов DNS (secondary name servers). Первичный и вторичный сервера должны быть независимы и избыточны таким образом, чтобы система DNS не вышла из строя при отказе одного из серверов.

Основное отличие между первичными и вторичными серверами заключается в том, что первичные загружают всю необходимую информацию из дисковых файлов, тогда как вторичные получают информацию от первичного. Процесс передачи информации от первичного сервера вторичному называется передачей зоны (zone transfer). Когда в зоне появляется новый хост, администратор добавляет соответствующую информацию (минимум, имя и IP адрес) в дисковый файл на первичном сервере. После чего первичный сервер DNS уведомляется о необходимости повторно считать свои конфигурационные файлы. Вторичные сервера регулярно опрашивают первичные (обычно каждые 3 часа), и если первичные содержат новую информацию, вторичный получает ее с использованием передачи зоны.

Что произойдет, если сервер DNS не содержит необходимой информации? Он должен установить контакт с другим сервером DNS. (В этом заключается распределенная природа DNS.) Однако не каждый сервер DNS знает, как обратиться к другому серверу. Вместо этого каждый сервер DNS должен знать, как установить контакт с корневыми серверами DNS (root name servers). В апреле 1993 года существовало восемь корневых серверов, все первичные сервера должны знать IP адреса каждого корневого сервера. (Эти IP адреса находятся в конфигурационных файлах первичного сервера. Первичные сервера должны знать именно IP адреса корневых серверов, а не их DNS имена.) Корневой сервер, в свою очередь, знает имена и положения (IP адрес) каждого официального сервера DNS для всех доменов второго уровня. При этом возникает последовательный процесс: запрашивающий сервер должен установить контакт с корневым сервером. Корневой сервер сообщает запрашивающему серверу о необходимости обратиться к другому серверу и так далее. Мы рассмотрим эту процедуру и соответствующие примеры позже в этой главе.

Вы можете получить текущий список корневых серверов, воспользовавшись анонимным (anonymous) FTP. Получите файл netinfo/root-servers.txt с ftp.rs.internic.net или nic.ddn.mil.

Фундаментальная характеристика DNS - это кэширование (caching). Когда DNS сервер получает информацию о соответствии (скажем, IP адресов именам хостов), он кэширует эту информацию таким образом, что в случае следующего запроса может быть использована информация из кэша, дополнительный запрос на другие сервера не делается. В разделе "Кэширование" этой главы мы рассмотрим кэширование более подробно.

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

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

Еще один пример

Давайте рассмотрим еще один пример, который описывает несколько функций DNS, о которых мы рассказали раньше. Мы запустили клиента Rlogin, подсоединившись к Rlogin серверу в каком-то удаленном домене. На рисунке 14.16 показан обмен пакетами.

Формат DNS отклика, соответствующий

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

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

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

Формат раздела вопроса (question) в запросе DNS.

Рисунок 14.5 Формат раздела вопроса (question) в запросе DNS.

(Дальше в этом разделе мы увидим, что байт счетчик с двумя старшими битами, установленными в 1, значения от 192 до 255, используется в схеме со сжатием.) В отличие от многих других форматов сообщений, которые мы рассмотрели, этому полю разрешено заканчиваться на ограничителе не равном 32 битам. Заполнение не используется.

На рисунке 14.6 показано, как хранится имя домена gemini.tuc.noao.edu.

Формат сообщения DNS

Для DNS запроса и для DNS отклика используется одинаковый формат. На рисунке 14.3 показан общий формат DNS сообщения.

Формат записи ресурса DNS.

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

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

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

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

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

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

Иерархическая организация DNS.

Рисунок 14.1 Иерархическая организация DNS.

Каждый узел (кружочки на рисунке 14.1) имеет метку длиной до 63 символов. Корень дерева это специальный узел без метки. Метки могут содержать заглавные буквы или маленькие. Имя домена (domain name) для любого узла в дереве - это последовательность меток, которая начинается с узла выступающего в роли корня, при этом метки разделяются точками. (Здесь видно отличие от файловой системы Unix, где полный путь всегда начинается с вершины (корня) и опускается вниз по дереву.) Каждый узел дерева должен иметь уникальное имя домена, однако одинаковые метки могут быть использованы в различных точках дерева.

Имя домена, которое заканчивается точкой, называется абсолютным именем домена (absolute domain name) или полным именем домена (FQDN - fully qualified domain name). Например, sun.tuc.noao.edu.. Если имя домена не заканчивается на точку, подразумевается, что имя должно быть завершено. Как будет закончено имя, зависит от используемого программного обеспечения DNS. Если незаконченное имя состоит из двух или более меток, его можно воспринимать как законченное или полное; иначе справа от имени должен быть добавлен локальный суффикс. Например, имя sun может быть завершено локальным суффиксом .tuc.noao.edu..

Домены верхнего уровня поделены на три зоны: arpa это специальный домен, используемый для сопоставления адрес - имя (раздел "Запросы указателя" этой главы). Семь 3-символьных доменов называются общими (generic) доменами. В некоторых публикациях они называются организационными (organizational) доменами. Все 2-символьные домены, основанные на кодах стран, можно найти в ISO 3166. Они называются доменами стран (country), или географическими (geographical) доменами.

На рисунке 14.2 приведен список обычной классификации семи основных доменов.

Домен	Описание
com	коммерческие организации
edu	учебные организации
gov	правительственные организации США
int	международные организации
mil	военные организации США
net	сети
org	другие организации

Кэширование

Чтобы уменьшить траффик DNS в Internet, все сервера DNS используют кэширование. В стандартных Unix реализациях кэш поддерживается сервером, а не разборщиком. Так как разборщик является частью каждого приложения, а приложения приходят и уходят, оставляя кэш в программах, которые живут все время, пока система работает (сервер DNS), имеет смысл поддерживать кэш именно на сервере. При этом кэш доступен любому приложению, которое использует сервер. Любые другие хосты в узле, которые используют этот сервер DNS, также пользуются кэшем сервера.

В примерах (рисунок 14.9), мы запускали клиентов на хосте sun, и обращались к DNS серверу на хост noao.edu через SLIP канал. Сейчас попробуем запустить DNS сервер на хосте sun. В этом случае, если просмотреть с использованием tcpdump траффик DNS в SLIP канале, мы увидим только запросы, которые не могут быть обработаны сервером в своем собственном кэше.

По умолчанию разборщик ищет сервер DNS на локальном хосте (UDP порт 53 или TCP порт 53). Мы удалили запись nameserver из файла разборщика, оставив только запись domain:

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

Отсутствие записи nameserver в этом файле приводит к тому, что разборщик пользуется сервером DNS на локальном хосте.

Затем мы запустили команду host следующим образом:

sun % host ftp.uu.net
ftp.uu.net A 192.48.96.9

На рисунке 14.14 показан вывод команды tcpdump для этого запроса.

1 0.0 sun.tuc.noao.edu.domain > NS.NIC.DDN.MIL.domain:
2 A? ftp.uu.net. (28)
2 0.559285 (0.5593) NS.NIC.DDN.MIL.domain > sun.tuc.noao.edu.domain:
2- 0/5/5 (229)

3 0.564449 (0.0052) sun.tuc.noao.edu.domain > ns.UU.NET.domain:
3+ A? ftp.uu.net. (28)
4 1.009476 (0.4450) ns.UU.NET.domain > sun.tuc.noao.edu.domain:
3* 1/0/0 A ftp.UU.NET (44)

Краткие выводы

DNS это одна из важнейших частей любого хоста, подключенного к Internet, эта система также широко используется в частных объединенных сетях. Основа организации - иерархическое дерево, которое формирует пространство имен DNS.

Приложения обращаются к разборщикам, чтобы конвертировать имя хоста в IP адрес и наоборот. Разборщики обращаются к локальным серверам DNS, а они, свою очередь, могут обратиться к одному из корневых серверов или к другим серверам, чтобы получить ответ на запрос.

Все DNS запросы и отклики имеют один и тот же формат. Эти сообщения содержат записи ресурсов (RR) вопросов и, возможно, ответов, RR полномочий и RR дополнительной информации. Мы рассмотрели множество примеров, в которых показана конфигурация разборщика и некоторые принципы организации DNS: указатели на имена доменов (чтобы уменьшить размер сообщений), кэширование, домен in-addr.arpa (поиск имени по заданному IP адресу) и возвращаемые дополнительные RR (для того чтобы запрашивающий не выдавал повторный запрос).

Обмен пакетами при старте Rlogin клиента и сервера.

Рисунок 14.16 Обмен пакетами при старте Rlogin клиента и сервера.

Было осуществлено 11 шагов, при этом заранее никакой информации на клиенте или сервере кэшировано не было: Клиент стартует и вызывает свою функцию разборщика, чтобы конвертировать имя хоста, которое мы ввели вместо IP адреса. Запрос типа A отправляется на корневой сервер. Ответ от корневого сервера содержит DNS сервера для домена в котором находится Rlogin сервер. Разборщик клиента повторно отправляет запрос типа A на DNS сервер. Этот запрос обычно имеет установленный флаг "рекурсия необходима". Приходит отклик с IP адресом хоста. Клиент Rlogin устанавливает TCP соединение с сервером Rlogin. (В главе 18 этот процесс описывается более подробно.) TCP модули клиента и сервера обмениваются друг с другом тремя пакетами. Сервер Rlogin принимает соединение от клиента и вызывает свой разборщик, чтобы получить имя хоста клиента по IP адресу, который сервер получил от своего TCP. Это PTR запрос, выданный на корневой DNS сервер. Может быть, это не тот корневой сервер, к которому обратился клиент в шаге 1. Отклик корневого сервера содержит имя DNS сервера домена in-addr.arpa клиента. Разборщик сервера повторно отправляет PTR запрос к DNS серверу клиента. PTR отклик содержит FQDN хоста клиента. Разборщик сервера отправляет запрос типа A к DNS серверу клиента, спрашивая IP адрес, соответствующий имени, возвращенному в предыдущем шаге. Это может быть сделано автоматически с использованием функции сервера gethostbyaddr, как мы описали в разделе "Запросы указателя" этой главы, или сервер Rlogin осуществляет этот шаг самостоятельно. Также, DNS сервер клиента часто тот же самый, что и DNS сервер клиента in-addr.arpa, однако это необязательно. Отклик от DNS сервера клиента содержит запись A для хоста клиента. Сервер Rlogin сравнивает запись A с IP адресом клиента, потребовавшего открыть TCP соединение.

Кэширование может уменьшить количество пакетов, которыми произошел обмен в этом примере.

Общий формат DNS запроса и ответа.

Рисунок 14.3 Общий формат DNS запроса и ответа.

Сообщение содержит фиксированный 12-байтный заголовок, за которым следуют четыре поля переменной длины.

Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.

16-битовое поле флагов (flags) поделено на несколько частей, как показано на рисунке 14.4.

Основы DNS

Пространство имен DNS имеет иерархическую структуру, которая внешне напоминает файловую систему Unix. На рисунке 14.1 показана иерархическая организация DNS.

Поле флагов (flags) в заголовке DNS.

Рисунок 14.4 Поле флагов (flags) в заголовке DNS.

Описание каждого поля мы начнем с крайне левых битов. QR (тип сообщения), 1-битовое поле: 0 обозначает - запрос, 1 обозначает - отклик. opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения - это 1 (инверсный запрос) и 2 (запрос статуса сервера). AA - 1-битовый флаг, который означает "авторитетный ответ" (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов. TC - 1-битовое поле, которое означает "обрезано" (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика. RD - 1-битовое поле, которое означает "требуется рекурсия" (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query) . Мы рассмотрим примеры обоих типов запросов в следующих примерах. RA - 1-битовое поле, которое означает "рекурсия возможна" (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности). Это 3-битовое поле должно быть равно 0. rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Представление имени домена gemini.tuc.noao.edu.

Рисунок 14.6 Представление имени домена gemini.tuc.noao.edu.

У каждого вопроса есть тип запроса (query type), а каждый отклик (называемый записью ресурса, о чем мы поговорим ниже) имеет тип (type). Существует около 20 различных значений, некоторые из которых в настоящее время уже устарели. На рисунке 14.7 показаны некоторые из этих значений. Тип запроса это надмножество (множество, подмножеством которого является данное множество) типов: два из показанных значений, могут быть использованы только в вопросах.

Имя	Цифровое значение	Описание	тип (type)?	тип запроса (query type)?
A	1	IP адрес	·	·
NS	2	сервер DNS	·	·
CNAME	5	каноническое имя	·	·
PTR	12	запись указателя	·	·
HINFO	13	информация о хосте	·	·
MX	15	запись об обмене почтой	·	·
AXFR	252	запрос на передачу зоны		·
* или ANY	255	запрос всех записей		·

Пример

Пример

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

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)

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

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

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 клиента

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

Проверка неправильного имени хоста

Когда IP датаграмма прибывает на хост сервера, будь то UDP датаграмма или TCP сегмент с требованием установить соединение, все что доступно процессу сервера это IP адрес клиента и номер порта (UDP или TCP). Некоторые сервера требуют, чтобы IP адрес клиента имел запись указателя в DNS. В разделе "Примеры FTP" главы 27 мы рассмотрим пример, иллюстрирующий это, используя анонимный FTP с неизвестного IP адреса.

Другие серверы, как, например, сервер Rlogin (глава 26), требуют не только то, чтобы IP адрес клиента имел запись указателя, но и еще спрашивают DNS об IP адресе, соответствующем имени, возвращенном в PTR отклике, и требуют, чтобы один из возвращенных адресов совпадал с IP адресом в принятой датаграмме. Эта проверка осуществляется потому, что пункты в файле .rhosts (глава 26, раздел "Протокол Rlogin") содержат имя хоста, а не IP адрес; таким образом, сервер хочет убедиться, что имя хоста действительно соответствует входящему IP адресу.

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

Мы можем увидеть, как это происходит, с помощью библиотеки разборщика SunOS 4.1.3. Мы написали простую программу, которая осуществляет запрос указателя путем вызова функции gethostbyaddr. Также мы поместили записи в файл /etc/resolv.conf таким образом, чтобы использовать в качестве DNS сервера хост noao.edu, получить доступ к которому можно через SLIP канал с хоста sun. На рисунке 14.13 показан вывод команды tcpdump, полученный от SLIP канала, при вызове функции gethostbyaddr, в случае, когда получается имя, соответствующее IP адресу 140.252.1.29 (хост sun).

1 0.0 sun.1812 > noao.edu.domain: 1+ PTR?
29.1.252.140.in-addr.arpa. (43)
2 0.339091 (0.3391) noao.edu.domain > sun.1812: 1* 1/0/0 PTR
sun.tuc.noao.edu. (73)
3 0.344348 (0.0053) sun.1813 > noao.edu.domain: 2+ A?
sun.tuc.noao.edu. (33)
4 0.669022 (0.3247) noao.edu.domain > sun.1813: 2* 2/0/0 A
140.252.1.29 (69)

Раздел вопросов в DNS запросе

Формат каждого вопроса в разделе вопросов (question) показан на рисунке 14.5. Обычно присутствует только один вопрос.

Имя запроса (query name) это искомое имя. Оно выглядит как последовательность из одной или нескольких меток. Каждая метка начинается с 1-байтового счетчика, который содержит количество следующих за ним байт. Имя заканчивается байтом равным 0, который является меткой с нулевой длиной. И является, в свою очередь, меткой корня. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина метки ограничена 63 байтами.

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

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

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

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

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

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

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

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

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)

UDP или TCP

Мы уже упоминали, что заранее известные номера портов для DNS серверов - UDP порт 53 и TCP порт 53. Это означает, что DNS поддерживает как UDP, так и TCP. Однако все примеры, которые мы просмотрели с использованием tcpdump, использовали UDP. Когда используется тот или иной протокол и почему?

Когда разборщик выдает запрос и возвращается отклик с установленным битом TC (обрезано - truncated), это означает, что размер отклика превысил 512 байт, только первые 512 байт были возвращены серверу. Разборщик обычно отправляет запрос снова, но уже с использованием TCP. При этом возвращается больше, чем 512 байт. (Вспомните описание максимального размера UDP датаграммы в разделе "Максимальный размер UDP датаграммы" главы 11.) Так как TCP делит поток данных на части, которые называются сегментами, он может передать любое количество пользовательских данных с использованием нескольких сегментов.

Также, когда в домене включается вторичный сервер DNS, он осуществляет передачу зоны с первичного сервера домена. Мы также говорили, что вторичный сервер регулярно запрашивает первичный (обычно каждые три часа). При этом определяется, не обновил ли первичный сервер свою таблицу, и если да, то осуществляется передача зоны. Передача зоны осуществляется с использованием TCP, так как в этом случае передается значительно больше данных, чем в случае одного запроса или отклика.

Так как DNS в основном использует UDP, и разборщик, и сервер DNS должны отработать свой собственный тайм-аут и осуществить повторную передачу. В отличие от других приложений Internet, которые используют UDP (TFTP, BOOTP и SNMP) и которые функционируют обычно в локальных сетях, DNS отправляет запросы и получает отклики обычно по глобальным сетям. Процент потерянных пакетов и разница в значениях времен возврата обычно значительно выше в глобальных сетях, нежели в локальных, при этом повышается важность надежной передачи и четкости работы алгоритма расчета тайм-аутов для клиентов DNS.

Упражнения

Упражнения

Классифицируйте DNS разборщик и DNS сервер как с точки зрения модели "клиент-сервер". Объясните назначение всех 75 байт в отклике на рисунке 14.12. В разделе "Примеры широковещательных запросов" главы 12 мы говорили, что приложения, которые понимают как IP адреса в виде десятичных цифр, разделенных точками, так и имена хостов, должны воспринимать сначала IP адреса, а затем имена хостов, в том случае, если получить IP адрес не удалось. Что произойдет, если порядок проверки будет изменен на обратный? Каждая UDP датаграмма имеет длину. Процессу, который получает UDP датаграмму, сообщается ее длина. Разборщик может выдать запрос с использованием TCP вместо UDP. TCP это поток байтов без каких-либо маркеров записи. Как приложение может узнать, сколько данных возвращено? Обратите внимание, что в DNS заголовке нет поля длины (рисунок 14.3). (Подсказка: обратитесь к RFC 1035.) Мы говорили, что сервер DNS должен знать IP адреса корневых серверов, и что эта информация доступна через анонимный FTP. К сожалению, не все системные администраторы обновляют свои DNS файлы, если изменяется список корневых серверов. (В списке корневых серверов иногда происходят изменения, однако нечасто.) Как Вы думаете, каким образом DNS обрабатывает подобную ситуацию? Получите файл, упомянутый в упражнении 8 главы 1, и определите, кто несет ответственность за обслуживание корневых серверов DNS. Как часто обновляется информация на корневых серверах? В чем заключается проблема обслуживания кэша на сервере DNS и какую роль в этом играет разборщик? При обсуждении рисунка 14.10 мы сказали, что DNS сервер сортирует записи A таким образом, что адреса, принадлежащие сети, в которой находится запрашивающий хост, становятся первыми. Кто должен сортировать записи A: сервер DNS или разборщик? Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Введение

Введение

Система имен доменов (DNS - Domain Name System) это распределенная база данных, которая используется приложениями TCP/IP, для установления соответствия между именами хостов и IP адресами. DNS также используется для маршрутизации электронной почты. Мы используем термин распределенная, потому что на одном узле Internet не хранится вся необходимая информация. Каждый узел (университет, университетский городок, компания или отдел внутри компании) поддерживает собственую информационную базу данных и запускает программу сервер, которая может отправить запрос по Internet к другим системам. DNS предоставляет протокол, который позволяет клиентам и серверам общаться друг с другом.
С точки зрения приложения, доступ к DNS осуществляется посредством разборщика (resolver) (разборщик (resolver) - подпрограммы, которые используются для создания, отправки и интерпретации пакетов, используемых серверами имен Internet). В Unix системах, к разборщику можно получить доступ через две библиотечные функции, gethostbyname(3) и gethostbyaddr(3), которые линкуются с приложением, когда оно строится. Первая воспринимает в качестве аргумента имя хоста и возвращает IP адрес, а вторая воспринимает в качестве аргумента IP адрес и возвращает имя хоста. Разборщик устанавливает контакты с одним или несколькими серверами DNS (name servers), чтобы установить это соответствие.
На рисунке 4.2 показано, что разборщик - это часть приложения. Он не является частью ядра операционной системы как протоколы TCP/IP. Приложение должно конвертировать имя хоста в IP адрес, перед тем как оно попросит TCP открыть соединение или послать датаграмму с использованием UDP. Протоколы TCP/IP внутри ядра ничего не знают о DNS.
В этой главе мы рассмотрим, как разборщики общаются с DNS серверами с использованием протоколов TCP/IP (в основном UDP). Однако мы не будем рассматривать установку и администрирование DNS серверов или все опции, существующие у разборщиков и серверов. Это может составить еще одну книгу. (В публикации [Albitz and Liu 1992] приведены подробности функционирования стандартных Unix разборщиков и серверов DNS.)
RFC 1034 [Mockapetris 1987a] описывает концепции, лежащие в основе DNS, а RFC 1035 [Mockapetris 1987b] содержит подробности разработки и спецификации DNS. Наиболее широкоиспользуемая реализация DNS, как разборщика, так и сервера - BIND (Berkeley Internet Name Domain). Процесс сервера называется named. Анализ траффика, генерируемого DNS в глобальных сетях, приводится в [Danzig, Obraczka, and Kumar 1992].

Вывод команды 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

Вывод tcpdump для: host ftp.ee.lbl.gov.

Рисунок 14.15 Вывод tcpdump для: host ftp.ee.lbl.gov.

Из строки 1 видно, что теперь наш сервер установил контакт с другим корневым сервером (c.nyser.net). Сервер DNS обычно циклически опрашивает различные серверы для зоны, при этом накапливается информация о времени отклика от того или иного сервера. И, в конце концов, будет использован тот сервер, время возврата от которого минимально.

Так как наш сервер установил контакт с корневым сервером, флаг "рекурсия необходима" не установлен. Корневой сервер не сбросил флаг "рекурсия возможна", как мы видели в строке 2 на рисунке 14.14. (Даже если так, DNS сервер все равно не должен запрашивать корневой сервер с помощью рекурсивного запроса.)

В строке 2 отклик приходит назад без ответа, однако с четырьмя RR полномочий и четырьмя RR дополнительной информации. Как мы можем догадаться, четыре RR полномочий это имена DNS серверов для ftp.ee.lbl.gov, а другие четыре RR содержат IP адреса этих четырех серверов.

Строка 3 - это запрос на сервер ns1.lbl.gov (первый из четырех DNS серверов, полученных в строке 2). Флаг "рекурсия необходима" установлен.

Отклик в строке 4 отличается от предыдущих откликов. Возвращено два RR ответа, и tcpdump сообщает, что первый - это RR CNAME. Каноническое имя для ftp.ee.lbl.gov - это ee.lbl.gov.

Это общепринятое использование записи CNAME. FTP узел для LBL всегда имеет имя, начинающееся с ftp, однако время от времени он может перемещаться с одного хоста на другой. Пользователям достаточно знать только имя ftp.ee.lbl.gov, а DNS сама установит соответствие с тем или иным хостом.

Вспомните, что когда мы запускали host, он печатал и CNAME и IP адрес, соответствующий каноническому имени. Это потому, что отклик (строка 4 на рисунке 14.15) содержит два RR ответа. Первый это CNAME, второй это запись A. Если запись A не была возвращена вместе с CNAME, наш сервер пошлет еще один запрос, спрашивая IP адрес ee.lbl.gov. Это еще одна оптимизация реализации: CNAME и запись A канонического имени возвращается в одном отклике.

Вывод tcpdump для: host ftp.uu.net.

Рисунок 14.14 Вывод tcpdump для: host ftp.uu.net.

Появилась новая опция программы tcpdump. Мы получаем все данные, направляющиеся к или от UDP или TCP портов 53, с помощью опции -w. В этом случае весь символьный вывод сохраняется в файле для дальнейшей обработки. При этом tcpdump не пытается вызвать свой собственный разборщик, чтобы напечатать все имена, соответствующие IP адресам. После того как запущены все запросы, мы перезапустили tcpdump с опцией -r. В этом случае программа читает выходной файл и генерирует обычный вывод (который показан на рисунке 14.14). Это занимает несколько секунд, так как tcpdump вызывает свой разборщик.

Первое на что необходимо обратить внимание в выводе tcpdump, это то, что идентификаторы представляют собой небольшие целые числа (2 и 3). Это потому, что мы выключили сервер DNS и затем перестартовали его, чтобы очистить кэш. Когда сервер DNS стартует, он устанавливает идентификатор в 1.

Затем мы ввели запрос, в котором требуется получить IP адрес для хоста ftp.uu.net, DNS сервер установил соединение с одним из восьми корневых серверов, ns.nic.ddn.mil (строка 1). Это обычный запрос типа A, который мы уже видели ранее, однако обратите внимание, что флаг требования рекурсии не установлен. (Если флаг установлен, после идентификатора 2 должен быть напечатан знак плюс.) В наших предыдущих примерах говорилось, что разборщик устанавливает флаг необходимости рекурсии, однако здесь мы видим, что наш сервер DNS не установил флаг, когда он обратился к одному из корневых серверов. Это произошло потому, что от корневых серверов нельзя требовать рекурсивных ответов - они должны быть использованы только для того, чтобы найти адреса к другим полномочным серверам.

Из строки 2 видно, что отклик пришел назад без записи ресурса (RR) ответа, с пятью RR полномочий и пятью RR дополнительной информации. Знак минус, следующий за идентификатором 2, означает, что флаг "рекурсия возможна" (RA) не установлен - этот корневой сервер не ответит на рекурсивный запрос, даже если мы его об этом попросим.

Несмотря на то, что tcpdump не напечатал 10 записей ресурсов, которые были возвращены, мы можем исполнить команду host, чтобы посмотреть, что находится в кэше:

sun % host -v ftp.uu.net
Query about ftp.uu.net for record types A
Trying ftp.uu.net ...
Query done, 1 answer, status: no error
The following answer is not authoritative:
ftp.uu.net 19109 IN A 192.48.96.9
Authoritative nameservers:
UU.NET 170308 IN NS NS.UU.NET
UU.NET 170308 IN NS UUNET.UU.NET
UU.NET 170308 IN NS UUCP-GW-1.PA.DEC.COM
UU.NET 170308 IN NS UUCP-GW-2.PA.DEC.COM
UU.NET 170308 IN NS NS.EU.NET
Additional information:
NS.UU.NET 170347 IN A 137.39.1.3
UUNET.UU.NET 170347 IN A 192.48.96.2
UUCP-GW-1.PA.DEC.COM 170347 IN A 16.1.0.18
UUCP-GW-2.PA.DEC.COM 170347 IN A 16.1.0.19
NS.EU.NET 170347 IN A 192.16.202.11

В этот раз мы указали опцию -v, чтобы увидеть не только записи A. Вывод показывает, что в домене uu.net присутствует пять полномочных DNS серверов. Пять RR с дополнительной информацией, которые были возвращены корневым серверам, содержат IP адреса этих пяти DNS серверов. Поэтому у нас нет необходимости снова устанавливать контакт с корневым сервером, чтобы найти адрес одного из этих серверов. Это еще одно из расширений реализации, сделанное в DNS.

Команда host определяет, что ответ не авторитетный. Это произошло из-за того, что ответ был получен из кэша нашего DNS сервера, а не в результате контакта с полномочным сервером.

Вернемся к строке 3 на рисунке 14.14; сервер DNS установил контакт с первым полномочным сервером (ns.uu.net) с тем же самым вопросом: какой IP адрес ftp.uu.net? На этот раз наш сервер установил флаг "рекурсия необходима". Ответ, возвращенный в строке 4 - это отклик с одним ответом RR.

Затем мы снова исполнили команду host, спрашивая о том же самом имени:

sun % host ftp.uu.net
ftp.uu.net A 192.48.96.9

Это как раз то, что мы и ожидали, потому что ответ на команду host был получен из кэша сервера.

Мы исполнили команду host снова в поисках адреса для ftp.ee.lbl.gov:

sun % host ftp.ee.lbl.gov
ftp.ee.lbl.gov CNAME ee.lbl.gov
ee.lbl.gov A 128.3.112.20

На рисунке 14.15 показан вывод команды tcpdump.

1 18.664971 (17.6555) sun.tuc.noao.edu.domain > c.nyser.net.domain:
4 A? ftp.ee.lbl.gov. (32)
2 19.429412 ( 0.7644) c.nyser.net.domain > sun.tuc.noao.edu.domain:
4 0/4/4 (188)

3 19.432271 ( 0.0029) sun.tuc.noao.edu.domain > ns1.lbl.gov.domain:
5+ A? ftp.ee.lbl.gov. (32)
4 19.909242 ( 0.4770) ns1.lbl.gov.domain > sun.tuc.noao.edu.domain:
5* 2/0/0 CNAME ee.lbl.gov. (72)

Вывод tcpdump для запроса указателя.

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

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

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

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

Вызов функции разборщика, которая

Рисунок 14.13 Вызов функции разборщика, которая осуществляет запрос указателя.

В строке 1 запрос указателя, в строке 2 отклик. Однако, функция разборщика автоматически посылает запрос об IP адресе в строке 3 на имя, возвращенное в строке 2. Отклик в строке 4 содержит две записи ответа, так как хост sun имеет два IP адреса. Если ни один из адресов не совпал с аргументом gethostbyaddr, отправляется сообщение системе, которая фиксирует событие, а функция возвращает ошибку приложению.

Записи ресурсов

Мы видели несколько различных типов записей ресурса (RR), а именно: IP адрес имеет тип A, а PTR обозначает запрос указателя. Также мы видели RR, которые возвращает DNS сервер: RR ответа, RR полномочий и RR дополнительной информации. Всего существует около 20 различных типов записей ресурсов, некоторые из которых мы сейчас опишем.

Запись А определяет IP адрес. Хранится как 32-битное двоичное значение.

PTR

Запись указателя используется для запросов указателя. IP адрес представляется в виде имени домена (последовательность меток) в домене in-addr.arpa.

CNAME

"Каноническое имя" (canonical name). Представляется как имя домена (последовательность меток). Имя домена, которое имеет каноническое имя, часто называется псевдонимом (alias). Они используются некоторыми FTP узлами, для того чтобы предоставить легкозапоминаемый псевдоним для какой-либо системы.

Например, сервер gated (мы упоминали о нем в разделе "Демоны маршрутизации в Unix" главы 10) доступен через анонимное FTP с сервера gated.cornell.edu. Однако, не существует системы, названной gated, это псевдоним для какой-то другой системы. Эта другая система является каноническим именем для gated.cornell.edu:

sun % host -t cname gated.cornell.edu
gated.cornell.edu CNAME COMET.CIT.CORNELL.EDU

Здесь мы использовали опцию -t, чтобы указать на один конкретный тип запроса.

HINFO

Информация о хосте: две символьные строки, указывающие на центральный процессор (CPU) и операционную систему. Не все хосты предоставляют записи HINFO для своих систем, и предоставляемая информация может быть устаревшей.

sun % host -t hinfo sun
sun.tuc.noao.edu HINFO Sun-4/25 Sun4.1.3

Записи, посвященные обмену почтой, которые используются по следующему сценарию: (1) узел, который не подсоединен к Internet, может использовать узел, который подсоединен к Internet, в качестве своего почтового сервера. Два узла работают попеременно, обмениваясь любой прибывшей почтой, в основном с использованием протокола UUCP. (2) запись MX предоставляет возможность доставить почту на альтернативный хост, когда хост назначения недоступен. (3) записи MX позволяют организациям предоставлять виртуальные хосты, на которые можно отправлять почту, как, например, cs.university.edu, даже если хост с таким именем не существует. (4) Организации со шлюзами firewall могут использовать записи MX, чтобы ограничить доступ к внутренним системам.

Многие хосты, которые не подключены к Internet, имеют UUCP каналы к хостам, подключеным к Internet, как, например, UUNET. С помощью записи MX обеспечивается передача электронной почты с использованием стандартного обращения user@host (пользователь@хост). Например, фиктивный домен foo.com может иметь следующую MX запись:

sun % host -t mx foo.com
foo.com MX relay1.UU.NET
foo.com MX relay2.UU.NET

MX записи используются программами доставки почты на хостах, подключенных к Internet. В этом примере программа доставки почты говорит "если у тебя есть почта, которую необходимо послать на user@foo.com, пошли почту на relay1.uu.net или на relay2.uu.net".

В каждой записи MX есть 16-битное целое значение, которое называется значением предпочтительности. Если для одного пункта назначения существует несколько MX записей, они будут использованы по порядку, начиная с той записи, у которой наименьшее значение предпочтительности.

Записи MX используются, когда хост выключен или недоступен. В этом случае программа доставки почты использует MX записи только в том случае, если не может подсоединиться к пункту назначения с использованием TCP. Для объединенных сетей, с которыми экспериментировал автор, его основная система подключена к Internet через SLIP канал, и если она не работает, мы получим:

sun % host -tv mx sun
Query about sun for record types MX
Trying sun within tuc.noao.edu ...
Query done, 2 answers,authoritative status: no error
sun.tuc.noao.edu 86400 IN MX 0 sun.tuc.noao.edu
sun.tuc.noao.edu 86400 IN MX 10 noao.edu

Опцию -v позволяет посмотреть значения предпочтительности. (Благодаря этой опции в выводе появятся и все другие поля.) Второе поле, 86400, - это время жизни в секундах. Время жизни равно 24 часам (24х60х60). Третья колонка, IN, это класс (Internet). Мы видим, что непосредственная доставка на хост (первая запись MX) имеет наименьшее значение предпочтительности равное 0. Если это не работает (SLIP канал выключен), используется следующее более высокое значение предпочтительности (10), и делается попытка доставить почту на хост noao.edu. Если и это не сработает, отправитель отработает тайм-аут и повторит попытки позже.

В разделе "Примеры SMTP" главы 28 мы покажем примеры доставки почты SMTP с использованием записей MX.

Запись имени сервера. Указывает на полномочные DNS серверы для домена. Представлена в виде имен доменов (последовательность меток). Мы рассмотрим примеры этих записей в следующем разделе.

Это общие типы RR. В следующих примерах мы увидим еще некоторые типы.

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

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

Во-первых, вернемся к рисунку 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.

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

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

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

Значения type и query type для DNS вопросов и ответов.

Рисунок 14.7 Значения type и query type для DNS вопросов и ответов.

Наиболее распространенный тип запроса - тип A, который обозначает, что необходим IP адрес для запрашиваемого имени (query name). PTR запрос требует имена, соответствующие IP адресу. Это запрос указателя, который мы опишем в разделе "Запросы указателя" этой главы. Другие типы запросов мы опишем в разделе "Записи ресурсов" этой главы.

Класс запроса (query class) обычно равен 1, что указывает на адреса Internet. (В некоторых случаях поддерживаются не-IP значения.)