Чем отличается dns от dns

Обновлено: 05.07.2024

Этичный хакинг и тестирование на проникновение, информационная безопасность

Введение

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

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

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

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

Путь DNS-запроса

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

Некоторые приложения, в том числе большинство веб-браузеров, поддерживают внутренний кеш последних запросов. Если в нём есть такая функциональность, то это первое место, где приложение попытается найти IP-адрес домена, к которому нужно подключиться. Если оно не находит ответа на свой вопрос здесь, оно просит системного распознавателя (resolver — резолвер) выяснить, каков адрес доменного имени.

Затем рекурсивный сервер следует по пути отсылок к каждому последующему серверу имён, которому делегирована ответственность за компоненты домена, до тех пор, пока он не найдёт конкретный сервер имён, который имеет полный ответ. Он помещает этот ответ в кэш для последующих запросов, а затем возвращает его клиенту.

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

Функциональные различия

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

DNS серверы с только авторитативной функцией (Authoritative-Only)

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

Серверы с только авторитативной функцией имеют следующие свойства:

Очень быстро реагирует на запросы для зон, которые он контролирует. Сервер с только авторитативной функцией будет иметь всю информацию о домене, за который он отвечает, или справочную информацию для зон в домене, которые были делегированы другим серверам имён.
Не будет отвечать на рекурсивные запросы. Серверы с только авторитативной функцией по своему понятию не предназначены отвечать на них. Это делает его только сервером, а не клиентом в системе DNS. Любой запрос, достигающий Authoritative-Only сервера, обычно поступает от распознавателя (резолвера), получившего ссылку на него, а это означает, что Authoritative-Only сервер либо имеет полный ответ, либо сможет передать новую ссылку на сервер имён, которому была делегирована соответствующая ответственность.
Не кеширует результаты запроса. Поскольку сервер authoritative-only никогда не запрашивает информацию на других серверах для обработки запроса, то ему просто нечего кэшировать. Вся информация, которую он знает, уже находится в его системе.

Кеширующий DNS-сервер

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

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

Кэширующий DNS-сервер имеет следующие свойства:

Перенаправляющие (Forwarding) DNS-сервера

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

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

Перенаправляющий (Forwarding) DNS-сервер имеет следующие свойства:

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

Комбинированные решения

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

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

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

Различия в отношениях

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

Основной (Primary) и подчинённый (Slave) серверы

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

И главный, и подчинённый серверы являются авторитативными для зон, с которыми они работают. Главный (master) не имеет больше власти над зонами, чем Slave. Единственный различающий фактор между главным и подчиненным серверами — это то, откуда они читают свои файлы зон.

Главный сервер считывает файлы своей зоны из файлов на системном диске, обычно здесь администратор зоны добавляет, редактирует или передаёт исходные файлы зоны.

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

Серверы не обязательно должны относиться только к master или только к slave для всех зон, с которыми они работают. Главный или подчинённый статус присваивается по зонам, поэтому сервер может быть ведущим для некоторых зон и ведомым для других.

DNS-зоны обычно имеют как минимум два сервера имён. Любая зона, отвечающая за маршрутизируемую зону Интернета, должна иметь как минимум два сервера имён. Часто для обслуживания повышенной нагрузки и увеличения избыточности используется гораздо больше серверов имён.

Публичные и частные серверы

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

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

Хотя выше мы упомянули о возможности иметь один сервер для выполнения всех этих задач на «комбинированном» сервере, есть определённые преимущества для разделения рабочей нагрузки. На самом деле, поддержание совершенно отдельных серверов (внутренних и внешних), которые не знают друг друга, обычно является более предпочтительным вариантом. С точки зрения безопасности особенно важно, чтобы на общедоступном сервере не было приватных записей. Это означает не перечислять ваши частные серверы имён с записями NS в публичных файлах зон.

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

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

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

Заключение

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

Перенаправляющий/кэширующий DNS-сервер можно настроить даже на домашнем компьютере Linux. Такой сервер может полностью заменить файл /etc/hosts для обращения к ресурсам локальной сети. А при поступлении запросов для получения IP доменных имён, этот сервер будет получать данные от внешнего кэширующего сервера (например, 8.8.8.8 и 8.8.4.4 — DNS-серверы от Google) и сохранять полученные ответы в своём кэше — это в том случае, если вы настроили перенаправляющий DNS-сервер. Если же вы выберите рекурсивный кэширующий DNS-сервер, то он будет делать несколько запросов, начиная с корневых DNS-серверов и получать в конечном счёте ответы исключительно от авторитативных DNS-серверов (а не от сторонних кэширующих серверов, как это обычно происходит). Полученные данные также будут храниться в кэше. В случае повторных запросов этих имён, локальный DNS сервер их будет брать из кэша, что может немного ускорить работу сети.

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

Продолжение и дополнительный материал

Для продолжения знакомства с DNS рекомендуются следующие статьи:

[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]

DNS сервер это сокращение от Domain Name System (или Domain Name Service) - фактически система (или служба) серверов доменных имен.

DNS-серверы выполняют функцию преобразования доменных имен в IP-адреса и наоборот. Система DNS представляет собой базу данных, распределенную по всей сети Интернет, и целую сеть серверов. Каждый DNS-сервер знает своих «соседей» и способен быстро и автоматически, по специально разработанной иерархической схеме, опрашивать их, если к нему поступил запрос на установление соответствия «IP - доменное имя" или, наоборот, "доменное имя - IP». Для соединения с web-сервером и получения соответствующей web-страницы браузеру необходим IP-адрес этого имени. Браузер вызывает функцию DNS для получения данной информации. Функция отображения доменных имен в IP-адреса, которую предоставляет DNS, называется name resolution (разрешение имен). Протокол, который используется для выполнения функции разрешения имен, называется DNS-протокол.

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

Интернет представляет собой самую большую компьютерную сеть. С точки зрения пользователя, каждый узел или ресурс в этой сети идентифицируется уникальным именем – так называемым доменным именем. Некоторыми примерами ресурсов Интернет, для которых определяются доменные имена, являются: Web-серверы; Mail-серверы.

С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется IP-адресом, который представляет собой набор из четырех групп чисел, разделенных точками (например, 123.67.43.245). Для доступа к ресурсам Интернета по доменным именам, понятным пользователям, а не по этим IP-адресам, пользователям нужна система, которая преобразовывает доменные имена в IP-адреса и обратно. Такое преобразование является первоочередной задачей сервисов, называемых Domain Name System (DNS).

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

Функция DNS, описанная выше, включает следующие составные части. Во-первых, необходимо иметь репозиторий для хранения доменных имен и соответствующих им IP-адресов. Так как количество доменных имен весьма велико, то основными требованиями являются масштабируемость и эффективность. Также должно существовать ПО, которое управляет этим репозиторием и предоставляет функцию разрешения имен. Эти две функции (управление репозиторием доменных имен и предоставление сервиса разрешения имен) выполняются компонентой DNS, называемой name-сервер. Существует несколько категорий таких серверов – рекурсивный name-сервер и stub resolver, различающиеся по своим возможностям. Коммуникационный протокол, различные компоненты DNS, политики, которые определяют конфигурацию этих компонент, процедуры создания, хранения и использования доменных имен составляют инфраструктуру DNS.

Name-сервер

Name-сервер выполняет следующие функции:

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

Resolver’ы

Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

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

Базовые штуки

Давайте взглянем на маппинг между именем и адресом:

Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:

Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.

Оставшаяся часть ответа описывает сам ответ:

