вводить
Что такое DNS Полное название DNS — Система доменных имен (Domain Name System). DNS — сложная часть обучения настройке сайта или службы. Понимание того, как работает DNS, может помочь вам диагностировать проблемы с конфигурацией доступа к вашему сайту, а также углубить ваше понимание механизма, лежащего в его основе.
В этой статье мы обсудим некоторые основные понятия о DNS, которые помогут вам лучше настроить DNS. Конечно, лучше, если у вас уже есть доменное имя на руках до изучения этой статьи.
Прежде чем мы подготовимся к настройке разрешения доменного имени вашего сайта или настройке вашего доменного имени в панели управления бэкэнда, давайте изучим несколько понятий о том, как работает DNS.
Концепция домена
Мы должны начать с определения терминов. Хотя некоторые из этих тем знакомы в других контекстах при обсуждении доменных имен и DNS, многие из терминов, используемых при обсуждении доменных имен и DNS, обычно не используются в других вычислительных областях. Давайте начнем:
система доменных имен
Система доменных имен (часто называемая «DNS») — это сетевая система, которая позволяет нам преобразовывать понятные человеку имена в уникальные адреса.
Доменное имя
Доменное имя — это удобное для человека имя, которое мы используем для связи с интернет-ресурсом. Например, google.com — это доменное имя. Конечно, некоторые думают, что google — это доменное имя, но мы обычно называем доменным именем комбинацию google.com.
IP-адрес IP-адрес
IP-адрес — это то, что мы называем сетевой адресацией местоположения. Каждый IP-адрес в сети должен быть уникальным. Когда мы говорим о веб-сайтах, под этой сетью мы подразумеваем наш Интернет.
IPv4 — наиболее распространенная форма сетевого адреса, состоящая из 4 групп цифр, каждая группа состоит из трех цифр, группы разделены точками. Например, «111.222.111.222» — это допустимый IP-адрес IPv4. Используя DNS, мы можем сопоставить имя с нашим адресом, чтобы нам не нужно было запоминать эту сложную строку чисел, когда мы хотим получить к ней доступ в Интернете.
Домен верхнего уровня
Домены верхнего уровня, также известные как TLD, являются наиболее распространенной частью доменного имени. Это домен самого высокого уровня в иерархии DNS Интернета, и он хранится в пространстве имен корневого домена DNS. Доменное имя верхнего уровня — это последняя часть доменного имени, то есть буква после последней точки доменного имени.Например, в доменном имени example.com домен верхнего уровня — .com (или .COM), и случай считается таким же.wiki
Домен верхнего уровня — это самый высокий уровень доменного имени. Эта часть организована ICANN (Интернет-корпорация по присвоению имен и номеров). Для административного распространения оно распространяется в TLD через регистратора доменных имен.
Хост-хост
С помощью доменного имени вы можете определить независимые хосты для доступа к различным компьютерам и службам через доменное имя. Например, большинство владельцев доменных имен делают свое доменное имя доступным как через (example.com), так и через «www» (www.example.com), как это определено хостом.
Вы также можете определить другие имена хостов. Например: вы можете определить хост API и получить доступ к API через api.example.com или вы можете определить ftp или хост файлов, а затем получить к нему доступ через (ftp.example.com или files.example.com). Для доменного имени имя хоста под ним может быть произвольным, если оно гарантированно уникально для доменного имени.
Субдомен субдомена
Одна тема, связанная с именем хоста, — это поддомены.
DNS является иерархическим. Под именем домена верхнего уровня TLD может быть много доменных имен. Например, доменное имя верхнего уровня «com» будет иметь такие доменные имена, как «google.com» и «ubuntu.com». Субдомены — это те домены, которые находятся под большим доменным именем. Например, «ubuntu.com» в этом примере можно назвать поддоменом com. Мы называем ubuntu вторичным доменным именем SLD (домен уровня Secode).
То есть каждое доменное имя может управлять всеми поддоменами под ним. Это то, что мы обычно говорим через поддомены. Например, вы можете присвоить поддомен «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-адреса этих зеркальных серверов имеют тот же IP-адрес, что и единственный корневой сервер. Когда запрос отправляется на корневой сервер, он направляется на ближайший зеркальный корневой сервер.
Так что они делают с сервером? Корневые серверы обрабатывают запросы на информацию о домене верхнего уровня. Таким образом, если запрос не может быть разрешен на серверах имен более низкого уровня, запрашиваются корневые серверы для имени.
Корневой сервер на самом деле не знает, где находится хост домена. Они направляют запрос на сервер имен, который обрабатывает указанное доменное имя верхнего уровня для обработки.
Таким образом, если запрос сделан на корневой сервер, такой как «www.wikipedia.org», корневой сервер не найдет результата в своей записи. Он проверит свой файл зоны, чтобы увидеть, есть ли совпадение с «www.wikipedia.org». Конечно не найдут.
Вместо этого он находит запись для TLD «org» и возвращает адрес сервера имен для адреса организации.
TLD Server сервер доменных имен верхнего уровня
Затем запрашивающая сторона отправляет новый запрос на новый адрес (предоставленный корневым сервером), который является ответом TLD на этот запрос.
Итак, чтобы продолжить наш пример, он отправит запрос на сервер имен в ответ на известное доменное имя организации, чтобы узнать, существует ли местонахождение «www.wikipedia.org».
На этот раз запросчик ищет свой файл зоны. До сих пор не могу найти его в документации.
Однако он найдет IP-адрес сервера, ответственного за имя «wikipedia.org». Теперь мы на шаг ближе к желаемому ответу.
Сервер имен доменного уровня Сервер имен доменного уровня
На данный момент запрашивающая сторона уже имеет IP-адрес сервера имен, который обрабатывает фактический IP-адрес этого ресурса. Он отправляет новый водород на сервер имен, чтобы узнать, может ли сервер разрешить «www.wikipedia.org».
Сервер имен проверяет свой файл зоны и находит файл зоны, связанный с этим wikipedia.org. В этом файле есть запись для хоста «www». Эта запись содержит конкретный IP-адрес хоста. Затем сервер имен возвращает окончательный ответ запрашивающей стороне.
Что такое сервер разрешения имен?
В приведенном выше сценарии мы ссылались на «заявителя». Что такое Requester в этом сценарии?
Почти во всех случаях инициатором запроса является то, что мы называем «сервером разрешения имен». Сервер разрешения имен настроен на то, чтобы задавать вопросы другим серверам. Он действует как посредник для увеличения скорости пользователя за счет кэширования результатов предыдущего запроса, а также знает адреса корневых серверов, которые могут разрешать связанные запросы, которые ему еще не известны.
В основном пользователи редко настраивают серверы доменных имен на своих компьютерах. Серверы разрешения доменных имен обычно предоставляются интернет-провайдерами или другими организациями. Например, вы можете запросить DNS-серверы, предоставленные Google. Конечно, вы можете настроить их автоматически или вручную на своем компьютере.
Когда вы вводите URL-адрес в адресную строку браузера, ваш компьютер сначала ищет локально, чтобы узнать, был ли найден ресурс. Он делает это, проверяя файл hosts и некоторые другие файлы поиска на компьютере. Затем инициируйте запрос к серверу разрешения имен и дождитесь получения IP-адреса, соответствующего ресурсу.
Затем сервер разрешения имен проверяет свой кэш, чтобы узнать, может ли он найти ответ. Если он не найдет его, он выполнит шаги, упомянутые ранее.
Сервер разрешения имен обычно сжимает ход обработки запроса для конечного пользователя. Клиенту просто нужно спросить у сервера разрешения имен, где находится ресурс, и быть уверенным, что он вернет окончательный ответ.
Файл зоны Файл зоны
В приведенной выше процедуре мы упомянули файл зоны «Файл зоны» и запись «запись».
Файлы зоны — это место, где серверы имен хранят информацию об известных им доменных именах. Каждое доменное имя, известное серверу имен, хранится в файле зоны. Большинство запросов к общим серверам имен не требуют от сервера поиска в файле зоны.
Если он настроен на рекурсивный запрос, как сервер разрешения имен, он найдет ответ и вернет его. В противном случае он сообщит запрашивающей стороне, где искать дальше.
Чем больше файлов зон имеет сервер имен, тем больше запросов ему нужно обработать.
Файл зоны описывает зону DNS, которая является подмножеством всей системы доменных имен DNS. Обычно он используется для настройки одного доменного имени. Он может содержать несколько записей, чтобы определить, где находится ресурс, соответствующий доменному имени в запросе.
По умолчанию $ORIGIN в Zone является параметром, эквивалентным самому высокому уровню привилегий в зоне.
Таким образом, если файл зоны используется для настройки доменного имени «example.com.», для $ORIGIN будет установлено значение example.com.
Это настраивается в верхней части файла зоны или также может быть определено в файле конфигурации DNS-сервера для ссылки на файл зоны. В любом случае этот параметр указывает, какой файл представляет этот файл зоны.
Точно так же $TTL используется для настройки информации о «времени жизни». Он по сути таймер. Используется для представления кэша, в котором сервер имен может использовать результаты предыдущих запросов, пока не истечет время TTL.
Тип записи записи
В файле зоны мы можем использовать разные типы записей. Вскоре мы обсудим некоторые распространенные типы (или типы принуждения).
SOA-записи
Запись Initial Authorization или SOA является обязательной записью во всех файлах зон. Он должен быть первой реальной записью в файле (хотя
Над ним появится 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. Конечно, вы часто будете видеть здесь @, который является заполнителем для $ORIGN, как мы сделали выше.
- IN SOA: Часть «IN» означает Интернет (появляется во многих записях). SOA — это индикатор, используемый для указания того, что это запись SOA.
- ns1.domain.com.: Это определяет первичный сервер имен для этого домена. Сервер имен может быть главным сервером или подчиненным сервером. Если настроен динамический DNS, то здесь требуется мастер-сервер. Если у вас не настроен динамический DNS, это просто ваш основной сервер имен.
- admin.domain.com.: Это адрес электронной почты администратора этой зоны. @ в адресах электронной почты заменяется точкой. Если в адресе электронной почты есть точка, вместо нее нужно использовать обратную косую черту, например, ваше.имя@домен.com (его нужно писать как ваше\имя.домен.com).
- 12083: это серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, вы должны увеличивать это число, чтобы файл распространялся правильно. Ведомые проверят, больше ли серийный номер файла зоны мастера, чем серийный номер, уже имеющийся в их системе. Если это так, он запросит новый файл зоны, в противном случае он продолжит использовать старый.
- 3 часа: это период интервала обновления файла зоны. Подчиненное устройство ждет в течение этого периода времени, а затем опрашивает хост, чтобы проверить наличие изменений в файле зоны.
- 30 м: это интервал между повторными попытками файлов зоны. Если ведомое устройство не может подключиться к ведущему по истечении времени обновления, оно ждет некоторое время и повторяет попытку опроса ведущего.
- 3w: Срок годности. Если ведомый сервер имен не может подключиться к серверу в течение этого периода времени, он не может ответить как уполномоченный для зоны.
- 1h: этот период времени представляет собой время, в течение которого сервер имен кэширует ошибку имени, если он не может найти запрошенное имя в файле.
Рекорды A и AAAA
Все эти записи сопоставляют хост с IP-адресом. Записи A используются для сопоставления узла с IP-адресом IPv4, а записи AAAAA используются для сопоставления узла с адресом IPv6.
Общий формат этих записей
host IN A IPv4_address
host IN AAAA IPv6_address
Наша запись SOA вызывает наш основной сервер для ns1.domain.com. Нам нужно сопоставить его с IP-адресом, потому что файл зоны для домена.com в ns1.domain.com также определен.
Запись выглядит так:
ns1 IN A 111.222.111.222
Обратите внимание, что нам не нужно указывать полное имя. Нам нужно указать только хост, полное доменное имя не требуется, 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-адресов для организаций и поставщиков услуг. RIR включают 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 можно использовать для запроса IP-адреса обратного DNS-сервера.
Вот пример команды копать. Дополнительный +short используется для сокращения вывода обратного DNS-имени.
$ dig -x 8.8.4.4 +short
Выполните приведенную выше команду, вы увидите запись PTR для доменного имени, соответствующего IP-адресу.
google-public-dns-b.google.com.
Серверы в Интернете используют записи PTR для внесения доменных имен в записи журналов, принятия обоснованных решений по обработке спама и отображения легко читаемых сведений для других устройств.
Наиболее часто используемые почтовые серверы будут запрашивать записи PTR при получении почты. Если исходный IP-адрес не имеет связанной информации записи PTR, отправленное электронное письмо будет рассматриваться как спам и отклонено. Неважно, что полное доменное имя в PTR совпадает с доменным именем отправляемого электронного письма. Важно, чтобы существовали действительные записи PTR с соответствующими и совпадающими записями A вперед.
Часто сетевые маршрутизаторы в Интернете предоставляют записи PTR, соответствующие их физическим адресам. Например, вы можете увидеть ссылки на NYC или CHI как маршруты в Нью-Йорке и Чикаго. Это полезно при запуске traceroute или MTR или для просмотра путей интернет-трафика.
Большинство провайдеров предлагают выделенные услуги или услуги VPS, которые дадут клиентам возможность настраивать записи PTR для своего IP-адреса.
FQDN在PTR记录中有一个通讯并匹配前向A记录。
例如111.222.333.444有一个PTR到server.example.com和server.expamle.com有一个指向111.222.333.444的A记录
записи CAA
Записи CAA используются для указания того, каким центрам сертификации (ЦС) разрешено выдавать сертификаты SSL/TLS для вашего доменного имени. С 8 сентября 2017 г. всем центрам сертификации разрешено проверять эти записи перед выдачей сертификатов. Если это не задокументировано, любой ЦС может выдать сертификат. В противном случае существуют определенные центры сертификации, которые могут выдавать сертификаты. Записи CAA можно применять к одному хосту или ко всему доменному имени.
Ниже приведен пример записи CAA:
example.com. IN CAA 0 issue "letsencrypt.org"
host, IN и тип записи CAA являются общими в полях DNS. Информация CAA выше0 issue "letsencrypt.org"часть. Он состоит из трех частей: флаги (0), теги (проблема) и значения («letsencrypt.org»).
- Флаги — это целое число, указывающее, что ЦС должен обрабатывать теги, которые он не понимает. Если флаг равен 0, ведение журнала игнорируется. Если значение равно 1, ЦС ДОЛЖЕН отказать в выдаче сертификатов.
- Теги — это строки, представляющие цель записи CAA. В настоящее время они могут иметь полномочия разрешать центрам сертификации создавать сертификаты для определенных имен хостов, isswild — разрешать сертификаты с подстановочными знаками или iodef — определять URL-адреса, по которым центры сертификации могут сообщать о нарушениях политики.
- Values — это строка, связанная с записью тега. Для issue и issuewild это обычно домен, которому вы предоставляете полномочия CA. Для iodef это может быть URL-адрес контактной формы или ссылка на mailto: для обратной связи по электронной почте.
ты можешь использоватьdigДля отправки и получения записей CAA используйте следующие параметры:
$ dig example.com type257
Для получения дополнительной информации о записях CAA вы можете прочитать RFC6844.
в заключении
Теперь у вас должно быть достаточно хорошее представление о том, как работает DNS. Эти концепции относительно легко понять, если вы знакомы с этими стратегиями, но неопытным администраторам все еще трудно их реализовать.