Введение в DNS: основные термины, компоненты и понятия

Amber

5 лет назад

DNS (или Domain Name System, система доменных имен) – довольно сложная область в управлении серверами и сайтами. Навыки работы с DNS помогут вам определить проблемы в настройках доступа к веб-сайтам и расширят понимание того, что происходит «за кадром».

В этой статье вы найдете основные понятия DNS, которые помогут вам справиться с базовой конфигурацией DNS.

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

Основные термины DNS

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

DNS, или система доменных имен – это сетевая система, которая позволяет разрешать удобочитаемые доменные имена на уникальные адреса.
Доменное имя – это удобочитаемое имя, которое используется для связи с интернет-ресурсом. Например, «google.com» является доменным именем. URL-адрес «google.com» связан с серверами, принадлежащими Google Inc. Система доменных имен позволяет получить доступ к серверам Google при вводе «google.com» в браузер.
IP-адрес – это сетевой адрес. Каждый IP-адрес должен быть уникальным в своей сети. Когда речь идет о веб-сайтах, под сетью подразумевается весь интернет.
IPv4, наиболее распространенная форма адресов, записывается в виде четырех наборов чисел, каждый из которых имеет до трех цифр, и каждый набор разделяется точкой. Например, «111.222.111.222» может быть IP-адресом IPv4. DNS сопоставляет домен с адресом, чтобы пользователям не приходилось запоминать сложный набор цифр для каждого сайта.
Домен верхнего уровня (или TLD) является самым высоким уровнем после корневого домена. Домен верхнего уровня находится после точки. Популярными доменами верхнего уровня являются com, net, org, gov, edu и io. Домены верхнего уровня находятся в верхней части иерархии с точки зрения доменных имен. Некоторым сторонам ICANN (Internet Corporation for Assigned Names and Numbers) предоставляет корпоративный контроль над доменами верхнего уровня. Затем эти стороны могут распространять доменные имена под TLD, как правило, через регистраторы доменов.
Хосты ссылаются на отдельные компьютеры или сервисы, доступные через определенный домен. Например, большинство владельцев доменов делают свои веб-серверы доступными через голый домен (example.com), а также через определение хостов (www.example.com). В общем домене можно иметь и другие определения хостов. Получить доступ к API можно через хост api (api.example.com), а доступ к ftp – через хост ftp или files (ftp.example.com или files.example.com). Имена хостов могут быть произвольными, поскольку они уникальны для домена.
Поддомены (субдомены) – это домены, которые являются частью домена более высокого уровня. DNS работает как иерархия. TLD могут иметь много поддоменов. Например, в домене «com» есть поддомен «google.com» и «ubuntu.com». Поддомен – это по сути любой домен, который является частью домена высшего уровня. В этом случае «ubuntu.com» можно назвать субдоменом «com». Обычно часть «ubuntu» называется SLD, или доменом второго уровня. Каждый домен может управлять своими поддоменами. Например, у школы может быть субдомен для отдела истории www.history.school.edu (где history является субдоменом).
Разница между именем хоста и субдоменом заключается в том, что хост определяет компьютер или ресурс, а субдомен расширяет родительский домен – это метод разбиения самого домена.
Работая с субдоменами и хостами, вы можете заметить, что слева в домене располагаются уточняющие части, а справа – общие. Так работает DNS: читая слева направо, вы двигаетесь от узких к общим компонентам домена.
FQDN (fully qualified domain name, или полное доменное имя) – это имя, которое также является абсолютным доменным именем. Домены в системе DNS могут сопоставляться относительно друг друга и быть несколько неоднозначными. Полное доменное имя является абсолютным именем, определяющим его местоположение по отношению к абсолютному корню системы доменных имен. Это означает, что FQDN определяет каждый родительский домен, включая TLD. Правильный FQDN заканчивается точкой, указывающей корень иерархии DNS. Примером FQDN является «mail.google.com.». Иногда программное обеспечение, требующее полного доменного имени, не учитывает конечную точку, но по стандартам ICANN она необходима.
Сервер имен – это компьютер, предназначенный для перевода доменных имен в IP-адреса. Эти серверы выполняют большую часть работы в системе DNS. Поскольку общее количество переводов домена слишком велико для одного сервера, каждый сервер может перенаправить запрос на другие серверы имен или передать ответственность за поднабор поддоменов. Серверы имен могут быть авторитетными; такие серверы обслуживают запросы о доменах, находящихся под их контролем. Также серверы имен могут указывать на другие серверы или обслуживать кешированные копии данных других серверов имен.
Файл зоны – это простой текстовый файл, который содержит сопоставления между именами доменов и IP-адресами. Таким образом система DNS узнает, с каким IP-адресом следует связаться, когда пользователь запрашивает определенное доменное имя. Файлы зон хранятся на серверах имен и обычно определяют ресурсы, доступные по определенному домену, или место, где можно получить эту информацию. Записи хранятся в файлах зон. В своей простейшей форме запись – это одно сопоставление между ресурсом и именем. Они могут сопоставлять доменное имя с IP-адресом, определять серверы имен или почтовые серверы для доменов и т. д.

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

Теперь, когда вы знаете основные термины, можно посмотреть, как работает система DNS.

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

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

Ранее уже говорилось, что DNS по своей сути является иерархической системой. В верхней части этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и передают полномочия ICANN.

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

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

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

К примеру, если запрос на www.wikipedia.org отправлен на корневой сервер, корневой сервер не найдет результат в своих записях. Он проверит свои файлы зон и попробует найти запись, которая соответствует «www.wikipedia.org». Но не не найдет ее. Вместо этого он найдет запись для «org» и предоставит запрашивающей организации адрес сервера имен, ответственного за адреса «org».

TLD-серверы

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

Например, он отправил бы запрос серверу имен, ответственному за домены «org», чтобы узнать, где находится www.wikipedia.org.

Новый сервер также будет искать www.wikipdia.org в своих файлах зон. Он не найдет эту запись в своих файлах, однако он найдет запись с IP-адресом сервера имен, ответственным за «wikipedia.org».

Серверы имен доменов

На этом этапе инициатор запроса имеет IP-адрес сервера имен, который отвечает за IP-адрес ресурса. Он отправляет новый запрос серверу имен, снова спрашивая, может ли он разрешить www.wikipedia.org.

Сервер имен проверяет свои файлы зон и обнаруживает, что у него есть файл зоны, связанный с «wikipedia.org». Внутри этого файла есть запись для хоста «www». Эта запись сообщает IP-адрес, где находится этот хост. Сервер имен возвращает окончательный ответ инициатору запроса.

Что такое разрешающий сервер имен?

В приведенном выше примере упоминается инициатор запроса. Что это такое?

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

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

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

Затем разрешающий сервер имен проверяет свой кэш. Если он не найдет в кэше ответ, он выполнит описанные выше действия.

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

Файлы зон

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

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

Чем больше файлов зон имеет сервер имен, тем больше запросов он сможет авторитетно обслужить.

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

$ORIGIN – это параметр, который определяет максимальный авторитет зоны по умолчанию.

Поэтому, если файл зоны используется для настройки домена «example.com.», параметр $ORIGIN будет иметь значение «example.com.».

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

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

Типы записей

Файлы зон могут содержать записи разных типов. Рассмотрим самые распространенные из них.

SOA-записи

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

Начало SOA-записи выглядит примерно так:

domain.com. IN SOA ns1.domain.com. admin.domain.com. ( 12083 ; serial number 3h ; refresh interval 30m ; retry interval 3w ; expiry period 1h ; negative TTL )

domain.com. – это корень зоны. Указывает файл зоны для domain.com.domain. Часто вы будете видеть, что эта часть заменена на @ (это просто заполнитель, который заменяет содержимое переменной $ORIGIN).
IN SOA: часть «IN» означает Интернет (и будет присутствовать во многих записях). SOA является индикатором того, что это запись Start of Authority.
ns1.domain.com определяет основной сервер имен для этого домена. Серверы имен могут быть как ведущими, так и ведомыми. Если настроен динамический DNS, один сервер должен быть «ведущим мастером». Если вы не настроили динамический DNS, этот параметр просто определит один из основных серверов имен.
admin.domain.com – адрес электронной почты администратора этой зоны. Символ «@» в адресе электронной почты заменяется точкой. Если в самом адресе электронной почты есть точка, она заменяется символом «\» (например, your.name@domain.com преобразуется в your\name.domain.com).
12083 – серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, вы должны увеличить этот номер. Ведомые серверы будут проверять, увеличился ли серийный номер главного сервера зоны. Если это так, они запросят новый файл зоны, а если нет – продолжат обслуживать исходный файл.
3h – интервал обновления зоны. Это время ожидания ведомого устройства до запроса изменений файла зоны с мастер-сервера
30m – интервал повторного подключения для этой зоны. Если ведомый сервер не может подключиться к ведущему устройству для обновления, он повторить попытку спустя заданное в этом параметре время.
3w – время истечения срока действия. Если подчиненный сервер имен не смог связаться с мастером в течение этого времени, он больше не будет возвращать ответы в качестве авторитетного сервера этой зоны.
1h – количество времени, в течение которого сервер имен будет кэшировать ошибку, если он не может найти запрошенное имя в этом файле.

Записи А и АААА

Обе эти записи сопоставляют хост с IP-адресом. Запись A используется для сопоставления хоста с IP-адресом IPv4, а запись AAAA используется для сопоставления хоста с IPv6-адресом.

Общий формат этих записей таков:

host IN A IPv4_address host IN AAAA IPv6_address

Так как SOA-запись определила ns1.domain.com как основной сервер, его нужно сопоставить с IP-адресом, поскольку ns1.domain.com находится в зоне domain.com.

Запись может выглядеть примерно так:

ns1 IN A 111.222.111.222

Обратите внимание: тут не нужно указывать полное имя. Вы можете просто предоставить хост, без FQDN, а DNS-сервер заполнит остальные поля значением $ORIGIN. Но при желании вы можете так же легко использовать FQDN:

ns1.domain.com. IN A 111.222.111.222

В большинстве случаев здесь определяется веб-сервер как www:

www IN A 222.222.222.222

Также нужн указать, куда разрешается базовый домен. Сделать это можно так:

domain.com. IN A 222.222.222.222

Можно использовать @ для ссылки на базовый домен:

@ IN A 222.222.222.222

Специальный символ * позволяет разрешить все, связанное с этим доменом, что не определено явно на этом сервере.

* IN A 222.222.222.222

Аналогичным образом создаются и записи AAAA для адресов IPv6.

CNAME-записи

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

Например, если запись A определяет хост server1, вы можете использовать «www» в качестве псевдонима для этого хоста:

server1 IN A 111.111.111.111 www IN CNAME server1

Имейте в виду, эти псевдонимы сказываются на производительности, поскольку они требуют дополнительного запроса к серверу. В большинстве случаев такого же результата можно достичь, используя дополнительные записи A или AAAA.

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

MX-записи

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

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

IN MX 10 mail.domain.com.

Обратите внимание, в начале нет имени хоста.

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

Запись MX обычно указывает на хост, определенный записью A или AAAA, а не на хост CNAME.

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

IN MX 10 mail1.domain.com. IN MX 50 mail2.domain.com. mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222

В данной настройке хост mail1 имеет более высокий приоритет.

Эти записи можно создать так:

IN MX 10 mail1 IN MX 50 mail2 mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222

NS-записи

Этот тип записи определяет серверы имен, которые используются для этой зоны.

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

Как и записи MX, эти параметры распространяются на всю зону, поэтому они также не принимают хосты. В целом эти записи выглядят так:

IN NS ns1.domain.com. IN NS ns2.domain.com.

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

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

IN NS ns1.domain.com. IN NS ns2.domain.com. ns1 IN A 111.222.111.111 ns2 IN A 123.211.111.233

PTR-записи

Записи PTR используются для определения имени, связанного с IP-адресом. Записи PTR являются инверсией записи A или AAAA. PTR уникальны тем, что они начинаются с корня .arpa и передаются владельцам IP-адресов. Региональные интернет-регистраторы (RIR) управляют передачей IP-адресов. Региональные интернет-регистраторы – это APNIC, ARIN, RIPE NCC, LACNIC и AFRINIC.

Вот пример записи PTR для 111.222.333.444:

444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.

Этот пример записи PTR для IPv6-адреса показывает полубайтовый формат обратного DNS-сервера Google IPv6 2001:4860:4860::8888.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

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

Вот пример команды dig.

dig -x 8.8.4.4 +short

Эта команда вернет домен в записи PTR:

google-public-dns-b.google.com.

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

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

Примечание: Важно, чтобы FQDN в записи PTR имело соответствующую A-запись. Например, адрес 111.222.333.444 имеет PTR-запись для server.example.com, а server.example.com – это запись A, которая указывает на 111.222.333.444.

CAA-записи

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

CAA-запись выглядит так:

example.com. IN CAA 0 issue "letsencrypt.org"

Хост, IN и тип записи (CAA) – это обычные поля DNS. Информация, относящаяся к CAA, приведена в разделе «letencrypt.org». Он состоит из трех частей: флаги (0), теги (issue) и значения («letencrypt.org»).

Флаг – это число, которое определяет, как ЦС будет обрабатывать теги, которые он не понимает. Флаг 0 будет игнорировать такой тег. Флаг 1 отменит выдачу сертификата, если есть непонятные теги.
Тег – это строка, которая определяет цель записи CAA. В настоящее время они могут есть тег issue (для авторизации ЦС для создания сертификатов определенного имени хоста), issuewild (для авторизации wildcard сертификатов) и iodef (для определения URL-адреса, по которому ЦС может сообщить о нарушении правил).
Значение – это строка, связанная с тегом записи. Для тегов issue и issuewild указывается домен доверенного ЦС. Для тега iodef это может быть URL или почтовый адрес, куда ЦС может отправить сообщение об ошибке.

Вы можете использовать dig для извлечения записей CAA, используя следующие параметры:

dig example.com type257

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