В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес ( 192.168.1.1 ), на какой порт стучался dig ( 53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.

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

Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:

Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.

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

Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.

В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!

Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!

Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.

Другие типы

Заметьте, что MX -запись указывает на имя, а не на IP-адрес.

Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

Что не так с CNAME

Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

Запросы к другим серверам

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

Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

CNAME для Heroku или Github

С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.

Wildcards

Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

Задумывались ли вы как мы вообще попадаем на какой-либо сайт? Где он лежит и почему адреса в интернете выглядит именно так? Сегодня мы поговорим о том,что такое DNS и IP адрес. Откуда появилось WWW? Как можно быстро и просто ускорить интернет, а также обезопасить себя в сети? И что мы будем делать, если или точнее когда адреса закончатся?

Система доменных имён

Поначалу, когда интернет только зарождался, IP-адрес сайтов и соответствующие им доменные имена хранились прямо на компе, в файле hosts. Пользователи Adobe Creative Cloud прекрасно знают этот файл.

Но, естественно, файл очень быстро стал расти, он не успевал обновляться, возникали различные конфликты имён.

И тогда в 1983 году Пол Мокапетрис придумал другую систему: автоматизированную, децентрализованную и надежную. И назвали её системой доменных имён или DNS - Domain, Name, System. Что это за система такая?

Структура доменного имени

com - это домен верхнего уровня
youtube - домен второго уровня
www - имя компьютера

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

Итого, мы получаем вот такую иерархию DNS-серверов. Зачем она нужна?

[caption align="aligncenter" width="640"] Источник: Andrey Sozykin (YouTube)[/caption] [caption align="aligncenter" width="640"] Источник: Andrey Sozykin (YouTube)[/caption]

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

Корневая доменная зона содержит записи всех доменов верхнего уровня: com, ru, org и т.д. Зона ru содержит записи всех доменов второго уровня. А, к примеру yandex адреса своих поддоменов - maps, taxi и других.

Кстати, тройное W в имени сайта - необязательная вещь, просто эта аббревиатура символ всемирной паутины: WWW - World Wide Web.

DNS Resolver

сначала спросить у корневого сервера, какой там адрес у RU-сервера,
потом у, нашего родного, RU-сервера узнать где лежит Yandex,
у Яндекса спросить где там maps.

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

Когда в DNS RESOLVER поступает запрос, найти адрес того или иного сайта, он делает всю грязную работу за нас, то есть отправляет запрос в корневой сервер и дальше по порядку. После чего, когда получает искомый адрес он отправляет его нам и одновременно записывает этот адрес себе в кэш. Поэтому, когда к нему повторно поступает такой же запрос, он может быстро вытащить адрес из кэша. При этом кэш обновляется каждые 24 часа, поэтому чаще всего записи там актуальные.

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

DNS и безопасность

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

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

CISCO UMBRELLA

Но как эту проблему решить? Если говорить о домашнем использовании, можно самостоятельно прописать адреса надежного публичного DNS-сервера для своего роутера и всех устройств.

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

А вот для компаний, особенно сейчас, в период работы на удаленке необходимы более продвинутые инструменты. Одно из самых крутых корпоративных решений - это Cisco Umbrella . Это облачная платформа обеспечения безопасности, которая при помощи глубоких нейронных сетей анализирует шаблоны интернет-трафика и автоматически выявляет инфраструктуру злоумышленников, вычисляет планируемые атаки, и заранее блокирует запросы к вредоносным узлам.

Имран Хан, сотрудник отдела развития бизнеса Microsoft, советник по бизнесу в компаниях zkCapital и NorthwesternU, в посте на Medium делает подробный обзор децентрализованных систем регистрации доменных имён и обрисовывает их перспективы.

История и архитектура DNS

Иерархия DNS

Управление DNS

Как работает DNS

Упрощённая схема работы DNS

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

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

Вот несколько возможностей для перехвата вашего запроса:

Почему стоит использовать блокчейн

Ниже я расскажу о проектах, которые работают над созданием системы серверов доменных имён на блокчейне.

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

Handshake

Handshake — это децентрализованный, не требующий подтверждения третьей стороны, совместимый с DNS протокол имён, при котором каждый участник отвечает за управление корневой зоной. Цель Handshake — создание альтернативы существующим органам сертификации.

При использовании Handshake «рекурсивные ресолверы указывают на авторитетные серверы доменных имен, которые привязаны к блокчейну, а не к файлу корневой зоны ICNN». Далее Handshake делает следующий шаг и создаёт для владельца доменного имени криптографический ключ. Он даёт своему обладателю возможность создавать криптографические подписи. Такой процесс, по существу, позволяет заменить органы сертификации, которые существуют сегодня.

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

Различия между Handshake и ENS

Резюме

Система Domain Name Servers ежедневно обрабатывает миллиарды запросов от устройств по всему миру. Если DNS однажды перестанет работать, мы не сможем получить доступ ко Всемирной сети. Сама по себе инфраструктура является распределённой, однако она полагается на работу серверов при обработке запросов. Такая зависимость от серверов делает систему уязвимой для хакерских атак, а также даёт правительствам больше возможностей подвергнуть цензуре контент, доставляемый пользователям.

Системы, основанные на блокчейне, предлагают надёжное решение для обеспечения безопасности и высокой масштабируемости, хотя, возможно, здесь могут быть подводные камни. Я в восторге от проектов, которые строятся на блокчейне, таких как Blockstack, Handshake и Ethereum Naming Services. Когда эти проекты достигнут больших масштабов, мы получим возможность работать с миллиардами запросов ежедневно. Я буду внимательно следить за их развитием и обязательно присоединюсь к ним, когда сервисы будут созданы.

Читайте также: