Доменная система имен (Domain Name System, DNS) является технологией, обеспечивающей присвоение имен доменов IP-адресам. Каждый узел в интернете имеет адрес доменного имени (http://www.microsoft.com) и IP-адрес (192.17.3.4).

В данной лекции мы расскажем о функционировании TCP/IP и DNS, об их взаимосвязи с компонентом IIS. Но наш рассказ не будет полным без исторического обзора этого семейства протоколов.

История TCP/IP и интернет

Большинство людей думают, что TCP/IP – это единый протокол, однако на самом деле этим термином обозначается пакет протоколов коммуникации. Протокол управления передачей (TCP) и межсетевой протокол (IP) являются двумя наиболее значимыми протоколами, однако они представляют лишь небольшую часть семейства протоколов TCP/IP. В состав TCP/IP входят протокол передачи пользовательских дейтаграмм (User Datagram Protocol, UDP) и протокол межсетевых управляющих сообщений (Internet Control Message Protocol, ICMP).

Сеть ARPANET

В 1968 г. Управление перспективного планирования научно-исследовательских работ (ARPA) Министерства обороны США (позже это ведомство было переименовано в Управление перспективного планирования научно-исследовательских работ в области обороны – DARPA) начало исследование сетевой технологии, известной сегодня как коммутация пакетов. Тогда и было положено начало протоколам TCP/IP. Целью создания TCP/IP было упрощение связи между сообществом Министерства обороны (DoD) без использования публичного канала телефонной линии. Эта сеть была названа ARPANET, и она стала прародителем современной сети интернет. В 1978 г. были формализованы отдельные функции TCP и IP, а в 1983 г. они стали стандартными протоколами ARPANET. В 1989 г. компьютеры ARPANET были подключены к сети NSFnet, являвшейся Сетью национальных научных разработок; она была намного больше и быстрее, чем сеть ARPANET. Это и стало рождением современного интернета. Принимая во внимание историю семейства протоколов TCP/IP, его часто называют семейством пакетом протоколов Министерства обороны США или семейством протоколов интернета.

Архитектурные модели протоколов связи

Для обеспечения среды, в которой протоколы связи могут взаимодействовать друг с другом, используется определенная структура, помогающая объяснять и разрабатывать протоколы. Архитектурная модель задает общую структуру и разделяет функции, выполняемые протоколами связи, на четыре уровня: прикладной, транспортный, межсетевой и уровень сетевого доступа. Каждый из уровней выполняет определенную функцию, для которой может быть создано и задействовано любое количество протоколов.

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

Чаще всего для описания TCP/IP-соединений используются две архитектурные модели: модель протокола DoD и модель протокола взаимодействия открытых систем (Open Systems Interconnection, OSI).

Модель протокола DoD

Первоначально модель протокола DoD (или модель межсетевых связей) содержала три уровня: сетевого доступа, передачи от узла к узлу и приложений. Позже был добавлен четвертый уровень – межсетевой. Эта модель часто используется для описания функционирования стека протоколов TCP/IP (см. рис. 8.1).

Каждый из четырех уровней модели DoD выполняет свои функции.

• Прикладной уровень. Верхний уровень модели, включающий протоколы, обрабатывающие данные пользователей и осуществляющие управление обменом данными между приложениями. На этом уровне стандартизируется представление данных.
• Транспортный уровень. Содержит протоколы для обеспечения целостности данных при сквозной передаче. Обеспечивает управление инициализацией и закрытием соединений.
• Межсетевой уровень. Содержит протоколы для маршрутизации сообщений в сети; служит для размещения данных в дейтаграмме.
• Уровень сетевого доступа. Нижний уровень модели. Содержит протоколы для физической доставки данных к сетевым устройствам. Этот уровень размещает данные в кадре.

Модель протокола OSI

Модель протокола взаимодействия открытых систем (Open Systems Interconnection, OSI) представляет собой семиуровневую модель, разработанную Международной организацией по стандартизации (ISO) и соответствующую уровням модели DoD. Модель OSI изначально создавалась как универсальный стандарт для всех коммуникационных протоколов, однако не стала им. Сегодня протоколы приблизительно соответствуют модели OSI, но точное соответствие и не требуется. Уровни модели OSI показаны на рис. 8.2.

Каждый из семи уровней модели OSI выполняет свои собственные функции.

• Прикладной уровень. Обеспечивает процессы приложений и взаимодействие с конечным пользователем. Все, что находится на этом уровне, является спецификой приложений. Обеспечивает работу служб передачи файлов приложений, работу электронной почты и других программных служб сети.
• Уровень представлений. Устраняет различия в представлении данных. Преобразует данные в формат, совместимый с прикладным уровнем.
• Сеансовый уровень. Данный уровень является независимым от сетевого соединения – наличие соединения подразумевается. Содержит элементы для управления соединениями между приложениями.
• Транспортный уровень. Отвечает за передачу данных между узлами. Обеспечивает обнаружение ошибок и восстановление данных, а также правильную передачу данных. На данном уровне находятся протоколы TCP и UDP.
• Сетевой уровень. Отвечает за адресацию и создание виртуальных каналов для сквозной передачи данных. На данном уровне расположены IP-адреса.
• Канальный уровень. Состоит из двух подуровней: подуровня LLC (логический контроль канала), управляющего синхронизацией кадров и потоком данных, и подуровня MAC (управление доступом к среде передачи данных), отвечающего за адресацию канального уровня.
• Физический уровень. Определяет спецификации физических компонентов сетевого соединения. Здесь располагаются биты, сигналы и спецификации кабелей. Данный уровень непосредственно обеспечивает соединение.

Связь уровней

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

Инкапсуляция

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

Давайте проследим, каким образом данные передаются от одного компьютера к другому. Три верхних уровня обеспечивают представление информации транспортному уровню, на котором начинается непосредственный процесс сетевого соединения; с него-то мы и начнем. На рисунке 8.3 показан путь, по которому данные передаются от одного компьютера к другому.

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

На компьютере 2 биты принимаются по каналу связи на физическом уровне и передаются на канальный уровень. На канальном уровне из информации заголовка кадра считывается MAC-адрес. При его соответствии процесс продолжается, и данные (пакет уровня 3) передаются на сетевой уровень. Если MAC-адрес не совпадает, данные аннулируются. На сетевом уровне считывается IP-адрес, и при его совпадении дейтаграмма передается на транспортный уровень. На транспортном уровне считываются номер порта и протокол для определения получателя данных. Данные передаются на сеансовый уровень для непосредственного представления приложению.

Адресация в TCP/IP

В стеке протоколов TCP/IP важное значение имеют два типа адресов: MAC-адреса и IP-адреса. Об информации транспортного уровня (TCP и UPD) речь пойдет в разделе "Протоколы TCP, UDP и ICMP" далее в лекции.

MAC-адреса

MAC-адреса располагаются на канальном уровне модели OSI. Эти адреса присваиваются Институтом инженеров по электротехнике и электронике (IEEE). Каждое сетевое устройство имеет MAC-адрес, и каждый MAC-адрес является полностью уникальным (теоретически).

MAC-адреса используют 48-битное адресное пространство, что позволяет использовать миллионы MAC-адресов по всей сети интернет. MAC-адреса состоят из двух частей: первые 24 бита являются идентификатором производителя. Каждый производитель имеет свой собственный префикс. Производитель присваивает адреса, называемые идентификаторами станции, использующие оставшиеся 24 бита.

IP-адреса

IP-адреса занимают седьмой уровень модели OSI. Эти адреса присваивает Агентство по выделению имен и уникальных параметров протоколов интернета (IANA), которое распределило свои функции между несколькими различными ведомствами.

IP является маршрутизируемым протоколом, поэтому IP-адреса состоят из двух частей.

• Идентификатор сети. Первая часть IP-адреса, идентифицирующая адрес устройств сети, являющихся частью единой группы устройств.
• Идентификатор узла. Вторая часть IP-адреса, определяющая отдельное устройство в сети.

Версии протокола IP

В настоящее время используются две версии протокола IP: версия 4 и версия 6. IPv4 представляет собой стандарт, созданный в конце 70-х годов. IPv6 является новым стандартом.

IPv4

При настройке соединения с помощью IPv4 используются IP-адрес, маска подсети и шлюз по умолчанию.

IP-адрес

IPv4 состоит из 32-битных адресов, представляющих собой разделенные точками 8-битные блоки, например: 192.168.0.1. Протокол IPv4 имеет ряд недостатков, поскольку обеспечиваемое им адресное пространство недостаточно велико и не соответствует спросу на адреса. Частично причиной этому является неэффективное назначение адресов. Многие используют частные адреса и прокси-серверы для ограничения общих адресов. Число компьютеров, подключенных к интернету, постоянно растет, поэтому в определенный момент времени ресурсы адресного пространства IPv4 будут исчерпаны. Для решения этой проблемы разработан протокол IPv6, обеспечивающий большее адресное пространство.

Маска подсети

Маска подсети определяет, какие части IP-адресов идентифицируют сеть, а какие – узлы. Маска подсети представляет собой разделенный точками адрес, состоящий из четырех частей (октетов) и "маскирующий" часть IP-адреса для определения того, в каком месте находится граница части идентификатора сети и идентификатора хоста. Маска подсети обычно выглядит так: 255.255.255.0. Первые три октета представляют номер сети, а последний октет является номером узла. Применительно к IP-адресу в нашем примере верно следующее:

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

• IP-адрес 192.168.0.1 в двоичном виде выглядит следующим образом: 11000000.10101000.00000000.00000001
• Маска подсети 255.255.255.0 в двоичном виде выглядит следующим образом: 11111111.11111111.11111111.00000000

Маску подсети также обозначают /24, поскольку она содержит 24 бита (единицы). Запись 192.168.0.0 /24 означает, что маска относится к блоку адресов с 192.168.0.0 по 192.168.0.255, а сама маска подсети имеет вид 255.255.255.0. В данном случае можно применить более точную маску подсети, поскольку для всех устройств одной и той же сети она должна быть одинакова. Здесь работает правило: "Другая маска подсети – другая сеть".

Шлюз по умолчанию

Подключение ко всем устройствам с одним и тем же сетевым номером реализовать довольно просто: нужно лишь отправить пакет, и он попадет именно туда, куда нужно. Связь в подсетях реализуется несколько сложнее, и здесь появляется понятие стандартного шлюза. Стандартным шлюзом является IP-адрес устройства, находящегося в той же подсети. Это устройство поддерживает несколько сетевых соединений и может "маршрутизировать" пакеты из одной подсети в другую, так как ему известны параметры различных соединений.

IPv6

Протокол IPv6 имеет 128-битное адресное пространство. Это достаточный размер для того, чтобы каждый квадратный метр земной поверхности имел свой собственный IP-адрес. Протокол IPv6 должен пройти долгий путь, прежде чем завоевать всеобщее признание, поскольку IPv4 глубоко интегрирован с каждым элементом сетевой структуры. Поддержка IPv6 в Windows Server 2003 (WS03) ограничена.

Адреса IPv6 представляют собой восемь блоков 16-разрядных адресов (например, FEAD:D8F1:FFA0:FAB7:1234:5678:9012:FF1A). Вы видите, что этот адрес гораздо больше адреса IPv4, и его использование повышает значение системы DNS, осуществляющей присвоение IP-адресов именам доменов. Достаточно трудно запоминать 4-октетные IP-адреса, запомнить же 16-битный шестнадцатеричный адрес практически невозможно.

IPv6 можно настраивать автоматически или вручную. Автоматически настраиваются следующие параметры.

• Неадаптивная. Неадаптивная настройка осуществляется через анонсы маршрутизатора. Этот процесс отличается от работы DHCPv6. Анонсы маршрутизатора содержат данные, необходимые клиенту для задания IP-адреса и стандартного шлюза. Это единственный тип автоматической конфигурации, поддерживаемый WS03.
• Адаптивная. Адаптивная настройка использует конфигурационный протокол, такой как DHCPv6, для получения информации, необходимой для настройки интерфейса.
• Обе. Данная опция использует как протокол конфигурации, так и анонсы маршрутизатора для настройки интерфейса.

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

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

Протоколы TCP, UDP и ICMP

Протоколы TCP, UDP и ICMP располагаются на транспортном уровне. TCP разбивает сообщения на дейтаграммы и доставляет их получателям. Он передает подтверждения приема между устройствами для отслеживания того, какие дейтаграммы были приняты. Если дейтаграмма не достигает пункта назначения, она отправляется повторно. TCP выполняет сборку дейтаграммы в правильном порядке, используя номер последовательности в заголовке дейтаграммы TCP.

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

ICMP используется для вывода сообщений об ошибках и решения проблем, возникающих в коммуникационной среде. Например, при попытке подключения к узлу система может вернуть ICMP-сообщение "Узел недоступен". ICMP не имеет номеров портов, поскольку сетевое программное обеспечение само интерпретирует ICMP-сообщения. Протокол ICMP используется двумя распространенными утилитами – ping и tracert.

Использование TCP/IP

Теперь попробуем выяснить, каким образом функционируют протоколы TCP/IP в WS03, и как работает IP-адресация в отношении сайтов IIS.

IPv4 установлен в операционной системе WS03 по умолчанию, поэтому все, что нужно сделать, – настроить соединение. По умолчанию для настройки сетевых подключений используется DHCP. DHCP автоматически настраивает IP-адреса, причем выполняет это на сервере DHCP, а не на каждом отдельном компьютере. В данной книге мы используем IP-адреса, настроенные вручную.

Выбор IP-адреса

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

Настройка IPv4

Настройка IPv4 осуществляется с помощью Network Connections (Сетевые подключения) в Панели управления.

1. Выберите Start\Control Panel (Пуск\Панель управления).
2. Дважды щелкните на значке Network Connections (Сетевые подключения) в Панели управления. Откроется окно Network Connections (см. рис. 8.4).

Вы можете настроить также и параметры TCP/IP; с помощью дополнительных параметров реализуется расширенная настройка опций. Выполните следующие действия.

1. В окне Network Connections (Сетевые подключения) дважды щелкните на сетевом подключении, которое необходимо настроить. Появится окно Status (Состояние).
2. Нажмите на кнопку Properties (Свойства).
3. Во вкладке General (Общие) окна свойств выберите в списке Internet Protocol (TCP/IP) (Межсетевой протокол [TCP/IP]), затем нажмите на кнопку Properties.
4. В окне Internet Protocol (TCP/IP) Properties (Свойства межсетевого протокола [TCP/IP]) нажмите на кнопку Advanced (Дополнительно). Отобразится окно Advanced TCP/IP Settings (Дополнительные параметры TCP/IP).

В этом окне во вкладке IP Settings (Настройка IP) настраиваются параметры.

Вкладка IP Settings (Настройка IP)

В данной вкладке (см. рис. 8.5) указываются IP-адреса для использования и стандартный шлюз. В области IP Addresses (IP-адреса) укажите один или несколько IP-адресов.

Для применения нескольких IP-адресов имеется несколько причин, например, необходимость поддержки нескольких сайтов на сервере IIS, причем с собственным IP-адресом для каждого сайта. Для веб-сайтов можно использовать заголовки узлов (см. лекции 2), а для FTP-сайтов – нельзя, поэтому наличие нескольких FTP-сайтов требует нескольких IP-адресов.

Добавление IP-адресов к сетевому подключению

На вкладке IP Settings (Настройка IP) нажмите на кнопку Add (Добавить) и укажите IP-адрес и маску подсети. Повторите это действие для каждого IP-адреса, который необходимо настроить. Здесь можно указывать любые IP-адреса, даже присутствующие в других сетях. Так как OSI является модульной, на одном физическом уровне может существовать несколько различных сетей.

Изменение и удаление IP-адресов для сетевого подключения

Для изменения выделите нужный IP-адрес и нажмите на кнопку Edit (Изменить). Для удаления выделите нужный IP-адрес и нажмите на кнопку Remove (Удалить).

Присвоение шлюза сетевому подключению

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

Изменение и удаление шлюза для данного сетевого подключения

Значение Interface Metric (Метрика интерфейса) представляет собой число, присвоенное данному интерфейсу. Метрика позволяет Windows выбирать сетевое подключение на данном компьютере, через которое будут отправляться данные. Значение метрики можно сравнить с ценой. Чем больше число, тем дороже (в отношении затраченного времени) данное подключение. Опция Automatic metric (Автоматическая метрика) позволяет Windows вычислить метрику для данного интерфейса, основываясь на скорости подключения.

Различием между метриками в окне Advanced TCP/IP Settings (Дополнительные параметры TCP/IP) и в окне TCP/IP Gateway Address (Адрес шлюза TCP/IP) является то, что первая предназначается сетевому подключению на данном компьютере, а вторая – компьютеру, используемому для отправки информации с данного компьютера.

Рассмотрим сетевое подключение по отношению к сетевой карте. Каждая сетевая карта имеет собственное подключение. Метрика шлюза в окне TCP/IP Gateway Address (Адрес шлюза TCP/IP) предназначена для всех сетевых карт компьютера.

Вкладка DNS Configuration (Настройка DNS)

DNS представляет собой технологию, с помощью которой IP-адресам присваиваются имена доменов. Более подробно о системе DNS будет рассказана в разделе "DNS и Windows Server 2003" далее в лекции. Сейчас мы рассмотрим лишь параметры конфигурации во вкладке DNS Configuration (Настройка DNS) (см.рис. 8.6).

Присвоение адресов DNS-сервера сетевому подключению

Нажмите на кнопку Add (Добавить) и введите адрес DNS. Повторите эту процедуру для каждого добавляемого адреса. Вы можете указать несколько адресов DNS и IP (а на вкладке General – только два).

Изменение и удаление адресов DNS-сервера для сетевого подключения

Для изменения выделите нужный адрес DNS-сервера и нажмите на кнопку Edit (Изменить). Для удаления выделите нужный адрес DNS-сервера и нажмите на кнопку Remove (Удалить).

Добавление суффиксов DNS для присвоения имен

Доменная система имен (DNS) обрабатывает полные имена доменов, например, myserver.mydomain.com. Обработки части myserver не увенчается успехом. Для предотвращения проблем такого рода указывается набор суффиксов DNS, присоединяющихся к запросам на присвоение имен. Это позволяет Windows использовать DNS для обработки таких запросов на присвоение имен, которые обычно обработать невозможно. Можно указать главный, родительский и специфичный для подключения адреса, либо указать список конкретных суффиксов.

Append Primary and Connection-Specific DNS Suffixes (Добавлять основной DNS-суффикс и суффикс подключения). Позволяет Windows использовать главный DNS-суффикс и DNS-суффикс, указанный для рассматриваемого подключения (указано ниже в этом же окне), для обработки имен IP-адресов.

Append Parent Suffixes of the Primary DNS Suffix (Добавлять родительские суффиксы основного DNS-суффикса). Позволяет Windows использовать родительские DNS-суффиксы для обработки имен IP-адресов. Например, если главным DNS-суффиксом является redmond.microsoft.com, то microsoft.com также используется для присвоения DNS.

DNS Suffix for this Connection (DNS-суффикс данного подключения). Указывается DNS-суффикс, используемый для конкретного сетевого подключения. Этот параметр игнорирует DNS-суффикс, предоставляемый DHCP-сервером.

Append These DNS Suffixes (in Order) (Добавлять следующие DNS-суффиксы [по порядку]). Указывается перечень суффиксов DNS, используемый для присвоения. Этот список обрабатывается сверху вниз, поэтому имя, отображаемое в нескольких доменах DNS, будет обработано и преобразовано в первую очередь.

Зарегистрировать адреса данного подключения в DNS

При выборе опции Register this Connection’s Addresses in DNS (Зарегистрировать адреса данного подключения в DNS) система будет регистрировать полное имя домена на DNS-сервере. Если DNS-сервер не поддерживает динамическое обновление, то система попытается обновить запись на сервере DNS, но эта операция не увенчается успехом.

Использовать DNS-суффикс подключения при регистрации в DNS

В опции Use this Connection’s DNS Suffix in DNS Registration (Использовать DNS-суффикс подключения при регистрации в DNS) указывается необходимость использования DNS-суффикса подключения при динамической регистрации данного компьютера. Этот параметр дополняет динамическую регистрацию главного суффикса DNS.

Вкладка WINS Configuration (Настройка WINS)

Windows Internet Name Service (WINS) (Служба имен интернета Windows) представляет собой технологию преобразования имен в IP-адреса. Служба WINS обрабатывает имена NetBIOS вместо полных имен домена. Так как WINS и NetBIOS не используются в IIS, мы не будем рассказывать о них подробно. Рассматриваемая вкладка показана на рис. 8.7.

Адреса WINS в порядке использования

Серверы WINS, назначенные для использования данным компьютером, приводятся в списке данной вкладки. В этом списке можно добавлять адреса серверов WINS, располагая их в том порядке, в котором они будут использоваться Windows для преобразования имен NetBIOS.

Добавление, изменение и удаление адресов серверов WINS для данного сетевого подключения

Для добавления адреса нажмите на кнопку Add (Добавить) и введите адрес сервера WINS. Повторите эту процедуру для каждого добавляемого адреса.

Для изменения выделите нужный адрес сервера WINS и нажмите на кнопку Edit (Изменить).

Для удаления выделите нужный адрес сервера WINS и нажмите на кнопку Delete (Удалить).

Опция Enable LMHOSTS Lookup (Включить просмотр LMHOSTS)

Опция позволяет указать, что в процессе преобразования имен следует использовать файл LMHOSTS. Файл LMHOSTS представляет собой текстовый файл, содержащий связи имен с IP-адресами, аналогично системе WINS. Файл LMHOSTS является статическим, в то время как служба WINS – динамическая.

NetBIOS Setting (Параметры NetBIOS)

Эта группа опций указывает на необходимость использования NetBIOS в сетевых подключениях. Поскольку NetBIOS располагается на сеансовом уровне модели OSI, то находится выше TCP/IP. Он является необязательным для работы IIS, если для преобразования имен используется система DNS. В большинстве случаев вы будете работать со службой DNS.

Default (По умолчанию). Опция включает соединение NetBIOS, если параметры сервера DHCP не противоречат этому.

Enable NetBIOS over TCP/IP (Включить NetBIOS через TCP/IP). Опция включает соединение NetBIOS, даже если параметры DHCP-сервера этому противоречат.

Disable NetBIOS over TCP/IP (Отключить NetBIOS через TCP/IP). Опция отключает соединение NetBIOS, даже если параметра DHCP-сервера этому противоречат.

Вкладка Options (Параметры)

Во вкладке Options (Параметры) настраиваются параметры фильтрации TCP/IP. Фильтрация TCP/IP разрешает использование только определенных портов и позволяет отключить те порты, которые, по мнению администратора, не должны быть открыты. Этот процесс выполняется на транспортном уровне модели OSI. При включении фильтрации портов ее действие будет распространяться на каждый сетевой адаптер системы. Поскольку фильтрация портов не позволяет селективно отключать порты, рекомендуется использовать межсетевой экран, если на первом месте стоят вопросы безопасности. Для настройки фильтрации TCP/IP нажмите на кнопку Properties (Свойства) во вкладке Options (Параметры). Откроется окно TCP/IP filtering (Фильтрация TCP/IP) (см. рис. 8.8). Здесь располагаются следующие опции.

Порты TCP – Permit All (Разрешить все) или Permit Only (Разрешить только)

При выборе опции Permit Only (Разрешить только) Вам так же необходимо указать порты, которые Вы хотите разрешить, если не разрешить ни одного порта, будут запрещены все порты. Нажмите на кнопку Add (Добавить) и введите номер порта, который нужно включить. Нажмите на кнопку Remove (Удалить) для удаления порта из списка.

Порты UDP - Permit All (Разрешить все) или Permit Only (Разрешить только)

При выборе опции Permit Only (Разрешить только) Вам так же необходимо указать порты UDP, которые Вы хотите разрешить, если не разрешить ни одного порта, будут запрещены все порты. Нажмите на кнопку Add (Добавить) и введите номер порта, который нужно включить. Нажмите на кнопку Remove (Удалить) для удаления порта из списка.

Протоколы IP - Permit All (Разрешить все) или Permit Only (Разрешить только)

При выборе опции Permit Only (Разрешить только) укажите те протоколы IP, которые нужно отключить. Нажмите на кнопку Add (Добавить) и введите номер протокола, который следует включить. Каждый протокол в TCP/IP имеет числовой идентификатор. Нажмите на кнопку Remove (Удалить) для удаления протокола из списка.

Настройка IPv6

Хотя в операционной системе WS03 по умолчанию установлен протокол IPv4, она также поддерживает IPv6. Разумеется, для работы с IPv6 его необходимо установить.

Установка IPv6

IPv6 устанавливается и настраивается посредством утилиты командной строки netsh. Для установки IPv6 выполните следующие действия.

1. В командной строке введите команду NETSH.
2. Введите INTERACTIVE IPV6.
3. Введите INSTALL.
4. Система включит IPv6, и в окне командной строки отобразится результат – "OK".

После ввода команды IPCONFIG/ALL вы увидите, что наряду с имеющимся адресом IPv4 теперь присутствует адрес IPv6. Если посмотреть повнимательней, то IP-адрес напоминает видоизмененный MAC-адрес. Все MAC-адреса являются уникальными, поэтому они прекрасно подходят для добавления к IP-адресам с целью обеспечения уникальности.

Использование интерфейса NETSH

В интерфейсе NETSH устанавливаются параметры маршрутов, туннелирования и конфигурации. В интерфейсе NETSH после ввода команды help или ? вы получите справку по настройке интерфейса IPv6. Так как поддержка IPv6 в IIS 6 ограничена, мы не будем останавливаться на этом подробно. По мере распространения для протокола IPv6 будет обеспечена более основательная поддержка приложений. Если вы решили использовать IPv6 на сервере, имейте в виду, что IIS Manager (Диспетчер IIS) не отображает адреса IPv6. Кроме того, на сайтах вы сможете использовать только имена Host Header (Заголовки узлов) (для получения более подробной информации о заголовках узлов см. лекцию 2).

Изменение главного суффикса DNS

Главным суффиксом DNS является домен DNS, членом которого объявляет себя компьютер. Этот параметр должен совпадать с доменом DNS, в котором находится запись Address (A) рассматриваемого сервера. Для изменения главного суффикса DNS выполните следующие действия.

1. Выполните команду Start\Control Panel\System (Пуск\Панель управления\Система).
2. Откройте вкладку Computer Name (Имя компьютера).
3. Нажмите на кнопку Change (Изменить).
4. Нажмите на кнопку More (Больше).
5. Введите к текстовом поле главный суффикс DNS (см. рис. 8.9), затем нажмите на кнопку OK.

Теперь более подробно рассмотрим работу DNS.

DNS и Windows Server 2003

В интернете DNS является главным способом преобразования имен, поэтому необходимо серьезно отнестись к ее установке и настройке. Существует несколько программ DNS, включая DNS-сервер, встроенный в WS03.

История DNS

Система DNS была разработана DARPA в начале 1980-х годов для решения проблем, связанных с преобразованием имен в сети ARPANET. С помощью DNS компьютеры используют номера для идентификации устройств, как люди используют имена и фамилии для своей идентификации.

Вначале каждый узел сети ARPANET имел уникальное имя и уникальный номер. Организация InterNIC (Internet Information Center) осуществляла сбор и распространение данной информации в виде файла узлов, в котором хранились связи имен с IP-адресами. Этот файл подлежал автоматическому обновлению, и каждый пользователь мог загрузить его к себе на компьютер. Если пользователю требовалась связь с другим компьютером, то его компьютер осуществлял преобразование имен с использованием файла узлов.

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

Когда DARPA стандартизировало TCP/IP как протокол сети ARPANET, эта организация решила также усовершенствовать систему преобразования имен и остановилась на DNS, так как DNS является центральной базой данных, содержащей указатели на децентрализованные базы данных, включающие записи для каждого пространства имен. DARPA использовали доменную систему имен Беркли (Berkeley Internet Name Domain, BIND) в качестве программного обеспечения DNS.

Краткий обзор DNS и TLD

DNS – это иерархическая система преобразования имен, состоящая из нескольких уровней обработки имен. Первый уровень называется Top Level Domain (TLD) и является самой правой частью адреса DNS. Адреса DNS читаются по секциям, справа налево. Например, http://www.microsoft.com представляет собой TLD, а microsoft – имя домена второго уровня. Самая левая часть (www) представляет собой имя записи, а не имя домена. Имена доменов могут иметь в глубину множество уровней. Например, адрес www.on.thursday.i.will.eat.pizza.com – вполне реальное имя домена. В этом примере необходимо обработать семь уровней доменов для перехода к искомой записи.

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

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

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

Представьте себе огромную базу данных, содержащую все TLD и направляющую трафик на соответствующие серверы DNS для каждого TLD. Такая база является основой, на которой держится весь интернет. Она располагается на объекте, который называется корневым сервером имен. Корневые серверы имен располагаются в домене root-servers.net. Их можно просмотреть, используя поиск по команде whois. Все серверы DNS обращаются к корневым серверам имен, чтобы начать обработку имени. Корневым серверам имен известны все TLD, и они направляют их на сервер DNS, содержащий записи для определенного имени домена.

Как работают TLD

Реестр всех имен доменов в интернет берет свое начало из IANA, т.е. группы, назначающей IP-адреса. IANA содержит реестр с информацией о компаниях, назначающих имена доменов второго уровня в доменах верхнего уровня. В настоящее время используется множество доменов верхнего уровня, и некоторые компании содержат информацию об этих доменах. Кроме этого, каждой стране соответствует свой двухсимвольный код TLD, определенный кодом ISO для каждого государства. Например, TLD США является .us, а TLD Великобритании - .uk.

Исходный перечень TLD

Изначально для использования было установлено восемь TLD, приведенных ниже; последние два TLD в списке являются особыми TLD, предназначенными для специальных целей и недоступными для организаций.

• .com Коммерческие организации.
• .gov Для использования правительством США.
• .net Для сетевых провайдеров.
• .edu Для учебных заведений.
• .mil Армия США.
• .org Некоммерческие организации.
• .int Для организаций, созданных в результате международных переговоров.
• .arpa Для обратной информации DNS.

Недавно внедренные TLD

В ноябре 2000 г. ICANN приняла семь новых TLD. В таблице 8.1 приведены используемые сегодня TLD, а также организации, ответственные за управление и регистрацию доменов в каждом пространстве имен.

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

Получение своего собственного имени домена

Получить свое собственное имя домена легко; все, что нужно сделать, – заплатить регистрационный взнос и заполнить соответствующие формы. При регистрации выполнится небольшая проверка, если вы не регистрируетесь в домене ограниченного использования, таком как .museum. Каждый регистратор имеет свои собственные политики, руководящие использованием и оплатой имен доменов. Регистраторы функционируют независимо друг от друга, поэтому при регистрации одного и того же имени в других TLD это выполняется в различных организациях.

Обработка имен DNS

DNS-сервер обрабатывает запросы либо рекурсивно, либо итеративно.

Рекурсивный запрос происходит при обработке DNS-сервером имени, даже если сервер не имеет соответствующую информацию. Сервер будет запрашивать корневые серверы до тех пор, пока не получит информацию. DNS-сервер в WS03 по умолчанию настроен на рекурсивные запросы.

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

Рассмотрим процесс преобразования имени в IP-адрес с помощью рекурсивного запроса.

1. Клиент выполняет некоторую операцию, например, щелчок на веб-ссылке, требующую преобразования имени DNS.
2. Компьютер клиента проверяет кэш DNS и файлы узлов на компьютере на наличие адреса. Предположим, адрес в указанных местах отсутствует.
3. Компьютер клиента отправляет DNS-запрос первому DNS-серверу, приведенному в конфигурации TCP/IP.
4. DNS-сервер проверяет наличие в своем кэше искомого имени.
5. Если в кэше сервера присутствует искомый адрес, клиенту отображается соответствующая информация.
6. Если адрес отсутствует, сервер просматривает все домены, для которых имеются DNS, и отправляет запрос одному из корневых серверов DNS.
7. Корневой DNS-сервер просматривает свои записи для данного домена (домен второго уровня) и отправляет запись обратно на DNS-сервер клиента с именем сервера, обеспечивающего работу этого домена.
8. Если запись адреса находится в этом домене, DNS-сервер клиента отправляет свой запрос в конечный DNS-сервер для выяснения адреса.
9. В противном случае, при наличии большего количества уровней доменов, DNS-сервер клиента продолжает запрашивать сервера имен и переходит вниз по дереву, пока не достигнет сервера имен, содержащего домен с записью адреса.
10. По достижении нужного сервера имен выполняется запрос этого сервера имен на запись адреса.
11. DNS-сервер возвращает IP-адрес DNS-серверу клиента.
12. DNS-сервер клиента кэширует этот IP-адрес и возвращает компьютеру клиента.

Типы зон в Windows Server 2003

Зоной называется часть домена DNS. Например, домен MyCompany.com может содержать несколько зон, например, Sales.MyCompany.com и Corp.MyCompany. Как правило, термин "зона" используется для обозначения части домена в отношении DNS-сервера. Термин "поддомен" используется для обозначения части домена, содержащегося в зоне. При наличии в домене только одной зоны используется любой из этих терминов.

Операционная система WS03 поддерживает три типа зон.

Главная зона. Главная зона является главной копией зоны. Эта зона является полномочной для той части домена, которой она управляет. Файл зоны можно как считывать, так и редактировать.

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

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

Хранилище зоны DNS

Информация зоны DNS хранится либо в текстовом файле, либо в Active Directory. При создании главной или остаточной зоны можно указать место хранения для файла зоны. Файлы вторичных зон хранятся только в формате текстовых файлов.

Сохранение информации зоны в текстовом файле

Информации зоны в текстовом файле по умолчанию сохраняется в папке %systemroot%\system32\dns. Имя файла может быть любым; обычно оно имеет вид [имя_зоны].DNS (например, microsoft.com.dns). Файл зоны изменяется через консоль MMC для DNS, однако при остановке службы DNS это можно сделать напрямую, отредактировав текстовый файл зоны. Если запись занимает несколько строк, то разрывы строк должны заключаться в скобки. Комментарии в файле зоны DNS определяются точками с запятой (";"), расположенными перед ними. На рисунке 8.10 показан пример файла зоны DNS.

Ниже приводится описание записей, находящихся в файле зоны DNS.

Запись SOA. Первая запись в файле зоны DNS является записью Start of Authority (Начало полномочий). Запись SOA состоит из следующих полей:

Исходный компьютер. Определяет узел, на котором создан файл.

Контактный адрес электронной почты. Адрес электронной почты лица, ответственного за данный файл зоны. Символ "@" в адресе электронной почты заменяется на символ точки (".").

Серийный номер. Серийный номер данной версии файловой базы данных зоны, используемый для контроля версий.

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

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

Срок действия. Время (в с), в течение которого информация считается действительной. Запись информирует вторичный сервер о промежутке времени, по прошествии которого все данные должны быть сброшены. Этот счетчик сбрасывается в случае успешной передачи зоны. Таким образом, в процессе взаимодействия вторичного сервера с главным сервером данные сбрасываться не будут.

Минимальное время жизни (TTL). Передается вместе с запросом на преобразование имени. Означает минимальный промежуток времени (с), в течение которого запрашивающий кэширует имя для отображения в IP-адрес. Значение по умолчанию – 1 час. При значении, равном 0, кэширования данных не происходит.

Другие записи. Другие записи в файле зоны DNS наследуют TTL из записи ресурса SOA, однако могут игнорироваться в индивидуальных записях. Синтаксис для индивидуальной записи имеет вид: <имя> <класс> <тип> <данные>.

• Имя. Имя узла или записи, подлежащей преобразованию.
• Класс. Содержит стандартный текст, означающий класс записи источника. IN означает, что запись источника принадлежит классу Internet. Это единственный класс, поддерживаемый Windows DNS.
• Тип. Указывает тип записи источника. Например, A означает, что запись источника хранит информацию об адресе узла.
• Данные. Это поле содержит особые данные записи. Формат может быть различным в зависимости от типа записи.

Сохранение информации зоны в Active Directory

Интегрированные зоны Active Diectory содержатся в контейнере, расположенном в дереве Active Directory под контейнером объекта домена. База данных Active Directory представляет собой расширяемое хранилище с названием ntds.dit. Он создается при создании контроллера домена. Объекту контейнера присваивается имя по имени зоны, присвоенного ей при ее создании.

Преимущества интеграции с Active Directory

Хранение зон DNS в Active Directory является рекомендуемым методом для серверов WS03, поскольку он дает следующие преимущества.

Отказоустойчивость. Хранение DNS в Active Directory обеспечивает отказоустойчивость зон DNS, поскольку информация о зонах DNS сохраняется на каждом контроллере домена внутри рассматриваемого домена. Даже если на определенном контроллере домена служба DNS не работать, он все равно содержит копию базы данных. Таким образом, в случае отказа сервера DNS база данных DNS потеряна не будет.

Многоабонентское обновление. WS03 Active Directory позволяет выполнять так называемое многоабонентское обновление, подразумевающее существование нескольких копий базы данных DNS с возможностью обновления любой из них. Так как интегрированные с Active Directory зоны DNS сохраняются в базе данных Active Directory, каждый контроллер домена содержит копию зоны. При добавлении нового контроллера домена база данных DNS реплицируется на этот контроллер домена. Любой контроллер домена WS03 с работающей службой DNS Server может обновлять главную копию зоны DNS.

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

Безопасность. Интегрированные с Active Directory зоны позволяют использовать списки контроля доступа (ACL) для ограничения доступа к зонам или записям в них. Например, только некоторым пользователям или компьютерам разрешено обновлять записи в данной зоне. Этот процесс известен как безопасное динамическое обновление, и он используется по умолчанию для интегрированных с Active Directory зон.

Улучшенная производительность. Стандартные зоны DNS требуют репликации всей зоны на вторичные серверы при изменении записи. Зоны, интегрированные с Active Directory, реплицируют только сами изменения. Это кардинально уменьшает объем трафика репликации и упрощает сам процесс репликации. Изменения в DNS реплицируются с помощью репликации Active Directory, поэтому планирование репликации зон DNS исключается, что также уменьшает объем задач по администрированию.

Динамическое обновление DNS

Службы DNS системы WS03 позволяют проводить динамическое обновление, посредством которого клиенты могут вводить свои собственные записи A (Address) и PTR (Pointer Resource) в DNS. Обычная DNS является статической, поэтому при изменении IP-адресов соответствующие записи DNS становятся рассинхронизированными. Раньше это не представляло особой проблемы, поскольку записи DNS располагались только на серверах, а IP-адреса серверов в большинстве случае являются статическими. Кроме того, основная часть задач по преобразованию имен выполнялась системой WINS. Теперь Windows опирается, в основном, на DNS, и самое главное – все компьютеры содержатся в DNS. Многие клиенты располагаются на DHCP и могут получать различные IP-адреса, поэтому без обновления DNS при изменении адресов IP все может пойти наперекосяк. Здесь-то и вступает в игру динамическая DNS. При получении новых IP-адресов клиенты регистрируют свои записи, и администратору не приходится выполнять задачи, связанные с их обновлением.

При создании зоны DNS можно использовать безопасное динамическое обновление (от него потом можно отказаться). А теперь обсудим различия между двумя типами обновлений – обычным и безопасным.

Обычное динамическое обновление

При использовании динамических обновлений клиент или сервер DHCP является ответственным за обновление записей DNS A и PTR. Поскольку имя может зарегистрировать каждый, невозможно предотвратить злоумышленную регистрацию IP-адреса на имя, представляющее важность. Такая возможность является не безопасной; поэтому была разработана система безопасного динамического обновления.

Безопасное динамическое обновление

Безопасное динамическое обновление доступно только для интегрированных с Active Directory зон. Оно позволяет аутентифицировать клиентов, регистрирующих имена. Безопасные зоны имеют стандартные списки контроля доступа ACL, поэтому обновлять записи могут только те клиенты, которые отвечают разрешениям безопасности. Такой подход удобен следующим: можно заблокировать зоны, чтобы свои записи обновляли только серверы и DHCP-сервер. Таким образом, произвольная регистрация имен становится невозможной.

Windows Server 2003 как кэширующий сервер

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

Сервер DNS в WS03 выступает в роли кэширующего сервера по умолчанию. При создании зоны на сервере DNS он по-прежнему будет выполнять кэширование; но теперь он не будет только кэширующим сервером.

Типы записей источников в DNS

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

A. Запись адреса. Используется для определения записи ресурса узла. Она преобразует имя домена DNS в 32-битный адрес IPv4.

AAAA. Определяет запись ресурса адреса узла для IPv6. Преобразует доменное имя DNS в 128-битный адрес IPv6.

AFSDB. Запись ресурса Andrew File System Database связывает имя DNS с сервером базы данных AFS.

ATMA. Запись ресурса Asynchronous Transfer Mode Address преобразует имя домена DNS в адрес ATM.

CNAME. Запись ресурса Canonical Name преобразует одно имя DNS в другое, используется для присвоения псевдонимов. В рассматриваемом домене должно присутствовать имя DNS, которому присваивается псевдоним.

HINFO. Запись ресурса Host Information указывает тип CPU и операционной системы для записи узла. Эта информация используется протоколами приложений (например, FTP), которые иногда применяют определенные процедуры для определенных процессоров или операционных систем.

ISDN. Запись ресурса Intergrated Services Digital Network преобразует имя домена DNS в телефонный номер ISDN.

KEY. Запись ресурса Public Key содержит открытый ключ для зоны, указанной в данной записи.

MB. Запись ресурса Mailbox преобразует имя почтового ящика домена в имя почтового ящика узла. Имя почтового ящика узла должно совпадать с записью ресурса действительного адреса узла (A), используемой узлом в этой зоне.

MG. Запись ресурса Mail Group указывает запись ресурса почтового ящика для почтовой группы домена. Записи ресурса почтового ящика (MB) должны находиться в текущей зоне.

MINFO. Запись ресурса Mailbox Mail List Information указывает почтовый ящик стороны, ответственной за почтовый ящик или список рассылки. Записи ресурса почтового ящика (MB) должны находиться в текущей зоне.

MR. Запись ресурса Mailbox Renamed указывает запись ресурса почтового ящика, соответствующую другому почтовому ящику. Запись ресурса MR используется для пересылки почты пользователю, сменившему почтовый ящик.

MX. Запись ресурса Mail Exchanger указывает почтовый сервер, принимающий почту для текущей зоны. Двузначный приоритет обозначает предпочитаемый порядок при указании нескольких узлов обмена почтой. Каждый сервер, указанный в записи MX, должен иметь соответствующую запись ресурса адреса узла (A).

NS. Запись ресурса Name Server связывает имя домена DNS с сервером, ответственным за данный домен. Указанный сервер должен иметь соответствующую запись ресурса адреса узла (A).

NXT. Запись ресурса Next игнорирует существование записи в домене посредством создания цепочки из имен владельца в данной зоне.

OPT. Запись ресурса Option добавляет данные опций в запрос или ответ DNS.

PTR. Запись ресурса Pointer связывает одно имя с другим именем в другой зоне. Широко используется в дереве домена in-addr.arpa для реализации обратного поиска связей адрес-имя.

RP. Запись ресурса Responsible Person указывает имя почтового ящика домена лица, ответственного за данную зону.

RT. Запись ресурса Route Through обеспечивает промежуточное связывание внутренних узлов, не имеющих прямого адреса, с внешним сетевым подключением. Как и в записи MX, для установки приоритета используется двузначное значение при указании нескольких узлов промежуточной маршрутизации; соответствующая запись ресурса адреса узла (A) должна находиться в текущей зоне.

SIG. Запись ресурса Signature преобразует набор записей ресурса в доменное имя.

SOA. Запись ресурса Start of Authority указывает имя сервера, являющегося главным сервером имен, ответственным за данную зону. Является первой записью в зоне и содержит следующую информацию.

• Серийный номер. Версия, используемая в данной зоне.
• Обновление. Время (с), в течение которого вторичный сервер ожидает обновления информации о зоне с главного сервера.
• Повтор. Время (с), в течение которого вторичный сервер ожидает повтора неудавшейся передачи зоны.
• Срок действия. Время (с), по истечении которого сервер перестает отвечать на запросы и принимает информацию зоны как недействительную (при отсутствии передачи зоны).
• Минимальный TTL. TTL по умолчанию записей в зоне.

SRV. Запись ресурса Service Locator позволяет нескольким серверам обеспечивать работу аналогичных служб TCP/IP для простоты нахождения последних. Данная запись контролирует список серверов для определенных служб, чтобы эти службы можно было найти посредством одной операции DNS-запроса. Серверы можно упорядочить по предпочтению доменного имени DNS. Таким способом клиенты находят серверы Windows Active Directory, так как запись SRV содержит сведения о контроллерах доменов, использующих службу LDAP через порт TCP 389.

В записи SRV содержаться несколько полей.

• Служба. Имя службы. Распространенные службы имеют предопределенные имена, установленные в RFC 1700. Можно указать любое желаемое имя, однако при наличии предопределенное имени в соответствии со стандартом нужно использовать именно его.
• Протокол. Указывает тип транспортного протокола. По умолчанию выбирается TCP или UDP. В RFC 1700 определяются другие протоколы, которые также можно использовать.
• Имя. Имя домена DNS для данной записи службы. Имя записи ресурса SRV является уникальным, в отличие от других типов записей DNS.
• Приоритет. Устанавливает приоритет для узла, указанного в этой записи. Клиенты пытаются установить контакт с первым достигаемым узлом самого низшего из указанных здесь приоритетов.
• Вес. Устанавливает вес сервера, указанного в данной записи. При наличии нескольких серверов одного приоритета клиенты выбирают серверы по их весу. Данное поле является необязательным.
• Порт. Указывает порт, используемый службой, обозначенной в поле Служба. Распространенные порты указаны в RFC 1700. Можно указывать порты в диапазоне от 0 до 65535.
• Цель. Указывает имя домена DNS узла для данной службы. Имена узлов должны иметь в рассматриваемом домене DNS действительную запись узла (A).
• TXT. Запись ресурса Text содержит описание или дополнительную информацию о зоне.
• WKS. Запись ресурса Well-Known Service содержит перечень распространенных служб TCP/IP, поддерживаемых определенным протоколом (TCP или UDP) на конкретном IP-адресе.
• X25. Запись ресурса X.25 устанавливает соответствие имени домена DNS с номером PSDN (Сеть с открытой коммутацией).

Установка DNS на WS03 Server

В современном виртуальном пространстве присутствует огромное множество серверов DNS, многие из которых работают в Windows. В комплект WS03 входит сервер Microsoft DNS. DNS не устанавливается по умолчанию при инсталляции WS03. Для установки данного компонента выполните следующие действия.

1. В Панели управления щелкните на значке Add/Remove Programs (Установка и удаление программ) для открытия соответствующего окна.
2. Нажмите на кнопку Add/Remove Windows Components (Установка/Удаление компонентов Windows).
3. Выделите пункт Networking Services (Сетевые службы) и нажмите на кнопку Details (Состав).
4. Отметьте опцию Domain Name System (DNS).
5. Нажмите на кнопку OK, затем – на кнопку Next (Далее).
6. Вставьте компакт-диск Windows (при необходимости).
7. Если вы используете какие-либо DHCP-присвоенные IP-адреса, то возможно изменение статического IP-адреса.
8. Нажмите на кнопку Finish (Готово) для завершения процесса.

Консоль DNS

DNS, как и все остальные компоненты WS03, администрируется при помощи консоли MMC (см. рис. 8.11). Консоль MMC DNS открывается с помощью команды Start\Administrative Tools\DNS (Пуск\Администрирование\DNS).

В консоли DNS в левой области под именем компьютера располагаются три компонента: Event Virewer (Просмотр событий), Forward Lookup Zones (Зоны прямого поиска) и Reverse Lookup Zones (Зоны обратного поиска).

Просмотр событий

Секция Event Viewer содержит часть DNS Events (События DNS) обычной программы просмотра событий. Это делает консоль DNS универсальным средством управления сервером доменных имен. Опции управления данной секции соответствуют опциям, доступным при обычном просмотре событий.

Зоны прямого поиска

Секция Forward Lookup Zones (Зоны прямого поиска) выводит список всех зон прямого поиска компьютера для обычных записей домена DNS (A, SRV, MX и т.д.).

Для создания зоны прямого поиска выполните следующие шаги.

1. Откройте консоль DNS MMC.
2. Щелкните правой кнопкой мыши на пункте Forward Lookup Zones (Зоны прямого поиска), затем во всплывающем меню выберите New Zone (Создать зону).
3. Откроется мастер создания новых зон (New Zone Wizard). Нажмите на кнопку Next (Далее).
4. Выберите тип создаваемой зоны, затем отметьте опцию Store In Active Directory (Сохранить в Active Directory), если она доступна.
5. Введите имя зоны.
6. Укажите имя файла, который будет использоваться (если не AD).
7. Разрешите/запретите динамические обновления.
8. Нажмите на кнопку Finish (Готово).

После создания зоны обратного поиска можно создать записи. Самым распространенным типом записи является Address (Адрес), поэтому мы начнем именно с нее.

1. Откройте консоль DNS.
2. Щелкните правой кнопкой мыши на зоне, в которую нужно добавить записи, и выберите New Other Records (Создать другие записи). Отобразится перечень всех типов записей, которые можно расположить в данной зоне.
3. Укажите нужный тип записи. В нашем примере следует указать Host(A).
4. Нажмите на кнопку Create Record (Создать запись). Появится окно New Resurce Record (Новая запись ресурса).
5. Введите имя узла. При создании веб-сайта в качестве имени узла обычно указывается WWW.
6. Введите IP-адрес узла.
7. Если есть зона обратного поиска, и вы хотите обновить обратную запись, отметьте опцию, после чего произойдет ее автоматическое обновление.
8. Нажмите на кнопку OK.
9. Нажмите на кнопку Done (Готово) для закрытия окна Resouce Record type (Тип записи ресурса).

Зоны обратного поиска

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

Давайте рассмотрим пример, связанный с работой зон обратно поиска. Предположим, кто-то представился под именем mail.someisp.com и IP-адресом – 55.56.57.58. При проверке обратного соответствия выясняется, что данный IP-адрес принадлежит имени spamalot.badmail.com. С точки зрения безопасности здесь что-то не так. Именно для этого и предназначены обратные DNS-адреса.

Как функционируют зоны обратного поиска

Зоны обратного поиска аналогичны зонам прямого поиска, за исключением двух важных отличий. Все IP-адреса являются частью одного домена с именем in-addr.arpa. Этот домен является полномочным для всех операций поиска имен по IP-адресам. Такие домены делегируются посредством блоков IP-адресов. Например, для IP-блока класса C адресов 192.168.0.0 / 24 (192.168.0.0 – 192.168.0.255) зоной обратного поиска в DNS является 0.168.192.in-addr.arpa. Обратные зоны присваиваются в обратном порядке. Часть IP-адреса, представляющая собой номер сети, формирует зону, а номера узлов образуют записи PTR.

Ниже приведены несколько примеров.

Обратный адрес DNS делегируется блоком IP, начиная с верхнего блока вниз до используемого вами блока. Это означает, что адреса класса A делегируются с первого октета, адреса класса B – со второго октета, а адреса класса С – с третьего октета.

Рассмотрим последовательность преобразования IP-адреса в имя посредством обратного поиска DNS.

1. Клиенту нужно выяснить, кем является определенный IP-адрес, скажем, 55.66.77.88. Клиент спрашивает у DNS-сервера: "Кто такой 88.77.66.55.in-addr.arpa?".
2. Поскольку это адрес класса A, начинаем с первого октета. DNS-сервер начнет с опроса корневых серверов: "Кто такой 88.77.66.55.in-addr.arpa?".
3. Корневой сервер отвечает, что ему это не известно, но 0.0.0.55.in-addr.arpa принадлежит MongoISP.
4. DNS-сервер спрашивает у DNS-сервера провайдера MongoISP: "Кто такой 88.77.66.55.in-addr.arpa?".
5. DNS-сервер провайдера MongoISP отвечает, что ему это не известно, однако ему принадлежит 0.0.0.55.in-addr.arpa, и он делегировал 0.0.66.55.in-addr.arpa провайдеру MidTierISP.
6. DNS-сервер спрашивает у DNS-сервера провайдера MidTierISP: "Кто такой 88.77.66.55.in-addr.arpa?".
7. DNS-сервер MidTierISP отвечает, что ему это не известно, но в его владении находится 0.0.66.55.in-addr.arpa, и что он делегировал 0.77.66.55.in-addr.arpa провайдеру HomeTownISP.
8. DNS-сервер спрашивает у DNS-сервера HomeTownISP "Кто такой 88.77.66.55.in-addr.arpa?"
9. DNS-сервер провайдера HomeTownISP отвечает, что он точно знает, кто это, и что данный адрес принадлежит mail.somebody.com.

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

Например, обратной зоной DNS для подсети 192.168.0.128 / 26 является 128/26.0.168.192.in-addr.arpa. Число 128 говорит о том, что нужно начать с этой подсети с 26-битной маской подсети.

Почему "делегирование"?

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

Если вас интересуют более глубокие аспекты, связанные с работой обратного поиска DNS, обратитесь к документу RFC 2317 "Classless IN-ADDR.ARPA Delegation".

Создание зоны обратного поиска

Рассмотрим процесс создания зоны обратного поиска.

1. Откройте консоль DNS.
2. Щелкните правой кнопкой мыши на сервере, где нужно создать зону, после чего выберите команду New Zone (Создать зону).
3. Выберите тип зоны. В данном примере – Standard Primary (Стандартная главная) (не в AD).
4. Выберите создание зоны обратного поиска Reverse Lookup Zone (Зона обратного поиска).
5. Введите сетевой идентификатор создаваемой зоны. В данном примере используйте 192.168.0. Обратите внимание на то, что здесь не указывается четвертый октет, поскольку с ним нельзя создать зону обратной DNS. Если создается бесклассовая (в подсети) обратная зона, то следует ввести имя, а не использовать область мастера Network ID (Сетевой идентификатор).
6. Выберите создание зоны с данным именем файла, введите новое имя файла либо используйте существующий файл. Помните, что при создании бесклассовой зоны в имени файла нельзя использовать прямой слеш, поскольку он является недопустимым символом в именах файлов Windows. Вместо него следует использовать дефис ("-"). При использовании существующего файла преимущество заключается в том, что готовый файл DNS уже настроен и содержит все записи.
7. Разрешите или запретите динамическое обновление. Если не используется интегрированная с AD зона, нельзя разрешить только защищенные динамические обновления, потому что невозможно настроить списки контроля доступа на стандартных зонах. Тем не менее, можно разрешить динамические обновления с любого клиента.
8. Нажмите на кнопку Finish (Готово) для завершения процесса.

После создания зоны в ней можно создать записи. В нашей зоне требуется создание записи PTR и обеспечение делегирования.

Создание записей в зоне обратного поиска

Для создания записей обратного поиска выполните следующие действия.

1. Выделите зону, в которой нужно создать записи.
2. Выберите команду Action\New Pointer (PTR) (Действие\Новый указатель [PTR]).
3. Введите узловую часть IP-адреса в соответствующем текстовом поле.
4. Введите имя узла.
5. Нажмите на клавишу OK.

Делегирование зон DNS

Рассмотрим процесс делегирования зоны обратного поиска в DNS.

1. Выделите зону обратного поиска, для которой необходимо реализовать делегирование.
2. Выберите команду Action\New Delegation (Действие\Новое делегирование).
3. Введите номер подсети, которую нужно делегировать. Например, если для подсети 10.10.0.0/16 нужно делегировать 10.10.5.0/24, то следует ввести 5.
4. Нажмите на кнопку Next (Далее).
5. Добавьте имя (имена) DNS-сервера (серверов), на которых будет располагаться зона, нажав на кнопку Add (Добавить).
6. Нажмите на кнопку Next (Далее).
7. Нажмите на кнопку Finish (Готово) для завершения работы мастера.

Вам необходимо также создать соответствующую зону на рассмотренном сервере. В этом случае запись указывает клиенту на сервер имен при выполнении преобразования клиентом имени DNS.

Использование круговой DNS

Круговая DNS является упрощенной формой распределения нагрузки на несколько веб-серверов (или других серверов). Для использования круговой DNS создается несколько записей Address (Адрес) для одного и того же IP-адреса. При запросе клиентом IP-адреса DNS-сервер возвращает все записи ресурсов, например:

В следующий раз при запросе клиентом данного имени список IP-адресов будет выглядеть так:

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

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

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

Использование файла узлов для преобразования имен

Раньше преобразование имен выполнялось, главным образом, с помощью файлов узлов. В наши дни для этого используется система DNS. Тем не менее, Windows поддерживает файлы узлов на тот случай, если потребуется дополнить записи DNS такими файлами. Файл узлов располагается в папке %systemroot%\system32\drivers\etc. Его можно редактировать и пополнять своими собственными записями.

Файл узлов изменяется следующим образом.

1. Откройте файл узлов в Notepad (Блокнот).
2. Расположите вашу запись под записью localhost в файле узлов (см. рис.8.12).
3. Сохраните и закройте файл узлов.

Запись в файле узлов состоит из двух полей: IP-адрес и полное имя домена, соответствующее этому IP-адресу. Этих элементов достаточно для выполнения преобразования имен.