Как производится опрос dns сервера

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

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня «.com»), а также подчиненные ему узлы (напр., домен второго уровня «example.com», домен третьего уровня «mail.example.com» и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие «уровень» — показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

• «.» — домен нулевого уровня
• «.ru» — домен первого (верхнего) уровня
• «example.com» — домен второго уровня
• «mail.example.com» — домен третьего уровня
• Этот список можно продолжать

Обратите внимание на домен нулевого уровня «.» (dot — точка), также называемый корневым. На практике точку обычно не указывают («example.com» вместо «example.com.»), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце — полностью определенным (FQDN — Fully Qualified Domain Name).

Доменная зона — часть иерархического дерева доменных имен (напр. «.ru»), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены («anyaddress.ru», «any.anyaddress.ru»).

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

Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны («.ru»), так называемых «склеивающих» («glue») NS-записей для делегируемой дочерней зоны («example.com»), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня «example.com» и всех его дочерних доменов (например, «mail.example.com» и т.д.) хранятся на DNS-серверах этой компании, а родительская зона «.ru» хранит только указывающие на эти сервера NS-записи.

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

DNS-клиент — набор программных средств для работы с DNS. Сам DNS-сервер периодически также выступает в качестве клиента.

Основные типы ресурсных записей

Ресурсная запись (RR — Resource Record) — единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

• Имя (Name) — имя домена, к которому относится запись
• TTL (Time To Live) — допустимое время хранения записи неответственным сервером
• Тип (Type) — параметр, определяющий назначение и формат записи в поле данных (Rdata)
• Класс (Class) — тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
• Длина поля данных (Rdlen)
• Поле данных (Rdata) — содержание и формат поля зависят от типа записи

Ниже представлены типы dns записей, используемые чаще всего:

• A (IPv4 Address Record — адресная запись) — связывает доменное имя с IPv4-адресом хоста
• AAAA (IPv6 Address Record) — связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
• CNAME (Canonical Name Record — каноническая запись имени) — используется для перенаправления на другое доменное имя
• MX (Mail Exchange — почтовый обменник) — ссылается на почтовый сервер, обслуживающий домен
• NS (Name Server — сервер имен) — ссылается на DNS-сервер, ответственный за домен
• TXT — текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
• PTR (Point to Reverse — запись указателя) — связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Рекурсивные и нерекурсивные DNS-запросы

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

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

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

Как работают DNS-серверы

DNS работает очень просто:

1. В поле поиска браузера вводится запрос — доменное имя. Браузер перенаправляет запрос DNS-серверу, который ищет совпадения между доменным именем и IP.
2. Если совпадение найдено, DNS вернет IP-адрес, по которому браузер сделает запрос и отобразит полученные данные. Если совпадения не обнаружены, запрос будет перенаправлен корневому серверу.
3. Если DNS-запись не найдётся у корневого сервера — браузер вернёт страницу с кодом ошибки.

Стоит сказать, что существует ещё нулевой шаг. На нем браузер обращается к специальному файлу hosts, в котором могут быть прописаны пользовательские DNS-адреса. Это нужно для локального тестирования web-приложений.

О том как работать с файлом hosts, вы можете узнать из этого мануала, а если вы ищете удобный и бесплатный сервис по работе с DNS — обратите внимания на услугу DNS-хостинг от 1cloud.

Поделиться в соцсетях:

Средняя оценка: 5,0, всего оценок: 32 Спасибо за Вашу оценку! К сожалению, проголосовать не получилось. Попробуйте позже

191014 Санкт-Петербург ул. Кирочная, 9

235 70

1cloud ltd
2022-08-16 Основы работы со службой DNS
191014 Санкт-Петербург ул. Кирочная, 9

235 70

1cloud ltd

600 auto

Как производится опрос dns сервера

Среди ИТ-специалистов все более популярным сегодня становится вопрос разработки систем распространения контента (content distribution system), на успех работы которых очень влияет размещение информационных серверов. Речь идет о таком размещении серверов, при котором время доступа было бы если не минимальным, то хотя бы приемлемым (отвечающим SLA). Фактически, требуется в единицу времени обслужить максимальное число пользователей при заданном времени обслуживания одного. Например, для Web-страниц таким ограничивающим фактором будет приемлемое время загрузки страницы браузером, которое складывается не только из времени передачи данных по сети и времени их интерпретации, но также и времени, затраченного на поиск IP-адреса сервера в том числе и из времени обращения к сервису Системы Доменных Имен (DNS).

Мой адрес не дом и не улица…

Система доменных имен Internet – ключевой сервис, на который в сети замыкаются адреса информационных ресурсов, а точнее их идентификаторы (Uniform Resource Identifier, URI, RFC-2396 [1]). Как отмечено в RFC-3467 [2], посвященном роли системы доменных имен, архитектура DNS оставалась неизменной с момента своего создания, в то время как ее функции существенно изменились — коммерциализация Сети привела к существенному «уплощению» иерархии доменных имен. Владельцы сервисов предпочитают использовать домены 2-ого уровня в рамках национальных доменов или доменов общего назначения, например microsoft.com, а не закапываться вглубь иерархии имен. Кроме того, начиная с 90-х годов, систему DNS стали использовать в качестве инструмента балансировки нагрузки серверов информационных ресурсов, эксплуатируя для этого алгоритм Round Robin, который применяется серверами доменных имен при ответе на запросы клиентов. Ни первое, ни второе при проектировании системы доменных имен не предполагалось. Во всяком случае, в основополагающих документах RFC-1034 [3] и RFC-1035 [4] этого не указано.

Вспомним типовую схему поиска IP-адреса по доменному имени (рис.1)

Рис.1. Схема получения IP-адреса по известному доменному имени в системе DNS

Браузер через механизм resolver обращается к локальному кэширующему серверу доменных имен с рекурсивным запросом. Этому серверу передается доменное имя, для которого нужно найти IP-адрес. Сам браузер IP-адрес не ищет, а перепоручает это локальному кэширующему серверу доменных имен (в этом может убедиться каждый, кто сам настраивал подключение своего компьютера к Сети). При подключении через провайдера, например, по коммутируемому соединению, этого делать не нужно: сеть настраивается в большинстве случаев автоматически (в момент автоматической настройки провайдер по протоколу PPP присылает IP-адреса серверов доменных имен, которые будут выполнять рекурсивные запросы пользователя).

На схеме (Рис. 1) указаны два типа запросов: рекурсивный и нерекурсивный. Первый – это запрос, при котором клиент перепоручает поиск IP-адреса серверу, второй – запрос при котором клиент сам производит опрос серверов. Локальный кэширующий сервер самостоятельно опрашивает все серверы доменных имен, поэтому он обменивается с ними нерекурсивными запросами.

В системе доменных имен существует жесткая иерархия имен. Начинается она с корня, который часто обозначают как «.», хотя это и не совсем правильно. Затем следуют домены верхнего уровня (Top Level Domains, TLD), например, com., org., net., ru. и т.п. Далее следуют домены второго уровня, например, nic.ru, vesti.ru и т.п. Каждый домен поддерживается авторитарным сервером домена и, как правило, не одним. При этом сервер, который поддерживает старшие имена, имеет возможность перепоручить управление младшими именами другому серверу. Такое перепоручение отражается в описании домена, управляемом сервером, и называется делегированием. Та часть дерева иерархи имен, которой управляет сервер, называется зоной. Если серверу поручено управлять корнем дерева имен, и он перепоручил все TLD другим серверам, то в его ведении остается только управление соответствиями между именами доменов и именами серверов, которым он эти домены перепоручил.

Кому поручено управления младшими именами, знает только тот сервер, который осуществляет делегирование, поэтому, когда мы ищем что-то в домене RU, мы сначала должны узнать, кто поддерживает домен RU, а потом, кто поддерживает ту часть домена RU, которая, собственно, нас и интересует. На первый вопрос отвечает корневой сервер, который обслуживает «корень» имен DNS – корневую зону. Таких серверов 13 — 10 в США, 2 в Европе и один в Японии. До сих пор такое размещение было оправдано (согласно данным CIADA (Cooperative Association for Internet Data Analysis) [5] около 60% клиентов корневых серверов размещены в США). На второй вопрос ответят серверы, поддерживающие национальный домен RU. Их шесть: три размещены в России и три в Европе. Кстати, если верить статистике Фонда «Общественное мнение» [6], то 19% пользователей Рунета находятся в Москве, там же, где расположены и три российских сервера зоны RU. С точки зрения использования DNS, правильнее ориентироваться на данные SpyLog, которые получены на основе агрегирования статистики его счетчиков, размещенных на Web-сайтах — на апрель 2003 года в Москве находилось 43% всех городских пользователей Рунета [7].

После получения ответа с сервера, поддерживающего национальный домен, мы можем обратиться к авторитативному (authorative) серверу домена, которому принадлежит интересующее нас имя. Авторитативным этот сервер называют по той причине, что именно ему делегировано право отвечать на запросы к именам из этого домена. По правилам делегирования доменов второго уровня в RU для каждого домена таких серверов должно быть не менее двух. Вообще говоря, их может быть и больше — RFC-2182 [8] рекомендует иметь три. Нарушением регламента регистрации доменов, способным повлечь временную приостановку делегирования, является ситуация когда, суммарное время отсутствия связи с сервером превышает два часа за сутки [9]. Ели домен обеспечен тремя серверами, то вероятность отказа сразу на двух серверах меньше, чем на одном, что существенно понижает риск временной потери делегирования. На самом деле, локальный кэширующий сервер доменных имен обращается к корневым серверам и авторитативным серверам домена RU только тогда, когда не может найти необходимый ему адрес в своем кэше.

Время хранения соответствий в кэше сервера определяется временем TTL (Time To Live), которое устанавливает администратор соответствующего домена. Например, TTL имен авторитативных серверов домена RU равно 86400 секунд или 1 сутки, т.е. после первого обращения за адресом из домена RU локальный кэширующий сервер доменных имен обратиться к корневому серверу за получением списка авторитативных серверов домена RU только через сутки. Аналогичная схема работает и для всех остальных доменов. Если один пользователь обратился, например, к www.yandex.ru через локальный кэширующий сервер dialup провайдера, то этот сервер будет обслуживать всех остальных пользователей этого провайдера в течение суток, не обращаясь ни к корневым серверам доменных имен, ни к авторитативным серверам домена RU. Но, если в качестве примера выбрать www.rambler.ru, то такое кэширование (по данным на июнь 2003 года) будет осуществляться только 1 час. А для mail.ru это время будет равно двум часам. Таким образом, для конкретного пользователя системы DNS время отклика будет варьироваться от времени полного опроса всех серверов, обслуживающих искомый адрес, начиная от корневого сервера и кончая авторитативным сервером поддомена, до времени опроса только своего локального кэширующего сервера.

Вернемся к вопросу о времени отклика на запрос, а точнее к RTT (Round Trip Time), которое обычно и используют в качестве основы различных метрик в расчетах эффективности размещения сервисов [5].

Не думай о секундах с высока…

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

Как показывают исследования [10, 11], все зависит от того, какую задачу решает пользователь. При этом обычно исследуют либо время задержки, которое начинает вызывать раздражение, либо влияние времени задержки на эффективность работы в целом. Обычно время задержки (загрузки Web-страницы) свыше 1 с., вызывает дискомфорт, однако, если пользователь знает, что он получит, то раздражения не вызывают и задержки до 5 секунд. Но после 30 с. речь уже не может идти об интерактивной работе. В целом для работы с известным интерфейсом подходит следующая шкала: до 5 секунд – «хорошо»; до 10 секунд – «удовлетворительно»; более 10 секунд – «плохо». Однако, если показывать элементы страницы по мере их получения, то шкала для времени полной загрузки страницы изменится: до 39 с. – «хорошо»; до 56 с. – «удовлетворительно»; более 56 секунд – «плохо». Любопытно и другое — непреодолимое желание «ускорить» процесс возникает в среднем после 8,6 секунд ожидания хоть какого-нибудь результата.

С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт [12] – именно столько удается передать при dialup-соединении со скоростью 28800 бит/c за 3 – 5 с. На самом деле не стоит надеяться, что зашедший первый раз на ваш сайт пользователь будет ждать 5 секунд, а уж баннеры большинство пользователей однозначно не любят, поэтому при разработке страниц стоит все-таки стремиться к односекундной задержке до появления первого символа на экране.

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

Попытка — не пытка…

Фактически, алгоритм поиска IP-адреса по имени – это многоступенчатый процесс, состоящий из серий попыток, которые выполняет «решатель» resolver и локальный кэширующий сервер (рис.1). У каждого из них примерно одинаковый механизм опроса серверов доменных имен за исключением того, что кэширующий сервер применяет ранжирование авторитативных серверов зон по RTT. Рассмотри этот алгоритм более внимательно.

В настройках resolver обычно указывают один-два сервера доменных имен, к которым он обращается с рекурсивными запросами. Процесс опроса начинается с первого сервера в списке и идет последовательно. Может быть совершено до четырех попыток. В первой попытке resolver ждет отклика от сервера 5 секунд, после чего переходит к следующему серверу. Если ответ не получен, то период ожидания увеличивается вдвое, и опрос серверов возобновляется с первого сервера в списке. Если resolver использует только один сервер, то тогда максимальное время ожидания отклика равно 75с (5+10+20+40). Если серверов несколько, то возможно два варианта. В первом приведенный алгоритм справедлив для каждого сервера [13], во втором время ожидания при каждой попытке на каждом сервере получается как результат деления установленного для данной попытки времени ожидания на число серверов. Например, для первой попытки и случая двух серверов оно будет равно 5/2 [14].

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

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

На самом деле различные серверы применяют различный алгоритм выбора первого сервера для опроса [15] — BIND ранжирует серверы по RTT, а Windows выбирает просто случайным образом из полученного списка.

Что же дает анализ работы resolver в плане понимания компонентов времени отклика при поиске адреса? Во-первых, первым в настройках resolver должен быть указан сервер, который быстрее всего откликается на запросы клиента, т.е. локальный кэширующий сервер должен быть расположен как можно ближе к пользователю. Во-вторых, все серверы зоны должны быть одинаково хорошо расположены относительно пользователя, точнее его кэширующего сервера, т.к. не факт, что клиент Windows, например, запросит тот сервер, который лучше всего расположен относительно него. В-третьих, с точки зрения «человеческого фактора» время задержки в 5 секунд достаточно большое для того, чтобы браузер пользователя многократно обращался к серверам.

Что такое хорошо, и что такое плохо…

Какое время отклика DNS сервера принято считать «хорошим», а какое «плохим»? Посмотрим при этом на наиболее загруженные и критичные с точки зрения всей системы серверы – корневые и те, что обслуживают «национальные» домены.

За последние два года было проведена ряд исследований в этой области. Специалисты CIADA[5] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время большее 0,5 с. Следует заметить, что для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода пока проводились эти исследования доля точек в России с большим откликом не изменилась (например, на Украине она увеличилась в два раза) и была отмечена общая тенденция к сокращению времени отклика.

Более точные измерения проведены работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16] для США и Европы характерным временем отклика является время меньше 0,2 с. Здесь следует оговориться. В силу различных причин, основной объем DNS трафика приходится на корневой A-сервер, поэтому именно время отклика от этого сервера и является определяющим, а оно при прямом подключении (исследовался также и dialup) в редких случаях превышает 0,2 с. Как правило, время отклика ccTLD серверов несколько хуже, чем корневых — порядка нескольких десятых долей секунды. Например, для Парижа среднее время отклика A-сервера равно 0,18 с, а сервера национального домена FR – примерно, 0,25 с.

В этой связи интересно посмотреть, а какое время отклика имеют серверы, поддерживающие домены в зоне RU? Для этого было решено замерять время обращения за SOA (Start Of Authority) записью зоны, для которой сервер является авторитативным, проверять авторитативность отклика и запоминать RTT отклика. Измерения проводились из точки, для которой значение RTT до ns.ripn.net было равно 0,0013 с (запрос SOA для зоны RU), т.е. фактически от авторитативного сервера зоны RU. Полученное распределение приведено на рис.2.

Рис.2. Распределение времени отклика серверов доменов второго уровня в зоне RU

Cогласно статистике компании RU-CENTER, на момент проведения измерений в зоне RU было 28106 серверов [17], которые поддерживали домены второго уровня. Это означает, что 48% серверов имели время отклика менее 0,1 секунды. Еще 12% попадали в интервал от 0,1-0,2 с. Приемлемое время отклика до 1 секунды имело 79% серверов и до 5 с укладывался 81% серверов.

Интересно посмотреть на 10 самых медленных (Таблица 1) и самых быстрых (Таблица 2)серверов из 50 наиболее популярных (по числу поддерживаемых ими уникальных доменов в зоне RU).

Измерения проводились в июле 2003 года в течении одной недели. В качестве точки отсчета RTT (Round Trip Time) выбрана была точка обмена трафиком M9.

Понятно, что сервера с «заграничной» маршрутизацией проигрывают по времени отклика «местным» серверам.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне RU, как и во всем мире [18], в большинстве случаев (70%) одновременно являются и серверами, которые выполняют рекурсивные запросы. Чем ближе данный сервер расположен к корневому серверу, тем лучше и тем больше времени из интервала «приемлемого времени» останется на передачу полезной информации, а не на накладные расходы, которыми является сервис DNS.

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

Есть еще один момент. Например, rambler.ru, как уже было указано, кэшируется только час, а время доступа до него от ns.ripn.net 0,004 с. Для mail.ru время доступа от ns.ripn.ru тоже 0,004 с. Время определяется не только физическим расстоянием, но и качеством, и пропускной способностью канала. Например, для сервера ns.nsk.ru время отклика составляет 0,18 с, а для ns.spb.su – 0,019 с. В таких условиях времена отклика серверов доменных имен хостинг-провайдеров, которые превышают 0,15 секунды выглядят плохо. Понятно, что это, скорее всего дулирующие серверы (secondary), но алгоритмы выбора серверов resolver предполагают «одинаковость» авторитативных серверов доменов.

Сухой остаток

Следует признать «приемлемым» время загрузки от 1 до 5 с, а в качестве цели, которую желательно достичь при разработке страниц сайтов – 1 с до появления первого символа на экране пользователя.

В качестве цели при размещении DNS серверов следует признать такое время поиска в системе DNS, которое не превышало бы 0,15 с. Согласно измерениям времени отклика серверов доменных имен второго уровня в зоне RU, более половины серверов удовлетворяют этим условиям.

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

«Хорошо» размещать нужно не только primary (master) сервер зоны, но и все авторитативные серверы — неисправность любого из них грозит приостановкой делегирования, а кроме того, совершенно не обязательно, что resolver-сервер пользователя выберет при поиске primary сервер.

Таблица 1. Десять самых быстрых из 50-и наиболее популярных на июль 2003 года

Как работает технология DNS

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

Зачем нужна технология DNS и как она работает

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

Работу DNS-технологии в качестве этой самой «телефонной книги» обеспечивает DNS-сервер — оборудование или программное обеспечение, с помощью которого предоставляется доступ к системе доменных имен, хранятся данные о соответствии конкретного IP-адреса соответствующему домену, а также осуществляется кэширование информации в виде IP-адреса и соответствующего ему домена других DNS-серверов.

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

Ниже список самых популярных и общедоступных DNS-серверов (актуально на октябрь 2021):

• Google: 8.8. 8.8 & 8.8. 4.4.
• Quad9: 9.9. 9.9 & 149.112. 112.112.
• OpenDNS: 208.67. 222.222 & 208.67. 220.220.
• Cloudflare: 1.1. 1.1 & 1.0. 0.1.
• CleanBrowsing: 185.228. 168.9 & 185.228. 169.9.
• Alternate DNS: 76.76. 19.19 & 76.223. 122.150.
• AdGuard DNS: 94.140. 14.14 & 94.140.

