Введение в терминологию, компоненты и концепции DNS

Введение

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

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

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

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

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

Начнем с простого:

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

Система доменных имен, более известная как «DNS», представляет собой сетевую систему, которая позволяет нам преобразовывать понятные человеку имена в уникальные IP-адреса.

Доменное имя

Доменное имя — это понятное человеку имя, которое мы привыкли ассоциировать с интернет-ресурсом. Например, \google.com — это доменное имя. Некоторые люди скажут, что часть \google — это домен, но обычно мы можем называть комбинированную форму доменным именем.

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 (Интернет-корпорация по присвоению имен и номеров) предоставляет определенным сторонам контроль над доменами верхнего уровня. Затем эти стороны могут распространять доменные имена в TLD, обычно через регистратора доменов.

Хозяева

Внутри домена владелец домена может определить отдельные хосты, которые относятся к отдельным компьютерам или службам, доступным через домен. Например, большинство владельцев доменов обеспечивают доступ к своим веб-серверам через пустой домен (example.com), а также через определение \хоста\www (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». Часть «история» является субдоменом.

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

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

Полное доменное имя

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

Это означает, что он указывает каждый родительский домен, включая TLD. Правильное полное доменное имя заканчивается точкой, указывающей на корень иерархии DNS. Примером полного доменного имени является \mail.google.com.. Иногда программное обеспечение, запрашивающее полное доменное имя, не требует конечной точки, но точка в конце требуется для соответствия стандартам ICANN.

Сервер имен

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

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

Файл зоны

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

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

Рекорды

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

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

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

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

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

Как мы уже говорили выше, DNS по своей сути представляет собой иерархическую систему. На вершине этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и делегированы полномочиями ICANN (Интернет-корпорации по присвоению имен и номеров).

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

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

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

Таким образом, если запрос \www.wikipedia.org” сделан на корневой сервер, корневой сервер не найдет результат в своих записях. Он проверит файлы своей зоны на наличие списка, соответствующего \www.wikipedia.org. Он не найдет ни одного.

Вместо этого он найдет запись для TLD \org и предоставит запрашивающей стороне адрес сервера имен, ответственного за адреса \org.

TLD-серверы

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

Таким образом, чтобы продолжить наш пример, он отправил бы запрос серверу имен, ответственному за знание доменов \org, чтобы узнать, знает ли он, где находится \www.wikipedia.org.

И снова запрашивающая сторона будет искать \www.wikipedia.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-записи

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

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

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.. Часто вы увидите, что это заменено на @, который является просто заполнителем, заменяющим содержимое переменной $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: это серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, вы должны увеличивать это число, чтобы файл зоны распространялся правильно. Вторичные серверы будут проверять, больше ли серийный номер основного сервера для зоны, чем тот, который у них есть в их системе. Если это так, он запрашивает новый файл зоны, если нет, он продолжает обслуживать исходный файл.
3 часа: это интервал обновления для зоны. Это количество времени, в течение которого вторичный сервер будет ждать, прежде чем опросить основной сервер на наличие изменений в файле зоны.
30 м: это интервал повтора для этой зоны. Если вторичный сервер не может подключиться к первичному по истечении периода обновления, он подождет это время и повторит попытку опроса основного.
3w: Это период истечения срока действия. Если вторичный сервер имен не может связаться с первичным в течение этого времени, он больше не возвращает ответы в качестве авторитетного источника для этой зоны.
1h: Это количество времени, в течение которого сервер имен будет кэшировать ошибку имени, если он не сможет найти запрошенное имя в этом файле.

Рекорды A и AAAA

Обе эти записи сопоставляют хост с 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

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

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

НС отчеты

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

Вы можете задаться вопросом: «Если файл зоны находится на сервере имен, зачем ему ссылаться на самого себя?». Часть того, что делает 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-сервера IPv6 Google 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-адреса.

Вот пример команды копать. +short добавляется, чтобы сократить вывод до обратного DNS-имени.

dig -x 8.8.4.4 +short

Результатом команды dig выше будет имя домена в записи PTR для IP-адреса:

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

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

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

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

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

Примечание. Важно, чтобы полное доменное имя в записи 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, относится к части 0 issue letsencrypt.org. Он состоит из трех частей: флагов (0), тегов (issue) и значений (letsencrypt.org).

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

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

dig example.com type257

Для получения более подробной информации о записях CAA вы можете прочитать Как создавать записи CAA и управлять ими с помощью DNS DigitalOcean.

Заключение

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

Для обзора ознакомьтесь с разделом «Как настроить домены в панели управления DigitalOcean».