Интернет состоит из множества взаимосвязанных компьютерных сетей и обеспечивает удаленный доступ к компьютерам, веб-страницам, электронной почте, базам данных и т.д. Также можно сказать, что интернет — это всемирная компьютерная сеть, состоящая из разнообразных компьютерных сетей, объединенных стандартными соглашениями о способах обмена информацией и единой системой адресации.
Работы над созданием интернета начались в 60-х годах, когда корпорация RAND и несколько крупных высших учебных заведений США приступили к разработке технологий передачи информации по сетям. Смысл технологии заключается в том, что переданная информация разбивается на пакеты, которые путешествуют индивидуально, зачастую по нескольким географическим областям, выбирая наиболее эффективный и доступный маршрут. В конце концов, все пакеты достигают своего финального назначения, где они снова собираются в первоначальную форму, после чего пользователь получает посланную информацию.
На основе новой технологии была создана сеть, получившая название ARPANET (Advanced Research Projects Agency Network), после чего была разработана программа Internetting Project (Проект объединения сетей). Этот проект создал предпосылки для успешной интеграции многих сетей в единую мировую сеть, которая и называется интернет.
Transmission Control Protocol/Internet Protocol (TCP/IP) - это промышленный стандарт стека протоколов, разработанный для глобальных сетей. Стандарты TCP/IP опубликованы в серии документов, названных Request for Comment (RFC).
Стек протоколов TCP/IP представляет собой совокупность следующих друг за другом протоколов разных уровней, а также их обработчиков, которые получают данные от выше- и нижележащего протокола, преобразуют полученные данные и передают их на вход следующего уровня.
Поскольку стек TCP/IP изначально создавался для глобальной сети Internet, он имеет много особенностей, дающих ему преимущество перед другими протоколами, когда речь заходит о построении сетей, включающих глобальные связи. В частности, очень полезным свойством, делающим возможным применение этого протокола в больших сетях, является его способность фрагментировать пакеты. Действительно, большая составная сеть часто состоит из сетей, построенных на совершенно разных принципах. В каждой из этих сетей может быть установлена собственная величина максимальной длины единицы передаваемых данных (кадра). В таком случае при переходе из одной сети, имеющей большую максимальную длину, в сеть с меньшей максимальной длиной может возникнуть необходимость деления передаваемого кадра на несколько частей. Протокол IP стека TCP/IP эффективно решает эту задачу.
Другой особенностью технологии TCP/IP является гибкая система адресации, позволяющая более просто по сравнению с другими протоколами аналогичного назначения включать в интерсеть сети других технологий. Это свойство также способствует применению стека TCP/IP для построения больших гетерогенных сетей. Также в стеке TCP/IP очень экономно используются возможности широковещательных рассылок. Это свойство совершенно необходимо при работе на медленных каналах связи, характерных для территориальных сетей.
DNS использует в своей работе два протокола: TCP и UDP. UDP - это безсессионный протокол. Он является штатным транспортом для запросов и ответов DNS. Так, по UDP отправляют запросы рекурсивные резолверы, ответы от авторитативных серверов также приходят по UDP. Сессионный TCP используется в нескольких случаях: если по UDP получить ответ не удаётся (например, большой по размеру ответ не проходит через промежуточные узлы, или DNS-сервер не может отправить длинный ответ по UDP); если резолвер или авторитативный сервер настроен на работу только по TCP (что является нарушением спецификации и встречается редко); при трансфере зоны - трансфер, в соответствии со спецификацией, подразумевает использование TCP. Служба DNS использует номер порта 53, и для UDP, и для TCP.
RFC (Request for Comments - «призыв прокомментировать», запрос комментариев) – это множество документов, которые регламентируют внутреннюю жизнь Internet. Они могут содержать технические спецификации и стандарты, широко применяемые в сети Internet. Кроме того, некоторые из них представляют собой отчеты рабочих групп или описания ресурсов. Первичной публикацией документов RFC занимается IETF под эгидой открытой организации ISOC (Internet Society, Общество Интернета). Правами на RFC обладает именно ISOC.
Формат RFC появился в 1969 году при обсуждении проекта ARPANET RFC1. Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде. Подробный очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.
Запросы комментариев RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft — черновик). RFC доступны всем из множества источников и распространяются бесплатно.
Компьютеры оперируют цифрами, и любая информация, находящаяся в виртуальном пространстве, имеет цифровой вид. Поэтому каждый компьютер, подключенный к интернету, имеет свой IP-адрес (Internet Protocol Address), состоящий из четырех групп цифр, разделенных точками. IP-адрес является уникальным идентификатором, благодаря которому все сетевые устройства взаимодействуют между собой, запрашивая и получая ту или иную информацию.
IP-адрес назначается администратором конкретного компьютера или иного устройства во время конфигурирования компьютера. При этом четыре группы цифр, из которых состоит IP-адрес, разделяются на две части: номер сети, в которой находится конкретное устройство, и номер узла (хоста). Для определения границы между сетевой и хостовой частью используется маска подсети, которая указывается в паре с IP-адресом. Для сетей, которые работают как составная часть интернета, адрес выдается провайдером либо региональной интернет-регистратурой (Regional Internet Registry, RIR).
При наборе в командной строке веб-браузера не доменного имени, а IP-адреса, пользователь интернета также попадает на нужный веб-сервер и получает запрашиваемую информацию. Но запоминание огромного количества IP-адресов для обычного человека невозможно, поэтому еще в 1980 году была придумана система доменных имен (DNS), которая возникла именно для удобства пользователей: гораздо легче запомнить доменное имя (например, cctld.ru), чем четыре числа IP-адреса.
В интернете используется межсетевой протокол (IP) четвёртой версии, также известный как IPv4. В протоколе этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 32 байта. При этом IPv4, нынешний стандарт межсетевого протокола, ограничивает допустимое число адресов в интернете четырьмя миллиардами.
Эксперты расходятся в точной оценке числа используемых сейчас IP-адресов и сроков, когда все IP-адреса окажутся задействованными. Однако все популярнее становятся PDA, телефоны и другие интеллектуальные устройства с доступом в интернет, и для них требуются постоянные IP-адреса.
Новая версия протокола IP, названная IPv6, была разработана для решения проблем масштабирования и безопасности, возникших при использовании IPv4, а также для расширения возможностей современных сетевых устройств и приложений. Эта версия протокола позволяет адресовать значительно большее количество узлов, чем IPv4. IPv6 отличается повышенной разрядностью адреса (128 байт), встроенной возможностью шифрования и некоторыми другими особенностями. Наиболее важным фактором внедрения протокола IPv6 является преодоление ограниченности адресных ресурсов IPv4: IPv6 предлагает практически неограниченный с сегодняшней точки зрения запас адресов. В то же время протокол IPv6 не является совместимым с протоколом IPv4. Это означает, что устройство, поддерживающее только IPv6, не может взаимодействовать с устройством IPv4 напрямую. Этот факт существенно усложняет процесс перехода к IPv6.
Система доменных имен (Domain name system, DNS) – это распределенная база данных, которая по запросу, содержащему доменное имя, может сообщить IP-адрес хоста (компьютера или иного сетевого устройства). Возможно и обратное, когда по IP-адресу определяется доменное имя.
Система DNS является иерархической и распределенной. Не существует единой базы данных, хранящей информацию о всех именах и соответствующих им IP-адресах. Напротив, DNS – это миллионы баз данных, каждая из которых содержит информацию о конкретном доменном имени. Для обеспечения надежности и избыточности корневые серверы распределены по сети Интернет (в основном по географическому принципу).
Каждое доменное имя (например, cctld.ru), строится в обратном порядке, начиная с корневой зоны, причем суффикс доменного имени – .RU, .COM, .ORG, .NET и т.д. – определяет верхний уровень иерархии, непосредственно после точки (.), обозначающей корневую зону. После каждого из суффиксов (которые обычно называют доменами верхнего уровня – top-level domains или TLD) следуют доменные имена, определяемые не корневыми серверами, а отдельными хостами DNS в сети Интернет.
При запросе трансляция доменного имени cctld.ru и соответствующего ему IP-адреса будет происходить в несколько этапов. Сначала будут запрошены серверы, обслуживающие корневую зону. Эти серверы ничего не знают о существовании доменного имени cctld.ru, но они сообщат, как можно связаться с серверами, обслуживающими доменное имя верхнего уровня - .ru. От них мы узнаем адреса серверов доменного имени cctld.ru, которые и ответят на запрос о IP-адресе сервера cctld.ru. Такая архитектура DNS позволяет распределить нагрузку и ответственность за работу системы между администраторами отдельных доменов.
Аббревиатура DNS обозначает сопряжённые понятия: доменную систему имён (Domain Name System) и сервис доменных имён (Domain Name Service). Первое из этих понятий, - система имён, - относится к области хранения информации в глобальной распределённой базе данных. Второе, - сервис, - это технологии, позволяющие находить в этой безе данных нужную информацию. Система хранения - бесполезна без механизма извлечения данных, а механизм извлечения, в свою очередь, не пригоден для практического применения, если данные извлекать неоткуда.
Рассмотрим, прежде всего, систему доменных имён. DNS - это база данных, в которой хранятся пары "ключ - значение". Это означает, что каждой "единице хранения" в базе данных сопоставлено некоторое имя (или индекс, не так важно), это имя называется ключом. Чтобы извлечь "единицу хранения" - необходимо знать ключ, база данных принимает только запросы вида "вот ключ - найдите соответствующую запись". Наиболее часто используется пара "доменное имя - IP-адрес", в которой ключом служит доменное имя - текстовая строка, обычно представляющая собой понятное для человека сочетание символов. Например, пара "test.ru - 192.168.11.17" означает, что ключу test.ru соответствует адрес 192.168.11.17, и если отправить в DNS правильно подготовленный запрос с ключом test.ru, то можно узнать IP-адрес для этого имени. Несмотря на то, что работа с парами "доменное имя - IP-адрес" является чрезвычайно распространённым, классическим применением DNS, необходимо помнить, что сама эта система сейчас значительно шире: она позволяет хранить данные других типов.
Так как DNS - сложная, распределённая система, для извлечения данных необходим специальный сервис поиска. Этот сервис, получив на вход ключ, осуществляет просмотр базы данных DNS и пытается найти соответствующее ключу значение: данный процесс называется (рекурсивным) опросом DNS. Если значение удалось обнаружить, то сервис вернёт его запросившему. Другими словами, сервис доменных имён предоставляет простой интерфейс "запрос-ответ", позволяющий находить нужные значения.
Представьте себе огромную библиотеку, где каждой книге соответствует индекс - уникальное обозначение. Тогда этот индекс будет ключом, а книга - значением, которое можно быстро найти по индексу. Библиотека роботизирована. Вы называете роботу-библиотекарю индекс, он разыскивает и приносит вам соответствующую книгу. Эта воображаемая библиотека занимает множество зданий, а книги распределены между ними в соответствии с некоторыми правилами записи индекса. Всё это вместе - неплохая аналогия для DNS, и как системы, и как сервиса.
Система доменных имён - одна из древнейших систем в Интернете. Она появилась в 80-х годах прошлого века как инструмент удобной записи адресов электронной почты: ни веба, ни разнообразных "мобильных приложений" и "мессенджеров" тогда ещё не существовало. DNS остаётся фундаментальной технологией, без неё глобальная Сеть, в нынешнем виде, невозможна, так как эта система не только позволяет пользователям находить сайты по символьным именам, и, как несколько десятков лет назад, принимать сообщения электронной почты, но и реализует массу сервисных функций, обеспечивающих глобальный обмен информацией.
Когда мы говорим о том, что DNS представляет собой глобальную распределённую базу данных, это означает, что объекты, внесённые в эту базу данных, сохраняются на специальных серверах, находящихся по всему миру. Система доменных имён имеет иерархическую структуру. Лучше всего эту структуру можно понять, разобрав пример с доменным именем. Рассмотрим имя name.example.com - здесь три подстроки, которые разделены точками; точка - имеет большое значение при записи доменных имён, так как именно при помощи точки формируется иерархия составляющих имя подстрок. Точка разбивает запись по уровням, их принято разбирать слева направо. Наш пример соответствует имени третьего уровня name, которое находится внутри доменной зоны example.com. В свою очередь, example.com - это второй уровень иерархии, а .com - первый.
При помощи этого термина «доменная зона» обозначают совокупность имён, находящихся в общей ячейке адресного пространства. Можно считать, что доменное имя верхнего, второго и ниже уровней может обозначать как имя отдельного узла, так и название доменной зоны.
Таким образом, всякое доменное имя можно разобрать на уровни иерархии, разделив «по точкам». www.test.ru - обозначает имя третьего уровня. test.ru - имя второго уровня. .ru - первого. При этом test.ru и test.com - являются именами второго уровня, но находятся в разных зонах первого уровня: .ru и .com, соответственно. Иерархия имён образует дерево, где ветви - это доменные зоны, а листья - имена конкретных записей в базе данных. Корень этого дерева называется корневым доменом. К корневому домену принадлежат все имена первого уровня, а его обозначение часто опускают, потому что у корневого домена нет имени, он обозначается просто точкой. Так, строгая и полная запись адреса из предыдущего примера будет такой: name.example.com. - здесь присутствует завершающая, крайняя справа, точка, она соответствует корневому домену. Эта точка очень важна в специальных случаях: от её наличия зависит верная интерпретация адреса программным обеспечением. В современной глобальной DNS корень - единый для всех.
Если двигаться по доменному дереву от корня в направлении листьев, то сразу же можно обнаружить интенсивное ветвление: уже внутри корневого домена, на первом уровне, находятся тысячи имён уровнем ниже. Среди этих имён, например, ru и su.
Предположим, что некто администрирует зону .com, то есть, обладает полномочиями по распределению и настройке имён внутри этой зоны. Тогда данный администратор может завести новое имя example.com, назначить для него другого администратора и наделить его полномочиями по управлению внутри example.com. Как мы только что разобрались, внутри example.com возможно своё дерево имён: name.example.com, www.example.com, best.name.example.com и так далее. То есть, example.com - в некотором смысле, образует отдельную доменную зону, зависимость которой от .com сводится к тому, что этот домен верхнего уровня содержится во всех адресах новой зоны. Это позволяет example.com иметь независимую административную политику: то, что example.com принадлежит к .com, никак не мешает администратору example.com настраивать в своей зоне любые имена, кроме того, что все они должны быть уровнем ниже example.com. То есть, если в зоне .com присутствует домен test.com, то это не мешает администратору зоны exsmple.com завести домен test.example.com. Например, глобальным корневым доменом управляет организация по распределению имён и адресов - ICANN, однако находящиеся внутри корневого домена национальные зоны (ru, us, tk и др.) могут устанавливать собственные политики распределения адресов в своих доменах первого уровня.
Адресная информация, соответствующая каждой доменной зоне, находится на специальных серверах DNS, которые отвечают на запросы именно об этой зоне. Эти серверы называются авторитативными. Вернёмся к test.ru. Предположим, что этой зоне соответствуют серверы, которые мы условно обозначим NS1 и NS2. Именно эти серверы содержат сведения об объектах базы данных, соответствующих именам (ключам) внутри test.ru, задача серверов отвечать на запросы об этих именах. О других зонах серверы могут ничего не знать. Так, если кому-то потребовалось определить IP-адрес, соответствующий имени www.test.ru, то этот кто-то может обратиться к NS1 или NS2 и получить ответ (в той или иной форме). У example.com, соответственно, другие DNS-серверы, у .ru - третьи, и так далее.
Для того чтобы определить, какие DNS-cерверы каким зонам соответствуют, в DNS предусмотрен механизм делегирования. Узнать, какие серверы поддерживают test.ru, можно у серверов, поддерживающих .ru, а эти серверы можно определить при помощи запроса к корневому домену. Адресное пространство имён в DNS делегируется на уровень ниже, как раз при помощи указания серверов DNS, отвечающих за «следующую» по уровню зону. В корне DNS делегируют .ru, в .ru - test.ru, и так далее. В этом предложении присутствует некоторый намёк на рекурсию - дело в том, что поиск DNS-серверов, которые поддерживают некоторую доменную зону, является важной частью так называемого рекурсивного опроса, относящегося к сервису доменных имён.
Сервис доменных имён позволяет извлекать записи из глобальной базы данных, то есть, осуществлять в ней поиск. Поиск в DNS сильно отличается от, например, поиска страниц в вебе при помощи поисковой системы. В DNS нельзя отправить "размытый" запрос: "хочу найти что-то похожее на google, но с картинками". Для того, чтобы запрашивать сведения в DNS, нужно точно сформулировать запрос - нужно знать ключ. В большинстве случаев таким ключом является доменное имя.
Так как DNS представляет собой множество серверов, на которые наложена некоторая иерархия имён, поиск ответа редко ограничивается одним или двумя действиями. Обычно, для того, чтобы добраться до нужного сервера, требуется найти множество промежуточных узлов в иерархии и опростить их. Так как практически в каждом случае для получения информации _из_ DNS сначала требуется получить информацию об узлах _самой_ DNS, из этой же системы, опрос называется рекурсивным. Выполняет такой опрос специальный сервер, который, в свою очередь, называется рекурсивным резолвером. (Резолвер - от английского resolve, в значении "определять".)
Предположим, что нам нужно определить IP-адрес для имени www.example.com, какой алгоритм следует выполнить? В несколько упрощённом виде, этот алгоритм можно описать следующим образом. Верхнее имя (.com) находится внутри корневого домена, поэтому на первом шаге необходимо отправить запрос к корневым серверам DNS и узнать адреса серверов, отвечающих за зону .com. Именно .com, так как .com - следующая за корневым доменом зона в нашем адресе. На втором шаге, отправив запрос к серверам зоны .com, узнаем адреса серверов, отвечающих за зону example.com. И уже у этих серверов, на третьем шаге, выясним адрес для www - потому что имя www, это имя третьего уровня, находящееся внутри example.com. На практике, всё работает несколько сложнее, так как в DNS есть много тонкостей и хитростей. Например, обычный рекурсивный резолвер скорее всего будет обращаться к узлам DNS не с запросом о DNS-серверах, а сразу с запросом об IP-адресе для полного имени. При этом промежуточные запросы могут потребоваться для поиска IP-адресов DNS-серверов, так как ответы будут содержать их имена, а не адреса. Но основной принцип рекурсивного опроса DNS именно такой: последовательно отправляются запросы на DNS-серверы, в соответствии с иерархией, закреплённой в записи имени.
В основе первоначально созданной DNS находилась система корневых (root) серверов, состоявшая из первичного (primary) сервера a.root-servers.net и растущего числа реплик (secondary), с именами b.root-servers.net, c.root-servers.net и т.д. до m.root-servers.net. – всего 12 штук. Каждый сервер управлялся отдельной организацией-оператором, который нес за него ответственность. Позднее был создан «скрытый» мастер-сервер, и a.root-servers.net стал одним 13 равноправных корневых серверов, управляемых 12 независимыми организациями, различными по роду деятельности, организации и географии (их список доступен на сайте www.root-servers.org).
С целью повышения производительности и устойчивости системы и в ответ на взрывной рост интернета (и количества обращений к доменам), с 2003 года была внедрена технология anycast, позволившая операторам сделать множество зеркал корневых серверов, находящихся ближе к пользователям. В настоящее время число таких зеркал составляет несколько сотен.
Корневые серверы DNS являются критическим компонентом системы, поскольку обеспечивают доступ к корневой зоне DNS. Эту зону называют еще зоной нулевого уровня, и адресуют одним символом «.» (точка). Корневая зона содержит информацию обо всех доменах верхнего (первого) уровня, называемых также просто «зонами»: национальных доменах (например .ru), общих доменах (например .org .com) и спонсированных доменах (например .xxx ;). Эта информация указывает клиенту на какие серверы DNS отправить запрос для разрешения полного доменного имени. Если информация о запрашиваемом домене не была ранее сохранен в кэше клиента, то его запрос начинается с обращения к корневому серверу, и будет обработан ближайшим зеркалом.
Если требуется изменить адресацию в корневой зоне, например, изменить состав серверов, обслуживающих домен, администратор домена верхнего уровня посылает подписанный ЭЦП запрос, который тщательно проверяется (сейчас эту проверку осуществляет IANA) и авторизуется специальным аудитором. Авторизованный запрос передается оператору, который вправе вносить изменения на скрытом мастер-сервере DNS (сейчас это VeriSign) , а затем распространяется по защищённому протоколу на все корневые сервера-реплики.
База данных доменов корневой зоны - Root Zone Database - включает реестр доменов верхнего уровня с указанием их имен, типов и администраторов. Для каждого домена на отдельной странице (переход - кликом по имени домена) дается подробная информация по организации-администратору (наименование, реквизиты для контактов, URL интернет-сайта), информация по DNS-серверам доменной зоны (имена, адреса IPv4 и адреса IPv6) и дата последнего обновления записи. Информация в базе данных может корректироваться администраторами доменов через специальную форму.
Основным административным механизмом, с помощью которого выстраивается иерархическая система доменных имён, является делегирование. Технически, делегирование домена - это размещение в DNS записей, указывающих на серверы имён, которые отвечают на запросы о данном домене. Необходимо различать регистрацию домена и его делегирование. С точки зрения технологии, эти операции напрямую не связаны. Напомним, что регистрация домена - это размещение сведений об администраторе, о состоянии имени ("имя зарегистрировано") в специальной базе данных, которую обычно называют реестром. Сам реестр не является базой DNS, но служит авторитативным источником информации о том, как настроена DNS в конкретной доменной зоне. В частности, в реестре находятся сведения о том, какие серверы имён соответствуют данному домену. Таким образом, процесс делегирования может начинаться с внесения записей о серверах имён в реестр. Это типовая ситуация для доменов, размещённых в корне глобальной DNS, например, для национальных доменов или для доменов общего назначения (gTLD). Однако для доменов, которые не используют строгих процессов управления, реестр может отсутствовать, а делегирование - сводится к размещению записей непосредственно в DNS. Именно так действуют "обычные" доменные зоны, находящиеся на втором или третьем уровне. Доменное имя может быть зарегистрировано в реестре, но не быть делегированным. Это означает, что рекурсивные резолверы не могут найти какие-то содержательные записи для неделегированного домена: в DNS этого домена не существует.
Рассмотрим типичный процесс делегирования домена на примере example.com. Пусть делегирование выполняет обычный пользователь, а домен ещё не зарегистрирован. Тогда, так как домен находится в зоне .com, прежде всего, потребуется обратиться к тому или иному регистратору доменов и зарегистрировать example.com. После успешной регистрации, пользователь, ставший теперь администратором домена, должен выбрать и настроить серверы имён. Для имени в .com, согласно правилам, таких серверов потребуется минимум два (они должны различаться по именам и адресам). Предположим, администратор выбрал следующие серверы: server1.test.ru и server2.test.ru. (Обратите внимание, что имена серверов, на которые будет делегирован домен, не обязательно должны находиться в делегируемой зоне: наоборот, более распространён вариант, когда имена находятся в другой зоне.) Процесс делегирования состоит в том, что имена server1.test.ru и server2.test.ru должны быть указаны в зоне .com для example.com. Для этого администратор тем или иным способом передаёт имена DNS-серверов регистратору (обычно, через панель управления), а регистратор вносит их в реестр зоны .com. У регистратора есть доступ к реестру через специальный программный интерфейс (API), который предоставляет оператор реестра. Через некоторое время после того, как соответствующие изменения попадут в реестр, они отразятся в глобальной DNS и рекурсивные резолверы смогут находить записи о домене example.com.
Под записью (или ресурсной записью) в DNS понимают логически выделенные пары "ключ-значение", фактически, поля данных. Например, в случае IP-адреса, для имени example.com записью будет называться соответствие example.com - IP-адрес. Записям соответствуют типы, обозначаемые сочетаниями букв. Так, запись с IP-адресом - это A-запись (A - от англ. Address). Ключевая особенность DNS - кеширование записей, то есть, копии полученных от других серверов записей некоторое время сохраняются в памяти "локального" сервера (обычно, это резолвер). Кеширование придаёт DNS устойчивость.
Что означает хранение записи в кеше резолвера? То, что при поступлении повторного запроса о той же записи, резолверу не нужно вновь опрашивать всю иерархию серверов - он может сразу ответить записью из своего кеша. Это экономит ресурсы сразу на двух направлениях: во-первых, резолвер ответит на запрос гораздо быстрее, так как ответ уже готов; во-вторых, так как резолвер не будет опрашивать другие серверы, уменьшится нагрузка и на эти серверы. Кеширование чрезвычайно важно в глобальной DNS. При отсутствии кеширования серверы имён, которые поддерживают сколь-нибудь популярные доменные имена, получали бы в сотни раз больше запросов каждую секунду.
Кеширование подразумевает хранение копии записи на кеширующем сервере (резолвере). Но значения записей периодически изменяются - как долго следует хранить копию? Это определяется специальным параметром - "временем жизни", TTL (от англ. Time To Live - время жизни). TTL приписывается каждой записи в DNS. Этот параметр содержит число секунд, в течение которых следует сохранять запись в кеше. Пусть для A-записи example.com установлено значение TTL в 1200 секунд. Это означает, что рекурсивный резолвер, получив значение A-записи в ответе DNS-сервера, будет в течение 1200 секунд с момента получения ответа использовать результат, находящийся в локальном кеше. То есть, на запросы своих клиентов рекурсивный резолвер будет отправлять ответы из кеша. Если за эти 1200 секунд на исходном сервере значение A-записи изменится, то клиенты рекурсивного резолвера всё равно будут получать старое значение, до тех пор, пока не истечёт срок кеширования. Если же запрос к рекурсивному резолверу поступит уже после того, как истёк интервал TTL, то резолвер вновь выполнит опрос серверов имён и получит новое значение записи. Важно понимать, что, за исключением редких специальных случаев, рекурсивный резолвер не опрашивает автоматически DNS для всех записей из локального кеша, у которых истёк TTL, он это делает только если поступил соответствующий запрос от клиента. Другими словами - первый запрос о какой-то записи будет выполняться заведомо дольше, а второй и последующие - быстрее, так как ответ уже есть в кеше.
Кеширование увеличивает общую надёжность DNS, с точки зрения каждого конкретного пользователя. Так, если серверы имён, поддерживающие доменную зону, на некоторое время стали недоступны, эта недоступность не повлияет на кеширующие серверы (конечно, до тех пор, пока не истечёт TTL).
Типичные значения TTL в современной Сети обычно составляют 900-3600 секунд, но зависят от типа записи - для некоторых устанавливаются интервалы значительно больше, например, 86400 (24 часа). Исходное значение TTL определяет авторитативный сервер имён, однако кеширующие резолверы могут его для себя переопределить (как в большую, так и в меньшую сторону).
Авторитативными - называют серверы имён, на которые делегирована данная зона и которые "уполномочены" отвечать на запросы о ней. В DNS, ответы, полученные непосредственно от авторитативных серверов, обозначаются специальным флагом. Напротив, не авторитативный ответ - это ответ, полученный, например, от рекурсивного резолвера (признака авторитативного ответа он содержать не должен).
Авторитативный сервер, а также кеширующий сервер или рекурсивный резолвер, это разные типы DNS-серверов, они составляют основу DNS. Технически они представляют собой программно-аппаратные комплексы разной степени сложности, и обычно работают на выделенном физическом сервере или в виртуальной машине. Функции конкретно сервера имён выполняет программное обеспечение (пакет программ), специально разработанное для решения данной задачи. Примеры программных пакетов DNS-серверов: BIND (Berkeley Internet Name Daemon, этот пакет является стандартом де-факто), NSD (Name Server Daemon), Unbound, Knot DNS, PowerDNS и др. При работе в качестве авторитативного сервера, DNS-сервер отвечает на запросы других серверов о доменной зоне, для которой является авторитативным. В качестве рекурсивного резолвера (или кеширующего сервера) - DNS-сервер выполняет запросы к другим DNS-серверам (к авторитативным), запоминает полученные ответы в локальной памяти (в кеше), и отвечает на запросы клиентов. Клиентами рекурсивного резолвера являются другие компьютеры.
Рассмотрим роли серверов и используемое программное обеспечение на простом примере. Предположим, что пользователь, желая зайти на сайт под доменом www.example.com, вводит в адресной строке браузера соответствующее имя: www.example.com. Браузер передаёт данный запрос локальному сервису DNS, встроенному в операционную систему. Такие локальные сервисы часто называют stub-резолверами, они очень простые и не умеют выполнять рекурсивный опрос DNS. Основная функция системного stub-резолвера - отправить запрос, ответ на который ему неизвестен, дальше, в адрес резолвера, предоставленного провайдером (этот резолвер указывается при настройке сетевого соединения в операционной системе). Резолвер провайдера является рекурсивным резолвером и, скорее всего, представляет собой экземпляр одного из программных пакетов, упомянутых выше. Рекурсивный резолвер либо может ответить на запрос сразу, если обнаружит актуальную копию DNS-ответа в локальном кеше, либо приступит к опросу авторитативных серверов для того, чтобы извлечь ответы, которых нет в кеше. Если кеш пуст, то рекурсивный резолвер начинает с обращения к корневым серверам, являющимся авторитативными для корня DNS. Корневые серверы также могут использовать то или иное программное обеспечение DNS-сервера. То есть, во многих практических случаях и рекурсивный резолвер провайдера, и корневой сервер глобальной DNS используют одно и то же программное обеспечение, например, BIND.
Полное, с точки зрения настроек DNS, описание доменной зоны может быть представлено в файле зоны. Файл зоны, кроме служебной информации, содержит набор строк, определяющих ресурсные записи DNS. Ресурсная запись это набор из имени и других DNS-параметров, где ключом является имя. Каждую ресурсную запись можно представить в виде понятной текстовой строки, содержащей, помимо имени, класс записи, тип записи, значение TTL, значение самой записи и другие параметры. Например, A-запись, определяющая IP-адрес для данного имени, можно представить следующим образом: example.com. 900 IN A 192.0.2.71
Таким образом, файл зоны - это текстовый файл типового формата, соответствующего DNS-серверу BIND, содержащий определения для ресурсных записей. Его использование является стандартом де-факто, однако различные авторитативные серверы применяют и другие методы хранения данных, в том числе, с использованием СУБД. Тем не менее, файл зоны остаётся универсальным инструментом обмена данными о той или иной доменной зоне. Обычно DNS-хостинги принимают файлы зон в качестве управляющей информации.
Многие зоны DNS размещены на нескольких авторитативных серверах. Для DNS использование нескольких серверов изначально является стандартной практикой. При этом один из серверов является "главным" - он называется первичным DNS-сервером или master-сервером (экзотические конфигурации с несколькими первичными серверами мы не рассматриваем). Первичным - сервер делает то, что он является источником файла зоны для всех остальных серверов ("ведомых", вторичных или secondary-серверов). То есть, другие авторитативные серверы периодически получают свою копию файла зоны с первичного, обращаясь к нему с соответствующим запросом. Этот процесс называется трансфером (transfer) зоны, в типовом случае он сводится к одной транзакции: вторичный сервер отправляет запрос на первичный, указывая имя зоны, для которой требуется получить полный файл; в ответ - первичный сервер присылает актуальную копию файла зоны. Существует также механизм уведомления вторичных DNS-серверов первичным о том, что в файле зоны произошли изменения. Если новый файл зоны не получен каким-либо вторичным DNS-сервером, то этот сервер будет отвечать на запросы устаревшими данными. Спецификация DNS предусматривает, что вторичные серверы в любом случае периодически пытаются получить обновлённый файл зоны с первичного, даже если в какой-то момент этого сделать не удалось.
Тип ресурсной DNS-записи обозначает её предназначение. В соответствии с типом интерпретируется содержание записи. Например, A-запись - это ресурсная запись типа A, которая содержит IP-адрес. Также различают классы записей, однако в современной DNS в подавляющем большинстве случаев используется единственный класс - IN (от англ. Internet). Типов ресурсных записей существует несколько десятков. Сред них есть два строго обязательных: соответствующие записи должны быть в любой зоне, иначе она считается некорректной. Обязательные типы - это SOA и NS.
SOA
SOA - аббревиатура Start of Authority (в переводе: "начало полномочий", что означает, буквально, начало зоны ответственности). SOA-запись содержит базовые параметры доменной зоны. В частности, имя первичного DNS-сервера и контактный адрес электронной почты. SOA-запись в зоне допускается только одна. Пример SOA-записи:
example.com IN SOA ns1.example.com. admin.example.com.
( 2018032600 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
900 ) ; TTL
IN - класс записи;
SOA - тип записи;
следом за SOA идут два поля, содержащие имя первичного DNS-сервиса и контактный адрес электронной почты (см. ниже);
числа, которые даны в скобках, соответствуют параметрам SOA-записи: serial - это серийный номер экземпляра DNS-зоны; refresh, retry, expire - интервалы в секундах, определяющие, соответственно, периодичность обновления файла зоны, интервал ожидания при повторной отправке запроса на обновление в случае ошибки, интервал, по окончании которого локальная копия файла зоны становится недействительной (в случае, если не удалось получить обновление с первичного сервера);
параметр TTL обозначает TTL по умолчанию для «отрицательных ответов», то есть, например, для DNS-ответов авторитативного сервера, относящихся к несуществующим записям (также это значение может трактоваться как минимальный интервал TTL для записей в зоне или значение TTL по молчанию).
В примере SOA-записи указаны два имени: ns1.example.com. и admin.example.com. Первое - это имя первичного DNS-сервера, которое дано в привычной форме. Второе имя - admin.example.com. - соответствует адресу электронной почты. Так как символ @ в формате файла зоны имеет специальное значение, в записи адреса он заменяется на точку (первая слева). Таким образом, admin.example.com. следует читать как admin@example.com.
NS
Второй необходимый тип ресурсных записей - NS. Это записи, содержащие адреса авторитативных серверов имён (DNS-серверов) для конкретного имени домена. Пример пары NS-записей:
example.com. 3600 IN NS ns1.test.ru.
example.com. 3600 IN NS ns2.test.ru.
С помощью таких записей для зоны example.com назначаются два авторитативных сервера: ns1.test.ru. и ns1.test.ru.
NS-записи также используются при делегировании зон, то есть, для размещения в иерархии DNS зон, находящихся на уровень ниже данной, которые поддерживаются собственными авторитативными серверами. Например, пусть в example.com размещается зона третьего уровня site.example.com, тогда в файле зоны example.com должны быть добавлены записи NS для site.example.com (как минимум, одна такая запись, но рекомендуется хотя бы две, с разными DNS-серверами):
site.example.com. 3600 IN NS ns.example.net.
Обратите внимание, что для размещения под именем site.example.com веб-узла - не обязательно делегировать зону site.example.com. В этом случае достаточно внести в файл зоны example.com A-запись со значением IP-адреса:
site.example.com. 600 IN A 192.0.2.11
Отличие размещения NS-записей (делегирования) в том, что таким образом в DNS создаётся новая зона, адресная информация о которой находится на авторитативных серверах, указанных при делегировании. (В случае делегирования, для того, чтобы разместить под site.example.com веб-узел, нужно указанную выше запись внести уже в файл зоны site.example.com.)
A- и AAAA-записи
A-запись содержит IP-адрес, соответствующий имени. Эта запись подходит только для IPv4. Шестая версия протокола IP - имеет другой формат записи адресов и ей соответствует другой тип ресурсной адресной записи: AAAA (читается как "квад-эй" или "квадро-эй"). AAAA-запись практически аналогична А-записи, за исключением того, что в качестве значения указывается IPv6-адрес. Пример AAAA-записи:
site.example.com. 600 IN A 2001:db8::bebe
MX-запись
Для размещения информации о почтовых серверах, обслуживающих данную доменную зону, используются MX-записи. Эти записи содержат имя почтового сервера, а также его приоритет. Приоритет обозначает то, в каком порядке внешний сервер, пытающийся доставить почту, должен обращаться к почтовым серверам, указанным в MX-записях. Пример:
example.com. 1200 IN MX 5 mail1.example.com.
example.com. 1200 IN MX 10 mail2.example.com.
Приоритет - это число, указанное после типа записи MX. Данные записи обозначают, что при попытке доставить почту для адреса user@example.com, внешние (относительно зоны example.com) почтовые серверы будут, прежде всего, обращаться к mail1.example.com, а в случае неудачи, попытаются использовать mail2.example.com.
TXT
TXT - запись этого типа позволяет размещать в DNS текстовые строки. Может быть использована для публикации дополнительной информации о зоне, нередко служит контейнером для различных ключей авторизации или для "псевдозаписей", которые ещё не получили собственного типа. Предусмотрен формат хранения пар "ключ-значение" в TXT-записях, в таком случае строка разделяется символом "=" Пример:
string.example.com. 3600 IN TXT "Batman=Game over, Joker!"
SPF
SPF - тип записи, позволяющий определить политику доставки электронной почты для данного домена. Основное применение - защита от спама и спуфинга почтовых адресов: например, запись позволяет указать IP-адреса серверов, которым разрешено отправлять почту от имени данной доменной зоны, соответственно. SPF-запись имеет собственный формат, достаточно сложный, чтобы описывать различные ограничения и разрешения, касающиеся отправки почты. Информация для SPF также может размещаться в TXT-записи.
CAA
CAA - эти записи позволяют разместить в DNS информацию, связанную с выпуском TLS-сертификатов для имён в зоне. В частности, при помощи CAA-записи можно указать, каким удостоверяющим центрам администратор доменной зоны разрешает выпуск TLS-сертификатов.
Авторитативные серверы, на которые делегирована доменная зона, отвечают на запросы рекурсивных резолверов об этой зоне. Это означает, что авторитативные серверы полностью контролируют адресацию внутри зоны. Так, изменяя информацию в MX-записях, можно перенаправить всю почту, поступающую в домен. Изменение A-записей - позволяет перенаправить веб-трафик. То есть, список авторитативных серверов должен поддерживаться в актуальном состоянии, соответствующем логике административного управления зоной.
Наиболее распространёнными ошибками в этой области являются неверное указание имён авторитативных серверов и потеря контроля над доменными зонами, в которых находятся имена серверов. Проиллюстрируем ситуацию парой примеров:
1. Администратор доменного имени test.ru делегировал его, при помощи панели управления регистратора, на серверы имён ns1.example.com и ns2.exapmle.com. При этом второе имя указано с опечаткой: exa_pm_le. Злоумышленник, обнаружив такие настройки делегирования (а они доступны в DNS), зарегистрировал домен exapmle.com и разместил там собственный DNS-сервер под именем ns2.exapmle.com. Таким образом, часть запросов резолверов, относящихся к имени test.ru, теперь поступает на DNS-сервер злоумышленника, который может произвольно перенаправлять пользовательский трафик с помощью специально подготовленных DNS-ответов.
2. Администратор test.ru делегировал имя на серверы ns1.example.net и ns2.example.net, которые принадлежат хостинг-провайдеру. Однако через некоторое время хостинг-провайдер разорился и снял с делегирования свой домен example.net. В результате зона test.ru оказалась недоступной.
Протокол DNS изначально разрабатывался как средство сопоставления символических имён хостов и их IP-адресов. Некоторое время на заре существования ARPANet (предшественника интернета) списки соответствия распространялись в виде файлов, но с ростом сети потребовалась иерархическая схема, когда NS-сервер знает IP-адреса нижележащих доменов. Процесс получения IP-адреса по символическому имени называется резолвингом.
Теоретическая схема резолвинга описывается следующим образом: доменное имя разделяется на части, и на каждом шаге серверу, отвечающему за более узкое подмножество имён, передаётся всё более точный запрос. Опрос начинается с корневых серверов, где хранится информация о серверах имён доменов верхнего уровня (таких как .RU, РФ, .COM, NET). К NS-серверу доменов верхнего уровня приходит уже запрос с именем второго уровня (например, cctld.ru). Запросы повторяются рекурсивно, пока не будет получен ответ для изначально запрошенного имени.
На практике схема отличается. В большинстве операционных систем встроенные резолверы не делают рекурсивный опрос, а просто переадресуют запрос провайдерским серверам или серверам так называемым публичным резолверам (самые известные поддерживаются такими компаниями, как Google, в России держателем одного из самых популярных публичных NS-ов является Яндекс). Такие провайдерские сервера кешируют ряд ответов, так что при повторном обращении за одним и тем же именем рекурсивного опроса не будет, а ответ будет передан пользователю почти мгновенно.
Для корректной работы рекурсивного резолвинга необходимо, чтобы в зону более высокого уровня были внесены данные о name server-ах доменов. Для доменов второго (в ряде зон — третьего) уровня эти записи могут быть внесены только через регистратора. Также для большинства доменов верхнего уровня только через регистратора могут вноситься данные о ключах, используемых в технологии DNSSec. Так как на практике у сайта хостинг-провайдер, оператор name server-ов и регистратор могут не иметь между собой ничего общего, то при смене хостинг-провайдера или регистратора могут возникнуть проблемы, приводящие к временной недоступности сайтов.
В последние несколько лет в связи с разоблачениями Сноудена встал вопрос о privacy в сети — по данным исследователей, около 70% пользователей могут быть идентифицированы по их ежедневным запросам к DNS. В связи с этим принимаются и внедряются дополнительные меры по маскировке запросов DNS. Эти меры можно разделить на две группы. К одной относится желание сократить объём данных, передаваемых вышележащим серверам — если пользователь запрашивает информацию о домене четвёртого уровня (например, level3.test.example.ru), то у корневого сервера достаточно спросить только про корневой домен RU, у домена зоны RU - про example.ru и так далее. Такой подход называется QNAME minimization и сейчас он достаточно хорошо поддержан популярными DNS-серверами. Второй подход опирается на традиционные криптографические методы защиты передаваемых данных и предполагает, что запросы по сети передаются в шифрованном виде. У этого подхода есть тот недостаток, что он сильно затрудняет кеширование ответов, и криптографические операции тоже сравнительно ресурсоёмкие. По оценкам держателей крупных DNS-серверов, нагрузка при использовании шифрованного DNS возрастает в несколько раз.
Некоторое время назад была предложена технология DANE и соответствующая DNS-запись, предназначенная для размещения в DNS информации о TLS-сертификатах, которые используются для защиты соединения с сайтом или другими сервисами в домене. Удостоверять подлинность этой записи предполагалось с помощью DNSSec. Технология не получила широкого распространения для верификации веб-сайтов и не была поддержана ни одним браузером из-за появления на рынке бесплатных TLS-сертификатов. В то же время она получила распространение для защиты соединений с почтовыми серверами.
Важной категорией записей DNS специального вида являются так называемые обратные записи (PTR records, от pointer - указатель). Эти записи размещаются в специальной служебной зоне in-addr.arpa и сопоставляют IP-адресу, указанному в обратном порядке — адресу 1.2.3.4 будет соответствовать запись 4.3.2.1.in-addr.arpa — имя хоста, которое считается для него основным. Для IPv6 будет аналогично использована зона ip6.arpa.
Запись может использоваться, например, для борьбы со спамом — при получении почты адрес хоста будет сверяться с адресом отправителя.
