Обзор терминологии, компонентов и концепций DNS

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

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

Давайте начнем!

Терминология доменов

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

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

Система доменных имен (сокращенно DNS) — это сетевая система, которая преобразует удобные для человека доменные имена в уникальные IP-адреса.

• Доменное имя

Доменное имя — это удобное для человека имя, используемое для связи с интернет-ресурсом. Например, “cloudsigma.com” — это доменное имя. Некоторые могут утверждать, что доменным именем является только часть “cloudsigma”, но в целом это относится ко всему имени целиком.

URL-адрес “cloudsigma.com” связан с серверами, принадлежащими CloudSigma. При вводе URL-адреса в веб-браузер он связывается с DNS для подключения к IP-адресу целевого сервера.

• IP-адрес

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

Существует два типа IP-адресов:

• • IPv4: Это наиболее распространенная форма IP-адреса. Он записывается в виде набора из четырех чисел, каждый набор содержит до 3 цифр. Каждая группа разделяется точкой. Диапазон IPv4 составляет от 0.0.0.0 до 255.255.255.255.

  • IPv6: Это более современный стандарт, разработанный для решения проблемы исчерпания адресов IPv4. IPv4 поддерживает до 232 уникальных адресов, в то время как IPv6 поддерживает до 2128 адресов. Любой IPv6-адрес записывается шестнадцатеричными цифрами. Он может содержать до 32 цифр, разделенных на 8 разделов (по 4 цифры в каждом разделе). Каждый раздел разделяется двоеточием (:).

Домен верхнего уровня

Домен верхнего уровня (сокращенно TLD) — это наиболее общая часть домена. Он относится к крайней правой части (отделенной точкой). Некоторые из распространенных доменов верхнего уровня включают:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

С точки зрения доменных имен, эти домены находятся на вершине иерархии. ICANN (Internet Corporation for Assigned Names and Numbers) может выдавать разрешения определенным сторонам на управление доменами верхнего уровня. С этого разрешения эти стороны могут распространять доменные имена в рамках TLD (обычно через регистратора доменов).

• Хосты

В домене владелец может указывать отдельные хосты, относящиеся к отдельным машинам/службам, доступным через домен. Например, обычной практикой является обеспечение доступа к веб-серверам через «голый» домен ( example.com) и определение “хоста” “www  ( www.example.com).

В рамках общего домена можно иметь дополнительные хосты, например, доступ к API через хост “api” ( api.example.com), доступ по FTP через хост “ftp” или “files” ( ftp.example.com или files.example.com).

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

• Поддомен

Поддомен — это понятие, связанное с хостами. DNS функционирует по иерархическому принципу. TLD может содержать множество доменов. Например, “ example.com”, “ cloudsigma.com”, etc. are all under the “com” TLD. In that regard, a sub-domain is a reference to any domain that’s a part of the target domain. Thus, we can say that “example.com” is a sub-domain of “com”. Generally, the “example” portion is referred to as an SLD (second-level domain).

Аналогично, домен может контролировать все “поддомены”, расположенные под ним. Обычно именно это имеют в виду под словом “поддомен”. Например, “ history.example.com” является поддоменом “ example.com”.

Ключевое отличие между именем хоста и поддоменом заключается в том, что хост определяет компьютер/ресурс, тогда как поддомен расширяет родительский домен. Когда мы говорим о поддоменах или хостах, вы можете убедиться в этом, посмотрев на самую левую часть домена, так как она является наиболее конкретной. Именно так работает DNS: от наиболее конкретного (крайняя левая сторона) к наименее конкретному (крайняя правая сторона).

• Полностью определенное доменное имя

Полностью определенное доменное имя (сокращенно FQDN) относится к абсолютному доменному имени. В системе DNS домены могут быть заданы относительно друг друга. Это может привести к некоторой двусмысленности. Однако FQDN — это абсолютное имя, указывающее на абсолютный корень системы доменных имен.

Это означает, что FQDN указывает каждый родительский домен, включая TLD. Подходящим примером будет “ mail.google.com”. В некоторых случаях FQDN может не заканчиваться точкой, но он должен иметь точку в конце (этого требуют стандарты ICANN).

• Сервер имен

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

Сервер имен может быть “авторитетным”, что означает, что он дает ответы только на запросы о доменах, находящихся под его управлением. Такие серверы могут передавать запрос другим серверам имен или предоставлять кэшированную копию данных других серверов имен.

• Файл зоны

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

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

• Записи

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

DNS в действии

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

• Корневые серверы

DNS по своей сути функционирует по иерархическому принципу. На самом верху системы находятся “корневые серверы”. Эти серверы находятся под контролем различных организаций. Полномочия этих серверов делегированы ICANN (Интернет-корпорация по присвоению имен и номеров).

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

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

Однако корневой сервер на самом деле не знает местоположение домена. Он лишь перенаправляет запрос тому, кто обрабатывает конкретно запрошенный домен верхнего уровня. Например, если сделан запрос к “ blog.cloudsigma.com”, у корневого сервера не будет его в записях. Он выполнит поиск в своих зонных файлах, но записи для него не найдется. Вместо этого он распознает TLD “com” и перенаправит запрашивающий объект к DNS-серверу, обслуживающему адреса “com”.

• Серверы TLD

Продолжая наш предыдущий пример, запрашивающий объект теперь отправит запрос на IP-адрес (предоставленный корневым сервером). В случае с “ blog.cloudsigma.com”, DNS-сервер “com” выполнит поиск в записях своих зонных файлов.

Записи, соответствующей запросу, не найдется. Однако он найдет запись с IP-адресом DNS-сервера, отвечающего за “ cloudsigma.com”.

• DNS-сервер уровня домена

Теперь у запрашивающего объекта есть IP-адрес DNS-сервера, который непосредственно хранит информацию о “ blog.cloudsigma.com”. Теперь он отправит новый запрос к серверу с просьбой разрешить “www.cloudsigma.com”.

Как и прежде, DNS-сервер проверит свои зонные файлы и найдет тот, который связан с “ cloudsigma.com”. Внутри этого файла будет находиться запись для хоста “www”. Эта запись описывает, где расположен хост. Затем окончательный ответ передается запрашивающему объекту.

• Резолвящий DNS-сервер

В примере мы упомянули запрашивающий объект. Что это такое? В большинстве случаев запрашивающей стороной будет “резолвящий DNS-сервер”. Это сервер, настроенный на отправку запросов другим серверам. Он выступает в качестве промежуточного сервера для пользователей. Он кэширует результаты для повышения скорости.

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

При вводе URL-адреса в веб-браузере он ищет местоположение ресурса. Сначала поиск выполняется локально. Сюда входит файл “hosts” (и некоторые другие места). Если адрес не найден, запрос отправляется на резолвящий DNS-сервер. Получив запрос, резолвящий DNS-сервер ищет ответ в своем кэше. Если он не найден, то выполняются шаги, описанные ранее.

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

• Зонные файлы

Мы уже обсуждали понятия “зонных файлов” и “записей”. Как же они работают?

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

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

Параметр $ORIGIN зоны равен наивысшему уровню полномочий зоны. Например, зонный файл для “ cloudsigma.com” будет иметь в качестве $ORIGIN значение “ cloudsigma.com”. Значение параметра может храниться в начале файла зоны или в конфигурации DNS-сервера. В любом случае параметр описывает, для какой зоны этот файл является авторитетным.

Параметр $TTL задает информацию о “времени жизни” (time to live) предоставляемого им результата. Его можно описать как таймер, который кэширующий сервер может использовать для отслеживания актуальности кэшированных ответов. Если значение TTL истекает, ответ перестает быть действительным и отбрасывается.

• Типы записей

Файлы зон состоят из многочисленных записей. Существуют различные типы записей. Далее мы рассмотрим некоторые из наиболее распространенных (и обязательных) типов записей:

Записи SOA

Запись Start of Authority (сокращенно SOA) обязательна во всех файлах зон. Она должна быть первой реальной записью в файле. Однако такие записи, как $ORIGIN или $TTL могут появляться перед ней.

Запись SOA — один из наиболее сложных типов записей. Ее структура выглядит примерно так:

Давайте разберем ее по частям:

• • example.com: Эта часть определяет корень зоны. В данном примере файл зоны предназначен для домена “ example.com”. Иногда это значение может быть заменено на @ (заполнитель для подстановки значения $ORIGIN).

  • IN SOA: Термин “IN” означает “internet”. Вы найдете его во многих записях. Термин “SOA” указывает на то, что это запись SOA.

  • ns1.example.com: Это значение содержит основной DNS-сервер для домена “ example.com”. DNS-серверы могут быть как основными, так и вторичными. Если была настроена динамическая DNS, то должен быть один “основной” сервер. Если динамическая DNS не настраивалась, то это будет один из основных DNS-серверов.

  • admin.example.com: Здесь указывается адрес электронной почты администратора зоны. Обратите внимание, что символ @ заменяется на . здесь. Если исходный адрес электронной почты содержит точку, то она заменяется на \. Например, “ my.domain@example.com” превратится в “ my\domain.example.com”.

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

  • 3h: Представляет собой интервал обновления зоны. Вторичные серверы будут ожидать в течение этого времени перед проверкой обновлений файла зоны.

  • 30m: Это значение представляет собой интервал повтора для зоны. Если вторичному серверу не удается подключиться к основному серверу по истечении периода обновления, он будет ожидать в течение этого времени перед повторным опросом основного сервера.

  • 3w: Это значение представляет собой период истечения срока действия. Если вторичному серверу не удается подключиться к основному серверу в течение этого времени, он перестанет возвращать ответы как “авторитетные”.

  • 1h: Это значение представляет собой время, в течение которого DNS-сервер будет кэшировать ошибку имени, если оно не было найдено в его файле зоны.

Записи A и AAAA

Эти записи устанавливают соответствие между хостом и IP-адресом. Здесь запись “A” означает сопоставление IPv4 с хостом, а AAAA — сопоставление IPv6.

Это базовая структура записей A и AAAA:

В примере записи SOA мы назвали DNS-сервер “ ns1.exampel.com”. DNS-сервер относится к домену “ example.com”. Вот как будет выглядеть его запись A:

Обратите внимание, что нам не нужно было указывать полное имя. Используя только имя хоста (без FQDN), DNS-сервер может подставить оставшуюся часть, взяв значение из $ORIGIN. Тем не менее, мы все еще можем использовать FQDN:

Вот как можно определить веб-сервер как “www”:

Нам также следует включить сопоставление с базовым доменом. Запись будет выглядеть следующим образом:

В качестве альтернативы мы можем использовать @ символ для обозначения базового домена (вместо его полного имени):

Рекомендуется добавить групповую (wildcard) запись, которая позволяет разрешать любые имена в этом домене, не определенные явно:

Эта же структура применима и к записям AAAA. Единственное отличие — это IPv6-адреса.

Записи CNAME

Записи CNAME действуют как псевдоним для канонического имени сервера (определенного записью A или AAAA). Посмотрите на следующий пример:

Здесь мы использовали “server1” в качестве псевдонима для определения имени “www”. Обратите внимание, что такие сокращения снижают производительность, поскольку серверу приходится выполнять дополнительные запросы для получения окончательного ответа. В зависимости от количества уровней псевдонимов это может легко привести к значительным потерям производительности. Однако существует один конкретный случай, когда использование псевдонимов CNAME приносит пользу, например, предоставление ресурса за пределами текущей зоны.

Записи MX

Записи MX определяют почтовые серверы для домена. Это помогает электронной почте правильно доходить до сервера. В отличие от других записей, записи MX не сопоставляют хост с чем-либо, так как они применимы ко всей зоне. Вот почему записи MX выглядят примерно так:

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

Запись MX должна указывать на хост, определенный записью A или AAAA (а не CNAME). Исходя из этого, если настроены два почтовых сервера, записи будут выглядеть следующим образом:

В этом примере, судя по номеру приоритета, “mail1” является более предпочтительным сервером, чем “mail2”. Мы можем еще больше сократить код, опустив полное доменное имя:

Записи NS

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

Подобно записям MX, записи NS применяются ко всей зоне. Таким образом, по умолчанию у них нет конкретного хоста. Записи NS будут выглядеть примерно так:

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

Вам также следует включить сопоставление хостов с записями A или AAAA:

Записи PTR

PTR-записи являются обратными классическим записям A или AAAA. Эти записи используются для определения имени, связанного с IP-адресом. Они обладают уникальным свойством, так как начинаются с .arpa корня и представляют владельца IP-адреса. Именно RIR (региональные интернет-регистраторы) распределяют IP-адреса между организациями и поставщиками услуг. К RIR относятся APNIC, AFRINIC, LACNIC, RIPE NCC и ARIN.

Например, PTR-запись для 111.222.333.444 будет выглядеть примерно так:

В следующем примере PTR-записи посмотрите на IPv6 DNS-сервер Google 2001:4860:4860::8888:

Мы можем использовать утилиту dig с флагом -x для поиска обратного DNS-имени IP-адреса. Например, посмотрите обратный DNS IP-адреса 8.8.4.4:

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

Популярные почтовые серверы проверяют PTR-запись IP-адреса, с которого было отправлено письмо. Если PTR-запись пуста, высока вероятность того, что письмо является спамом (и, следовательно, будет отклонено). Обратите внимание, что совпадение между FQDN и доменным именем в PTR-записи не является обязательным. Важным фактором является то, связана ли действительная PTR-запись с совпадающей и соответствующей прямой записью A.

Как правило, сетевые маршрутизаторы в Интернете имеют PTR-записи, соответствующие их физическому местоположению. Например, “NYC” или “CHI” являются допустимыми обозначениями для маршрутизаторов, расположенных в Нью-Йорке и Чикаго. Этот метод полезен при выполнении traceroute или MTR и анализе пути прохождения пакетов.

Записи CAA

Эти записи указывают центры сертификации (CA), которые могут выдавать SSL/TLS-сертификаты для вашего домена. С 8 сентября 2017 года все центры сертификации обязаны проверять записи CAA перед выдачей сертификата. Если запись CAA отсутствует, любой центр сертификации может выдать сертификат. В противном случае выдавать сертификаты разрешено только определенным центрам сертификации. Записи CAA могут применяться как к отдельным хостам, так и к домену в целом.

Вот пример записи CAA:

Часть записи, относящаяся к CAA, — это 0 issue "letsencrypt.org". Эта часть состоит из трех компонентов:

• Флаги: это целое число, указывающее, как центр сертификации должен обрабатывать теги, которые он не понимает. Если значение флага установлено в 0, то запись будет проигнорирована. Если значение равно 1, то центр сертификации должен отказать в выдаче сертификата.
• Теги: это строки, обозначающие назначение записи CAA. На данный момент допустимые значения включают issue (разрешение центру сертификации выдавать сертификаты для конкретного домена), issuewild (разрешение групповых сертификатов wildcard) и iodef (определение URL-адреса, по которому центры сертификации сообщают о нарушениях политики).
• Значения: это строки, связанные с тегом записи. Если тег — issue или issuewild, значением обычно будет домен центра сертификации, которому вы предоставляете разрешение. Если тег — iodef, это будет URL-адрес контактной формы или ссылка mailto: для обратной связи по электронной почте.

Мы можем использовать утилиту dig для получения записей CAA:

Для получения более подробной информации о записях CAA ознакомьтесь с RFC 6844.

Заключение

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

Вы являетесь клиентом CloudSigma? Тогда ознакомьтесь с управлением и обновлением обратных записей DNS/PTR для вашей инфраструктуры CloudSigma.

Приятной работы!