Очень приблизительно можно сказать, что у каждого компьютера в Интернете есть два основных идентификатора: доменное имя (например, systemadmins.ru) и IP-адрес (например, 127.0.0.1). Приблизительность заключается в том, что, во-первых, IP-адресов у компьютера может быть несколько (мало того, что у каждого интерфейса свой адрес, так еще и несколько адресов могут “висеть” на одном интерфейсе); во-вторых, имен тоже может быть несколько, причем они могут связываться как с одним, так и с несколькими IP-адресами; в-третьих, у компьютера может и не быть доменного имени… Словом, ясно, что картина уже начинает запутываться.

Как было сказано выше, основной задачей DNS-сервера является трансляция доменных имен в IP адреса и обратно. На заре становления Интернета (когда он еще был ARPANET’ом) это решалось ведением длинных списков, включающих все компьютеры сети, причем копия такого списка должна была присутствовать на каждом компьютере. Понятно, что с ростом сети эта технология перестала удовлетворять кого бы то ни было — ведь эти файлы надо было еще и синхронизировать, не говоря уж об их размере… Некоторые “пережитки” этого метода можно обнаружить и сейчас: существует файл HOSTS (и в UNIX, и в Windows), в котором можно прописывать адреса серверов, с которыми вы регулярно работаете (кстати, именно его использование лежит в основе многих “ускорителей Интернета” — такие программы просто записывают адреса серверов, к которым вы обращаетесь, в файл HOSTS и при следующем обращении берут данные из него, не тратя время на запрос к DNS-серверу).

На смену “однофайловой” схеме пришел DNS — иерархическая структура имен. Существует “корень дерева” с именем “.” (точка). Так как корень един для всех доменов, то точка в конце имени обычно не ставится (но она используется в описаниях DNS — тут надо быть очень внимательным!). Ниже корня лежат домены первого уровня. Их немного — com, net, edu, org, mil, int, biz, info, gov (есть еще несколько) и домены государств, например, ru. Еще ниже находятся домены второго уровня, например, systemadmins.ru. Еще ниже — третьего и т.д.

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

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

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

Полезным свойством DNS является умение использовать “пересыльщиков” (forwarders). “Честный” DNS-сервер самостоятельно опрашивает другие сервера и находит нужный ответ, но если ваша сеть подключена к Интернету по медленной (например, dial-up) линии, то этот процесс может занимать довольно много времени. Вместо этого можно перенаправлять все запросы, скажем, на сервер провайдера, а затем принимать его ответ. Использование “пересыльщиков” может оказаться интересным и для больших компаний с несколькими сетями: в каждой сети можно поставить относительно слабый DNS-сервер, указав в качестве “пересыльщика” более мощную машину, подключенную по быстрой линии. При этом все ответы будут кэшироваться на этом мощном сервере, что ускорит разрешение имен для целой сети.

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

Элементы базы DNS часто называют RR (сокращение от Resource Record). Базовый формат записи выглядит так:

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

Имя может быть относительным или абсолютным (FQDN — Fully Qualified Domain Name). Если имя относительное (не заканчивается точкой — помните про корневой домен?), то к нему автоматически добавляется имя текущего домена. Например, если в домене systemadmins.ru я опишу имя «www», то полное имя будет интерпретироваться как “www.systemadmins.ru.” Если же это имя указать как “www.systemadmins.ru” (без последней точки), то оно будет считаться относительным и будет интерпретировано как “www.systemadmins.ru.systemadmins.ru.”

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

класс определяет класс сети. Практически всегда это будет IN, обозначающее INternet.

Тип может быть одним из следующих:

SOA — определяет DNS зону
NS — сервер имен для зоны
A — преобразование имени в IP-адрес
PTR — преобразование IP-адреса в имя
MX — почтовая станция
CNAME — имена машины
HINFO — описание “железа” компьютера
TXT — комментарии или какая-то другая информация

Есть также некоторые другие типы, но они намного менее распространены.

В записях можно использовать символы # и ; для комментариев, @ для обозначения текущего домена, () — скобки — для написания данных на нескольких строках. Кроме того, можно использовать метасимвол * в имени. Порядок записей не имеет значения за одним исключением: запись SOA должна идти первой. Дальнейшие записи считаются относящимися к той же зоне, пока не встретится новая запись SOA. Как правило, после записи зоны указывают записи DNS-серверов, а остальные записи располагают по алфавиту, но это не обязательно.

Теперь попробуем рассмотреть записи. Первой описываем зону:

mycompany.ru. IN SOA ns.mycompany.ru. admin.mycompany.ru. (1001 ; serial 21600 ; Refresh — 6 часов 1800 ; Retry — 30 мин 1209600 ; Expire — 2 недели 432000) ; Minimum — 5 дней

Сначала идет имя домена: mycompany.ru. (обратите внимание на точку в конце имени). Вместо имени можно было (и чаще всего так и делают) поставить знак @.
ns.mycompany.ru. — основной сервер имен
admin.mycompany.ru. — почтовый адрес администратора в формате имя(точка)машина

затем в круглых скобках идут поля, необходимые для правильного “восприятия” вашей зоны другими серверами. Первое число — serial — является “версией” файла зоны. При внесении изменений это число надо увеличить — если вторичный сервер увидит, что его версия зоны меньше, чем у первичного сервера, то он перечитает данные. Типичной ошибкой является обновление зоны без обновления этого числа. Очень удобно в качестве serial использовать текущую дату, например, 2003040401 — 4 апреля 2003 года, первое обновление.
Refresh говорит вторичным серверам, как часто они должны проверять значение serial.

Retry говорит о том, как часто вторичный сервер должен пытаться прочитать данные, если первичный сервер не отвечает.

Expire говорит вторичным серверам, в течение какого времени они должны обслуживать домен, если первичный сервер не отвечает. По истечении этого времени вторичные сервера будут считать свои данные устаревшими.

Minimum задает время жизни записей по умолчанию для данной зоны.

Теперь опишем сервера имен, обслуживающие наш домен:mycompany.ru. IN NS ns.mycompany.ru.
mycompany.ru. IN NS ns.provider.ru.

Здесь ничего сложного нет. Так как имя зоны совпадает с указанным в поле имя записи SOA, то его можно оставить пустым.

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

major IN A 192.168.0.1 colonel IN A 192.168.0.2 IN HINFO “2xPIV-1.7 Win2K” general.mycompany.ru. IN A 192.168.0.3

Здесь сложного тоже ничего нет — имена могут быть относительные или “абсолютные”, можно добавить записи о конфигурации машины (пропущенное имя в записи HINFO говорит о том, что имеется в виду предыдущее имя). Не забудьте добавить записи

%. IN A 127.0.0.1 % IN CNAME %. mycompany.ru. IN A 192.168.0.1

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

C помощью CNAME можно задавать короткие имена серверов
Записи CNAME позволяют дать машинам удобные или значащие имена. Например:
ftp IN CNAME general говорит, что ftp.mycompany.ru живет по адресу 192.168.0.3. CNAME удобно использовать, если вы меняете имя машины, но хотите оставить доступ для клиентов, которые помнят старое имя. Удобный трюк с использованием CNAME заключается в назначении коротких имен частоиспользуемым адресам. Например, прописав ls IN CNAME systemadmins.ru., вы сможете заходить на systemadmins.ru просто набирая ls в качестве адреса.

MX описывает пересылку почты
Записи MX нужны для того, чтобы указать, куда пересылать почту. В этих записях добавляется приоритет — чем он меньше, тем выше приоритет машины. Приоритеты нужны для того, чтобы можно было задать несколько записей и перенаправить почту на альтернативный сервер, если основной не работает. MX запись должна быть указана для домена в целом и, возможно, для каждой машины в отдельности. Сложного тут тоже ничего нет за одним исключением: очень часто встречается неправильно использование метасимвола “*”. Запись “*.mycompany.ru.” означает не “любая машина домена mycompany.ru”, а “любая машина, которая еще не была описана”. Причем, даже если использовалась не MX, а, например, A-запись, то звездочка все равно не будет работать для этой машины. Более подробно почитать об использовании метасимволов можно в RFC 1034, раздел 4.3.3 В принципе, метасимволы нужны только для того чтобы принимать почту для сети, находящейся за брандмауэром и чтобы пересылать почту в сети, не подключенные к Интернету (например, работающие через UUCP). Так как записи DNS меняются довольно редко, то имеет смысл прописать MX записи для всех машин, описанных записями A.

mycompany.ru. IN MX 10 relay
mycompany.ru. IN MX 20 mycompany.ru.
mycompany.ru. IN MX 30 mail.provider.ru.
general.mycompany.ru. IN A 192.168.0.3
IN MX 10 mycompany.ru.

Реверсная зона позволяет определить имя по адресу
На этом создание файла зоны можно считать законченным. Но остается более увлекательное занятие: описание реверсной зоны. Если предыдущий файл позволяет определить IP-адрес по имени, то теперь надо сделать так, чтобы по IP-адресу можно было “вычислить” имя. Отсутствие реверсной зоны является довольно типичной ошибкой и может приводить к самым разным ошибкам — начиная от сбоев FTP-серверов и заканчивая классификацией отправленных писем как спама.

PTR преобразовывает адрес в имя
Для обратного преобразования используются записи PTR. Но не торопитесь их вписывать — тут есть одна хитрость: они пишутся в отдельном специальном домене верхнего уровня, с названием IN-ADDR.ARPA. Домен этот был создан для того, чтобы и для прямого, и для обратного преобразований можно было использовать одни и те же программные модули. Дело в том, что “мнемонические” имена пишутся слева направо: www.systemadmins.ru означает, что www находится в systemadmins.ru, а systemadmins — в ru. IP-адреса пишутся наоборот: 195.242.9.4 означает, что машина 4 находится в подсети 9, которая является частью 195.242 И для сохранения “единого стиля” адресов для обратного преобразования используются имена вида 4.9.242.195.IN-ADDR.ARPA (обратите внимание, что IP-адрес записан в обратном порядке).

Итак, мы создаем еще один файл зоны (для зоны, например, 0.168.192.IN-ADDR.ARPA), копируем в него запись SOA (а заодно и NS), после чего начинаем писать:

1 IN PTR major.mycompany.ru. 2 IN PTR colonel.mycompany.ru.

…
Можно задавать не только относительные, но и абсолютные имена:

3.0.168.192.IN-ADDR.ARPA. IN PTR general.mycompany.ru.

Не забудьте еще задать обратное преобразование для 127.0.0.1.

Обратите внимание на то, что право на ведение “прямого” домена не зависит от провайдера — его выдает организация, ведающая распределением имен в нужном вам домене. А вот пул IP-адресов находится в ведении провайдера, и именно провайдер делегирует (или не делегирует) вам права на ведение реверсной зоны. В связи с тем, что зачастую клиентам выдается не целая сеть класса «C», а ее часть, то и реверсная зона находится на сервере провайдера. Так что вам придется наладить с ним взаимодействие в области обновления данных.

Настройте трансфер зоны
Напоследок — одно маленькое замечание. Исследование DNS является одним из первых этапов “изучения сети” при подготовке ее взлома. Чаще всего используется перенос зоны, при котором все записи зоны передаются на компьютер “исследователя”, где он их может изучать в спокойной обстановке. Поэтому имеет смысл (помимо всего прочего) настроить брандмауэр на запрет TCP-соединений по 53 порту с несанкционированных адресов (в запросах на определение имен используется UDP, а для переноса зоны — TCP).

P.S. Для того чтобы посмотреть, что записано в DNS, используется команда nslookup (она есть и в UNIX, и в Windows).

Автор: Дмитрий Турецкий
Взято с .hostinfo

Интересное

Компания “Галион”. Предлагает алюминиевые окна, витрины. Бесплатная доставка и монтаж.

Источник: systemadmins.ru

Мой блог находят по следующим фразам

