Могут ли ответы вспомогательных dns серверов быть авторитетными
Авторитетный сервер DNS - это сервер, который фактически содержит записи ресурсов DNS и отвечает за них. Это сервер в нижней части цепочки поиска DNS, который будет отвечать запрашиваемой записью ресурса, в конечном счете позволяя веб-браузеру, отправляющему запрос, достичь IP-адреса, необходимого для доступа к веб-сайту или другим веб-ресурсам. Авторитетный сервер имен может удовлетворять запросы из своих собственных данных без необходимости запрашивать другой источник, так как он является конечным источником для определенных записей DNS.
Стоит отметить, что в тех случаях, когда запрос используется для поддомена, дополнительный сервер имен будет добавлен в последовательность после авторитетного сервера имен, который отвечает за хранение записи поддомена.
Существует ключевое различие между многими службами DNS и Cloudflare. Различные рекурсивные DNS резолверы, такие как Google DNS, OpenDNS и поставщики, такие как Comcast, поддерживают установку рекурсивных преобразователей DNS в центрах обработки данных. Эти распознаватели позволяют быстро и легко выполнять запросы через оптимизированные кластеры для DNS систем, но они принципиально отличаются от серверов имен, размещенных в Cloudflare.
Cloudflare поддерживает серверы имен на уровне инфраструктуры, которые являются неотъемлемой частью функционирования интернета. Одним из ключевых примеров является сеть серверов F-root за хостинг которых Cloudflare частично отвечает. F-root является одним из компонентов инфраструктуры DNS-серверов корневого уровня, ответственных за миллиарды запросов интернета в день. Сеть Anycast ставит в уникальное положение для обработки больших объемов трафика DNS без прерывания обслуживания.
Как происходит поиск DNS?
В большинстве случаев DNS связан с доменным именем, преобразуемым в соответствующий IP-адрес.
Примечание: часто информация о DNS-поиске будет кэшироваться локально, внутри запроса или удаленно в инфраструктуре DNS. Обычно поиск DNS состоит из 8 шагов. Когда информация DNS кэшируется, некоторые шаги пропускаются из процесса поиска DNS, что делает его быстрее. В примере ниже приведены все 8 шагов, когда ничего не кэшируется.
8 шагов в поиске DNS
Резолвер запрашивает корневой DNS-сервер имен (.).
Сервер TLD отвечает IP-адресом.
Рекурсивный резолвер отправляет запрос на сервер имен домена.
Резолвер DNS отвечает веб-браузеру с IP-адресом домена, запрошенного изначально.
Я прочитал Authoritative Nameserver , но не смог четко понять. Можно ли объяснить мне несколько простых терминов?
Авторитетный сервер имен - это сервер имен (DNS-сервер), который содержит фактические записи DNS (A, CNAME, PTR и т. Д.) Для определенного домена / адреса. Рекурсивным распознавателем будет DNS-сервер, который запрашивает авторитетный сервер имен для разрешения домена / адреса.
Это упрощение, так как здесь есть и другие вещи, такие как кеширование записей.
> Здесь "авторитетный ответ" является IP-адресом? или что-то другое. - любой тип RR (запись ресурса), например, запись A, AAAA, SOA, MX, PTR, CNAME, NS и т. д.
- Что такое авторитетный сервер имен?
- Что такое рекурсивный резолвер?
Обратите внимание, что «resolver» и «nameserver» не совсем синонимичны, и что вы спрашиваете о nameserver в первом случае и resolver во втором.
Авторитетный сервер имен является тот , который удовлетворяет запросы из своих собственных данных без необходимости ссылаться на другой источник. Если он также не является рекурсивным сервером имен (практика, которая обычно устарела), он будет отвечать только достоверными данными из своего собственного хранилища (которые могут поступать из главного файла зоны, из копии этих данных, переданных с главного сервера, с база данных, из динамического DNS, встроенная и т. д.) или с рефералом (например, «Я не знаю этого ответа, но вы можете так или иначе общаться с сервером, который отвечает на вопросы для этого субдомена . ), или с NXDOMAIN или подобной ошибкой.
Рекурсивный сервер имен является тот , который удовлетворяет запросы, задавая другие сервера имен для ответа, продвигаясь по дереву от корневого уровня DNS дерева , если это необходимо. Если он не знает ответа, он попытается найти его для запрашивающего клиента.
Средство распознавания (в совокупности) представляет собой набор функций, которые система, использующая DNS, использует для запроса DNS.
- Большинство клиентских систем имеют решатель-заглушку , который знает только очень простой способ, как запросить DNS-сервер и как получить ответ, но который не содержит логики для следования цепочке делегирования из корня.
- Рекурсивный распознаватель с полным спектром услуг распознаватель , который может перемещаться по дереву , чтобы найти ответ на запрос.
- Рекурсивные серверы имен должны содержать функциональность рекурсивного распознавателя , чтобы функционировать, но другие программы могут содержать рекурсивные распознаватели без выполнения функций сервера имен. Отличным примером является утилита / программа устранения неполадок DNS «dig» (распространяется ISC как часть BIND), которая содержит полный рекурсивный преобразователь .
Мастер и Раб
Подчиненные серверы, даже несмотря на то, что они получают данные своей зоны из другого источника, по-прежнему являются авторитетными серверами, поскольку они удовлетворяют запросы данными из своего собственного хранилища (любого типа), а не удовлетворяют их, рекурсивно передавая запросы другим серверам имен.
Подчиненные серверы являются официальными серверами (для зон, которые они обслуживают.)
Из любопытства я проверяю DNS-пакеты Wireshark. Я вижу, что есть DNS-запрос от хоста, а затем DNS-ответ от DNS-сервера. Все так, как и ожидалось.
Однако, если вы еще раз подтвердите запрос, вы увидите, что сервер также отправляет NS (полномочный сервер имен). Мой вопрос: почему?
Как хозяин, я забочусь только об IP. Это главный пункт DNS , чтобы разрешить имя в IP - адрес .
Зачем мне как хозяину информация о NS?
@ downvoter, пожалуйста, прокомментируйте. И если вы думаете, что мой вопрос настолько прост, то хотя бы ответьте на него, а затем понизьте.
По философии и замыслу голоса являются анонимными, и ни голосование за, ни голосование не требуют обязательного объяснения . Всплывающая подсказка, которая появляется, когда указатель мыши наводит курсор на кнопку «вниз», гласит: «этот вопрос не требует каких-либо исследований; он неясен или бесполезен» . Кроме того, вопросы могут привлечь к себе отрицательное голосование, если они не очень хорошо написаны , не совсем по теме или отсутствующим деталям.
Традиционно серверы имен отправляют не короткий ответ на запрос, а полный ответ в соответствии с RFC 1034 - 1035, который включает в себя раздел полномочий, содержащий записи ресурсов, которые указывают на авторитетный сервер (ы) имен.
Вероятно, причина в том, что с распределенным и делегированным характером DNS в то время казалось хорошей идеей включить «источник правды» в ответы.
В BIND это поведение можно настроить с помощью minimal-responses yes | no; директивы, где по умолчанию no задано значение, а разделы Authority и Additional ответа на запрос всегда будут заполнены полностью.
Другие серверы имен CloudFlare, AWS Route 53, Infoblocks и, возможно, другие уже будут отправлять такие минимальные ответы по умолчанию. Публичные распознаватели Google вернут раздел Authority, когда он будет доступен, Cloudflare.
Я думаю, что происхождение этой традиции, включающей как раздел полномочий, так и фактический ответ на запрос, коренится в (псевдо) коде из устаревшего RFC882, стр. 15-16.
спасибо за редактирование и дополнительную информацию. Я хотел бы дать вам больше, чем один голос ВВЕРХ :)
Это на самом деле не отвечает на вопрос. Мы уже знаем, полный ответ получен. Вопрос был в том, в чем выгода? Почему стандарт разработан таким образом? Какова ценность «дополнительной» информации в этой форме ответа?
@LightnessRacesinOrbit RFC не всегда включают мотивы дизайна. Чтобы прояснить «это казалось хорошей идеей в то время», я думаю, что причина, по которой традиционно добавляется раздел полномочий в дополнение к фактическому ответу на запрос, даже при том, что текущий RFC не предписывает, что происходит из (псевдо ) код из устаревшего RFC882 стр. 15-16 ". Если сервер имен не является полномочным, код копирует RR для более близкого сервера имен в ответ. В последнем разделе кода копируются все соответствующие RR в ответ . "
Сервер не знает, поступает ли запрос от конечного клиента или это рекурсивный запрос от другого сервера имен. Если это другой сервер имен, он может кешировать секцию полномочий и запрашивать эти серверы имен непосредственно в будущем.
Я считаю, что это было первоначальное обоснование в протоколе, но это имеет последствия для безопасности. Ответ может включать в себя раздел авторизации, в котором перечислены поддельные серверы имен, и это использовалось при атаках отравления кэша. Поэтому серверы имен, как правило, не будут кэшировать записи NS, если они не являются записями делегирования для субдомена запрашиваемого домена.
Сервер действительно может определить разницу между такими запросами. Во флагах есть немного, чтобы попросить рекурсию.
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
- Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
- Резолверпосылает запрос указанному серверу имен.
- Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
- Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
- Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
- пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
- и «вложенности» доменных имен.
- В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
- Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
- Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
- Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
- Запись заголовка — служебную информацию о запросе.
- Запись запроса — повторяет отправленный запрос.
- Запись ответа — собственно, сам ответ.
- Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
- Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Наглядно приведенную схему можно представить командами:
Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Резюме
Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.
Что еще почитать:
Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.
Серьезной проблемой современности являются сетевые угрозы ИБ, то есть классы угроз, реализуемых с использованием протоколов межсетевого взаимодействия. Одним из таких протоколов является протокол системы доменных имен — DNS.
К числу угроз, использующих систему доменных имен, относятся угрозы, основанные на модификации пакетов DNS-транзакций и направленные на создание в сети ложного маршрута. Их потенциальная опасность заключается в возможности перехвата данных, передающихся между клиентами сетевых сервисов и серверами этих сервисов.
Отследить модификацию пакетов DNS-транзакций, при потенциально высокой опасности реализации в информационных системах атак довольно непросто, поэтому становятся возможными такие атаки как:
- анализ сетевого трафика;
- подмена доверенного объекта сети;
- навязывание ложного маршрута;
- внедрение ложного объекта сети.
В состав типовой компьютерной сети, реализующей подмену IP-адреса для целевого домена, входят следующие элементы:
- Клиентская ПЭВМ (Клиент).
- Интернет-провайдер (в составе: кэширующий DNS-сервер, шлюз).
- Вспомогательный клиент.
- Система доменных имен.
- Точка мониторинга (межсетевой экран, фильтр, прокси-сервер).
- Сервер информационной службы.
- Существует контролируемый DNS-сервер, отвечающий за какую-либо (любую) зону системы доменных имен.
- Клиент обслуживается интернет-провайдером с кэширующим DNS-сервером либо известен иной DNS-сервер, услугами которого пользуется клиент, и данный сервер является кэширующим.
- В момент получения DNS-ответа от контролируемого DNS-сервера в кэше DNS-сервера интернет-провайдера отсутствует запись с целевым DNS-именем узла информационной службы.
- В точке мониторинга существует база IP адресов и доменных имен целевых информационных службы, в отношении которых ведется мониторинг и управление сетевым взаимодействием с клиентом.
Согласно рекомендациям RFC 1034, RFC 1035, устанавливающих порядок функционирования, спецификацию и применение системы доменных имен, при формировании DNS-ответа допускается добавление, так называемых полей «Additional». Данные поля необходимы для записи IP-адресов вспомогательных узлов различных типов, в том числе, для предотвращения повторного обращения к DNS-серверу, в случаях, когда по определенным причинам, основной узел, запись которого передается в поле «Answer», оказывается недоступным. В случае применения предлагаемого подхода, в поле «Additional» записывается IP-адрес, ставящийся в соответствие доменному имени целевой информационной службе, но реально принадлежащий точке мониторинга – межсетевому экрану.
Такую задачу (добавление нужного нам поля) можно возложить на скрипт, имитирующий работу легитимного DNS-сервера, отвечающего за какую-либо DNS-зону, причем не важно какого уровня…
После того как в процессе разрешения заданного DNS-имени кэширующий DNS-сервер интернет-провайдера (ISP) получает DNS-ответ, то при отсутствии записей в своей кэш-памяти соответствующих записям из дополнительных полей DNS-ответа, он помещает эти записи в кэш-память. Таким образом, в кэш-память DNS-сервера интернет-провайдера помещаются записи, устанавливающие соответствие доменных имен информационных служб, для которых будет осуществляться мониторинг, и IP-адреса, принадлежащего точке мониторинга. С этого момента, в случае, если клиент формирует DNS-запрос на разрешение имени узла целевой информационной службы с доменными именем, хранящимся в кэше провайдера и сохраненного из дополнительных полей, полученных после обработки DNS запроса «вспомогательного» клиента, то DNS-сервер интернет-провайдера формирует и отправляет DNS ответ клиенту на основе данных из своего кэша.
Таким образом, клиент получает разрешение доменного имени запрошенной информационной службы с IP адресом, полученным от контролируемого DNS сервера и хранящемся в момент обработки запроса клиента интернет-провайдером в кэш-памяти провайдера. При этом IP адрес принадлежит не целевой информационной службе, запрашиваемой клиентом, а точке мониторинга. Соответственно, далее, обращение клиента к целевой информационной службе происходит по IP адресу, принадлежащему точке мониторинга.
При обращении клиента по полученному IP адресу к точке мониторинга, в которой на основании предопределенных параметров сетевой политики безопасности производится ряд управляющих воздействий. К этим действиям относится:
- Разбор полученной от клиента транзакции.
- Выработка и применение управляющих воздействий.
- Аудит полученных транзакций и произведенных действий.
- Формирование на основе данных полученной клиентской транзакции запроса к информационной службе.
Проверка представленных изысканий производилась с использованием испытательного стенда в виде компьютерной сети со следующими элементами:
- DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".a", с доменным именем «ns.a».
- DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".b", с доменным именем «ns.b».
- Клиентская ПЭВМ с IP адресом 10.0.33.13.
- Точка мониторинга – межсетевой экран с IP адресом 10.0.33.13.
Между DNS-серверами пересылка зон настроена таким образом, что получая запрос на разрешения доменного имени из зоны, за который отвечает другой DNS сервер, текущий DNS сервер формирует и отправляет к нему повторный DNS запрос и, получив от него ответ, формирует и отправляет DNS ответ клиенту, сформировавшему первый запрос, одновременно помещая в свою кэш-память ответ от второго DNS сервера. Таким образом, моделируется работа DNS сервера интернет-провайдера.
На 2-м этапе происходит формирование и передача DNS-запроса для доменного имени «test.b» от клиента в систему доменных имен, состоящему из DNS сервера «ns.a» и DNS сервера «ns.b». При этом первичным DNS сервером (DNS сервером интернет-провайдера) для клиента является DNS сервер «ns.a».
Структура DNS-ответа
Проверка данного факта осуществляется командой
На основе представленных материалов проведенного эксперимента можно сделать вывод, что, при выполнении перечисленных условий и добавлению дополнительного поля «Additional» в DNS-коммутаторе при обработке запроса на разрешение доменного имени целевой информационной службы, возникает возможность осуществления контроля сетевого взаимодействия клиента и заданных информационных служб вне зависимости от их расположения и топологии компьютерной сети. Кроме этого появляется возможность мониторинга и контроля сетевого взаимодействия клиента и заданных информационных служб как на этапе установления сеанса соединения, так и на этапе информационного обмена, что не есть хорошо…
Концепции DNS, которые иногда путают с различием между авторитетным и рекурсивным:
Существует несколько концепций DNS, которые люди иногда путают с разделением достоверных и рекурсивных данных.
Делегация
Это сбивает с толку многих людей, особенно потому, что имя типа записи ресурса SOA (начало полномочий) содержит слово «полномочия», которое звучит так, как будто оно должно быть связано с «авторитетным». Тем не менее, вы можете предоставить достоверные данные для зоны, которая не делегирована вам, как делают многие. Примеры включают в себя блокировку контента на основе DNS и серверы, которые предоставляют достоверные ответы для зон RFC 1918 [т.е. никто не делегировал вам полномочия отвечать на запросы записей PTR для 168.192.in-addr.arpa (192.168.0.0/16) и аналогичных зон, но это не так. плохая идея для вашего сервера - отвечать на такие запросы авторитетно, а не просачивать запросы для тех зон в Интернет, где никому не поручено отвечать на них.
Не обязательно, чтобы вам были делегированы полномочия для зоны, чтобы ответы считались авторитетными.
Структура пакета DNS ответа
Проверка осуществляется командой
Структура запроса
Читайте также: