Представьте, что вы идете в офис, открываете браузер и переходите по адресу 172.217.172.197, чтобы проверить свою электронную почту. Затем вы посещаете 140.82.112.4, чтобы просмотреть некоторые изменения кода, предложенные вашими коллегами. Затем вы открываете свой любимый клиент чата и подключаетесь к 84.17.44.180. Если вы еще не поняли: это отстой. Это мир без доменных имен.

Мы больше привыкли набирать gmail.com, github.com и chat.freenode.net, но точно так же, как вам нужен номер телефона вашего друга, чтобы позвонить им, ваш веб-браузер должен знать IP-адрес сервера для запроса страниц.. К счастью, у нас есть система поиска IP-адреса для заданного доменного имени, которая работает настолько безупречно, что нам почти никогда не приходится об этом думать.

Это также означает, что раньше я понятия не имел, как это работает, поэтому всякий раз, когда кто-нибудь говорил со мной об изменении настроек DNS, я испытывал чувство страха; «Это как телефонная книга в Интернете» не помогает мне понять, как кэширование записей влияет на рекурсивный поиск.

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

⌨️ Найдите запись адреса для `www.ianjmacintosh.com`

Допустим, я хочу посетить www.ianjmacintosh.com. Чтобы мой браузер мог его увидеть, моему браузеру необходимо знать IP-адрес, с которого он будет запрашиваться. Сначала мой браузер проверит, есть ли уже кэшированная запись www.ianjmacintosh.comIP-адреса. Эта запись называется запись адреса, или запись A. Если у меня нет A-записи, мой браузер запрашивает ее у моего преобразователя DNS. Преобразователи DNS предоставляют клиентам любые запрошенные ими записи, и их предоставляет каждый крупный интернет-провайдер. Я собираюсь продемонстрировать, как использовать инструмент командной строки (digсокращенно от Domain Information Groper ), чтобы вручную запрашивать записи из общедоступного преобразователя DNS Google и других серверов имен.

dig выполняет поиск в DNS и отображает полученные ответы. Большинство администраторов DNS используют dig для устранения проблем с DNS из-за его гибкости, простоты использования и ясности вывода. Он предустановлен в большинстве систем Mac OS X и Linux, но пользователям Windows, которые хотят его использовать, необходимо установить его вручную. Если вы читаете это в другой ОС (например, Android или iOS), вы можете попробовать воспользоваться веб-клиентом для раскопок, подобным этому случайному, который я нашел, но вы, вероятно, получите больше от этой статьи, прочитав сейчас и запустив команды позже на компьютере с локальной установкой dig.

Попробуйте свой первый digзапрос:


dig @8.8.8.8 www.ianjmacintosh.com A +short

Этот вызов запрашивает 8.8.8.8(IP-адрес общедоступного преобразователя DNS Google) для записи www.ianjmacintosh.comʼs A(адреса). Опция +shortзапроса просит копать, чтобы дать краткий ответ.

Этот краткий ответ выглядит так:


54.207.147.214
18.230.52.212

Это IP-адреса, к которым DNS-распознаватель Google сказал, что я должен связаться, если я хочу www.ianjmacintosh.com.

Даже если вы перестанете читать сейчас, по крайней мере, вы увидели, как быстро связать IP-адрес с доменным именем.

DNS деревья

Представьте, у вас есть путь в локальной файловой системе: /Users/alice/projects/next-great-american-novel. next-great-american-novelКаталог находится в projectsкаталоге, который находится в aliceдиректории, которая находится в Usersдиректории, которая находится в корневой (/каталог). Ученые-компьютерщики называют эту абстрактную идею деревом.

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

Чтобы получить запись A www.ianjmacintosh.com, преобразователь DNS запрашивает сервер имен com, которому он уже доверяет, который указывает ему на другой сервер имен, который знает все ianjmacintosh.com, а также на другой сервер имен, который знает все www.ianjmacintosh.com.

На самом деле это не совсем так; DNS-преобразователи и серверы имен иногда имеют записи, кэшированные локально, и им даже не нужно делать запрос. Если сервер имен имеет кэшированную запись для ianjmacintosh.com, он будет начинаться оттуда, а не подниматься вверх, чтобы найти запись для www.ianjmacintosh.comили pozo.ianjmacintosh.comили другого поддомена ianjmacintosh.com.

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

Обычно это полезно, потому что помогает распределить работу, необходимую для поиска записей, но в нашем случае мы не хотим распространять эту работу! Мы хотим все делать сами. Итак, мы собираемся использовать dig, чтобы сообщить серверам имен, для которых нам нужна запись A www.ianjmacintosh.com, но мы не хотим рекурсии.

⌨️ Запрос `8.8.8.8`на `www.ianjmacintosh.com`то адрес (`A`) запись с `+norecurse`опцией запроса

Вот синтаксис, который мы будем использовать digв этой статье:


dig [@server] [name] [type] [queryopt...]

Я буду использовать смайлы на клавиатуре (⌨️), чтобы указывать на запросы, которые я бы хотел, чтобы вы выполняли dig. Я опишу их простым английским языком, ваше упражнение будет заключаться в вызове настоящих команд. Попробуйте написать каждую команду самостоятельно, прежде чем сравнивать с тем, как это сделал я.

??‍♂️ Пытаться угнаться за тем, как все это работает мысленно, без запуска команд сложно и глупо. Если можете, перейдите в командную строку, чтобы следить за ней и максимально эффективно использовать эту статью.

Попробуйте составить команду для запроса 8.8.8.8 www.ianjmacintosh.comадресной записи с параметром запроса + norecurse самостоятельно. Ниже вы можете увидеть призыв, который я использовал ?


dig @8.8.8.8 www.ianjmacintosh.com A +norecurse

Эти аргументы и варианты:

8.8.8.8это сервер для запроса: общедоступный DNS-преобразователь Google. Я поставил @спереди, потому что это то, что предписывает digʼs documentation (man dig). Если вы опустите этот [@server]аргумент, dig проконсультируется /etc/resolv.confи запросит перечисленные там серверы имен.
www.ianjmacintosh.com– это имя записи ресурса, которую нужно найти.
Aэто тип записи, которую мы запрашиваем – мы ищем запись «A» (запись адреса). Если вы опустите этот [type]аргумент, dig все равно выполнит поиск записи A, но я всегда предпочитаю быть максимально подробным и явным при отображении примеров.
+norecurseпараметр запроса для отключения рекурсии (и итерации). Вкратце: это говорит серверам НЕ выполнять за нас дополнительную работу. Если вы его опустите [queryopt], запрашиваемый сервер может избавить вас от необходимости выполнять дополнительные упражнения для поиска нашего ресурса. Так как мы пытаемся получить практику, это плохо!
ПРИМЕЧАНИЕ. Возможно, вы заметили, что я пропустил эту +shortопцию. В оставшейся части статьи я буду работать с подробными отчетами.

Собираем все вместе: эта команда дает команду dig запросить 8.8.8.8запись с именем www.ianjmacintosh.comтипа Aи просит сервер не выполнять рекурсивный поиск.

Прочтите ответ и обратите внимание, что вы получили ошибку

dig вернет отчет, подобный этому:

Вместо того, чтобы пытаться понять все это, перейдите к разделу заголовка (->> HEADER <<-) и посмотрите, как он читается status: SERVFAIL. Это сокращение от «сбой сервера» и означает, что сервер имен не смог обработать этот запрос из-за проблемы с сервером имен. Вы не задали плохой вопрос, но он не мог дать вам настоящего ответа. Если бы он действительноANSWER SECTION давал ответ, он бы показал большой раздел с заголовком, в котором была бы наша запрошенная запись. Это также явно указано ANSWER: 0в строке ниже SERVFAIL.

Короче говоря, этот отчет показывает нам, что у общедоступного DNS-преобразователя Google нет адресной записи www.ianjmacintosh.com. Если вы снова +shortзапустите эту команду и добавите параметр, вы получите пустой ответ.

Причина, по которой мы получили ответ, когда мы запускали digраньше, заключалась в том, что мы не отключили рекурсию, а общедоступный DNS-преобразователь Google проделал за нас дополнительную работу. Эта дополнительная работа началась с обращения к так называемым «корневым серверам имен».

Домен верхнего уровня comявляется частью .(произносится как «корень»), точно так же, как www.ianjmacintosh.comявляется частью ianjmacintosh.com, а подобное ianjmacintosh.comявляется частью com. Чтобы явно показать корень доменного имени, DNS часто использует конечную точку при отображении доменных имен, например: www.ianjmacintosh.com.Это называется «полное доменное имя» (FQDN), и это завершающее .слово имеет то же значение, что и начало /в абсолютный путь (например, /Users/alice/projects/next-great-american-novel): root.

Каждый поиск должен где-то начинаться, и поэтому наш поиск www.ianjmacintosh.comзаписи адреса должен начинаться с корня. Мы ищем записи сервера имен, а не адресную запись – мы не пытаемся открыть ее .в нашем браузере. По этой причине нам нужно изменить наш [type]аргумент с A(для «адреса») на NS(для «сервера имен»).

⌨️ Запрос `8.8.8.8`на свое `.`название сервера (`NS`) записи с`+norecurse`


dig @8.8.8.8. NS +norecurse

Эти аргументы и варианты:

8.8.8.8 общедоступный DNS-преобразователь Google
. является корнем всех доменных имен
NS сокращенно от «DNS-сервер»
+norecurse все еще мешает серверу выполнять наши упражнения за нас

Собираем все вместе: эта команда дает команду dig запросить 8.8.8.8запись с именем .типа NSи просит сервер не выполнять рекурсивный поиск.

Найдите корневой сервер из отчета об ответе

Вот это да! Это больше походит на это! ?

Во-первых, посмотрите заголовок, где написано status: NOERROR. Нет ошибок! И в следующей строке, где было сказано ANSWER: 0раньше, теперь говорится ANSWER: 13. У нас есть собственно ANSWER SECTIONс 13 различными корневыми серверами имен, любой из которых должен иметь возможность отвечать на запрос записи сервера имен для com.

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

Кстати, вместо того, чтобы использовать IP-адрес для сервера, на который будет отправлен ваш следующий запрос, вы можете использовать доменное имя. Перед отправкой запроса dig незаметно запросит у вашего DNS-распознавателя его IP-адрес в фоновом режиме. Вместо этого 8.8.8.8вы можете использовать dns.google. Вместо этого 198.41.0.4можно использовать a.root-servers.net.

⌨️ Запросить у корневого DNS-сервера запись `com`s `NS`(с `+norecurse`)


dig @a.root-servers.net com NS +norecurse

Эти аргументы и варианты:

a.root-servers.net– это сервер, который мы запрашиваем для записи сервера имен для домена верхнего уровня com.
com это название записи, которую мы просим
NS сокращенно от «DNS-сервер»
+norecurseне a.root-servers.netвыполняет рекурсивный поиск

Получить `com`сервер имен из отчета

Джимини Крикет! Это много информации! Мы получили 13 прав доступа на выбор для comзаписей и дополнительный раздел, содержащий все их IP-адреса.

Все эти 13 серверов имен имеют записи для каждого зарегистрированного домена com. В самом деле!

⌨️ Спросите у `com`DNS `ianjmacintosh.com`-сервера запись о DNS-сервере (`+norecurse`как обычно)


dig @192.31.80.30 ianjmacintosh.com NS  +norecurse

192.31.80.30– это сервер, который мы запрашиваем для записи сервера имен для домена верхнего уровня com.
- d.gtld-servers.netВместо этого я мог бы так же легко использовать его и позволить dig находить его IP-адрес в фоновом режиме, но, поскольку у меня уже был IP-адрес передо мной, я использовал его.
ianjmacintosh.com это название записи, которую мы просим
NS сокращенно от «DNS-сервер»
+norecurseне 192.31.80.30выполняет рекурсивный поиск

Получить `ianjmacintosh.com`сервер имен из отчета

Любой из этих четырех серверов имен может предоставить мне дополнительную информацию о записях для www.ianjmacintosh.com. Выберите один для следующего запроса, мы почти готовы!

⌨️ Запросить у `ianjmacintosh.com`сервера имен запись `www.ianjmacintosh.com`ʼs `A`( `+norecurse`)


dig @dns1.p03.nsone.net www.ianjmacintosh.com A  +norecurse

dns1.p03.nsone.net– это сервер, который мы запрашиваем для записи сервера имен для домена верхнего уровня com.
- Как видите, я снова стал ленивым и разрешаю копать найти IP-адрес для dns1.p03.nsone.net
[www.ianjmacintosh.com](http://www.ianjmacintosh.com/) это название записи, которую мы просим
A это сокращение от «адрес»
+norecurseне dns1.p03.nsone.netвыполняет рекурсивный поиск – не то чтобы

? Найдите IP-адрес для `www.ianjmacintosh.com`

Ты сделал это! У вас есть IP-адреса для хостинга серверов www.ianjmacintosh.com. Прямо там, в разделе ответов, вы увидите те же IP-адреса, которые мы видели в отчете о наших первых раскопках: 18.230.52.212&54.207.147.214

Для удовольствия вы можете запустить dig с +traceопцией запроса, чтобы увидеть, как dig автоматически перебирает все эти шаги:


dig www.ianjmacintosh.com +trace

Вывод

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

Еще многое предстоит узнать, но это отличная отправная точка. Я планирую написать следующие статьи, чтобы исследовать еще несколько загадок DNS, в том числе, что такое CNAME, как вы можете обновлять свои записи и как справиться с некоторыми распространенными ошибками конфигурации.

Если вы только что просмотрели эту статью, не запускали никаких команд и все равно хотите чувствовать себя более уверенно с DNS, это нормально! Я надеюсь, что вы вернетесь к этой статье и пройдетесь по шагам, когда сможете. А пока вот несколько быстрых советов:

DNS похож на «телефонную книгу для Интернета» только в самом расплывчатом аналоге; это больше похоже на дерево, и ответы на запросы включают переход от корня к ветви к ветви
DNS означает «система доменных имен»
По умолчанию сообщения DNS передаются через порт 53.
dig – полезный инструмент диагностики DNS, входящий в состав BIND
BIND означает «домен имен в Интернете в Беркли» и представляет собой набор инструментов для имен доменов, первоначально разработанных в Калифорнийском университете в Беркли.
Самым заметным приложением BIND является его чрезвычайно популярный сервер- демон имени (он сбивает с толку, namedкак в «имя D», сокращение от «имя dameon»), который может отвечать на запросы DNS.

Дополнительная информация

Почему деревья доменов пишутся справа налево (`subdomain.domain.com`), а пути – слева направо (`/users/~imacintosh/articles/dns-for-web-developers`)?

Хороший вопрос. Я не нашел удовлетворительного ответа. Общие объяснения на форумах вопросов и ответов указывают на то, как адреса электронной почты (user@host) работают одинаково, переходя от более конкретных к менее конкретным. В записях Джона Постела, сделанных на встрече «Рабочей группы сети» в 1982 году, предполагается, что группа стремилась принимать решения, которые обеспечили бы наименьшее количество проблем при реализации. Кажется, это одно из таких решений, но я не вижу причин, почему.

Как бы то ни было, Тим Бернерс-Ли упомянул в интервью, что если бы он мог вернуться и сделать что-то по-другому, он бы привел домены в com.domain.subdomainпорядок. ??‍♂️

Итак, в основном весь Интернет работает на 13 различных корневых DNS-серверах?

Неа! Это 13 разных IP-адресов, но серверов, отвечающих на их запросы, гораздо больше; когда я писал это, их было более 1300, и они довольно хорошо распределены по миру. На главной странице корневых серверов есть аккуратная карта, на которой показано, где они все находятся. Если вы хотите понять, как несколько систем могут совместно использовать один IP-адрес, вы можете поискать «anycast».

Если `18.230.52.212`это IP-адрес хостинга сервера `www.ianjmacintosh.com`, почему я получаю странное сообщение об ошибке вместо вашего веб-сайта при его посещении?

Сервер по адресу 18.230.52.212 обслуживает множество веб-сайтов, не только мой. Этот сервер должен знать, какой веб-сайт вы запрашиваете. Когда вы посещаете сайт www.ianjmacintosh.com в своем браузере, он сообщает серверу 18.230.52.212 обслуживать www.ianjmacintosh.com. Когда вы заходите на сайт 18.230.52.212, он может не знать, что вы хотите.

Источник записи: https://dev.to