• как правильно делать резервное копирование сервера
• скрипт запуска процесса на удаленном компьютере
• назначение dns-сервера
• Как передать информацию на ПК через Инфракрасный Порт ?
• очистка кэша и исправление ошибок в mac os
• Вид доступа к Интернет

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

Ну а для начала необходимо немного разобраться в том, как работают DNS-серверы. Оказывается, большинство из них для общения с клиентами используют протокол UDP. Между тем в этой технологии не предусмотрено каких-либо надежных средств идентификации. Для защиты от вторжения в нем используются два специальных поля запросов и ответов — идентификатор и номер порта. Первый из них имеет постоянное начальное значение, равное единице, а второе — 1023. После этого при каждом новом запросе к DNS-серверу значение обоих полей увеличивается на единицу. Причем в некоторых операционных системах (Windows 9x, многие версии Linux) идентификатор вообще не изменяется, оставаясь всегда равным первоначальному значению.

Подмена сервера путем перехвата DNS-запросов

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

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

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

Ну а теперь давайте посмотрим, как все это выглядит со стороны атакуемого пользователя. Он вводит адрес нужного ему сайта, но попадает при этом на совершенно другую страницу. Причем в строке браузера будет стоять именно тот адрес, который он вводил. Человек может сколько угодно перенабирать его или обновлять страницу — все равно ничего не изменится. И наверняка 99 человек из 100 решат, что либо по введенному адресу размещается теперь другой сайт, либо просто веб-проект был атакован и изменен хакерами. И практически никто из них не подумает, что атаке могли подвергнуться они сами, в то время как все остальные пользователи работают с веб-проектом в обычном режиме. В этом и заключается одна из самых главных опасностей хакерских воздействий на службу DNS.

Подмена сервера путем создания шторма ложных ответов

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

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

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

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

Дыры в программном обеспечении

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

Причем за примерами использования уязвимостей в программном обеспечении DNS-серверов далеко ходить не нужно. В 1996 году неизвестный хакер смог немного “подправить” базу данных московского провайдера “Роснет”. Эта история получила широкую огласку и привлекла к себе внимание журналистов. Провайдеру даже пришлось устраивать специальную пресс-конференцию, посвященную данному инциденту. Кстати, пострадавшей стороной тогда оказался крупный информационный проект (его адрес так и не был озвучен), все посетители которого были перенаправлены на другой сайт. Так что атаки, использующие дыры в программном обеспечении, являются, во-первых, весьма опасными, а во-вторых, простыми в исполнении.

Обман сервера путем создания шторма ложных ответов

Наверняка внимательные читатели обратили внимание на сходство названия этой атаки и наименования одного из целенаправленных воздействий. И они правы. Похожи не только названия, но и принцип действия этих атак. Впрочем, есть между ними и некоторые отличия. Какие? Чтобы разобраться в этом вопросе, необходимо рассмотреть принцип работы DNS-серверов.

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

Если внимательно приглядеться к описанной схеме работы, то становится видна одна возможность создания в базе данных DNS-сервера ложной записи. Речь идет вот о чем. Если в ответ на запрос сервера (к своему вышестоящему серверу) послать ответ с ложной информацией, причем сделать это раньше, чем придут настоящие данные, то в базу будет занесен неверный адрес. Вот только как это можно реализовать на практике? А вот для этого необходимо разобраться в протоколе, согласно которому DNS-серверы взаимодействуют между собой. Собственно говоря, мы о нем уже говорили в первой части статьи. Да-да, уважаемые читатели, DNS-серверы тоже общаются между собой по протоколу UDP. Впрочем, есть у этого взаимодействия одна особенность. Оказывается, DNS-серверы всегда передают информацию через фиксированный порт 53.

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

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

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

Подводим итоги

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

Автор: Марат Давлетханов
Взято с .hostinfo

Интересное

Продвижение сайтов под поисковые системы.

Источник: systemadmins.ru

Мой блог находят по следующим фразам

• Как в виндовс 7 создать коммандный файл
• протокол ipv6
• как положить деньги на skype
• сетевой Backup Schedule в Windows Server 2008 на сетевой диск
• Как вывести 12 в из блока питания компа
• логическое соединение в сокетах

Очень приблизительно можно сказать, что у каждого компьютера в Интернете есть два основных идентификатора: доменное имя (например, systemadmins.ru) и IP-адрес (например, 127.0.0.1). Приблизительность заключается в том, что, во-первых, IP-адресов у компьютера может быть несколько (мало того, что у каждого интерфейса свой адрес, так еще и несколько адресов могут “висеть” на одном интерфейсе); во-вторых, имен тоже может быть несколько, причем они могут связываться как с одним, так и с несколькими IP-адресами; в-третьих, у компьютера может и не быть доменного имени… Словом, ясно, что картина уже начинает запутываться.

Как было сказано выше, основной задачей DNS-сервера является трансляция доменных имен в IP адреса и обратно. На заре становления Интернета (когда он еще был ARPANET’ом) это решалось ведением длинных списков, включающих все компьютеры сети, причем копия такого списка должна была присутствовать на каждом компьютере. Понятно, что с ростом сети эта технология перестала удовлетворять кого бы то ни было — ведь эти файлы надо было еще и синхронизировать, не говоря уж об их размере… Некоторые “пережитки” этого метода можно обнаружить и сейчас: существует файл HOSTS (и в UNIX, и в Windows), в котором можно прописывать адреса серверов, с которыми вы регулярно работаете (кстати, именно его использование лежит в основе многих “ускорителей Интернета” — такие программы просто записывают адреса серверов, к которым вы обращаетесь, в файл HOSTS и при следующем обращении берут данные из него, не тратя время на запрос к DNS-серверу).

На смену “однофайловой” схеме пришел DNS — иерархическая структура имен. Существует “корень дерева” с именем “.” (точка). Так как корень един для всех доменов, то точка в конце имени обычно не ставится (но она используется в описаниях DNS — тут надо быть очень внимательным!). Ниже корня лежат домены первого уровня. Их немного — com, net, edu, org, mil, int, biz, info, gov (есть еще несколько) и домены государств, например, ru. Еще ниже находятся домены второго уровня, например, systemadmins.ru. Еще ниже — третьего и т.д.

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

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

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

Полезным свойством DNS является умение использовать “пересыльщиков” (forwarders). “Честный” DNS-сервер самостоятельно опрашивает другие сервера и находит нужный ответ, но если ваша сеть подключена к Интернету по медленной (например, dial-up) линии, то этот процесс может занимать довольно много времени. Вместо этого можно перенаправлять все запросы, скажем, на сервер провайдера, а затем принимать его ответ. Использование “пересыльщиков” может оказаться интересным и для больших компаний с несколькими сетями: в каждой сети можно поставить относительно слабый DNS-сервер, указав в качестве “пересыльщика” более мощную машину, подключенную по быстрой линии. При этом все ответы будут кэшироваться на этом мощном сервере, что ускорит разрешение имен для целой сети.

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

Элементы базы DNS часто называют RR (сокращение от Resource Record). Базовый формат записи выглядит так:

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

Имя может быть относительным или абсолютным (FQDN — Fully Qualified Domain Name). Если имя относительное (не заканчивается точкой — помните про корневой домен?), то к нему автоматически добавляется имя текущего домена. Например, если в домене systemadmins.ru я опишу имя «www», то полное имя будет интерпретироваться как “www.systemadmins.ru.” Если же это имя указать как “www.systemadmins.ru” (без последней точки), то оно будет считаться относительным и будет интерпретировано как “www.systemadmins.ru.systemadmins.ru.”

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

класс определяет класс сети. Практически всегда это будет IN, обозначающее INternet.

Тип может быть одним из следующих:

SOA — определяет DNS зону
NS — сервер имен для зоны
A — преобразование имени в IP-адрес
PTR — преобразование IP-адреса в имя
MX — почтовая станция
CNAME — имена машины
HINFO — описание “железа” компьютера
TXT — комментарии или какая-то другая информация

Есть также некоторые другие типы, но они намного менее распространены.

В записях можно использовать символы # и ; для комментариев, @ для обозначения текущего домена, () — скобки — для написания данных на нескольких строках. Кроме того, можно использовать метасимвол * в имени. Порядок записей не имеет значения за одним исключением: запись SOA должна идти первой. Дальнейшие записи считаются относящимися к той же зоне, пока не встретится новая запись SOA. Как правило, после записи зоны указывают записи DNS-серверов, а остальные записи располагают по алфавиту, но это не обязательно.

Теперь попробуем рассмотреть записи. Первой описываем зону:

mycompany.ru. IN SOA ns.mycompany.ru. admin.mycompany.ru. (1001 ; serial 21600 ; Refresh — 6 часов 1800 ; Retry — 30 мин 1209600 ; Expire — 2 недели 432000) ; Minimum — 5 дней

Сначала идет имя домена: mycompany.ru. (обратите внимание на точку в конце имени). Вместо имени можно было (и чаще всего так и делают) поставить знак @.
ns.mycompany.ru. — основной сервер имен
admin.mycompany.ru. — почтовый адрес администратора в формате имя(точка)машина

затем в круглых скобках идут поля, необходимые для правильного “восприятия” вашей зоны другими серверами. Первое число — serial — является “версией” файла зоны. При внесении изменений это число надо увеличить — если вторичный сервер увидит, что его версия зоны меньше, чем у первичного сервера, то он перечитает данные. Типичной ошибкой является обновление зоны без обновления этого числа. Очень удобно в качестве serial использовать текущую дату, например, 2003040401 — 4 апреля 2003 года, первое обновление.
Refresh говорит вторичным серверам, как часто они должны проверять значение serial.

Retry говорит о том, как часто вторичный сервер должен пытаться прочитать данные, если первичный сервер не отвечает.

Expire говорит вторичным серверам, в течение какого времени они должны обслуживать домен, если первичный сервер не отвечает. По истечении этого времени вторичные сервера будут считать свои данные устаревшими.

Minimum задает время жизни записей по умолчанию для данной зоны.

Теперь опишем сервера имен, обслуживающие наш домен:mycompany.ru. IN NS ns.mycompany.ru.
mycompany.ru. IN NS ns.provider.ru.

Здесь ничего сложного нет. Так как имя зоны совпадает с указанным в поле имя записи SOA, то его можно оставить пустым.

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

major IN A 192.168.0.1 colonel IN A 192.168.0.2 IN HINFO “2xPIV-1.7 Win2K” general.mycompany.ru. IN A 192.168.0.3

Здесь сложного тоже ничего нет — имена могут быть относительные или “абсолютные”, можно добавить записи о конфигурации машины (пропущенное имя в записи HINFO говорит о том, что имеется в виду предыдущее имя). Не забудьте добавить записи

%. IN A 127.0.0.1 % IN CNAME %. mycompany.ru. IN A 192.168.0.1

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

C помощью CNAME можно задавать короткие имена серверов
Записи CNAME позволяют дать машинам удобные или значащие имена. Например:
ftp IN CNAME general говорит, что ftp.mycompany.ru живет по адресу 192.168.0.3. CNAME удобно использовать, если вы меняете имя машины, но хотите оставить доступ для клиентов, которые помнят старое имя. Удобный трюк с использованием CNAME заключается в назначении коротких имен частоиспользуемым адресам. Например, прописав ls IN CNAME systemadmins.ru., вы сможете заходить на systemadmins.ru просто набирая ls в качестве адреса.

MX описывает пересылку почты
Записи MX нужны для того, чтобы указать, куда пересылать почту. В этих записях добавляется приоритет — чем он меньше, тем выше приоритет машины. Приоритеты нужны для того, чтобы можно было задать несколько записей и перенаправить почту на альтернативный сервер, если основной не работает. MX запись должна быть указана для домена в целом и, возможно, для каждой машины в отдельности. Сложного тут тоже ничего нет за одним исключением: очень часто встречается неправильно использование метасимвола “*”. Запись “*.mycompany.ru.” означает не “любая машина домена mycompany.ru”, а “любая машина, которая еще не была описана”. Причем, даже если использовалась не MX, а, например, A-запись, то звездочка все равно не будет работать для этой машины. Более подробно почитать об использовании метасимволов можно в RFC 1034, раздел 4.3.3 В принципе, метасимволы нужны только для того чтобы принимать почту для сети, находящейся за брандмауэром и чтобы пересылать почту в сети, не подключенные к Интернету (например, работающие через UUCP). Так как записи DNS меняются довольно редко, то имеет смысл прописать MX записи для всех машин, описанных записями A.

mycompany.ru. IN MX 10 relay
mycompany.ru. IN MX 20 mycompany.ru.
mycompany.ru. IN MX 30 mail.provider.ru.
general.mycompany.ru. IN A 192.168.0.3
IN MX 10 mycompany.ru.

Реверсная зона позволяет определить имя по адресу
На этом создание файла зоны можно считать законченным. Но остается более увлекательное занятие: описание реверсной зоны. Если предыдущий файл позволяет определить IP-адрес по имени, то теперь надо сделать так, чтобы по IP-адресу можно было “вычислить” имя. Отсутствие реверсной зоны является довольно типичной ошибкой и может приводить к самым разным ошибкам — начиная от сбоев FTP-серверов и заканчивая классификацией отправленных писем как спама.

PTR преобразовывает адрес в имя
Для обратного преобразования используются записи PTR. Но не торопитесь их вписывать — тут есть одна хитрость: они пишутся в отдельном специальном домене верхнего уровня, с названием IN-ADDR.ARPA. Домен этот был создан для того, чтобы и для прямого, и для обратного преобразований можно было использовать одни и те же программные модули. Дело в том, что “мнемонические” имена пишутся слева направо: www.systemadmins.ru означает, что www находится в systemadmins.ru, а systemadmins — в ru. IP-адреса пишутся наоборот: 195.242.9.4 означает, что машина 4 находится в подсети 9, которая является частью 195.242 И для сохранения “единого стиля” адресов для обратного преобразования используются имена вида 4.9.242.195.IN-ADDR.ARPA (обратите внимание, что IP-адрес записан в обратном порядке).

Итак, мы создаем еще один файл зоны (для зоны, например, 0.168.192.IN-ADDR.ARPA), копируем в него запись SOA (а заодно и NS), после чего начинаем писать:

1 IN PTR major.mycompany.ru. 2 IN PTR colonel.mycompany.ru.

…
Можно задавать не только относительные, но и абсолютные имена:

3.0.168.192.IN-ADDR.ARPA. IN PTR general.mycompany.ru.

Не забудьте еще задать обратное преобразование для 127.0.0.1.

Обратите внимание на то, что право на ведение “прямого” домена не зависит от провайдера — его выдает организация, ведающая распределением имен в нужном вам домене. А вот пул IP-адресов находится в ведении провайдера, и именно провайдер делегирует (или не делегирует) вам права на ведение реверсной зоны. В связи с тем, что зачастую клиентам выдается не целая сеть класса «C», а ее часть, то и реверсная зона находится на сервере провайдера. Так что вам придется наладить с ним взаимодействие в области обновления данных.

Настройте трансфер зоны
Напоследок — одно маленькое замечание. Исследование DNS является одним из первых этапов “изучения сети” при подготовке ее взлома. Чаще всего используется перенос зоны, при котором все записи зоны передаются на компьютер “исследователя”, где он их может изучать в спокойной обстановке. Поэтому имеет смысл (помимо всего прочего) настроить брандмауэр на запрет TCP-соединений по 53 порту с несанкционированных адресов (в запросах на определение имен используется UDP, а для переноса зоны — TCP).

P.S. Для того чтобы посмотреть, что записано в DNS, используется команда nslookup (она есть и в UNIX, и в Windows).

Автор: Дмитрий Турецкий
Взято с .hostinfo

Интересное

Компания “Галион”. Предлагает алюминиевые окна, витрины. Бесплатная доставка и монтаж.

Источник: systemadmins.ru

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

Ну а для начала необходимо немного разобраться в том, как работают DNS-серверы. Оказывается, большинство из них для общения с клиентами используют протокол UDP. Между тем в этой технологии не предусмотрено каких-либо надежных средств идентификации. Для защиты от вторжения в нем используются два специальных поля запросов и ответов — идентификатор и номер порта. Первый из них имеет постоянное начальное значение, равное единице, а второе — 1023. После этого при каждом новом запросе к DNS-серверу значение обоих полей увеличивается на единицу. Причем в некоторых операционных системах (Windows 9x, многие версии Linux) идентификатор вообще не изменяется, оставаясь всегда равным первоначальному значению.

Подмена сервера путем перехвата DNS-запросов

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

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

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

Ну а теперь давайте посмотрим, как все это выглядит со стороны атакуемого пользователя. Он вводит адрес нужного ему сайта, но попадает при этом на совершенно другую страницу. Причем в строке браузера будет стоять именно тот адрес, который он вводил. Человек может сколько угодно перенабирать его или обновлять страницу — все равно ничего не изменится. И наверняка 99 человек из 100 решат, что либо по введенному адресу размещается теперь другой сайт, либо просто веб-проект был атакован и изменен хакерами. И практически никто из них не подумает, что атаке могли подвергнуться они сами, в то время как все остальные пользователи работают с веб-проектом в обычном режиме. В этом и заключается одна из самых главных опасностей хакерских воздействий на службу DNS.

Подмена сервера путем создания шторма ложных ответов

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

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

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

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

Дыры в программном обеспечении

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

Причем за примерами использования уязвимостей в программном обеспечении DNS-серверов далеко ходить не нужно. В 1996 году неизвестный хакер смог немного “подправить” базу данных московского провайдера “Роснет”. Эта история получила широкую огласку и привлекла к себе внимание журналистов. Провайдеру даже пришлось устраивать специальную пресс-конференцию, посвященную данному инциденту. Кстати, пострадавшей стороной тогда оказался крупный информационный проект (его адрес так и не был озвучен), все посетители которого были перенаправлены на другой сайт. Так что атаки, использующие дыры в программном обеспечении, являются, во-первых, весьма опасными, а во-вторых, простыми в исполнении.

Обман сервера путем создания шторма ложных ответов

Наверняка внимательные читатели обратили внимание на сходство названия этой атаки и наименования одного из целенаправленных воздействий. И они правы. Похожи не только названия, но и принцип действия этих атак. Впрочем, есть между ними и некоторые отличия. Какие? Чтобы разобраться в этом вопросе, необходимо рассмотреть принцип работы DNS-серверов.

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

Если внимательно приглядеться к описанной схеме работы, то становится видна одна возможность создания в базе данных DNS-сервера ложной записи. Речь идет вот о чем. Если в ответ на запрос сервера (к своему вышестоящему серверу) послать ответ с ложной информацией, причем сделать это раньше, чем придут настоящие данные, то в базу будет занесен неверный адрес. Вот только как это можно реализовать на практике? А вот для этого необходимо разобраться в протоколе, согласно которому DNS-серверы взаимодействуют между собой. Собственно говоря, мы о нем уже говорили в первой части статьи. Да-да, уважаемые читатели, DNS-серверы тоже общаются между собой по протоколу UDP. Впрочем, есть у этого взаимодействия одна особенность. Оказывается, DNS-серверы всегда передают информацию через фиксированный порт 53.

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

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

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

Подводим итоги

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

Автор: Марат Давлетханов
Взято с .hostinfo

Интересное

Продвижение сайтов под поисковые системы.

Источник: systemadmins.ru

Мой блог находят по следующим фразам

• Интернет провайдер маскирует Ваш IP адрес
• Как скачать с youtube
• сети нового поколения
• как скачать с youtube
• физические среды передачи данных
• физические среды передачи данных

Вот как очистить кэш DNS на Microsoft Windows, Mac OS и Linux операционных системах:

Microsoft Windows (все версии)

Откройте командную строку: Пуск -> Выполнить -> cmdНапечатайте ipconfig /flushdns Возможно, что выпадет сообщение об ошибке, в таком случае необходимо запустить службу DNS-сервер.

Mac OS X (Tiger и старше)

Откройте окно терминалаНапечатайте lookupd -flushcache

Mac OS X (Leopard)

Откройте окно терминалаdscacheutil -flushcache

Linux

Откройте окно терминала/etc/rc.d/init.d/nscd restart

Источник: systemadmins.ru

Мой блог находят по следующим фразам

• windows 7 выполнение команд на удаленном компьютере
• win7 starter upgrade
• что за процесс scvhost.exe
• узнать имя админа в удаленной windows server
• 9876 udp
• история развития компьютерных сетей

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

Когда серверный процесс запущен, клиент может инициировать установку ТСР-соединения с сервером. Первым действием клиентской программы является создание сокета, при этом программа указывает адрес серверного процесса, состоящий из IP-адреса и номера порта процесса. После создания сокета клиентская сторона протокола TCP осуществляет процедуру тройного рукопожатия с сервером, оканчивающуюся установлением соединения. Заметим, что процедура рукопожатия никак не сказывается на работе приложения.

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

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

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

Существуют два вида приложений с архитектурой клиент/сервер. К первому виду относятся приложения, поддерживающие стандартный протокол, описанный в документах RFC. В этом случае как клиентская, так и серверная части приложения должны соответствовать всем описаниям, приведенным в RFC. Например, если приложение использует протокол FTP, то клиентская и серверная программы приложения должны быть построены в соответствии с требованиями документа RFC 959, описывающего FTP-приложения. Следование стандартам позволяет независимым разработчикам подключаться к созданию различных частей одного и того же приложения. Так, например, браузер Netscape способен успешно взаимодействовать с web-сервером Apache, а FTP-клиент, предназначенный для домашнего компьютера, — с FTP-сервером на платформе UNIX. Для приложений, разработанных по стандарту RFC, следует применять порт с номером, соответствующим используемому протоколу.

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

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

В этом разделе мы создадим простую клиентскую часть приложения, поддерживающую протокол TCP, а в следующем разделе — протокол UDP. Обе программы написаны на языке Java. Необходимо отметить, что эти же программы можно было с равным успехом писать на языке С или С++, однако наш выбор обусловлен несколькими существенными причинами. Во-первых, Java-код проще, понятнее (что особенно важно для новичков) и состоит из меньшего числа строк, чем код на С/ С++. Во-вторых, программирование приложений клиент/сервер на языке Java в последние годы получило большую популярность, и не исключено, что в ближайшие годы станет общепринятым. Не стоит отчаиваться, если вы не знакомы с языком Java: чтение кода не станет для вас проблемой, если вы обладаете навыками программирования на любом другом языке.

□ Первые 12 байт составляют заголовочную секцию, состоящую из нескольких полей. Первое поле представляет собой 16-разрядное число, идентифицирующее запрос. Идентификатор запроса копируется в ответное сообщение, что позволяет клиенту сопоставлять ответы с запросами. Поле флагов включает одноразрядный флаг «запрос/ответ» и определяет, является ли сообщение запросом (0) или ответом (1). Одноразрядный флаг полномочности устанавливается для ответного сообщения в случае, если сервер имен является полномочным для запрашиваемого имени.

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

□ Секция вопросов содержит информацию о запросе и включает поле имени, в котором указано имя запрашиваемого хоста, и поле типа, определяющее содержание ответа, например адрес хоста (тип А) или имя почтового сервера (тип MX).

□ Секция ответов присутствует в ответных сообщениях и содержит требуемые ресурсные записи. Каждая RR-запись включает поля Туре с одним из значений A, NS, CNAME или MX, Value и TTL. Поскольку имени хоста может быть сопоставлено несколько IP-адресов (например, из-за дублирования web-серверов, упоминавшегося в этой главе), секция ответов также может содержать несколько записей.

□ Секция полномочности включает в себя записи о других полномочных серверах.

