Федеральное агентство по образованию

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

Национальный исследовательский ядерный университет «МИФИ»

КАФЕДРА № 26

Электронные измерительные системы

Р Е Ф Е Р А Т

по теме "Система доменных имен Internet"

Выполнила:

Рудых В.К.

Группа А9-08

Проверил

Никитин А.М.

Москва, 2012

Оглавление

Введение.............................................................................................................................................3

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

Создание и регистрация доменов.....................................................................................................6

Система имен BIND...........................................................................................................................6

Принцип работы DNS-сервера..........................................................................................................7

База данных DNS................................................................................................................................9

Проблемы безопасности DNS-службы...........................................................................................16

Способы решения проблем безопасности DNS-службы..............................................................19

Пример практической реализации DNS.........................................................................................20

Список литературы..........................................................................................................................25

Введение

Для обращения к хостам в сети Internet используются 32-разрядные IP-адреса, однозначно идентифицирующие любой сетевой компьютер в этой сети. Однако для пользователей применение IP-адресов при обращении к хостам не удобно. Поэтому была создана система преобразования имен, позволяющая компьютеру в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от DNS-сервера, ip-адрес которого хранится в настройках подключения к Internet.

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

Для реализации системы DNS был создан специальный сетевой протокол DNS. В сети имеются специальные выделенные информационно-поисковые серверы - DNS-серверы.

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

Систему доменных имен формально описал Пол Мокапетрис (Paul Mocka-petris). В 1987 году ее откорректировали, а в 1990 г. расширили. Пол, кроме того, написал первую нe-UNIX-версию.

Работа по переносу DNS в UNIX была начата в 1984 г. четырьмя старшекурсниками университета в Беркли: Дугласом Терри (Douglas Terry), Марком Пойнтером (Mark Painter), Дэвидом Ригглом (David Riggle) и Сонг Ньян Чжоу (Songnian Zhou). Эстафету подхватил Ральф Кэмпбелл (Ralph Camp-bell) из Computer Systems Research Group, который начал "склеивать" доменную систему имен в BSD-UNIX. В 1985 г. Кевин Данлэп (Kevin Dunlap), инженер DEC, временно работавший в Беркли, принял этот проект в свои руки и создал систему BIND (Berkeley Internet Name Domain — систему доменных Internet-имен реализации Беркли). Майк Кареле (Mike Karels) и Пол Викси (Paul Vixie) сопровождали эту систему в течение ряда лет. Пол продолжает вести ее и сейчас, пользуясь помощью участников телеконференции isc.org и членов списка рассылки bind-workers.

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

Пример имени хоста в доменной нотации имеет вид, представленный на рис.1.

Рис. 1. Компоненты имени домена

Пространство имен DNS имеет вид дерева доменов с полномочиями, возрастающими по мере приближения к корню дерева.

По историческим причинам существует два вида имен доменов верхнего уровня. В США домены верхнего уровня отражают организационно-политическую структуру и, как правило, имеют трехбуквенные имена. Для доменов вне США используются двухбуквенные коды стран ISO. Оба эти принципа сосуществуют в одном глобальном пространстве имен.

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

Таблица № 1. Примеры общих доменов верхнего уровня

Домен	Назначение	Примечания
.biz	бизнес	Это открытый ДВУ. Любое физическое или юридическое лицо имеет право зарегистрироваться, однако регистрация в дальнейшем может быть оспорена, если это лицо не занимается коммерческой деятельностью в соответствии с уставом домена. ДВУ был создан для облегчения ситуации с доменом.com, который стал невероятно популярным и испытывал большие затруднения.
.com	коммерция	Это открытый ДВУ. Любое физическое или юридическое лицо имеет право зарегистрироваться. Хотя первоначально он предназначался для некоммерческих субъектов хозяйственной деятельности, по ряду причин он стал «главным» ДВУ доменных имен и в настоящее время используется любыми типами организаций, включая школы, частные лица и другие некоммерческие организации. Зарегистрированному доменному имени может быть заявлен отвод, если владелец не сможет доказать, что имя было зарезервировано без цели перепродажи.
.edu	образование	ДВУ.edu предназначен для образовательных учреждений, включая начальные и средние школы, колледжи и университеты. В 2001 году США ограничили его использование высшими учебными заведениями, аккредитованными признанными национальными агентствами из специального списка по аккредитации, поддерживаемого Министерством образования США. Поэтому этот домен почти исключительно используется колледжами и университетами США.
.info	информация	Это открытый ДВУ. Любое физическое или юридическое лицо имеет право зарегистрироваться.
.int	международные организации	ДВУ.int строго ограничен для организаций, ведомств и программ, которые подтверждены договором между двумя или более странами.
.mil	армия США	Домен.mil ограничен для применения только армией США.
.net	сети	Это открытый ДВУ. Любое физическое или юридическое лицо имеет право зарегистрироваться. Первоначально предназначался для использования доменами, относящимися к распределённой сети компьютеров, т. е. быть «зонтиком» или порталом для других более мелких веб-сайтов.
.org	организации	Это открытый ДВУ. Любое физическое или юридическое лицо имеет право зарегистрироваться. Первоначально предназначенный для использования некоммерческими организациями, он до сих пор используется в основном для той же цели.