Схема работы DNS-технологии

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

Затем браузер делает запрос на сервер по этому IP-адресу и после получения ответа отображает страницу ресурса.

Выделим основные характеристики DNS-технологии:

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

Как работают DNS-серверы:

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

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

Примечание: Помимо работы с публичными адресами, есть DNS, способные работать только с частными именами внутри VPS (Virtual Private Server). Например, система доменных имен от SberCloud позволяет гибко настраивать частные доменные имена в виртуальных ЦОДах VPC, быстро реагировать на запросы о доступе к виртуальным машинам ECS в VPC, а также к ресурсам OBS и RDS. Система также позволяет связать одну частную зону с несколькими VPC для единого управления. При этом безопасность обеспечивается мощными средствами от DDoS-атак.

Что такое DNS-зоны

Под понятием «зона» в системе доменных имен подразумевается часть пространства DNS-имен, которая управляется либо группой серверов, либо одним сервером. Зона DNS применяется для размещения DNS-записей конкретного домена. Каждая запись для домена создается внутри конкретной зоны DNS. Принято разделять зоны обратного и прямого просмотра в зависимости от того, какой поиск ведется внутри — по доменному имени ищут IP-адреса или по IP-адресу ищут доменное имя.

Geo-DNS

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

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

Атаки на DNS-серверы и способы защиты

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

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

Чтобы защититься от атак, необходимо встраивать средства защиты и безопасности DNSSEC, TSIG, DANE, а также предпринимать меры:

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

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

Резюме

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

DNS-технология появилась вместо словаря на сервере Стэнфордского исследовательского института в ответ на необходимость сопоставлять быстрорастущее количество IP-адресов с доменными именами. По аналогии с этим, когда в облаке растет количество используемых ресурсов, можно использовать DNS для обращения к виртуальным машинам, хранилищам или базам данных по доменным именам в частной зоне. В дополнение к этому современные DNS-сервисы дают ряд таких преимуществ, как защита от DNS-спуфинга и DDoS-атак, которые предлагает Domain Name Service облака SberCloud Advanced Сергей Кулаков старший технический писатель, SberCloud

Запросите бесплатную консультацию по вашему проекту