□ Дополнительная секция содержит прочие «полезные» записи. Например, в поле ответов для запроса на запись типа MX может находиться запись, хранящая каноническое имя почтового сервера, а в дополнительную секцию помещена запись типа А с IP-адресом почтового сервера.

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

RR-запись состоит из четырех полей:

(Name. Value, Type, TTL)

Поле TTL определяет время жизни записи в кэш-памяти; говоря точнее, оно содержит время удаления записи из кэш-памяти. В примерах, приводимых ниже, мы будем опускать поле TTL. Значения полей Name и Value зависят от поля Туре.

□ Если Туре = А, то поле Name содержит имя хоста, a Value — IP-адрес. Таким образом, тип А в дополнение к IP-адресу включает стандартное имя хоста. Примером записи типа А является (_relayl.bar.foo.com, 145.37.93.126, А).

□ Если Туре = NS, то поле Name содержит домен (например, _foo.com), a Value — имя хоста или полномочного сервера, располагающего информацией о том, на каком сервере имен хранятся IP-адреса хостов домена. Эта запись используется для дальнейшей передачи запроса по цепочке серверов имен. Примером записи типа NS является (_foo.com, _dns.foo.com, NS).

□ Если Туре = CNAME, то Value является каноническим именем хоста, a Name — псевдонимом хоста. Этот тип записи позволяет получить каноническое имя хоста по известному псевдониму. Примером записи типа CNAME является (_foo.com, _relayl.bar.foo.com, CNAME).

□ Если Туре = MX, то Value является каноническим именем почтового сервера с псевдонимом Name. Примером записи типа MX является (_foo.com, _mai4.bar.foo.com, MX). Записи типа MX позволяют использовать простые псевдонимы вместо длинных имен хостов почтовых серверов. Обратите внимание на то, что при помощи записей типа MX компании могут задействовать один и тот же псевдоним для своего почтового сервера и других серверов (например, web-сервера). Для получения канонического имени почтового сервера DNS-клиент создает запрос на запись типа MX, а для получения канонического имени web-серверов и прочих серверов — запрос на запись типа CNAME.

Если сервер имен является полномочным для хоста, то для этого хоста он будет содержать запись типа А (тем не менее, если сервер имен не является полномочным, он может содержать запись типа А для данного хоста в кэш-памяти); в противном случае сервер имен содержит запись типа NS с информацией о домене, включающем имя хоста, а также запись типа А с IP-адресом сервера имен, указанного в поле Value записи типа NS. Предположим, к примеру, что корневой сервер имен не является полномочным для хоста _gaia.cs.umass.edu. В этом случае корневой сервер будет содержать запись о домене, включающем хост cs.umass.edu (_umass.edu.dns, _umass.edu, NS), и запись, связывающую имя сервера имен dns.umass.edu с его IP-адресом (_dns.umass.edu, 128.119.40.111, А).

Предположим, что некоторому приложению (web-браузеру или программе чтения электронной почты), выполняющемуся на хосте пользователя, необходимо получить IP-адрес удаленного хоста. Приложение вызывает клиентскую сторону DNS и передает ей имя нужного хоста. (Многие UNIX-машины поддерживают функцию gethostbyname(), вызываемую приложениями для получения IP-адреса. В разделе «Программирование UDP-сокетов» этой главы мы покажем, каким образом Java-приложение может обратиться к службе DNS.) Клиентская сторона, в свою очередь, создает запрос, отсылает его DNS-серверу и ждет ответа. Как правило, время ответа DNS-сервера составляет от нескольких миллисекунд до десятков секунд. Ответ представляет собой сообщение, содержащее группу из одного или нескольких IP-адресов, которые передаются DNS-клиентом вызвавшему его приложению. Таким образом, с точки зрения приложения служба DNS является «черным ящиком», на входе которого находится имя удаленного хоста, а на выходе — его IP-адрес. На самом деле этот «черный ящик» представляет собой сложную систему, состоящую из множества серверов имен, распределенных по всему земному шару, и протокола, определяющего взаимодействие между серверами имен и пользовательскими хостами.

Как устроена служба DNS? Ее можно представить себе в виде единственного центрального сервера имен, который содержит всю информацию об именах хостов и их IP-адресах. Этот сервер принимает все запросы и отсылает ответы «без посредников» напрямую каждому DNS-клиенту. К сожалению, огромное (и постоянно растущее) число Интернет-хостов не позволяет применить эту простую схему на практике. Централизованной системе присущи некоторые «врожденные» недостатки.

□ Единственная точка возможного отказа. Сервер имен является «узким местом» с точки зрения надежности — его отказ парализует работу всего Интернета.

□ Объем трафика. Сервер имен является «узким местом» с точки зрения загрузки, поскольку вынужден обрабатывать все запросы, поступающие с сотен миллионов хостов всего мира.

□ Удаленность централизованной базы данных. Единственный сервер невозможно расположить на приемлемом расстоянии от всех клиентов. Например, разместив сервер в Нью-Йорке, мы обеспечим хосты Австралии гарантированными задержками, связанными с передачей сигнала по линиям связи, далеко не всегда высокоскоростным.

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

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

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

□ Локальные серверы имен имеются у каждого Интернет-провайдера (локальные серверы имен также называют серверами имен по умолчанию). Когда пользовательский хост посылает DNS-запрос, этот запрос сначала попадает на локальный сервер имен. Обычно IP-адрес локального сервера имен конфигурируется пользователем вручную, например, в операционной системе Windows для этого необходимо открыть Панель управления (Control Panel), щелкнуть на значке Сеть (Network), в списке установленных компонентов открывшегося окна выделить пункт TCP/IP и, щелкнув на кнопке Свойства (Properties), в появившемся диалоговом окне перейти на вкладку Конфигурация DNS (DNS Configuration). Обычно локальный сервер имен расположен на относительно небольшом расстоянии от пользовательского хоста. В случае, если Интернет-провайдером является государственное или коммерческое учреждение, сервер имен принадлежит локальной сети организации; для резидентных Интернет-провайдеров сервер имен обычно отделен от пользователя не более чем несколькими маршрутизаторами. Если окажется, что удаленный хост принадлежит тому же Интернет-провайдеру, локальный сервер самостоятельно проведет преобразование, и требуемый IP-адрес будет отослан пользовательскому хосту. Подобная ситуация, например, будет иметь место, когда хост _surf.eurecom.fr затребует IP-адрес _baie.eurecom.fr. В этом случае IP-адрес выдается локальным сервером имен института Eurecom.