Таблица № 2. Примеры национальных доменов верхнего уровня

Код	Страна
.AU	Австралия
.HU	Венгрия
.DE	Германия
.DK	Дания
.СА	Канада
.MX	Мексика
.RU	Россия
.UA	Украина
.FI	Финляндия
.FR	Франция
.СН	Швейцария
.SE	Швеция
.JP	Япония

В именах доменов не учитывается регистр. В контексте DNS Perm идентично perm и PERM. Реализации DNS должны игнорировать регистр при сравнениях, но обязаны распространять его, если он указан.

Internet-машина обычно входит в один домен, а может входить в несколько или ни в один.

Домен третьего уровня обычно представляет собой имя конкретной машины. Например, lab10.icmm.ru — полностью определенное имя машины lab10, находящейся в ИМСС. Другие организации могут использовать имя lab10, не испрашивая на то разрешения, потому что полностью определенные имена их машин все равно будут другими.

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

DNS - это иерархическая система имен (иерархическое пространство имен). Единицей измерения этого пространства является домен. Структура дерева имен показана на рис. 2.

Рис. 2. Фрагмент пространства имен DNS

Доменами второго уровня централизованно управляет Информационный центр сети (Network Information Center, NIC).

Использование некоторых имен запрещено. Это относится к уже взятым именам, ключевому слову AT, комбинациям имен доменов верхнего уровня (например, edu.com) и повторениям имен (например, х.х.соm). Например, xinet.xinet.com — допустимое имя, но имя домена — просто xinet.com, а в нем есть машина xinet.

Создание и регистрация доменов

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

1) выбор имени, уникального для данного поддомена;

2) назначение двух или более машин серверами нового домена;

3) согласование всего сделанного с администратором родительского домена.

Каждый новый домен определяет ветвь иерархии имен (см. рис. 1,2).

В Европе заявления о предоставлении доменных имен принимает организация Reseaux IP Europeens (RIPE, http://mcsun.eu.net). Бланки заявлений в Европе, Японии и остальной Азии можно получить все с того же узла http://rs.intemic.net/. Обработка заявления занимает около двух недель. Регистрация доменов второго уровня домена.ru производится по адресу http://www.ripn.net/.

Система имен BIND

BIND (Berkeley Internet Name Domain) - открытая и наиболее распространённая реализация DNS-сервера, обеспечивающая выполнение преобразования DNS-имени в IP-адрес и наоборот. BIND поддерживается организацией Internet Systems Consortium.

В систему BIND входят три компонента:

1) Демон named, который отвечает на запросы;

2) Библиотечные подпрограммы, которые отвечают на запросы машин, используя DNS;

3) Командные интерфейсы пользователь-DNS: nslookup, dig, host.

Согласно терминологии, принятой в DNS, демон типа named (или машина, на которой он работает) называется сервером имен, а программа-клиент, которая обращается к нему - определителем.

Демон named отвечает на запросы об именах машин и их IP-адресах. Если named не знает ответа на какой-либо запрос, он опрашивает другие серверы и помещает их ответы в кэш (рис 3). Этот демон, кроме того, отвечает за выполнение зонных пересылок, обеспечивающих копирование данных между серверами одного домена.

Рис. 3. Взаимодействие серверов DNS

Серверы имен работают по каждому домену в одном из трех режимов: основном, вспомогательном и кэширующем. Режимы отличаются друг от друга двумя характеристиками: откуда поступают данные и авторитетен ли сервер для данного домена. (Зона - это домен за вычетом своих поддоменов. Серверы имен работают именно с зонами, но часто говорится "домен", хотя подразумевается "зона".)

В каждом домене и поддомене есть один основной сервер имен. Основной сервер имен хранит на диске оригинал базы данных домена.

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

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

Принцип работы DNS-сервера

Для преобразования имен машин в IP-адреса программы прикладного уровня, такие как Netscape Navigator, вызывают подпрограмму gethostbyname. Если конфигурация машины предполагает использование DNS, gethostbyname запрашивает адрес у сервера имен, ip-адрес которого указан в настройках подключения к Internet.

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

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

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

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

Отсылки генерируются на иерархической основе. Если сервер, например, не сможет дать адрес машины vtau-bsd.pstu.ac.ru, он последовательно обратится к серверам домена pstu.ac.ru, ac.ru, ru и корневого домена. Отсылка должна включать адреса серверов домена, на который она указывает, поэтому выбор — не произвольный; сервер должен ссылаться на тот домен, серверы которого ему уже известны. Как правило, выдается наиболее полный из известных доменов. В нашем примере был бы выдан домен pstu.ac.ru (если это возможно).

Рассмотрим на примере, при попытке посетить сайт кафедры экономической кибернетики ПГУ (адрес машины keks.econ.psu.ru) с машины vtau-bsd.pstu.ac.ru. Машина vtau-bsd просит выяснить ответ на этот вопрос свой локальный сервер имен, ns.pstu.ac.ru. Последующие события показаны на рис. 4.

Рис. 4. Процесс обработки запроса в DNS

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

Локальный сервер имен ответа на запрос не знает. Более того, он не знает ничего ни о cs.psu.ru, ни о psu.ru. Он знает некоторые серверы домена ru и, будучи рекурсивным, спрашивает ru о машине keks.econ.psu.ru.

Доменом ru управляют нерекурсивные серверы имен, поэтому вместо сообщения запрошенного адреса локальному серверу передаются адреса серверов домена psu.ru. Локальный сервер посылает запрос о машине keks серверу домена psu.ru.

Сервер ПГУ не знает ответа, но, будучи рекурсивным, направляет этот запрос серверу домена econ.psu.ru. Этот сервер авторитетен по запрашиваемой информации и возвращает адрес машины keks. Сервер домена psu.ru кэширует этот адрес и возвращает его серверу ns.pstu.ac.ru.

В итоге, имеют место следующие операции:

1) ns.pstu.ac.ru кэшировал адрес машины keks;

2) ns.pstu.ac.ru кэшировал данные о серверах домена psu.ru;

3) сервер домена psu.ru кэшировал адрес машины keks.

Запросы демона named используют протокол UDP и порт 53. Если объем ответов превышает 512 байтов, то для их доставки используется протокол TCP. В зонных пересылках между серверами также применяется протокол TCP.

База данных DNS

База данных доменной системы имен DNS для каждого домена представляет собой набор текстовых файлов, которые системный администратор ведет на основном сервере имен этого домена. Элементы базы данных называются записями о ресурсах; иногда их сокращенно обозначают PR. Типы и форматы записей о ресурсах регламентируются документами RFC882, 1035 и 1183.

Базовый формат записи о ресурсах:

[имя] [время] [класс] тип данные

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

Таблица №3. Специальные символы записей о ресурсах

Символ	Значение
;	Ввод комментария
#	Ввод комментария (версия BIND 4.9)
@	Имя текущего домена
()	Позволяет данным занимать несколько строк
*	Метасимвол (только в поле "Имя")

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

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

В поле класс задается тип сети. Распознаются три значения: IN (Internet), СН (ChaosNet), HS (Hesiod). ChaosNet — устаревшая сеть, в которой раньше работали Lisp-машины фирмы Symbolics. Hesiod — это служба базы данных, являющаяся надстройкой системы BIND; пока она используется не слишком широко, но постепенно завоевывает популярность как замена NIS. Значением класса по умолчанию является IN.

Существуют записи трех различных типов:

1) Зонные записи: определяют домены и их серверы имен;

2) Базовые записи: преобразовывают имена в адреса и наоборот, обеспечивают маршрутизацию почты;

3) Факультативные записи: содержат дополнительную информацию о машинах.

Содержимое поля "Данные" зависит от типа записи (см. табл. 4).

Таблица №4. Основные типы записи

Тип записи	Подтип	Имя	Функции
Зонные	SOA	Начало полномочии	Определяет DNS-зону полномочий
NS	Сервер имен	Определяет серверы для зоны
Базовые	А	Адрес	Преобразование имени в адрес
PTR	Указатель	Преобразование адреса в имя
MX	Почтовая станция	Управляет маршрутизацией электронной почты
Факультативные	CNAME	Каноническое имя	Мнемонические имена машины
HINFO	Информация о машине	Описание аппаратных средств и операционной системы
RP	Ответственный	Технический специалист, отвечающий за машину
WKS	Известные услуги	Услуги, которые предоставляет машина
TXT	Текст	Комментарии или нестандартная информация

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

Запись SOA отмечает начало зоны - группы записей о ресурсах, расположенных в одной области пространства имен DNS. Домен DNS обычно соответствует минимум двум зонам; одна служит для преобразования имен машин в IP-адреса, а остальные - для обратного преобразования.

Для каждой зоны делается всего одна запись SOA; зона продолжается до тех пор, пока не появляется следующая запись SOA. Запись SOA содержит имя зоны, адреса, необходимые для установления технических контактов, различные значения тайм-аутов. Эта запись должна быть первой записью зоны. Например:

;; AUTHORITY RECORDS:

ccl.ru. 3600 IN SOA ns.ccl.ru. hostmaster.perm.ru. (

2000102401; serial

10800; refresh (3 hours)

3600; retry (1 hour)

2592000; expire (30 days)

3600); minimum (1 hour)

Поле "Имя" может содержать символ @, обозначающий имя текущей зоны. В этом примере можно было вместо ccl.ru использовать @.

Поле "Время" отсутствует. Класс - IN (Internet), тип — SOA, а остальные элементы составляют поле "Данные".

Сервер ns.ccl.ru — основной сервер имен этой зоны.

Запись hostmaster.perm.ru. указывает адрес электронной почты для технических контактов в формате "пользователь.машина", (а не "пользователь@машина"). Если необходимо отправить почту администратору домена, нужно просто заменить первую точку знаком @ и убрать последнюю точку.

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

Последовательные номера не обязательно должны быть непрерывными, но должны монотонно возрастать. Если Вы случайно задали на основном сервере очень большое число и оно передается вспомогательным серверам, то исправить порядковый номер на основном сервере не удастся. Вспомогательные серверы будут запрашивать новые данные только в том случае, если порядковый номер записи SOA основного сервера больше порядковых номеров записей, хранимых вспомогательными серверами (формальное ограничение на величину порядкового номера только одно: число справа от десятичной точки должно быть меньше 9999.).

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

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

Если вспомогательный сервер пытается проверить порядковый номер основного, а тот не отвечает, вспомогательный сервер сделает повторную попытку по истечении периода времени, заданного тайм-аутом retry. Обычно нормальное значение для данного параметра — от 20 до 60 минут (1200 — 3600 секунд).

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

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

Записи NS описывают серверы, которые авторитетны для данной зоны. Обычно эти записи следуют за записью SOA. Запись NS имеет следующий формат:

зона [время] [класс] NS имя_машины

Например:

ccl.ru 3600 IN NS ns.ccl.ru

ccl.ru 3600 IN NS ns.ussr.eu.net

ccl.ru 3600 IN NS ns.spb.su

Поскольку имя зоны здесь совпадает с указанным в поле имя записи SOA, которая идет перед записями NS, поле "Зона" можно оставить пустым. Поэтому строки

IN NS ns.ccl.ru

IN NS ns.ussr.eu.net

IN NS ns.spb.su

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

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

Записи А — обеспечивают перевод имен машин в IP-адреса, ранее заданные в файле /etc/hosts. Для каждого из сетевых интерфейсов машины должна быть сделана одна запись А. Эта запись имеет следующий формат:

имя_машины [время] [класс] А ip-адрес

Например:

lab10.icmm.ru 85640 IN A 62.76.204.162

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

Полностью определенные имена машин можно рассматривать как структуру, в которой "старший бит" стоит справа. Например, в имени

vtau.pstu.ac.ru

vtau находится в pstu, pstu находится в ac, a ac — в ru. С другой стороны, в IP-адресах "старший бит" стоит слева:

195.19.161.194

Машина 194 находится в сети 195.19.161.

Специальный домен верхнего уровня IN-ADDR.ARPA был создан для того, чтобы и для преобразования IP-адресов в имена машин, и для преобразования имен в IP-адреса использовался один и тот же набор программных модулей. Поддомены этого домена именуются как IP-адреса с байтами, расставленными в обратном порядке. Например, зона для cети 195.19.161 составлена следующим образом (см. рис. 5):

Рис. 5. Компонены зон в IN-ADDR.ARPA

На рис. 5 компонент 161.19.195 (представляющий сеть класса C) отмечен как одна зона. Зоны с именем 195.IN-ADDR.ARPA нет. Это противоречит сказанному выше, но этот случай является исключением.

Необходимо, чтобы запросы об адресах под 195.IN-ADDR.ARPA выдавали результаты, имеющие смысл.

Если сделать на всех серверах зоны IN-ADDR.ARPA записи NS о 161.19.195.IN-ADDR.ARPA, то надобность в промежуточной зоне (195.IN-ADDR.ARPA) исчезнет. Ссылки на ее поддомены будут обрабатываться таким образом, чтобы возвращался самый подробный адрес сервера, о котором у данного сервера есть запись NS.

Общий формат записи PTR таков:

адрес [время] [класс] PTR имя_машины

Запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины vtau, будет иметь такой вид:

194.161.19.195 IN PTR vtau.pstu.ac.ru.

Имя 194.161.19.195 не заканчивается точкой и поэтому является относительным. Для того чтобы эта запись была точной, домен по умолчанию должен называться "IN-ADDR.ARPA.".

Этого можно добиться либо поместив записи PTR в отдельный файл, в котором домен по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN.

Если домен по умолчанию определен как 161.19.195.IN-ADDR.ARPA., то запись можно представить так:

194 IN PTR vtau.pstu.ac.ru.

Поскольку pstu.ac.ru и 161.19.195.IN-ADDR.ARPA — разные области пространства имен DNS, они составляют две отдельные зоны. У каждой из этих зон должна быть своя запись SOA и свои записи о ресурсах. Помимо определения зоны IN-ADDR.ARPA для каждой реальной сети нужно определить зону, которая отвечала бы за закольцовывающую сеть, 127.0.0.

Файлы, содержащие записи PTR, в больших организациях часто строятся по подсетям. При этом домен по умолчанию включает лишь часть сетевого адреса, которая является обшей для всех подсетей (такое возможно лишь в том случае, если подсети разбиты по границе байта). В приведенном выше примере домен по умолчанию включает полный адрес подсети. Имя машины vtau должно быть полностью определенным, чтобы к нему не добавился домен 161.19.195.IN-ADDR.ARPA.

Обратные соответствия, содержащиеся в записях PTR в домене IN-ADDR.ARPA, используются всеми программами, которые аутентифицируют входящий сетевой трафик. Например, удаленная регистрация без пароля допускается, если исходная машина указана по имени в пользовательском файле ~/.rhosts. Когда машина-адресат получает запрос на установление соединения, она знает только IP-адрес машины-отправителя. Пользуясь услугами DNS, она преобразовывает IP-адрес в имя, которое сравнивается с соответствующим файлом. Программы natstat, sendmail, X Window, syslog, finger, ftp, rlogind — все они получают имена машин из IP-адресов с помощью обратного преобразования.

Важно, чтобы записи А соответствовали записям PTR. Несовпадение и отсутствие последних приводит к тайм-аутам, в результате чего система теряет в быстродействии.

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

Запись MX имеет следующий формат:

имя [время] [класс] MX приоритет машина...

Например:

mail.ccl.ru IN MX 10 gw1.ccl.ru

IN MX 40 gw4.ccl.ru

Записи MX используются во многих ситуациях, например:

1) если есть почтовый сервер;

2) если машина-адресат может быть выключена;

3) если адресат не подключен к Internet.

У самого домена должна быть запись MX для почтового сервера, чтобы можно было посылать почту по схеме пользователь@домен. Это все равно требует наличия уникальных пользовательских имен на машинах данного домена. Например, чтобы иметь возможность посылать почту пользователю [e-mail], нам нужна либо машина mail, либо запись MX в домене ccl.ru:

mail IN MX 10 gw1.ccl.ru

IN MX 40 gw4.ccl.ru

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

ftp IN CNAME anchor

kb IN CNAME kibblesnbits

Запись CNAME имеет следующий формат:

мнемоимя [время] [класс] CNAME имя_машины

Если у машины есть запись CNAME, которая содержит ее мнемонические имена, другие записи для данной машины должны ссылаться на ее реальное имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME, они останавливают свои запросы по мнемоническому имени и переключаются на реальное имя (Мнемоимена полезны, например, в случае, когда имя машины изменилось и вы хотите разрешить пользователям, знающим старое имя, получить доступ к машине).

В записи HINFO указываются изготовитель и модель компьютера, а также операционная система, которую он использует. Многие организации эти записи не ведут по соображениям безопасности. Если человек, имеющий доступ к Internet, сможет выяснить тип компьютера и версию операционной системы, система станет более уязвимой для взлома. Запись HINFO имеет следующий формат:

имя [время] [класс] HINFO тип_машины ос

Например, запись

anchor IN HINFO "sparc10" "sunos 4.1.3"

показывает, что anchor — это машина Sun Sparcstation 10, работающая в SunOS 4.1.3. Если данные состоят из одного слова, то кавычки не нужны; кавычки "защищают" встроенные пробелы. Можно использовать любые строковые данные. Рекомендуемые значения перечислены в RFC1340.

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

имя [время] [класс] WKS [адрес] протокол программы

Например:

anchor IN WKS TCP telnet smtp ftp

Поле "Адрес" (IP-адрес) обычно опускают.

Существует несколько записей, которые предназначены специально для содействия в маршрутизации почты, особенно при направлении почты группе получателей. Запись MB (Mail Box) задает машину, на которой находится почтовый ящик адресата, запись MG (Mail Group Member) определяет почтовую группу, а запись MR (Mail Rename Record) содержит новое имя почтового ящика. Одно время были записи MD и MF, но затем их заменили записями MX. Записи MINFO (Mailbox Information) обеспечивают управление списками рассылки.

Единственная широко используемая запись о ресурсах из вышеперечисленных — MX. Функциональные возможности, воплощенные в записях MG, MR и MINFO, можно реализовать с помощью файла aliases.

Запись ТХТ используется для добавления произвольного текста к DNS-записям машины. Например:

IN ТХТ "University of CO, Boulder Campus, CS Dept"

IN ТХТ WP-PH://directory.сolorado.edu/105

IN ТХТ WP-SMTP-EXPN-Finger://ns.cs.сolorado.edu

Запись ТХТ имеет такой формат:

имя [время] [класс] ТХТ информация

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

К новым типам записей относятся:

AFSDB	Это NS-запись для файловой системы Andrew (AFS), разработанной в университете Карнеги-Меллон (CMU) и продаваемой фирмой TransArc, и для уполномоченного сервера базы данных распределенной вычислительной среды (Distributed Computing Environment, DCE). Формат этой записи похож на формат записи MX, при этом поле приоритета используется для задания AFS или DCE.
ISDN	Поле ISDN содержит ISDN-адрес, который, по сути дела, является замаскированным номером телефона.
Х.25	Эта запись содержит адрес, заданный в соответствии со стандартом Х.25.
RT	Запись RT (Route Through — "Сквозная маршрутизация") предназначена для выдачи подсказок о том, как достичь конкретной машины или домена по сети ISDN или Х.25. Эти записи похожи на записи MX и указывают на промежуточные машины, которые направляют пакеты на машину-адресат по нe-Internet-овским каналам.
RP	Запись RP содержит адрес электронной почты (в котором знак @ заменен точкой) лица, ответственного за машину или домен, и псевдоимя записи ТХТ, которым можно пользоваться для получения дополнительной информации (например, номера телефона или полного имени).

Администратор DNS, указанный в записи SOA, отвечает за весь домен; записи RP позволяют конкретизировать задачу и обеспечивают включение другой полезной информации, а не только адреса электронной почты.

Проблемы безопасности DNS-службы

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

1) Удаленные атаки на DNS-сервер:

а) удаленная атака – “Ложный объект РВС” (распределенной вычислительной системы), т.е. внедрение пpомежуточного хоста, чеpез котоpый будет идти поток инфоpмации между атакуемым объектом и сеpвеpом или подмена (исправление) информации о зоне;

б) межсегментная удаленная атака - атака на DNS путем фальсификации ответа DNS – сервера;

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

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

1) “Шторм” ложных ответов DNS (рис.6)

Рис. 6. “Шторм” ложных ответов

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

2) Перехват запроса DNS

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

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

3) Межсегментная удаленная атака на DNS-сервер

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

Рис. 7. Межсегментная удаленная атака

Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является "подмена" IP-адреса web-сервера www.coolsite.com на IP-адрес сервера www.badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации о IP-адресе www.coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен coolsite.com. В ложном ответе вместо реального IP-адреса www.coolsite. com указывается IP-адрес www.badsite.com. Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера www.coolsite.com попадают на www.badsite.com (рис. 7).

Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырех условий:

1) IP адрес отправителя ответа должен соответствовать IP-адресу запрашиваемого сервера (в данном случае ns.coolsite.com);

2) UDP-порт, на который направляется ответ, должен совпадать с портом, с которого был послан запрос;

3) Идентификатор ответа должен совпадать с идентификатором запроса;

4) Ответ должен содержать запрашиваемую информацию (в данном случае IP-адрес web-сервера www.coolsite.com).

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

4) Ошибочные действия администратора DNS-сервера

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

Способы решения проблем безопасности DNS-службы

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

Рис 8. Структура защищаемого сегмента

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

Так же можно предложить использовать комплект приложений BIND (Berkley Internet Name Daemon) – берклевский демон имен Internet. Начиная с версии 4.9.3 в спецификацию BIND было внесено несколько директив и типов записей DNS, которые призваны несколько улучшить защиту серверов имен. Директива xfrnets файла начальной загрузки (/etc/named.boot) позволяет указать список IP-адресов сетей и серверов имен, на которые данный сервер имеет право пересылать информацию по зоне (операция зонной пересылки). Второе важное новшество - введение особого типа записи ресурсов TXT под названием SECURE_ZONE. Такая запись управляет перечнем машин и сетей (по IP-адресам), которым разрешено запрашивать данный сервер имен. Но несмотря на эти нововведения для отражения атак с подменой DNS требуется принять еще ряд мер. Среди них наиболее распространенной является установка двух серверов DNS: внешнего и внутреннего (см. рис. 8).

Внутренний сервер DNS предназначен исключительно для обслуживания внутренних клиентов сети. На нем хранится вся информация о хостах корпоративной сети. Благодаря использованию записей типа SECURE_ZONE этот сервер могут запрашивать только внутренние хосты. Более того, на брандмауэре устанавливается фильтр, который не пропускает IP-пакеты, направляемые в корпоративную сеть и предназначенные для порта 53 протоколов UDP и TCP внутреннего сервера DNS. Т. е. снаружи такой сервер DNS делается невидимым. Однако он сам может обращаться за информацией к серверам DNS сети Internet

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

Пример практической реализации DNS

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

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

Исходя из следующих предпосылок, приводится дальнейшее описание: клиент с сервером обращаются по протоколу UDP, где клиентом является OS Windows. Операционные системы от Microsoft работают с небольшими отличиями от стандартной схемы - это незаметно для пользователя, но важно для администратора. Это связано с ориентировкой на работу в рамках доменов. Каждый компьютер имеет имя и принадлежит определенному домену (рис. 9).

Рис. 9. Полное имя ресурса computer.office.acme.com.

Когда возникает необходимость в разрешении имени, работает следующая схема:

Нам надо узнать IP адрес сайта "www.yahoo.com" (без точки в конце). Компьютер клиента автоматически добавит имя домена, к которому принадлежит компьютер, т.е. на самом деле DNS запрос будет содержать имя: "www.yahoo.com.office.acme.com.".

Корпоративный сервер, ответственный за зону office.acme.com, не сможет найти ответ и возвратит клиенту ошибку, после чего сразу переспросит сервер "www.yahoo.com.". Сервер уже сможет обработать этот запрос и дать нужный или нужные IP адреса.

Для того, чтобы сервер не прибавлял суффикс достаточно в конце имени добавить точку. Кроме того, если запрос не содержит точки, например "user1", то выполняется добавление суффикса, а без него запроса не последует.

В настройках TCP/IP можно указать дополнительные суффиксы.

Стоит заметить, что полное имя ресурса должно заканчиваться точкой (www.yahoo.com.), но это правило только для пользователей, в самих сетевых пакетах финальная точка в явном виде отсутствует.

Общий формат пакета одинаков и для запросов, и для ответов.

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

Сервер должен скопировать идентификатор в ответ, без этого пакет просто будет отброшен клиентом.

Следующие два байта это флаги.

Таблица № 5. Идентификатор пакета

Поле	Кол-во бит
Тип сообщения
Код операции
Авторитетный ответ
Фрагментация
Требование рекурсии
Возможность рекурсии
Нулевое поле
Код возврата

Тип сообщения: 0 - запрос клиента, 1 - ответ сервера. Код операции: это ноль для обычного запроса и 1 для инверсного. Авторитетный ответ устанавливается сервером, ответственным за зону. Фрагментация устанавливается, если информация не уместилась в 512 байт. Требование рекурсии, как правило, всегда установлено, что переносит всю ответственность за разрешение с клиента на сервер. Возможность рекурсии устанавливается сервером в ответе. Код возврата ноль в случае успеха и 3 при ошибке имени.

Остальные варианты опций описаны в RFC 1035, но для реализации простой схемы диалога сервера с клиентом они не требуются.

Далее следуют четыре 2х байтовых поля, которые содержат количество значений в полях с переменными длинами. Вместе с байтами идентификации и флагами они составляют заголовок DNS пакета:

- идентификация;

- флаги;

- количество запросов;

- количество ответов;

- количество прав доступа;

- количество дополнительной информации.

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

Обе секции (запросы и ответы) имеют одинаковое начало: переменное количество байт, отведенное на имя, два байта на тип, и два - на класс. Класс будет всегда единицей. Типы - A, NS, MX, CNAME и т.д. Например, для типа A поле будет установлено в единицу, а для MX - 15. Для запросов и ответов имя кодируется одинаково. Все символы представляются своими ASCII кодами за исключением точек. Точки разделяют имя на части, а сами заменяются длинами этих частей. Для примера: www.yahoo.com. будет представлено в виде последовательности байт: 3www5yahoo3com0 - буквы представляются кодами.

При этом финальный ноль является обязательным, т.к. является маркером конца имени.

Теперь у нас есть достаточно информации, чтобы составить клиентский пакет, который запрашивает IP адрес хоста "aaa."

byte[] question={2,34,1,0,0,1,0,0,0,0,0,0,3,97,97,97,0,0,1,0,1};

2,34 - это идентификаторы, выбранные случайным образом

За ними следуют два байта флагов, которые сообщают о том, что это стандартный запрос, требующий рекурсию.

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

Такую же последовательность, за исключением идентификатора, можно увидеть сетевым монитором, сформировав запрос "aaa" с помощью утилиты nslookup.

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

//получение текста имени из запросаint i=12;String s="";String QUESTION; while (data[i]>0) { if (s.length()>0) {s+=".";} if ((data[i]+i+1)>=len) {s="";break;} s += new String(data, i+1, data[i]); i+=data[i]+1; }QUESTION = s;

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

Секция ответа состоит из полей имени ресурса, типа и класса, описанных выше. При этом их содержание можно полностью скопировать из запроса. За ними следуют четыре байта поля TTL (time-to-live), содержащее количество секунд, на которое можно кэшировать запрос (заполняем нулями). Следующие два байта - это длина данных ресурса, и сами ресурсы. В ресурс помещается информация об ответе. Как указывается в RFC 1035, она зависит от типа запроса, но в нашем случае это будут четыре байта под IP адрес.

Приведем пример ответа на предыдущий запрос:

byte[] reply={2,34,133,128,0,0,0,1,0,0,0,0,3,97,97,97,0,0,1,0,1,0,0,0,0,0,4,5,6,7,8};

Тут количество запросов - ноль, ответов - один. И ответ устанавливает соответствие имени хоста "aaa." с IP адресом 5.6.7.8 и TTL равным 0.

Стоит обратить внимание на флаги: 133 - авторитетный ответ, 128 - сервер поддерживает рекурсию.

Далее приведен код сервера, который принимает DNS пакет и генерирует ответ. При этом вне зависимости оттого, что спросит клиент, ответ будет содержать "aaa" и IP адрес 5.6.7.8

После компиляции проверить это можно при помощи утилиты nslookup

import java.net.*;import java.io.*; class udptest { public static void main(String arg[]){byte id1,id2,flags;int qtype; try { byte[] buffer = new byte[512]; DatagramPacket incoming = new DatagramPacket(buffer, buffer.length); DatagramSocket ds = new DatagramSocket(53); ds.receive(incoming); byte[] data = incoming.getData(); id1=data[0]; id2=data[1];int i=12;String s=""; while (data[i]>0) { if (s.length()>0) {s+=".";} s += new String(data, i+1, data[i]); i+=data[i]+1; }i++;byte[] reply={0,0,0,0,0,0,0,1,0,0,0,0,3,97,97,97,0,0,1,0,1,0,0,0,0,0,4,5,6,7,8};reply[0]=id1;reply[1]=id2;reply[2]=0&133;reply[3]=0; DatagramPacket out = new DatagramPacket(reply,reply.length, incoming.getAddress(), incoming.getPort()); ds.send(out);}catch (IOException e) {System.err.println(e);}}//main }//class

Список литературы

1. Крутиков М. П., Слок Е. А. "Сетевые службы INTERNET".

2. Виктор и Наталья Олифер "Введение в IP-сети".

3. П. Б. Храмцов, С.А. Брик, А.М. Русак, А.И. Сурин "Основы Web-технологий. Учебное пособие."

4. http://citforum.ru/internet/dns/ - подборка статей о DNS.

5. http://a-nomalia.narod.ru/rInform/155.htm

6. http://www.hardline.ru/4/49/1404/

Дата добавления: 2015-08-28