К новым типам записей относятся: 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 позволяют конкретизировать задачу и обеспечивают включение другой полезной информации, а не только адреса электронной почты. 5. Проблемы функционирования DNS-службы Вспомним DNS-алгоритм удаленного поиска IP-адреса по имени в Сети: ·хост посылает на IP-адрес DNS-сервера своего домена (он задается при настpойке пpотокола IP в сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти; ·DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней содержащегося в запросе имени. В случае, если имя найдено, а следовательно, найден и соответствующий ему IP-адрес, на запросивший хост DNS-сервер отправляет DNS-ответ, в котором записан искомый IP-адрес. Если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера root.cache, и описанная в этом пункте процедура повторяется, пока имя не будет найдено. Анализируя с точки зрения безопасности уязвимость этой схемы удаленного поиска с помощью протокола DNS, можно сделать вывод о возможности некорректного функционирования DNS-сервиса, а именно можно выделить две основные причины неправильного функционирования: • удаленные атаки на DNS-сервер, а именно: удаленная атака – “Ложный объект РВС” (распределенной вычислительной системы), т.е. внедрение пpомежуточного хоста, чеpез котоpый будет идти поток инфоpмации между атакуемым объектом и сеpвеpом или подмена (исправление) информации о зоне; межсегментная удаленная атака - атака на DNS путем фальсификации ответа DNS – сервера; • ошибочные действия администратора DNS-сервера, т.е. неправильное указание соответствия между IP-адресом хоста и его именем. Удаленные атаки на DNS-сервера. Практические изыскания и критический анализ безопасности службы DNS позволяют предположить, что существуют, как минимум, два возможных варианта удаленной атаки с использованием ложного объекта на эту службу: “Шторм” ложных ответов DNS Рис. 6. “Шторм” ложных ответов Первый вариант проведения удаленной атаки, направленной на службу DNS, основан на разновидности типовой удаленной атаки "Ложный объект РВС" [2]. В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса. (Рис 6). Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Критерии, предъявляемые сетевой ОС хоста к полученному от DNS-сервера ответу, - это, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-сервера; во-вторых, необходимо, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе; в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос, и, в-четвертых, в DNS-ответе поле идентификатор запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе. Перехват запроса DNS Из рассмотренной ранее схемы удаленного DNS-поиска следует, что в том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache. Т. е. в том случае, если DNS-сервер не имеет сведений о запрашиваемом хосте, он пересылает запрос далее - это значит, что теперь сам DNS-сервер является инициатором удаленного DNS-поиска. Поэтому ничто не мешает атакующему, действуя описанными выше методами, перенести свой удар непосредственно на DNS-сервер [2]. Иначе говоря, в качестве цели атаки теперь будет выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер. При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера. Т. е. если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимая информация уже находится у него в памяти.