□ Корневые серверы имен являются следующей ступенью в иерархии серверов DNS. Их число в Интернете составляет немногим более десятка, и большинство из них находится в Северной Америке. Рисунок 2.13 иллюстрирует положение корневых серверов имен на географической карте мира в феврале 2002 года. В случае, если локальный сервер имен не может самостоятельно удовлетворить запрос пользовательского хоста, он берет на себя роль клиента и передает запрос одному из корневых серверов имен. Корневой сервер обрабатывает запрос и при наличии соответствующей записи в базе данных отсылает локальному серверу ответ, содержащий IP-адрес, который, в свою очередь, передается локальным сервером пользовательскому хосту. Тем не менее корневой сервер имен не всегда может выполнить запрос из-за ограниченности своей базы данных. В случае, если хост не найден в базе данных, локальному серверу отсылается IP-адрес полномочного сервера имен, который располагает искомым IP-адресом.

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

Рассмотрим простой пример. Предположим, что хост _surf.eurecom.fr создал запрос IP-адреса _gaia.cs.umass.edu. Пусть локальный сервер имен института Eurecom имеет имя _dns.eurecom.fr, а полномочный сервер имен хоста _gaia.cs.umass.edu — имя _dns.umass.edu. Как показано на рис. 2.14, хост _surf.eurecom.fr сначала отправляет запрос своему локальному серверу имен _dns.eurecom.fr, в котором содержится имя для преобразования в IP-адрес (_gaia.cs.umass.edu). Локальный сервер имен передает запрос корневому серверу, который, в свою очередь, перенаправляет его серверу, являющемуся полномочным для всех хостов домена _umass.edu, например _dns.umass.edu. Сервер обрабатывает запрос, создает ответ с IP-адресом хоста _gaia.cs.umass.edu и отсылает его хосту _surf.eurecom.fr через корневой и локальный серверы имен. Обратите внимание на то, что в этом примере процедура получения IP-адреса требует передачи шести DNS-сообщений: трех запросов и трех ответов.
Выше было сделано допущение о том, что корневой сервер имен располагает IP-адресами полномочных серверов для любого хоста. На самом деле это допущение неверно. Корневой сервер «знает» адрес лишь промежуточного сервера имен, который содержит IP-адрес полномочного сервера хоста. Для того чтобы проиллюстрировать это, снова обратимся к примеру с хостом surf.eurecom.fr, желающим получить IP-адрес хоста _gaia.cs.umass.edu. Предположим, что локальный сервер имен университета Массачусетс имеет имя dns.umass.edu. Допустим также, что каждое подразделение университета располагает собственным локальным сервером имен, являющимся полномочным для всех хостов соответствующего подразделения. Как показано на рис. 2.15, когда корневой сервер имен получает запрос с именем, оканчивающимся на umass.edu, он перенаправляет запрос серверу имен _dns.umass.edu. Далее сервер _dns.umass.edu перенаправляет все запросы с именами, оканчивающимися на _cs.umass.edu, локальному серверу имен _dns.cs.umass.edu, являющемуся полномочным для всех хостов _cs.umass.edu. Искомый IP-адрес передается сервером _dns.cs.umass.edu хосту _surf.eurecom.fr последовательно через серверы _dns.umass.edu, корневой сервер имен и локальный сервер имен _dns.eurecom.fr. Таким образом, получение IP-адреса в этом примере потребовало посылки восьми DNS-сообщений. На практике встречаются ситуации, когда между корневым и полномочным серверами имен находятся два или более промежуточных сервера, что еще увеличивает количество DNS-сообщений в цикле получения IP-адреса.

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

Последовательность запросов, необходимых для получения IP-адреса хоста, может содержать одновременно и рекурсивные, и итеративные запросы. Пример такой смешанной цепи представлен на рис. 2.16. На практике часто встречаются ситуации, когда все запросы являются рекурсивными за исключением единственного итеративного запроса локального сервера имен к корневому. Это объясняется тем, что корневые серверы вынуждены обрабатывать значительное число запросов, а итеративный механизм снижает трудоемкость обработки запроса сервером. На сайте _http://www.awl.com/kurose-ross вы можете найти Java-апплет, позволяющий экспериментировать с различными комбинациями рекурсивных и итеративных запросов.

Теперь настало время рассмотреть такую важную составляющую DNS, как кэширование. Механизм кэширования активно используется DNS для того, чтобы сократить число запросов и время получения IP-адресов хостами. Идея кэширования проста: когда сервер имен получает ответ, содержащий IP-адрес хоста, он сохраняет пару «имя/1Р-адрес хоста» в специально отведенной области памяти (дисковой или оперативной). В случае, если этот сервер имен вновь получит запрос с тем же именем хоста, он сможет извлечь соответствующую пару из кэшпамяти и сгенерировать ответ, даже не являясь полномочным сервером хоста. Чтобы не хранить большие объемы невостребованной информации, записи остаются в кэш-памяти некоторый ограниченный промежуток времени (обычно 48 часов). Рассмотрим следующий пример. Пусть хост _surf.eurecom.fr создал запрос на получение IP-адреса хоста _cnn.com. Несколько часов спустя другой хост института Eurecom, например _baie.eurecom.fr, также создал DNS-запрос хосту _cnn.com. Механизм кэширования обеспечивает появление IP-адреса _cnn.com на локальном сервере имен Eurecom после выполнения запроса хоста _surf.eurecom.fr; таким образом, запрос хоста _baie.eurecom.fr будет удовлетворен локальным сервером без дальнейшей передачи. Кэширование поддерживается всеми серверами имен.