Dns система доменных имен год создания
DNS (англ. ) — распределённая система (распределённая база данных), способная по запросу, содержащему доменное имя хоста (компьютера или другого сетевого устройства), сообщить IP адрес или (в зависимости от запроса) другую информацию. DNS работает в сетях TCP/IP. Как частный случай, DNS может хранить и обрабатывать и обратные запросы, определения имени хоста по его IP адресу — IP адрес по таблице соответствия преобразуется в доменное имя, и посылается запрос на информацию типа «PTR».
Содержание
Сеть интернет работает на основе системы DNS, в которой содержатся доменные имена и IP-адреса. Существует 13 корневых серверов DNS с информацией о доменах верхнего уровня, таких как .com, .ru, .uk и т.п. Большинство из них расположены в США, несколько - в Европе и Японии, а также в разных странах есть "зеркала", которые дублируют информацию. Управлением DNS-серверов занимается международная некоммерческая организация ICANN, расположенная в США.
2021: «Ростелеком» запретил использование публичных DNS-серверов Google, Cloudflare и сервиса DoH
Как пишет Telegram-канал «Двач», «Ростелеком», вероятно, действует согласно указаниям Роскомнадзора и таким образом прорабатывается блокировка Рунета.
Как ранее сообщалось, в сентябре Роскомнадзор планирует протестировать блокировку ряда иностранных интернет-протоколов, скрывающих имя сайта, включая DoH, который внедряют Mozilla и Google. Такие протоколы могут затруднить блокировку доступа к запрещенным ресурсам.
Чтобы сохранить работоспособность сетей, ведомство рекомендовало компаниям до 9 сентября подключиться к DNS-сервисам российских операторов связи или Национальной системе доменных имен (НСДИ).
Вместо указанных серверов и DoH «Ростелеком» предложил использовать DNS-серверы под собственным управлением или IP-адреса Национальной системы доменных имен.
В пресс-службе компании рассказали, что благодаря этому планируется повысить надежность и оптимизацию работы сетей связи. По словам источника издания на ИТ-рынке, «Ростелеком» хочет унифицировать все DNS-серверы, на которые настроены устройства российских абонентов.
DNS-серверы позволяют обмениваться запросами и ответами по шифрованному протоколу. Они могут использоваться, чтобы, например, ускорить загрузку веб-страниц или обойти блокировку в приложениях.
Технический директор «Роскомсвободы» Станислав Шакиров рассказал РБК, что компании заранее переводят клиентов на другие серверы на случай возможной блокировки публичных DNS-серверов Google и Cloudflare. Анонимный источник издания полагает, что основная цель ограничений — прекратить работу протокола DoH, поскольку на мобильных сетях практически нет проблем с блокировкой доступа к запрещенным сайтам.
Независимый эксперт в области информационной безопасности Алексей Лукацкий считает, что блокирование публичных DNS-серверов — это часть кампании, в рамках которой на прошлой неделе некоторые госкомпании разослали письмо своим «дочкам», а Банк России — финансовым организациям с просьбой проверить, есть ли у компаний корпоративные, технологические сети и приложения, которые используют протоколы шифрования, скрывающие имя сайта (DNS-сервера Google, Cloudflare и сервис DoH). По мнению Лукацкого, такие действия ведут к существенному ограничению публичных DNS-серверов Google и Cloudflare в России. [1] [2]
ICANN обеспокоена угрозой безопасности ключевых элементов интернета
Ключевые элементы инфраструктуры мирового интернета находятся под угрозой масштабных кибератак. Об этом сообщили представители корпорации ICANN информагентству Agence France-Presse (AFP) 22 февраля [3] .
Как сообщает AFP, ICANN провела экстренное заседание в связи с «непрерывным высоким риском», которому подвергаются ключевые элементы инфраструктуры интернета. По словам старшего технологического директора корпорации Дэвида Конрада (David Conrad), злоумышленников интересует сама инфраструктура, лежащая в основе глобальной сети. «В прошлом уже были атаки, но ни одна не сравнится с этими», - отметил Конрад.
Атаки начались еще в 2017 году, однако стали вызывать обеспокоенность у исследователей безопасности только сейчас, в связи с чем и было собрано экстренное заседание. Злоумышленники атакуют DNS, что, по словам экспертов ICANN, потенциально может позволить им перехватывать трафик, тайно перенаправлять его в другое место и подделывать критически важные сайты.
По данным старшего аналитика FireEye в области кибершпионажа Бена Рида (Ben Read), атаки под названием DNSpionage начались в 2017 году. Атакующие в основном перехватывают учетные данные регистраторов доменных имен и интернет-провайдеров в странах Среднего Востока. За атаками предположительно стоят иранские хакеры, действующие в интересах иранского правительства.
«Какого-то одного инструмента для решения данной проблемы не существует», - сообщил Конрад. В связи с этим ICANN призывает специалистов усилить безопасность инфраструктуры интернета в целом.
С 1 февраля 2019 года многие сайты в интернете станут недоступными
Ряд DNS-сервисов и производителей DNS-серверов объявили [4] в январе 2019 года о проведении дня корректной обработки DNS-запросов или так называемого «Дня флага» (Flag Day). В этот день, намеченный на 1 февраля 2019 года, участники инициативы откажутся от реализации обходных путей для авторитативных DNS-серверов без поддержки протокола EDNS. К указанной дате каждый участник инициативы реализует соответствующие изменения в определенной версии своего ПО [5] .
В случае с BIND 9 обходные пути будут закрыты в версии BIND 9.14.0, запланированной к выпуску на 1 февраля. Нововведение уже доступно для ветки 9.13, но не будет портировано на 9.11 или более ранние ветки BIND, поскольку, согласно политике компании, в стабильные версии с продленной поддержкой изменения не вносятся. В авторитативном (первичном) DNS-сервере BIND поддержка протокола EDNS уже реализована.
С 1 февраля домены, обслуживающиеся несовместимыми с EDNS DNS-серверами, могут стать недоступными. Компании, чьи зоны DNS обслуживаются несовместимыми серверами, должны понимать, что их присутствие в интернете начнет существенно сокращаться и может сойти на нет, поскольку интернет-провайдеры и другие организации обновят свои DNS-резолверы. После обновления резолверов до версии без обходных путей некоторые сайты и почтовые серверы могут оказаться недоступными.
2018: Впервые в истории интернета обновлены ключи шифрования для защиты DNS
11 октября 2018 года состоялась первая в истории интернета и долгожданная замена криптографических ключей, защищающих систему доменных имен (DNS). Этот процесс, как сообщили в [[Internet Corporation for Assigned Names and Numbers ICANN|Корпорации по управлению доменными именами и IP-адресами (ICANN)]], прошла без неполадок.
ICANN планировала менять ключи каждые пять лет. В первый раз смена ключей должна была произойти в 2015 году, но ее откладывали из-за низкого уровня готовности интернет-провайдеров.
В ICANN предупреждали, что ряд интернет-пользователей, чьи сетевые операторы или интернет-провайдеры не будут готовы к смене ключа, могут столкнуться с проблемами. Они могут возникнуть при преобразовании имени ресурса в числовой IP-адрес, который компьютеры используют для соединения друг с другом.
Вице-президент ICANN по исследовательской деятельности Мэтт Ларсон уверен, что такое обновление криптографических ключей станет обычным делом для операторов. [6]
2017: Минкомсвязи поручили создать "независимый интернет" для стран БРИКС
В ноябре 2017 года Совет безопасности России поручил Минкомсвязи совместно с МИД РФ до 1 августа 2018 года проработать вопрос создания собственной системы корневых серверов доменных имен, или DNS, в странах БРИКС (Бразилия, Россия, Индия, Китай и Южная Африка). Иными словами, пишет РБК, Совбез поручил сделать интернет в этих странах не зависимым от международных организаций и воздействия извне.
"В рамках существующего интернета независимости достигнуть нельзя, все равно информация по корневым серверам будет расходиться из одной точки — IANA. Таким образом, создание системы корневых серверов доменных имен, независимой от международных администраторов, эквивалентно созданию альтернативного интернета, независимого от существующего", - цитирует издание представителя "Технического центра Интернета" (ТЦИ), который поддерживает DNS-структуру российского сегмента сети.
Таким образом, создание альтернативных DNS-серверов приведет к фрагментации интернета и созданию обособленной сети, отмечают наблюдатели.
2014: Передача функций контроля за управлением корневой зоной DNS от правительства США
В декабре 2014 года Межотраслевая рабочая группа ICANN подготовила предложения по передаче функций контроля за управлением корневой зоной DNS от правительства США интернет-сообществу. С инициативой передачи этих функций выступила весной нынешнего года Национальная администрация по телекоммуникациям и информации (NTIA), входящая в состав Министерства торговли США. Межотраслевая рабочая группа из 119 членов представила два варианта передачи функций.
Один из них проговорен в самых общих чертах, поскольку предусматривает передачу функций контроля непосредственно корпорации ICANN. При этом исполнение функций будет контролироваться через существующие механизмы подотчетности ICANN.
Другой вариант предполагает создание новой структуры, надзирающей за деятельностью ICANN по управлению доменной системой и управляемой представителями интернет-сообщества. Авторы предложений подчеркивают, что речь идет о некоммерческой структуре с минимальным числом сотрудников. Таким образом, межотраслевая рабочая группа стремится, очевидно, избежать того, чего опасаются многие наблюдатели – создания «еще одной ICANN для надзора над ICANN».
Структура, условно обозначенная в документе как Contract Co, и возьмет на себя функции NTIA по контролю за управлением корневой зоной DNS. Выработка условий контракта с Contract Co и надзор за соблюдением его исполнения будут возложены на комитет Multistakeholder Review Team, сформированный из числа делегатов всех сообществ, чьи интересы представляет ICANN. Механизмы формирования этого комитета пока не определены и, вероятно, станут предметом жарких дискуссий, поскольку к максимальному представительству в нем будут стремиться самые разные группы с зачастую противоположными интересами.
Также будет сформирован новый постоянный комитет Customer Standing Panel, куда войдут представители регистратур общих и национальных доменов верхнего уровня – как главные «потребители услуг» корневой зоны DNS. Он будет транслировать комитету Multistakeholder Review Team пожелания регистратур, обеспечивая тем самым подотчетность ICANN перед ними. Наконец, предполагается и создание независимого апелляционного комитета, куда могут быть поданы жалобы на любые решения, связанные с управлением корневой зоной DNS, включая, очевидно, и решения о делегировании либо снятии с делегирования доменов.
Предложения опубликованы на сайте ICANN, комментарии к ним принимаются до 22 декабря 2014 года. Окончательное предложение правительству США по передаче функций контроля над управлением корневой зоной DNS должно быть сформулировано летом 2015 года.
Ключевые характеристики DNS
DNS обладает следующими характеристиками:
- Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.
- Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
- Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
- Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.
Дополнительные возможности
- поддержка динамических обновлений
- безопасные соединения (DNSsec)
- поддержка различных типов информации (SRV-записи)
Терминология и принципы работы
Ключевыми понятиями DNS являются:
Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.
Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.
Рекурсия
Рассмотрим на примере работу всей системы.
В данном случае при разрешении имени, то есть в процессе поиска IP по имени:
- браузер отправил известному ему DNS-серверу т. н. рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;
- DNS-сервер, получив запрос от клиента, последовательно отправлял итеративные запросы, на которые получал от других DNS-серверов ответы, пока не получил авторитетный ответ от сервера, ответственного за запрошенную зону.
В принципе, запрошенный сервер, мог бы передать рекурсивный запрос «вышестоящему» DNS-серверу и дождаться готового ответа.
Запрос на определение имени обычно не идёт дальше кэша DNS, который сохраняет ответы на запросы, проходившие через него ранее. Вместе с ответом приходит информация о том, сколько времени разрешается хранить эту запись в кэше.
Обратный DNS-запрос
DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.
Записи DNS
Наиболее важные типы DNS-записей:
Зарезервированные доменные имена
Интернациональные доменные имена
Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.
Программное обеспечение DNS
- BIND (Berkeley Internet Name Domain)
- djbdns (Daniel J. Bernstein's DNS)
- MaraDNS
- NSD (Name Server Daemon)
- PowerDNS
- Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
- MyDNS
Атаки на DNS-серверы
Все программные решения DNS требуют защиты. Ведь, если хакер атакует DNS-сервер, то пользователи будут попадаться в ловушку, даже не подозревая об этом.
Во–первых, в результате DNS-атак пользователь рискует не попасть на нужную страницу. При вводе адреса сайта атакованный DNS будет перенаправлять запрос на подставные страницы.
Во–вторых, в результате перехода пользователя на ложный IP–адрес хакер может получить доступ к его личной информации. При этом пользователь даже не будет подозревать, что его информация рассекречена.
Информация о домене
Многие домены верхнего уровня поддерживают сервис whois, который позволяет узнать кому делегирован домен, и другую техническую информацию.
В прошлый раз мы начали рассказывать историю DNS — вспомнили, с чего стартовал проект, и какие проблемы был призван решить в сети ARPANET. Сегодня поговорим о первом DNS-сервере BIND.
Фото — John Markos O'Neill — CC BY-SA
Первые DNS-серверы
После того как в 1983 году Пол Мокапетрис (Paul Mockapetris) и Джон Постел (Jon Postel) предложили концепцию доменных имен для сети ARPANET, она достаточно быстро снискала одобрение ИТ-сообщества. Одними из первых реализовать её на практике взялись инженеры из Университета в Беркли. В 1984 году четыре студента представили первый DNS-сервер — Berkeley Internet Name Domain (BIND). Они работали в рамках гранта, выданного Управлением перспективных исследовательских проектов Министерства обороны США (DARPA).
Разработанная учащимися университета система автоматически преобразовывала DNS-имя в IP-адрес и наоборот. Интересно, что когда её код загрузили на BSD (систему распространения ПО), первые исходники уже имели номер версии 4.3. Первое время DNS-сервером пользовались сотрудники лабораторий университета. Вплоть до версии 4.8.3 за разработку BIND отвечали члены исследовательской группы Университета в Беркли — Computer Systems Research Group (CSRG), но во второй половине 1980-х DNS-сервер вырвался за пределы вуза — его передали в руки Пола Викси (Paul Vixie) из корпорации DEC. Пол выпустил обновления 4.9 и 4.9.1, а потом основал Internet Software Consortium (ISC), который с тех пор и отвечает за поддержку BIND. По словам Пола, все предыдущие версии опирались на код студентов из Беркли, и за прошедшие пятнадцать лет он полностью исчерпал свои возможности для модернизации. Поэтому в 2000 году BIND переписали с нуля.
Сервер BIND включает в себя сразу несколько библиотек и компонентов, реализующих «клиент-серверную» архитектуру DNS и отвечающих за настройку функций DNS-сервера. BIND широко распространен, особенно на Linux, и остается популярной реализацией DNS-сервера. Это решение установлено на серверах, обеспечивающих поддержку корневой зоны.
BIND и PowerDNS одни из самых распространенных, но не единственные DNS-серверы. Также стоит отметить Unbound, djbdns и Dnsmasq.
Развитие системы доменных имен
За всю историю DNS в её спецификацию вносили множество изменений. В качестве одного из первых и крупных обновлений добавили механизмы NOTIFY и IXFR в 1996 году. Они упростили репликацию баз данных системы доменных имен между первичным и вторичным серверами. Новое решение дало возможность настраивать уведомления об изменении DNS-записей. Такой подход гарантировал идентичность вторичной и первичной DNS-зоны плюс экономил трафик — синхронизация происходила только при необходимости, а не через фиксированные интервалы.
Фото — Richard Masoner — CC BY-SA
Изначально DNS-сеть была недоступна для широкой публики и потенциальные проблемы с ИБ не являлись приоритетом при разработке системы, но такой подход дал о себе знать впоследствии. С развитием интернета уязвимости системы начали эксплуатировать — например, появились такие атаки как DNS-спуфинг. В этом случае кэш DNS-серверов наполняют данными, не имеющими авторитетного источника, и перенаправляют запросы на серверы злоумышленников.
Модификации, упрощающие репликацию баз DNS и исправляющие проблемы безопасности, ИТ-комьюнити всячески приветствовало. Но были и изменения, которые сообщество восприняло не лучшим образом. В частности, переход от бесплатных к платным доменным именам. И это пример лишь одной из «войн» в истории DNS. Подробнее об этом мы поговорим в следующем материале.
Мы в 1cloud предлагаем услугу «Виртуальный сервер». С её помощью можно за пару минут арендовать и настроить удаленный VDS/VPS-сервер.
Также есть партнерская программа для всех пользователей. Разместите реферальные ссылки на наш сервис и получайте вознаграждение за приведенных клиентов.
Свое начало система доменных имен берет в 50-х — 60-х годах прошлого века. Тогда она помогла упростить адресацию хостов в сети ARPANET и очень быстро перешла от обслуживания сотен компьютеров к работе с сотнями миллионов, — пишет сайт proglib.io.
Появление ARPANET
В 1958 году правительство США основало Агентство передовых исследовательских проектов (ARPA). Усилия организации направили на разработку технологий в сфере хранения и передачи данных. В 60-х годах агентство получило новое аппаратное обеспечение — компьютер Q-32 — одну из крупнейших вычислительных систем на транзисторах весом более 60 тонн.
Она имела сразу два запоминающих устройства на магнитных барабанах, каждое из которых считывало и записывало по 50 бит информации. В то время Q-32 использовали для решения задач Министерства обороны США. Тогда данные между вычислительными системами переносили с помощью перфокарт, что существенно усложняло и замедляло расчёты.
Поиск нового решения военные доверили агентству ARPA в 1968 году. Его инженеры объединились с коллегами из MIT и разработали протокол пакетной коммутации. С его помощью они «связали» Q-32 с университетской машиной TX-2 (именно на ней пионер интернета Айвен Сазерленд написал Sketchpad — прародителя современных CAD).
Протокол совершенствовали всю первую половину 1969 года. Специалисты работали над уровнями взаимодействия компьютеров в сети: аппаратным, программным и модемным. Во второй половине года провели первое испытание технологии. Сеть состояла из двух терминалов, установленных на расстоянии 600 км в Калифорнийском и Стэнфордском университетах.
В качестве терминалов выступили 16-разрядные мини-компьютеры Honeywell DDP-316 с 12 кибибайтами оперативной памяти. Во время теста первый оператор вводил слово login на одной машине, а второй подтверждал, что видит его на экране другой.
Эксперимент прошел удачно, положив начало сети ARPANET.
Проблема адресации в сети
Сеть ARPANET стали использовать университеты, телекоммуникационные компании и учёные из разных областей науки. В 80-х к ней были подключены целых 320 компьютеров. Такое количество устройств породило проблему — стало сложно работать с адресами.
Для обмена данными каждый из подключенных компьютеров скачивал файл HOSTS.TXT с информацией об остальных хостах. Этот файл существовал в единственном экземпляре на сервере, размещенном в Стэнфордском исследовательском институте. Пользователям становилось все сложнее работать с раздутым списком, учитывая тот факт, что идентификаторы при подключении приходилось прописывать вручную.
Рождение DNS
В 1983 году инженеры Пол Мокапетрис (Paul Mockapetris) и Джон Постел (Jon Postel) решили распространить концепцию, описанную в RFC805, на всю сеть ARPANET. Они подготовили два новых RFC, в которых изложили основы DNS. В RFC882 «Domain Names: Concepts and Facilities» были описаны возможности системы доменных имен, а в RFC883 «Domain Names: Implementation and Specification» приведена детализация спецификации и методы внедрения.
С 1985 года система доменных имен претерпела множество изменений. Например, в неё добавили поддержку механизмов NOTIFY и IXFR, упростивших процессы репликации баз DNS между различными серверами. Подробнее об этих и других модификациях, мы расскажем в следующей части материала. Также мы поговорим о первых DNS-серверах, в частности, о проекте BIND, который до сих пор остается самым популярным решением в этой сфере.
Первые DNS-серверы
После того как в 1983 году Пол Мокапетрис (Paul Mockapetris) и Джон Постел (Jon Postel) предложили концепцию доменных имен для сети ARPANET, она достаточно быстро снискала одобрение ИТ-сообщества. Одними из первых реализовать её на практике взялись инженеры из Университета в Беркли. В 1984 году четыре студента представили первый DNS-сервер — Berkeley Internet Name Domain (BIND). Они работали в рамках гранта, выданного Управлением перспективных исследовательских проектов Министерства обороны США (DARPA).
Разработанная учащимися университета система автоматически преобразовывала DNS-имя в IP-адрес и наоборот. Интересно, что когда её код загрузили на BSD (платформу распространения ПО), первые исходники уже имели номер версии 4.3.
Первое время DNS-сервером пользовались сотрудники лабораторий университета. Вплоть до версии 4.8.3 за разработку BIND отвечали члены исследовательской группы Университета в Беркли — Computer Systems Research Group (CSRG), но во второй половине 1980-х DNS-сервер вырвался за пределы вуза — его передали в руки Пола Викси (Paul Vixie) из корпорации DEC. Пол выпустил обновления 4.9 и 4.9.1, а потом основал Internet Software Consortium (ISC), который с тех пор и отвечает за поддержку BIND. По словам Пола, все предыдущие версии опирались на код студентов из Беркли, и за прошедшие пятнадцать лет он полностью исчерпал свои возможности для модернизации. Поэтому в 2000 году BIND переписали с нуля.
Сервер BIND включает в себя сразу несколько библиотек и компонентов, реализующих «клиент-серверную» архитектуру DNS и отвечающих за настройку функций DNS-сервера. BIND широко распространен, особенно на Linux, и остается популярной реализацией DNS-сервера. Это решение установлено на серверах, обеспечивающих поддержку корневой зоны.
Отметим, что BIND и PowerDNS одни из самых распространенных, но не единственные DNS-серверы. Также стоит отметить Unbound, djbdns и Dnsmasq.
Развитие системы доменных имен
За всю историю DNS в её спецификацию вносили множество изменений. В качестве одного из первых и крупных обновлений добавили механизмы NOTIFY и IXFR в 1996 году. Они упростили репликацию баз данных системы доменных имен между первичным и вторичным серверами. Новое решение дало возможность настраивать уведомления об изменении DNS-записей. Такой подход гарантировал идентичность вторичной и первичной DNS-зоны плюс экономил трафик — синхронизация происходила только при необходимости, а не через фиксированные интервалы.
Изначально DNS-сеть была недоступна для широкой публики и потенциальные проблемы с ИБ не являлись приоритетом при разработке системы, но такой подход дал о себе знать впоследствии. С развитием интернета уязвимости системы начали эксплуатировать — например, появились такие атаки как DNS-спуфинг. В этом случае кэш DNS-серверов наполняют данными, не имеющими авторитетного источника, и перенаправляют запросы на серверы злоумышленников.
Модификации, упрощающие репликацию баз DNS и исправляющие проблемы безопасности, ИТ-комьюнити всячески приветствовало. Но были и изменения, которые сообщество встретило с критикой. В частности, переход от бесплатных к платным доменным именам. И это пример лишь одной из «войн» в истории DNS.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу. Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
Начиная с 2010 года в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.
Содержание
Уровни DNS
Ключевые характеристики DNS
DNS обладает следующими характеристиками:
- Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
- Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
- Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
- Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
- Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
Дополнительные возможности
- поддержка динамических обновлений
- защита данных (DNSSEC) и транзакций (TSIG)
- поддержка различных типов информации
Как работает DNS
Записи DNS
Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей[2]:
- имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
- тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
- класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети[3],
- TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
- длина поля данных (RDLEN),
- поле данных (RDATA), формат и содержание которого зависит от типа записи.
Наиболее важные типы DNS-записей:
Зарезервированные доменные имена
Интернациональные доменные имена
Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.
Вы когда-нибудь задавались вопросом, как браузер понимает, какую именно страницу открыть, когда вы вводите в строку адрес сайта? На самом деле, это глубокий вопрос, решать который стоит не непосредственно с перехода на сайты, а со связи компьютеров между собой.
В 70-х — 90-х годах 20 века существовала сеть под названием ARPANET. Это была попытка объединить множество компьютеров министерством обороны США для возможности передачи информации во время войны. Важность такого подхода заключалась в быстрой передаче информации на дальние расстояния. Впоследствии принципы работы ARPANET легли в основу современного интернета.
Изначально вся сеть объединяла компьютеры в четырёх различных институтах США:
- Калифорнийский университет в Лос-Анджелесе;
- Стэнфордский исследовательский центр;
- Университет Юты;
- Калифорнийский университет в Санта-Барбаре.
В самом начале компьютеров, подключённых к сети, было несколько десятков, и их идентификаторы было легко запомнить. Можно было записать эти адреса в блокнот и использовать его так же, как и телефонные книги.
Время шло, и уже к середине 80-х годов вместо нескольких десятков компьютеров сеть стала насчитывать несколько тысяч. И каждый из них имел уникальный идентификатор, который становилось всё сложнее учитывать вручную или запоминать. Необходима была система, которая позволит очеловечить имена компьютеров и хранить все адреса в одном месте, чтобы каждый компьютер в сети имел один и тот же набор всех идентификаторов.
Файл hosts — как первый шаг к созданию DNS
Для решения задачи разработчики решили использовать словарь, который связывал уникальное имя и IP-адрес каждого компьютера в сети. Таким словарём стал файл hosts.txt, который и отвечал за привязку IP-адреса к имени компьютера. Файл лежал на сервере Стэнфордского исследовательского института, и пользователи сети регулярно вручную скачивали этот файл на свои компьютеры, чтобы сохранять актуальность словаря, ведь новые компьютеры появлялись в сети почти каждый день.
Выглядел hosts.txt тогда (да и сейчас) таким образом:
При наличии такого файла на компьютере пользователя для связи с компьютером Майка, можно было не запоминать цифры, а использовать понятное латинское имя «MIKE-STRATE-PC».
Посмотрим, как выглядит файл и попробуем добавить туда новое имя, чтобы подключиться к компьютеру с использованием данного имени. Для этого отредактируем файл hosts. Вы можете найти его на своём компьютере по следующему адресу:
- В Unix-системах: /etc/hosts
- В Windows-системах: %Путь до папки Windows%/system32/drivers/etc/hosts
Компьютеру с IP-адресом 192.168.10.36, который находится внутри локальной сети мы указали имя «MIKE-STRATE-PC». После чего можно воспользоваться командой ping, которая пошлёт специальный запрос на компьютер Майка и будет ждать от него ответа. Похоже на то, как вы стучитесь в дверь или звоните в звонок, чтобы узнать, «есть ли кто дома?» Такой запрос можно послать на любой компьютер.
По мере развития сети и «обрастания» её новыми клиентами, такой способ становился неудобным. Всем пользователям компьютеров было необходимо всё чаще скачивать свежую версию файла с сервера Стэнфордского исследовательского института, который обновлялся вручную несколько раз в неделю. Для добавлений же новых версий было необходимо связываться с институтом и просить их внести в файл новые значения.
В 1984 году Пол Мокапетрис (Paul Mockapetris) описал новую систему под названием DNS (Domain Name System / Система доменных имён), которая была призвана автоматизировать процессы соотнесения IP-адресов и имён компьютеров, а также процессы обновления имён у пользователей без необходимости ручного скачивания файла со стороннего сервера.
Работа DNS в сети интернет
В настоящее время интернет окружает нас повсюду — мы используем его в мобильных и настольных устройствах. Системы видеонаблюдения и даже чайники взаимодействуют друг с другом с помощью интернета, и для корректной связи с ними нужна система, с помощью которой пользователи смогут одним запросом в адресной строке подключиться к нужному сервису. Всё это ложится на плечи системы DNS, которая внутри себя хранит намного больше информации, чем просто IP-адрес и название устройств. Записи в DNS также отвечают за корректную отправку электронных писем, связывают друг с другом разные домены и доменные зоны.
DNS является распределённой системой, а значит она имеет множество узлов, каждый из которых ответственен за свою зону. Такое возможно благодаря тому, что сама по себе структура DNS является иерархической, то есть выделяет зоны ответственности, где каждый родитель знает о расположении своего дочернего сервера, и знает зону его ответственности.
Рассмотрим работу DNS и её составных частей поближе.
Терминология
Основными компонентами DNS являются:
Домен (доменное имя) — символьное имя для обозначения сервера в сети интернет. Доменные имена являются иерархической структурой, в которой каждый уровень отделяется точкой. Основными уровнями являются:
DNS-сервер — система, ответственная за хранение и поддержание в актуальном состоянии записей о своих дочерних доменах. Каждый DNS-сервер ответственен только за свою зону, то есть DNS-сервер домена .io знает о том, где расположен домен hexlet, DNS-сервер которого знает о расположении своих поддоменов.
Корневой DNS-сервер — система, знающая расположение (IP-адреса) DNS-серверов доменов верхнего уровня.
Ресурсная запись — единица информации DNS-сервера. Каждая ресурсная запись имеет несколько полей:
- Имя (домен, к которому относится запись)
- Тип
- Параметры
- Значение
Подключение
Необходимо понимать, что доменное имя — это всего лишь абстракция для людей. Сам компьютер и приложения (например, браузер) обращается к сервисам внутри сети интернет только по IP-адресам.
Рассмотрим процесс получения IP-адреса по доменному имени на примере домена ru.hexlet.io .
Возможны два варианта событий:
Компьютер посылает запрос на известный ему DNS-сервер. Чаще всего им является DNS-сервер поставщика интернет-услуг (провайдера): какой IP-адрес у домена ru.hexlet.io?. DNS-сервер провайдера находит в своей базе информацию о том, что домен ru.hexlet.io расположен по IP-адресу 104.25.238.104 и возвращает значение нашему компьютеру. Этот процесс похож на то, как использовался файл hosts.txt .
Ближайший известный DNS-сервер не имеет записи о том, по какому IP-адресу располагается домен ru.hexlet.io . В таком случае запускается цепочка процессов, благодаря которым наш компьютер получит IP-адрес домена:
Так как домен является иерархической структурой, и все DNS-сервера знают IP-адреса корневых DNS-серверов, то к ним и происходит запрос на получение IP-адреса домена.
Корневые DNS-сервера, в соответствии со своей зоной ответственности знают о том, где располагаются DNS-сервера доменов верхнего уровня. Эти адреса возвращаются DNS-серверу нашего провайдера, после чего на нужный DNS-сервер (в нашем случае на DNS-сервер домена .io) посылается запрос на получение IP-адреса домена ru.hexlet.
В соответствии со своей зоной ответственности DNS-сервер домена верхнего уровня возвращает IP-адрес DNS-сервера домена hexlet, на который посылается запрос на получение IP-адреса поддомена ru.
DNS-сервер возвращает IP-адреса поддомена ru, после чего DNS-сервер нашего провайдера возвращает полученный адрес на наш компьютер, который уже может обратиться к домену ru.hexlet.io по его IP-адресу.
Рекурсия в DNS
Можно заметить, что оба описанных выше варианта сильно различаются: в первом случае мы просто послали запрос и получили ответ, а во втором — возникла необходимость идти от самого корневого домена в процессе поиска нужной нам записи. Такой процесс является рекурсивным, потому что ближайший DNS-сервер непрерывно посылает запросы к другим DNS-серверам до тех пор, пока не получит необходимые ресурсные записи. Данный процесс можно визуализировать следующим образом:
При запросах 1 и 2 ближайший сервер будет получать информацию о местонахождении DNS-серверов, которые входят в зону ответственности того сервера, на который был послан запрос. При запросе 3 будут получены необходимые ресурсные записи домена hexlet и его поддоменов.
Рекурсивный поиск — это достаточно долгая операция, которая к тому же сильно нагружает сеть и сами DNS-сервера. Именно для того, чтобы избавиться от рекурсии каждый DNS-сервер кеширует информацию о записях, которые получает, для быстрой отдачи этой информации пользователю.
Как видно, рекурсивный поиск предполагает нахождение конечного ответа на наш запрос путём поиска записи по всем необходимым DNS-серверам, начиная с корневого. В противовес такому способу также существует итеративный запрос, который в отличие от рекурсивного выполняет всего лишь одну итерацию — это запрос ближайшему DNS-серверу, от которого мы можем получить как закешированный ответ, так и данные той зоны, за которую он ответственен. Важно отметить, что итеративный запрос предполагает всего один такой запрос.
Чаще всего в интернете DNS-сервера умеют посылать рекурсивные запросы, потому что в таком случае ответ можно закешировать, что в дальнейшем позволит снизить нагрузку как на сам сервер, так и на другие DNS-сервера. Время, на которое DNS-сервер кеширует информацию, указывается в ресурсной записи DNS, о которой сейчас пойдёт речь.
Ресурсные записи DNS
Рассмотрим, какие ресурсные записи используются, и на что они указывают. Основными ресурсными записями DNS являются:
A-запись — одна из самых важных записей. Именно эта запись указывает на IP-адрес сервера, который привязан к доменному имени.
MX-запись — указывает на сервер, который будет использован при отсылке доменной электронной почты.
NS-запись — указывает на DNS-сервер домена.
TXT-запись — в этой записи хранится текстовая информация о домене. Часто используется для подтверждения прав на владение доменом, посредством добавления определённой строки, которую присылает нам интернет-сервис.
Ресурсные записи почти всегда одинаковые, но для некоторых записей могут появляться другие поля, например в MX-записях также присутствует значение приоритета. В основном ресурсные записи имеют следующую структуру:
Имя записи — указывается домен, которому принадлежит данная ресурсная запись.
TTL (time to live / время жизни) — время в секундах, на которое будет закешировано значение ресурсной записи. Это необходимо для разгрузки DNS-серверов. Благодаря кешированию и возможна ситуация, что ближайший DNS-сервер знает IP-адрес запрашиваемого домена.
Класс — предполагалось, что DNS может работать не только в сети интернет, поэтому в записи указывается и её класс. На сегодняшний день поддерживается только одно значение — IN (Internet).
Тип — указывает тип ресурсной записи, основные из которых были разобраны выше.
Значение — непосредственно значение ресурсной записи. В зависимости от типа ресурсной записи значения могут быть представлены в разном виде.
Утилита dig является DNS-клиентом и входит в состав одного из самых распространённых DNS-серверов BIND.
Пример реальных записей DNS
Не пугайтесь такого длинного вывода. Уже сейчас можно понять почти всё, что тут указано. Разберём вывод каждой секции более детально.
Вывод состоит из нескольких частей:
- Шапка
- Секция запроса
- Секция ответа
- Служебная информация
Шапка запроса
Секция запроса
В секции запроса указывается домен, к которому происходит обращение, класс записи и те записи, которые мы хотим получить. ANY указывает на то, что нужно вывести все доступные ресурсные записи, но если вы хотите поэкспериментировать с утилитой сами, то можете с помощью специального ключа получить вывод только конкретных записей, которые интересуют в настоящий момент.
Секция ответа
Секция ответа достаточно большая, поэтому для удобства разобьём её по типам ресурсных записей.
Как запись A, так и AAAA-запись указывают на IP-адрес, который привязан к нашему домену. A-запись указывает IP в формате IPv4, а запись AAAA — в формате IPv6.
MX-запись также имеет параметр приоритета. Так как серверов для отправки почты может быть несколько, то и записей может быть много, поэтому для определения основного сервера указывается приоритет записи. Чем меньше число, тем выше приоритет.
Запись SOA (Start of Authority) указывает на несколько различных параметров:
- Сервер с эталонной информацией о текущем домене
- Контактную информацию ответственного лица
- Различные параметры кеширования записей
Бывают и некоторые более специфичные ресурсные записи, о которых здесь не было речи, но это не значит, что они бесполезны. Полный перечень таких записей всегда можно найти в документации (например по DNS-серверу BIND).
Выводы
DNS-сервера сейчас составляют основу всего интернета и используются почти в каждом действии пользователя в сети, будь то переход на сайт, отправка электронной почты, работы с интернет-приложением на телефоне и так далее. Поэтому знания о принципах работы DNS-серверов и основных ресурсных записях, благодаря которым и возможно перемещение по сети интернет, являются важными для разработчика.
Читайте также: