Для чего нужна обратная зона dns. Создание и настройка зон DNS. Что такое запись обратной зоны DNS

Глава 1. Общая методика построения распределенных систем на основе веб-сервисов

1.1. Сервис-ориентированная архитектура.

1-2. Методика построения веб-сервисов Java.

1-3. Предварительное тестирование веб-сервисов.

Глава 2. Методы построения программного обеспечения веб-сервисов распределенной системы автоматизации схемотехнического проектирования

2-1. Математическое обеспечение систем автоматизации схемотехнического проектирования.

2-2. Веб-сервис для проектирования линейных систем в частотной области.

2-3. Веб-сервис для расчета стационарного режима нелинейных систем.

2-4. Сервис-ориентированная интегрированная система для частотного анализа линеаризованных схем.

2-5. Веб-сервис для расчета нелинейных систем в динамическом режиме.

Глава 3. Построение веб-сервисов на основе методов сжатия данных.

3-1. Методы устранения нулевых элементов при хранении и обработке матриц.

3-2. Методика разработки модифицированных версий веб-сервисов.

3-2-1. Модификация на символьном этапе.

3-2-2. Модификация на численном этапе.

3-3. Веб-сервис для расчета чувствительности схемных функций к вариации параметров.

3-3-1. Построение метода веб-сервиса на основе дифференцирования уравнений.

3-3-2. Метод веб-сервиса на основе присоединенной схемы.

3-4. Веб-сервис для расчета чувствительности переменных стационарного режима.

3-4-1. Построение метода веб-сервиса для расчета векторной чувствительности переменных.

3-4-2. Метод веб-сервиса для расчета скалярной чувствительности переменных.

Глава 4. Методы построения клиентских приложений распределенных САПР.

4-1. Методика построения клиентских приложений на основе WSDL-документа.

4-1-1. Развертывание веб-сервисов на сервере Apache Tomcat.

4-1-2. Методика импортирования файла WSDL и построения каркаса клиентского приложения.

4-2. Клиентские приложения распределенной системы схемотехнического проектирования.

4-2-1. Методика построения консольных клиентов.

4-2-2. Методика построения оконных клиентских приложений.

4-2-3. Методика построения клиентских веб- приложений.

4-3. Развертывание клиентских Java-приложений.

4-3-1. Развертывание клиентских Java-приложений, запускаемых из командной строки.

4-3-2. Развертывание клиентских Java-приложений, запускаемых из веб-броузера.

4-4. Организация взаимодействия клиентских приложений с вебсервисами в гетерогенных средах.

Введение диссертации (часть автореферата) на тему "Исследование и разработка методов построения распределенных систем автоматизированного проектирования на основе технологии веб-сервисов"

Широкое внедрение систем автоматизированного проектирования в практику решения инженерных задач существенно ограничивается высокой стоимостью лицензионного программного обеспечения САПР. Вместе с тем создание собственных систем автоматизированного проектирования связано с огромными затратами ресурсов и не может быть реализовано в сжатые строки, так как на разработку современных САПР требуются сотни человеколет. Проблема усложняется также и тем, что в реальных ситуациях эксплуатации многофункциональные интегрированные САПР (например, Micro-Cap 7, PSPICE, DISPC ) используются, как правило, крайне неэффективно, поскольку в процессе решения конкретных задач из базового программного обеспечения этих систем часто применяется не более 10-20% программного обеспечения, наиболее специфичного для каждого подразделения.

Решением этой актуальной проблемы может быть децентрализация архитектуры САПР путем перехода к распределенным системам проектирования, построенным на основе Интернет-технологий, реализующих задачи коммуникации и информационного обмена между приложениями. Такие независимо управляемые приложения являются автономными и могут взаимодействовать между собой в процессе выполнения общей задачи. Протоколы Интернет-технологий представляют надежную базу для связывания подсистем, и в отличие от Грид-технологий , не требуют согласованного использования ресурсов, находящихся в разных узлах сети, что существенно упрощает процесс построения и эксплуатации распределенной САПР. Основным требованием для возможности реализации такой распределенной системы является согласованность интерфейсов, посредством которых отдельные подсистемы могут взаимодействовать между собой. При выполнении этого требования отдельные компоненты распределенной САПР могут создаваться различными разработчиками и поддерживаться на различных сайтах, откуда они будут поставляться возможно, на коммерческой основе) потребителям.

Наиболее эффективным методом интеграции отдельных подсистем в распределенное приложение является удаленный вызов процедур на основе сервис-ориентированной архитектуры с использованием технологии веб-сервисов . Интеграция на основе веб-сервисов при разработке децентрализованных САПР позволяет перейти к описанию интерфейсов и взаимодействий на основе XML, обеспечивая возможность модификации и развития программного обеспечения при условии сохранения выбранного интерфейса. Это позволяет вследствие слабосвязанности отдельных подсистем обеспечивать взаимодействие между различными сервисами на любой платформе и проводить адаптацию существующих приложений к меняющимся условиям проектирования.

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

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

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

Веб-приложения обеспечивает возможность полностью разместить все программное обеспечение распределенной системы проектирования в сети Интернет. Достоинством приложения такой структуры является открытый доступ к использованию распределенной САПР через броузер любого типа, недостатком приложения такого типа является увеличение времени, необходимого для ввода описания компонентов моделируемой системы, вызванное ожиданием реакции на каждом шаге ввода исходных данных.

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

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

Для достижения поставленной задачи необходимо:

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

Выполнить исследование и разработку программного обеспечения веб-сервисов Java для распределенной системы автоматизации схемотехнического проектирования.

Исследовать и разработать методику построения веб-сервисов Java на основе технологии сжатия данных.

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

Разработать методику реализации функционирования веб-сервисов в гетерогенных средах.

Диссертационная работа содержит введение, четыре главы основного содержания, заключение и список литературы, содержащий 69 наименований. Работа изложена на 154 странице текста, и включает 21 рисунок и одну таблицу.

Заключение диссертации по теме "Системы автоматизации проектирования (по отраслям)", Анисимов, Денис Андреевич

Основные результаты диссертационной работы сводятся к следующим:

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

2. Реализована общая методика построения восходящим методом веб-сервисов Java и соответствующих WSDL-документов, а также доставки их на сервер распределенной САПР после проведения автономного тестирования в среде разработки.

3. Разработана методика построения программного обеспечения веб-сервисов Java для решения типовых задач моделирования непрерывных систем при автоматизированном проектировании электронных схем.

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

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

6. Разработана методика построения распределенных САПР, обеспечивающая взаимодействие веб-сервисов Java и клиентских приложений произвольного типа в гетерогенных средах.

Заключение

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

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

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

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

Список литературы диссертационного исследования кандидат технических наук Анисимов, Денис Андреевич, 2013 год

1. Автоматизация схемотехнического проектирования Текст.: монография / В.Н.Ильин [и др.]; под ред. В.Н.Ильина. М.: Радио и связь, 1987. - 368 с.

2. Автоматизация схемотехнического проектирования на мини-ЭВМ Текст.: учебное пособие / В.И.Анисимов [и др.]. JL: Изд-во Ленингр. ун-та, 1983. - 199 с.

3. Анисимов, В.И. Комплекс диалоговых пакетов моделирования аналоговых и цифровых электронных схем на IBM/PC Текст. / В.И.Анисимов, К.Б.Скобельцын, А.В.Никитин // Автоматизированное проектирование в радиоэлектронике и приборостроении: 1991.-С.3-6.

4. Анисимов, В.И. Чувствительность нелинейных систем к вариации параметров Текст. / В.И.Анисимов, Ю.М.Амахвр // Изв.СПБГЭТУ «ЛЭТИ». Сер. Информатика, управление и компьютерные технологии, -2007. Вып.2. - С. 22-26.

5. Анисимов, В.И. Моделирование непрерывных систем Текст.: учебное пособие / В.И.Анисимов. СПб.: ЛЭТИ, 2006. - 172 с.

6. Беллиньясо, М. Разработка Web-приложений в среде ASP.NET 2.0 Текст.: монография / М.Беллиньясо.; пер. с англ. под ред. Ю.Н. Артеменко. М.: ООО «И.Д.Вильямс», 2007. - 640 с.

7. Беллман, Р. Введение в теорию матриц Текст.: монография / Р.Беллман.; пер. с англ. под ред. В.Б. Лидского. М.: Наука, 1969. - 336 с.

8. Богданов, A.B. Сервис-ориентированная архитектура: новые возможности в свете развития GRID технологий / А.В.Богданов, Е.Н.Станкова, В.В.Мареев (http//www.ict.edu.ru/lib/index.php?idres=5639)

9. Влах, И. Машинные методы анализа и проектирования электронных схем Текст.: монография / И.Влах, К.Сингхал.; пер. с анг. М.: Радио и связь, 1988. - 560 с.

10. Гамма, Э. Приемы объектно-ориентированного проектирования Текст.: монография / Э.Гамма, Р.Хелм.; пер. с анг. СПб.: Питер, 2001.

11. И. Гербер, Ш. Полный справочник по С# Текст.: монография / Ш.Гербер.; пер. с анг. СПб.: Питер, 2006. - 740 с.

12. Глориозов, Е.Л. Введение в автоматизацию схемотехнического проектирования Текст.: монография / Е.Л.Глориозов, В.Г.Сорин, П.П.Сыпчук. М.: Советское радио, 1976. - 232 с.

13. Даконта, М. XML и Java 2. Библиотека программиста Текст.: монография / М.Даконта, А.Саганич.; пер. с анг. СПб.: 2001. - 384 с.

14. Дей, Н. Eclipse: Платформа Web-инструментов Текст.: монография / Н.Дей, Л.Мандел, А.Райман.; пер. с англ. М.:, 2008.- 688 с.

15. Дейтел, Х.М. Технология программирования на Java 2: Книга 1. Графика, JavaBeans, интерфейс пользователя Текст.: монография / Х.М.Дейтел, П.Д.Дейтел, С.И.Сантри.; М.: ООО «Бином-Пресс», 2003.-560 с.

16. Дейтел, Х.М. Технология программирования на Java 2: Книга 2. Распределенные приложения Текст.: монография / Х.М. Дейтел, П.Д.Дейтел, С.И.Сантри.; М.: ООО «Бином-Пресс», 2003.-464 с.

17. Дейтел, Х.М. Технология программирования на Java 2: Книга 3. Корпоративные системы, сервлеты, JSP, Web-сервисы Текст.: монография / Х.М.Дейтел, П.Д.Дейтел, С.И.Сантри.; пер. с анг. М.: ООО «Бином-Пресс», 2003.- 672 с.

18. Демидович, Б.П. Основы вычислительной математики Текст.: монография / Б.П.Демидович, И.А.Марон. М.: Физматгиз, 1963. - 658 с.

19. Джеймс, О. Итерационные методы решения нелинейных систем уравнений Текст.: монография / О.Джеймс, Р.Венер.; пер. с англ. под ред. Э.В. Вершкова, Н.П. Жидкова, И.В. Коновальцева. М.: Мир, 1975.- 551 с.

20. Джордж, А. Численное решение больших разреженных систем уравнений Текст.: монография / А.Джордж, Дж.Лю.; пер. с англ. Х.Д. Икрамова М.: Мир, 1984. - 333 с.

21. Диалоговые системы схемотехнического проектирования Текст.: монография / В.И.Анисимов [и др.]. М.: Радио и связь, 1988. - 287 с.

22. Дунаев С.Б. Java для Internet в Windows и Linux Текст.: монография / С.Б.Дунаев. М.: ДИАЛОГ-МИФИ, 2004. - 496 с.

23. Зеленухина, В.А. Разработка Интернет-ориентированных виртуальных лабораторий математического моделирования посредством разделения вычислительных и визуализационных задач Текст. / В.А.Зеленухина, //Информационные технологии, 2010. №10. - С.

24. Зыков, A.A. Основы теории графов Текст.: монография / А.А.Зыков. -М.: Наука, 1987.-256 с.

25. Ильин, В.Н. Основы автоматизации схемотехнического проектирования Текст.: монография / В.Н.Ильин. М.: Энергия, 1979. - 391 с.

26. Имитационное моделирование производственных систем Текст.: монография / А.А.Вавилов [и др.]. Киев: Техника, 1983. - 415 с.

27. Как программировать на XML Текст.: монография / Х.М.Дейтел, [и др.].; пер. с анг. М.: ЗАО «Издательство БИНОМ», 2001.- 944 с.

28. Калиткин, H.H. Численные методы Текст.: монография / Н.Н.Калиткин. -М.: Наука, 1978,- 519 с.

29. Кнут, Д. Искусство программирования для ЭВМ Текст.: монография / Д.Кнут.; пер. с англ. Г.П.Бавенко, Ю.М.Ваяковского.; под ред. К.И.Бабенко, В.С.Штаркмана. М.: Мир, 1976. - 734 с.

30. Кристофидес, Н. Теория графов. Алгоритмический подход Текст.: монография / Н.Кристофидес.; пер. с анг. под ред. Г.П.Гаврилова. М.: Мир, 1978.-432 с.

31. Мак-Дональд, М. Microsoft ASP.NET 2.0 с примерами на С# 2005 для профессионалов Текст.: монография / М. Мак-Дональд, М.Шпушта; пер. с анг. под ред. Ю.Н. Артеменко. М.: ООО «И.Д.Вильямс», 2006. - 1408 с.

32. Михайлов, В.Б. Численно-аналитические методы решения сверхжестких дифференциально-алгебраических систем уравнений Текст.: монография /В.Б.Михайлов. СПб.: Наука, 2005. - 223 с.

33. Норенков, И.П. Введение в автоматизированное проектирование технических устройств и систем Текст.: монография / И.П.Норенков. -М.: Высшая школа, 1986. 302 с.

34. Норенков, И.П. Основы теории и проектирования САПР Текст.: монография / И.П.Норенков, В.Б.Маничев. М.: 1990. -334 с.

35. Норенков, И.П. Системы автоматизированного проектирования электронной и вычислительной аппаратуры Текст.: монография / И.П.Норенков, В.Б.Маничев. -М.: Высшая школа, 1983. 272 с.

36. Ноутон, П. Java 2 Текст.: монография / П. Ноутон, Г.Шилдт. ; пер. с англ. СПб.: БХВ-Петербург, 2001. - 1072 с.

37. Петренко, А.И. Основы построения систем автоматизированного проектирования Текст.: монография / А.И.Петренко, О.И.Семенков. -Киев: Высшая школа, 1984. 293 с.

38. Петренко, А.И. Табличные методы моделирования электронных схем на ЭЦВМ Текст.: монография / А.И. Петренко, А.И.Власов, А.П.Тимченко. -Киев: Высшая школа, 1977. 186 с.

39. Писсанецки, С. Технология разреженных матриц Текст.: монография / С.Писсанецки.; пер. с анг. под ред. Х.Д.Икрамова. М.: Мир, 1988. - 410 с.

40. Разевиг, В. Схемотехническое моделирование с помощью Micro-Cap 7 Текст.: монография / В.Разевиг. М. : Телеком, 2003. - 368 с.

41. Разработка распределенных приложений на платформе Microsoft .Net Framework Текст.: монография / С.Морган [и др.].; пер. с англ. М.: «Русская Редакция», 2008. - 608 с.

42. Разработка клиентских веб-приложений на платформе Microsoft .Net Framework Текст.: монография / Гленн Д. [и др.].; пер. с англ. М.: «Русская Редакция», 2007. - 768 с.

43. Руководство разработчика Borland JBuilder Текст.: монография / М.Ленди [и др.].; пер. с англ. М.: Издательский дом «Вильяме», 2004. -864 с.

44. Райе, Дж. Матричные вычисления и математическое обеспечение Текст.: монография / Дж.Райс.; пер. с анг. М.: Мир, 1984. - 264 с.

45. С# для профессионалов Текст.: монография / Симон Робинсон [и др.].; пер. с англ. С.Коротыгин [и др.]. М.: Лори, 2005. - 1002 с.

46. Саймон, P. Microsoft Windows 2000 API. Энциклопедия программиста Текст.: монография / Р.Саймон.; СПб.: ДиаСофт, 2002.-1088 с.

47. Секреты программирования для Internet на Java Текст.: монография / М.Томас [и др.].; пер. с англ. СПб.: Питер, 1997. - 640 с.

48. Сешу, С. Линейные графы и электрические цепи Текст.: монография / С.Сешу, М.Б.Рид.; пер. с англ. М.: Высшая школа, 1971. - 448 с.

49. Сигорский, В.П. Алгоритмы анализа электронных схем Текст.: /

50. B.П.Сигорский, А.И.Петренко. М.: Советское радио, 1976. - 606 с.

51. Сигорский, В.П. Математический аппарат инженера Текст.: монография / В.П.Сигорский. Киев: Техника, 1975. - 765 с.

52. Слипченко, В.Г. Машинные алгоритмы и программы моделирования электронных схем Текст.: монография / В.Г.Слипченко, В.Г.Табарный -Киев: Техника, 1976. 157 с.

53. Советов, Б.Я. Моделирование систем Текст.: монография / Б.Я.Советов,

54. C.А.Яковлев. М.: Высшая школа, 1985. - 271 с.

55. Сольницев, Р.И. Автоматизация проектирования систем автоматического управления Текст.: монография / Р.И.Сольницев. М.: Высшая школа, 1991. - 328 с.

56. Сольницев, Р.И. Основы автоматизации проектирования гироскопических систем. Текст.: монография / Р.И. Сольницев. М.: Высшая школа, 1985. - 240 с.

57. Степаненко, И.П. Основы микроэлектроники: учеб. пособие для вузов Текст / И.П.Степаненко. М.: Советское радио, 1980. -567 с.

58. Тарасик, В.П. Математическое моделирование технических систем Текст.: монография / В.П. Тарасик. Минск: Дизайн ПРО, 2004. - 639 с.

59. Троелсен, Э. Язык программирования С# 2005 и платформа.NET 2.0 Текст.: монография / Э.Троелсен,; пер. с англ. под ред. А.Г.Спивака. М.: ООО «И.Д.Вильямс», 2007. - 1168 с.

60. Тьюарсон, Ф.Р. Разреженные матрицы Текст.: монография / Ф.Р.Тьюарсон.; пер. с анг. М.: Мир, 1977. - 189 с.

61. Фадеев, Д.К. Вычислительные методы линейной алгебры Текст.: монография / Д.К.Фадеев, В.Н. Фадеева. М.: Изд-во Физ-мат литературы, 1963. - 734 с.

62. Феррара, А. Программирование web-сервисов для.NET Текст.: монография / А.Феррара, М.Мак-Дональд. СПб.: Питер, 2003. - 422 с.

63. Форсайт, Дж. Машинные методы математических вычислений Текст.: монография / Дж.Форсайт, М.Малькольм, К.Моулер.; пер. с англ. под ред. Х.Д.Икрамова. М.: Мир, 1980. - 277 с.

64. Цимбал, A.A. Технология создания распределенных систем Текст.: монография / А.А.Цимбал, М.Л.Аншина. СПб.: Питер, 2003. - 576 с.

65. Чуа, Л.О. Машинный анализ электронных схем Текст.: монография / Л.О.Чуа, Лин.Пен-Мин.; пер. с анг. -М.: Энергия, 1980. 631с.

66. Хайнеман, P. PSPICE Моделирование работы электронных схем Текст.: монография / Р.Хайнеман. -М.: Издательство ДМК, 2005. 327с.

67. Хабибулин, И. Разработка Web-служб средствами Java Текст.: монография / И. Хабибулин. СПб.: БХВ-Петербург, 2003. - 400 с.

68. Холл, М. Сервлеты и JavaServer Pages Текст.: монография / М.Холл.; пер. с анг. -СПб.: Питер, 2001. 496 с.

69. Эстербю, О. Прямые методы для разреженных матриц Текст.: монография / О.Эстербю, З.Златев.; пер. с анг. М.: Мир, 1987. - 111 с.

70. Янг, М.Д. Microsoft XML. Шаг за шагом Текст.: монография / М.Д.Янг.; пер. с англ. -М.: Издательство ЭКОМ, 2002. 384с.69. http://bigor.bmstu.ru/?doc=080IS/ai006.mod/?cou-140CADedu/CAD.cou

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

Архитектура распределенных информационных систем и Web-приложений

Распределенная система - это набор независимых вычислительных машин, представляющийся их пользователям единой объединенной системой. Не смотря на то, что все компьютеры автономны, для пользователей они представляются единой системой.

К основным характеристикам распределенных систем:

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

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

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

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

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

К особенностям функционирования распределенных систем относятся:

· наличие большого количества объектов;

· задержки выполнения запросов (так если локальные вызовы требуют порядка пары сотен наносекунд, то запросы к объекту в распределенных системах требует от 0.1 до 10 мс);

· некоторые объекты могут не использоваться на протяжении длительного времени;

· распределенные компоненты выполняются параллельно, что приводит к необходимости согласования выполнения;

· запросы в распределенных системах имеют большую вероятность отказов;

· повышенные требования к безопасности.

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

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

Архитектура Web-приложений (Web -сервиса) широко применяется в настоящее время. Web-сервис – приложение, доступное через Интернет. Оно предоставляет услуги, форма которых не зависит от поставщика услуг, так как используется универсальная платформа функционирования и универсальный формат данных (XML). В основе Web –сервисов лежат стандарты, определяющие форматы и язык запросов, а также протоколы поиска этих сервисов в Интернете. Схема доступа к базе данных через Интернет показана на рис.1.12.

Рисунок 1.12 – Схема доступа к серверу СУБД через Интернет

В настоящее время существуют три различных технологии, поддерживающие концепцию распределенных объектных систем: EJB, DCOM CORBA.

Основная идея, лежащая в разработке технологии EJB (Enterprise Java Beans ) – создать такую инфраструктуру для компонентов, чтобы они могли бы легко вставляться и удаляться из серверов, тем самым повышая или снижая функциональность сервера. EJB-компоненты являются Java-классами и могут работать на любом EJB-совместимом сервере даже без перекомпиляции. Основными целями EJB-технологии является:

1. Облегчить разработчикам создание приложений, избавив их от необходимости реализовать с нуля такие сервисы, как транзакции, нити, загрузки и др. Разработчики могут сконцентрировать свое внимание на описании логики своих приложений, перекладывая задачи по хранению, передаче и безопасности данных на EJB-систему.

2. Описать основные структуры EJB-системы и интерфейсы взаимодействия между ее компонентами.

3. Освободить разработчика от реализации EJB-объектов за счет наличия специального кодогенератора.

Благодаря используемойJava-модели, EJB является относительно простым и быстрым способом создания распределенных систем.

Технология DCOM (Distributed Component Object Model ) - программная архитектура, разработанная компанией Microcoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одном из компьютеров может использовать DCOM для передачи сообщений к компоненту на другом компьютере. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленного компонента. Способность DCOM связывать компоненты позволила Microcoft наделить Windows рядом дополнительных возможностей, в частности, реализовать сервер Microsoft Transaction Server, отвечающий за выполнение транзакций баз данных через Интернет.

Историческая справка : Систему доменных имен разработал в 1983 году Пол Мокапетрис. Тогда же было проведено первое успешное тестирование DNS, ставшей позже одним из базовых компонентов сети Internet. С помощью DNS стало возможным реализовать масштабируемый распределенный механизм, устанавливающий соответствие между иерархическими именами сайтов и числовыми IP-адресами.

В 1983 году Пол Мокапетрис работал научным сотрудником института информатики (Information Sciences Institute, ISI ), входящего в состав инженерной школы университета Южной Калифорнии (USC ). Его руководитель, Джон Постел, предложил Полу придумать новый механизм, устанавливающий связи между именами компьютеров и адресами Internet, - взамен использовавшемуся тогда централизованному каталогу имен и адресов хостов, который поддерживала калифорнийская компания SRI International.

"Все понимали, что старая схема не сможет работать вечно, - вспоминает Мокапетрис. - Рост Internet становился лавинообразным. К сети, возникшей на основе проекта ARPANET, инициированного Пентагоном, присоединялись все новые и новые компании и исследовательские институты".

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

"Как только организация подключалась к сети, она могла использовать сколь угодно много компьютеров и сама назначать им имена", - подчеркнул Мокапетрис. Названия доменов компаний получили суффикс.com, университетов - .edu и так далее.

Первоначально DNS была рассчитана на поддержку 50 млн. записей и допускала безопасное расширение до нескольких сотен миллионов записей. По оценкам Мокапетриса, сейчас насчитывается около 1 млрд. имен DNS, в том числе почти 20 млн. общедоступных имен. Остальные принадлежат системам, расположенным за межсетевыми экранами. Их имена неизвестны обычным Internet-пользователям.

Новая система внедрялась постепенно, в течение нескольких лет. В это время ряд исследователей экспериментировали с ее возможностями, а Мокапетрис занимался в ISI обслуживанием и поддержанием стабильной работы "корневого сервера", построенного на мэйнфреймах компании Digital Equipment. Копии таблиц хостов хранились на каждом компьютере, подключенном к Internet, еще примерно до 1986 года. Затем начался массовый переход на использование DNS.

Необходимость отображения имен сетевых узлов в IP-адреса

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

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

Использование локального файла hosts и системы доменных имен DNS для разрешения имен сетевых узлов

На начальном этапе развития сетей, когда количество узлов в каждой сети было небольшое, достаточно было на каждом компьютере хранить и поддерживать актуальное состояние простого текстового файла, в котором содержался список сетевых узлов данной сети. Список устроен очень просто - в каждой строке текстового файла содержится пара "IP-адрес - имя сетевого узла". В системах семейства Windows данный файл расположен в папке %system root%\system32\drivers\etc (где %system root% обозначает папку, в которой установлена операционная система). Сразу после установки системы Windows создается файл hosts с одной записью 127.0.0.1 localhost.

С ростом сетей поддерживать актуальность и точность информации в файле hosts становится все труднее. Для этого надо постоянно обновлять содержимое этого файла на всех узлах сети. Кроме того, такая простая технология не позволяет организовать пространство имен в какую-либо структуру. Поэтому появилась необходимость в централизованной базе данных имен, позволяющей производить преобразование имен в IP-адреса без хранения списка соответствия на каждом компьютере. Такой базой стала DNS (Domain Name System) - система именования доменов, которая начала массовую работу в 1987 году.

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

Служба DNS: пространство имен, домены

DNS - это иерархическая база данных , сопоставляющая имена сетевых узлов и их сетевых служб IP-адресам узлов. Содержимое этой базы, с одной стороны, распределено по большому количеству серверов службы DNS, а с другой стороны, является централизованно управляемым. В основе иерархической структуры базы данных DNS лежит доменное пространство имен (domain namespace), основной структурной единицей которого является домен, объединяющий сетевые узлы (хосты), а также поддомены. Процесс поиска в БД службы DNS имени некоего сетевого узла и сопоставления этому имени IP-адреса называется "разрешением имени узла в пространстве имен DNS".

Служба DNS состоит из трех основных компонент:

Пространство имен DNS и соответствующие ресурсные записи (RR, resource record) - это сама распределенная база данных DNS;

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

DNS-клиенты (DNS-clients, DNS-resolvers) -компьютеры, посылающие запросы серверам DNS для получения ресурсных записей.

Пространство имен.

Пространство имен DNS - иерархическая древовидная структура, начинающаяся с корня, не имеющего имени и обозначаемого точкой ".". Схему построения пространства имен DNS лучше всего проиллюстрировать на примере сети Интернет (рис. 4.8 ).

Рис. 4.8.

Для доменов 1-го уровня различают 3 категории имен:

ARPA - специальное имя, используемое для обратного разрешения DNS (из IP-адреса в полное имя узла);

Общие (generic) имена 1-го уровня - 16 (на данный момент) имен, назначение которых приведено в табл. 4.4 ;

Двухбуквенные имена для стран - имена для доменов, зарегистрированных в соответствующих странах (например, ru - для России, ua - для Украины, uk - для Великобритании и т.д.).

Таблица 4.4.
Имя домена	Назначение
	Сообщества авиаторов
	Компании (без привязки к стране)
	Коммерческие организации, преимущественно в США (например, домен microsoft.com для корпорации Microsoft)
	Кооперативы
	Образовательные учреждения в США
	Правительственные учреждения США
	Домен для организаций, предоставляющих любую информацию для потребителей
	международные организации (например, домен nato .int для НАТО)
	Военные ведомства США
	Глобальный домен для частных лиц
	Домен для Интернет-провайдеров и других организаций, управляющих структурой сети Интернет
	Некоммерческие и неправительственные организации, преимущественно в США
	Домен для профессиональных объединений (врачей, юристов, бухгалтеров и др.)
	Кадровые агентства
	Туроператоры

Для непосредственного отображения пространства имен в пространство IP-адресов служат т.н. ресурсные записи (RR, resource record). Каждый сервер DNS содержит ресурсные записи для той части пространства имен, за которую он несет ответственность (authoritative ). табл. 4.5 содержит описание наиболее часто используемых типов ресурсных записей.

Таблица 4.5.
Тип ресурсной записи	Функция записи	Описание использования
	Host Address Адрес хоста, или узла	Отображает имя узла на IP-адрес (например, для домена microsoft.com узлу с именем www.microsoft.com сопоставляется IP-адрес с помощью такой записи: www A 207.46.199.60)
	Canonical Name (alias) Каноническое имя (псевдоним)	Отображает одно имя на другое
	Mail Exchanger Обмен почтой	Управляет маршрутизацией почтовых сообщений для протокола SMTP
	Name Server Сервер имен	Указывает на серверы DNS, ответственные за конкретный домен и его поддомены
	Pointer Указатель	Используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa
	Start of Authority Начальная запись зоны	Используется для указания основного сервера для данной зоны и описания свойств зоны
	Service Locator Указатель на службу	Используется для поиска серверов, на которых функционируют определенные службы (например, контроллеры доменов Active Directory или серверы глобального каталога )

Полное имя узла (FQDN, fully qualified domain name) состоит из нескольких имен, называемых метками (label) и разделенных точкой. Самая левая метка относится непосредственно к узлу, остальные метки - список доменов от домена первого уровня до того домена, в котором находится узел (данный список просматривается справа налево).

Серверы имен DNS.

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

DNS-клиенты.

DNS-клиент - это любой сетевой узел, который обратился к DNS-серверу для разрешения имени узла в IP-адрес или, обратно, IP-адреса в имя узла.

Служба DNS: домены и зоны

Как уже говорилось выше, каждый DNS-сервер отвечает за обслуживание определенной части пространства имен DNS. Информация о доменах, хранящаяся в БД сервера DNS, организуется в особые единицы, называемые зонами (zones). Зона - основная единица репликации данных между серверами DNS. Каждая зона содержит определенное количество ресурсных записей для соответствующего домена и, быть может, его поддоменов.

Системы семейства Windows Server поддерживают следующие типы зон:

Стандартная основная (standard primary) - главная копия стандартной зоны; только в данном экземпляре зоны допускается производить какие-либо изменения, которые затем реплицируются на серверы, хранящие дополнительные зоны;

Стандартная дополнительная (standard secondary) - копия основной зоны, доступная в режиме "только-чтение", предназначена для повышения отказоустойчивости и распределения нагрузки между серверами, отвечающими за определенную зону; процесс репликации изменений в записях зон называется "передачей зоны" (zone transfer ) (информация в стандартных зонах хранится в текстовых файлах, файлы создаются в папке "%system root%\system32\dns", имя файла, как правило, образуется из имени зоны с добавлением расширения файла ".dns"; термин "стандартная" используется только в системах семейства Windows);

Интегрированная в Active Directory (Active Directory–integrated) - вся информация о зоне хранится в виде одной записи в базе данных Active Directory (такие типы зон могут существовать только на серверах Windows, являющихся контроллерами доменов Active Directory; в интегрированных зонах можно более жестко управлять правами доступа к записям зоны; изменения в записях зоны между разными экземплярами интегрированной зоны производятся не потехнологии передачи зоны службой DNS, а механизмами репликации службы Active Directory);

Зона-заглушка (stub ; только в Windows 2003) - особый тип зоны, которая для данной части пространства имен DNS содержит самый минимальный набор ресурсных записей (начальная запись зоны SOA, список серверов имен, отвечающих за данную зону, и несколько записей типа A для ссылок на серверы имен для данной зоны).

Рассмотрим на примере соотношение между понятиями домена и зоны. Проанализируем информацию, представленную на рис. 4.9 .

Рис. 4.9.

В данном примере пространство имен DNS начинается с домена microsoft.com , который содержит 3 поддомена: sales.microsoft.com , it.microsoft.com иedu.microsoft.com (домены на рисунке обозначены маленькими горизонтальными овалами). Домен - понятие чисто логическое, относящееся только к распределению имен. Понятие домена никак не связано с технологией хранения информации о домене. Зона - это способ представления информации о домене и его поддоменах в хранилище тех серверов DNS, которые отвечают за данный домен и поддомены. В данной ситуации, если для хранения выбрана технология стандартных зон, то размещение информации о доменах может быть реализовано следующим образом:

записи, относящиеся к доменам microsoft.com и edu.microsoft.com , хранятся в одной зоне в файле "microsoft.com.dns" (на рисунке зона обозначена большим наклонным овалом);

управление доменами sales.microsoft.com и it.microsoft.com делегировано другим серверам DNS, для этих доменов на других серверах созданы соответствующие файлы "sales.microsoft.com.dns" и "it.microsoft.com.dns" (данные зоны обозначены большими вертикальными овалами).

Делегирование управления - передача ответственности за часть пространства имен другим серверам DNS.

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

Зоны, рассмотренные в предыдущем примере, являются зонами прямого просмотра (forward lookup zones) . Данные зоны служат для разрешения имен узлов в IP-адреса. Наиболее часто используемые для этого типы записей: A, CNAME, SRV.

Для определения имени узла по его IP-адресу служат зоны обратного просмотра (reverse lookup zones), основной тип записи в "обратных" зонах - PTR. Для решения данной задачи создан специальный домен с именем in-addr.arpa. Для каждой IP-сети в таком домене создаются соответствующие поддомены, образованные из идентификатора сети, записанного в обратном порядке. Записи в такой зоне будут сопоставлять идентификатору узла полное FQDN-имя данного узла. Например, для IP-сети 192.168.0.0/24 необходимо создать зону с именем "0.168.192.in-addr.arpa". Для узла с IP-адресом 192.168.0.10 и именем host.company.ru в данной зоне должна быть создана запись "10 PTR host.company.ru".

Алгоритмы работы итеративных и рекурсивных запросов DNS

Все запросы , отправляемые DNS-клиентом DNS-серверу для разрешения имен, делятся на два типа:

итеративные запросы (клиент посылает серверу DNS запрос , в котором требует дать наилучший ответ без обращений к другим DNS-серверам);

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

Обычные DNS-клиенты (например, рабочие станции пользователей), как правило, посылают рекурсивные запросы.

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

Допустим, что пользователь запустил программу Обозреватель Интернета и ввел в адресной строке адрес http://www.microsoft.com . Прежде чем Обозреватель установит сеанс связи с веб-сайтом по протоколу HTTP, клиентский компьютер должен определить IP-адрес веб-сервера. Для этого клиентская часть протокола TCP/IP рабочей станции пользователя (так называемый resolver ) сначала просматривает свой локальный кэш разрешенных ранее имен в попытке найти там имяwww.microsoft.com . Если имя не найдено, то клиент посылает запрос DNS-серверу, указанному в конфигурации TCP/IP данного компьютера (назовем данный DNS-сервер "локальным DNS-сервером" ), на разрешение имени www.microsoft.com в IP-адрес данного узла. Далее DNS-сервер обрабатывает запрос в зависимости от типа запроса.

Вариант 1 (итеративный запрос).

Если клиент отправил серверу итеративный запрос (напомним, что обычно клиенты посылают рекурсивные запросы), то обработка запроса происходит по следующей схеме:

microsoft.com ;

если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

www.microsoft.com в своем кэше разрешенных ранее DNS-запросов;

если искомое имя есть в кэше, то результат поиска возвращается клиенту; если локальный DNS-сервер не нашел в своей базе данных искомую запись, то клиенту посылается IP-адрес одного из корневых серверов DNS;

клиент получает IP-адрес корневого сервера и повторяет ему запрос на разрешение имени www.microsoft.com ;

корневой сервер не содержит в своей БД зоны "microsoft.com", но ему известны DNS-серверы, отвечающие за зону "com", и корневой сервер посылает клиенту IP-адрес одного из серверов, отвечающих за эту зону;

клиент получает IP-адрес сервера, отвечающего за зону "com", и посылает ему запрос на разрешение имени www.microsoft.com ;

сервер, отвечающий за зону com, не содержит в своей БД зоны microsoft.com , но ему известны DNS-серверы, отвечающие за зону microsoft.com , и данный DNS-сервер посылает клиенту IP-адрес одного из серверов, отвечающих уже за зону microsoft.com ;

клиент получает IP-адрес сервера, отвечающего за зону microsoft.com , и посылает ему запрос на разрешение имени www.microsoft.com ;

сервер, отвечающий за зону microsoft.com , получает данный запрос, находит в своей базе данных IP-адрес узла www, расположенного в зоне microsoft.com , и посылает результат клиенту;

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

Вариант 2 (рекурсивный запрос ).

Если клиент отправил серверу рекурсивный запрос , то обработка запроса происходит по такой схеме:

сначала локальный DNS-сервер ищет среди зон, за которые он отвечает, зону microsoft.com ; если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

в противном случае локальный DNS-сервер ищет запрошенное имя www.microsoft.com в своем кэше разрешенных ранее DNS-запросов; если искомое имя есть в кэше, то результат поиска возвращается клиенту;

если локальный DNS-сервер не нашел в своей базе данных искомую запись, то сам локальный DNS-сервер выполняет серию итеративных запросов на разрешение имени www.microsoft.com , и клиенту посылается либо найденный IP-адрес, либо сообщение об ошибке.

Реализация службы DNS в системах семейства Windows Server

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

поддержка службой DNS динамической регистрации (dynamic updates);

поддержка службой DNS записей типа SRV.

Служба DNS систем Windows Server удовлетворяет обоим условиям, и реализация служб каталогов Active Directory может быть обеспечена только серверами на базе систем Windows Server.

Рассмотрим несколько простых примеров управления службой DNS:

установка службы DNS;

создание основной и дополнительной зоны прямого просмотра;

создание зоны обратного просмотра;

выполнение динамической регистрации узлов в зоне.

сеть состоит из двух серверов Windows 2003 Server;

операционная система - ограниченная по времени 120-дневная русская версия Windows 2003 Server Enterprise Edition;

первый сервер установлен на ПК с процессором Intel Pentium-4 3Ггц и оперативной памятью 512 МБ, имя сервера - DC1, IP-адрес - 192.168.0.1/24 ;

второй сервер работает в качестве виртуальной системы с помощью Microsoft VirtualPC 2004, имя сервера -DC2, IP-адрес - 192.168.0.2/24 ;

имя домена в пространстве DNS и соответствующее имя в службе каталогов Active Directory - world.ru (сеть полностью изолирована от других сетей, поэтому в данном примере авторы были свободны в выборе имени домена; в реальной обстановке конкретного учебного заведения преподавателю нужно скорректировать данную информацию).

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

Установка службы DNS

Установка службы DNS (как и других компонент системы) производится достаточно просто с помощью мастера установки компонент Windows:

Откройте Панель управления .

Выберите пункт "Установка и удаление программ" .

Нажмите кнопку "Установка компонентов Windows" .

Выберите "Сетевые службы" - кнопка "Дополнительно" (ни в коем случае не снимайте галочку у названия "Сетевые службы" ).

Отметьте службу DNS.

Рис. 4.10.

Если система попросит указать путь к дистрибутиву системы, введите путь к папке с дистрибутивом.

Выполним данное действие на обоих серверах.

Создание основной зоны прямого просмотра .

На сервере DC1 создадим стандартную основную зону с именем world.ru.

Откроем консоль DNS.

Выберем раздел "Зоны прямого просмотра" .

Запустим мастер создания зоны (тип зоны - "Основная" , динамические обновления - разрешить, остальные параметры - по умолчанию).

Введем имя зоны - world.ru.

Разрешим передачу данной зоны на любой сервер DNS (Консоль DNS - зона world.ru - Свойства - Закладка "Передачи зон" - Отметьте "Разрешить передачи" и"На любой сервер" ).

Создание дополнительной зоны прямого просмотра .

На сервере DC2 создадим стандартную дополнительную зону с именем world.ru.

Откроем консоль DNS.

Выберем раздел "Зоны прямого просмотра"

"Дополнительная" , IP-адрес master-сервера (с которого будет копироваться зона) - адрес сервера DC1, остальные параметры - по умолчанию)

Введем имя зоны - world.ru.

Проверим в консоли DNS появление зоны.

Настройка узлов для выполнения динамической регистрации на сервер DNS .

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

Сервер DNS.

Создать соответствующую зону.

Разрешить динамические обновления.

Это нами уже выполнено.

Клиент DNS.

Указать в настройках протокола TCP/IP адрес предпочитаемого DNS-сервера - тот сервер, на котором разрешены динамические обновления (в нашем примере - сервер DC1).

В полном имени компьютера указать соответствующий DNS-суффикс (в нашем примере - world.ru). Для этого - "Мой компьютер" - "Свойства" - Закладка"Имя компьютера" - Кнопка "Изменить" - Кнопка "Дополнительно" - в пустом текстовом поле впишем название домена world.ru - кнопка "ОК" (3 раза)).

Рис. 4.11.

После этого система предложит перезагрузить компьютер. После выполнения перезагрузки на сервер DNS в зоне world.ru автоматически создадутся записи типаA для наших серверов (рис. 4.12 ).

Рис. 4.12.

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

Откроем консоль DNS.

Выберем раздел "Зоны обратного просмотра" .

Запустим мастер создания зоны (выбрать: тип зоны - "Основная" , динамические обновления - разрешить, остальные параметры - по умолчанию)

В поле "Код сети (ID)" введем параметры идентификатора сети - 192.168.0.

Выполним команду принудительной регистрации клиента на сервере DNS - ipconfig /registerdns.

Наши серверы зарегистрируются в обратной зоне DNS (рис. 4.13 ):

Прямой просмотр нужен для разрешения доменных имен в ІР-адреса, обратный просмотр – для разрешения ІР-адресов в доменные имена.

В каждом сегменте сети должна быть зона обратного просмотра. В частности, если у вас есть подсети 192.168.10.0, 192.168.11.0 и 192.168.12.0, у вас должно быть три зоны обратного просмотра.

Стандартное имя зоны обратного просмотра составляется из идентификатора сети, выстроенного в обратном порядке, и суффикса in-addr.arpa. Зоны обратного просмотра из предыдущего примера будут называться 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa и 12.168.192.in-addr.arpa. Записи зон обратного и прямого просмотра должны быть синхронизированы. В случае сбоя синхронизации в домене может произойти сбой проверки подлинности.

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

1. Откройте, консоль Диспетчер DNS (DNS Manager) и подключитесь к нужному серверу.

2. Щелкните правой кнопкой элемент сервера и выберите команду Создать новую зону (New Zone). Откроется Мастер создания новой зоны (New-Zone Wizard). Щелкните Далее (Next).

3. Если вы настраиваете основной сервер, интегрированный с Active Directory, установите переключатель Основная зона (Primary Zone) и убедитесь, что установлен флажок . Если вы не хотите интегрировать DNS в Active Directory, установите переключатель Основная зона (Primary Zone) и сбросьте флажок Сохранять зону в Active Directory (Store The Zone In Active Directory) . Щелкните Далее (Next).

4. Если вы настраиваете зону обратного просмотра для дополнительного сервера, установите переключатель Дополнительная зона (Secondary Zone) и щелкните Далее (Next).

5. Если вы интегрируете зону с Active Directory, выберите одну из следующих стратегий репликации:

Для всех DNS-серверов в этом лесу (То All DNS Servers In This Forest) Это обширнейшая стратегия репликации. Помните, что лес Active Directory включает все деревья доменов, использующие данные каталога совместно с текущим доменом.

Для всех DNS-серверов в этом домене (То All DNS Servers In This Domain) Выберите эту стратегию, чтобы реплицировать информацию DNS внутри текущего домена и его дочерних доменов.

Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain) Выберите эту стратегию, если хотите реплицировать информацию DNS на все контроллеры домена внутри текущего домена и его дочерних доменов. Хотя эта стратегия обеспечивает более широкую репликацию информации DNS внутри домена, не каждый контроллер домена является DNS-сервером (вам и не нужно настраивать каждый контроллер домена как DNS-сервер).

6. Установите переключатель Зона обратного просмотра (Reverse Lookup Zone) . Щелкните Далее (Next).

7. Укажите, для каких адресов вы хотите создать зону обратного просмотра (IPv4 или IPv6) и щелкните Далее (Next) . Выполните одно из следующих действий:

Если вы проводите настройку для IPv4, введите идентификатор сети для зоны обратного просмотра. Вводимые значения определяют стандартное имя зоны обратного просмотра. Щелкните Далее (Next).

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

8. Если вы настраиваете основной или дополнительный сервер, не интегрированный в Active Directory, задайте имя файла зоны. Стандартное имя файла для БД зоны DNS должно быть уже введено. Оставьте его неизменным или введите новое имя. Щелкните Далее (Next).

9. Укажите, следует ли разрешить динамические обновления. У вас есть три возможности:

Разрешить только безопасные динамические обновления (Allow Only Secure Dynamic Updates) Если зона интегрирована в Active Directory, вы можете воспользоваться списками ACL, чтобы ограничить круг клиентов, которые могут выполнять динамические обновления. Если вы установите этот переключатель, динамически обновлять записи ресурсов смогут только клиенты с учетными записями компьютеров, прошедшими проверку, и одобренными ACL.

Разрешить любые динамические обновления (Allow Both Nonsecure And Secure Dynamic Updates) Установите этот переключатель, чтобы позволить любому клиенту обновлять его записи ресурса в DNS при наличии изменений.

Запретить динамические обновления (Do Not Allow Dynamic Updates) Этот переключатель отключает динамические обновления DNS. Его следует использовать только при отсутствии интеграции зоны с Active Directory.

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

Основы

Что такое запись обратной зоны DNS?

Обычные DNS-запросы определяют неизвестный IP-адрес для известного имени хоста. Это необходимо когда, например, браузеру нужно установить TCP-соединение с сервером по введённому в адресном поле URL.

Forum.hetzner.de --> 213.133.106.33

Обратный DNS работает в другом направлении - запрос определяет имя хоста, принадлежащее IP-адресу.

213.133.106.33 --> dedi33.your-server.de

Как вы видите, именам хоста при прямом и обратном запросах необязательно совпадать!

Каково предназначение записи обратной зоны DNS?

• traceroute показывает не только IP-адреса, но и человекочитаемые имена узлов. Это значительно облегчает диагностику ошибок.
• Большое количество почтовых серверов принимает письма только если у IP-адреса отправителя есть обратная DNS-запись.
• Обратные DNS-записи могут использоваться в SPF-записях (Sender Policy Framework ; технология, предотвращающая рассылку спама и вирусов с поддельных email-адресов).

Как технически работает обратное преобразование на DNS-серверах?

Практика

Как я могу назначить несколько имён на мой IP-адрес, если различные домены размещены на моём сервере?

Это невозможно. Только одно имя назначается на каждый IP-адрес.

Более того, неважно какие обратные зоны прописаны для сервера. Для обращения к сайту браузеру достаточно провести лишь прямое преобразование (Имя --> IP). Здесь, конечно, может быть несколько имён, например несколько записей типа A или несколько записей типа CNAME, которые указывают на A-запись.

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

Если несколько доменов управляются через IP-адрес (достаточно частый случай), можно использовать нейтральное имя, не связанное с доменами пользователей. Спам-фильтры всего-лишь проверяют соответствует ли обратная DNS-запись имени в ответе на команду HELO. Это никак не влияет на доменные имена и почтовые адреса в передаваемых письмах.

• Обратная DNS-запись должна соответствовать имени почтового сервера или строиться на основании IP-адреса.
• Обратная DNS-запись должна также резолвиться "вперёд" - на тот-же IP-адрес.
• Обратная DNS-запись не должна быть похожа на автоматические-сгенерированную, например "162-105-133-213-static.hetzner.de", так так часто такие имена отрицательно оцениваются спам-фильтрами.
• Даваемое имя должно существовать. Пожалуйста, не используйте несуществующие доменные имена.

Пример хорошей записи:

Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.grossefirma.de ESMTP ready

Я задаю PTR на моём DNS-сервере. Почему это не работает?

Ваш DNS-сервер отвечает лишь за прямое преобразование.

Владелец блока IP-адресов (например, Hetzner Online GmbH) является ответственным за поддержание авторитативных DNS-серверов для обратных записей.

Обратные DNS-записи можно создавать только при помощи соответствующей функции панели Robot (левое меню -> "Servers" -> щелчок по серверу -> "IPs" -> щелчок по текстовому полю рядом с IP-адресом).

Обратная запись для моего сервера отличается от HELO моего почтового сервер. Является ли это проблемой?

Пример: обратная DNS-запись для IP-адреса сервера "www.grossefirma.de". В ответ на команду HELO почтовый сервер отвечает "mail.grossefirma.de".

Некоторые спам-фильтры расценивают письма от таких отправителей как "спам". Подобные несоответствия должны быть исправлены. Обратная DNS-запись и имя почтового сервера должны быть одинаковыми. В примере выше они могут быть, например, "srv01.grossefirma.de". Имя "www.grossefirma.de" может быть безо всяких последствий перенаправлено на srv01.grossefirma.de" при помощи CNAME-записи.

Подробное тестирование DNS-записей можно провести воспользовавшись