что такое доменное имя сервера
Давайте уже разберемся в DNS
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Базовые штуки
Давайте взглянем на маппинг между именем и адресом:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
Оставшаяся часть ответа описывает сам ответ:
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Другие типы
Что не так с CNAME
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com :
CNAME для Heroku или Github
Wildcards
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Что такое DNS-сервер простыми словами
Вы когда-нибудь задавались вопросом, как браузер понимает, какую именно страницу открыть, когда вы вводите в строку адрес сайта? На самом деле, это глубокий вопрос, решать который стоит не непосредственно с перехода на сайты, а со связи компьютеров между собой.
В 70-х — 90-х годах 20 века существовала сеть под названием ARPANET. Это была попытка объединить множество компьютеров министерством обороны США для возможности передачи информации во время войны. Важность такого подхода заключалась в быстрой передаче информации на дальние расстояния. Впоследствии принципы работы ARPANET легли в основу современного интернета.
Изначально вся сеть объединяла компьютеры в четырёх различных институтах США:
Учёные этих институтов быстро пришли к единому мнению, что передавать друг другу информацию об исследованиях удобнее при помощи новой сети. Для этого было достаточно знать идентификатор того компьютера, на который передаётся сообщение. Сейчас такие идентификаторы называются IP-адресами. У каждого устройства в интернете есть такой идентификатор и именно по нему обращаются устройства друг к другу.
В самом начале компьютеров, подключённых к сети, было несколько десятков, и их идентификаторы было легко запомнить. Можно было записать эти адреса в блокнот и использовать его так же, как и телефонные книги.
Время шло, и уже к середине 80-х годов вместо нескольких десятков компьютеров сеть стала насчитывать несколько тысяч. И каждый из них имел уникальный идентификатор, который становилось всё сложнее учитывать вручную или запоминать. Необходима была система, которая позволит очеловечить имена компьютеров и хранить все адреса в одном месте, чтобы каждый компьютер в сети имел один и тот же набор всех идентификаторов.
Файл hosts — как первый шаг к созданию DNS
Для решения задачи разработчики решили использовать словарь, который связывал уникальное имя и IP-адрес каждого компьютера в сети. Таким словарём стал файл hosts.txt, который и отвечал за привязку IP-адреса к имени компьютера. Файл лежал на сервере Стэнфордского исследовательского института, и пользователи сети регулярно вручную скачивали этот файл на свои компьютеры, чтобы сохранять актуальность словаря, ведь новые компьютеры появлялись в сети почти каждый день.
Выглядел hosts.txt тогда (да и сейчас) таким образом:
При наличии такого файла на компьютере пользователя для связи с компьютером Майка, можно было не запоминать цифры, а использовать понятное латинское имя «MIKE-STRATE-PC».
Посмотрим, как выглядит файл и попробуем добавить туда новое имя, чтобы подключиться к компьютеру с использованием данного имени. Для этого отредактируем файл hosts. Вы можете найти его на своём компьютере по следующему адресу:
Компьютеру с IP-адресом 192.168.10.36, который находится внутри локальной сети мы указали имя «MIKE-STRATE-PC». После чего можно воспользоваться командой ping, которая пошлёт специальный запрос на компьютер Майка и будет ждать от него ответа. Похоже на то, как вы стучитесь в дверь или звоните в звонок, чтобы узнать, «есть ли кто дома?» Такой запрос можно послать на любой компьютер.
По мере развития сети и «обрастания» её новыми клиентами, такой способ становился неудобным. Всем пользователям компьютеров было необходимо всё чаще скачивать свежую версию файла с сервера Стэнфордского исследовательского института, который обновлялся вручную несколько раз в неделю. Для добавлений же новых версий было необходимо связываться с институтом и просить их внести в файл новые значения.
В 1984 году Пол Мокапетрис (Paul Mockapetris) описал новую систему под названием DNS (Domain Name System / Система доменных имён), которая была призвана автоматизировать процессы соотнесения IP-адресов и имён компьютеров, а также процессы обновления имён у пользователей без необходимости ручного скачивания файла со стороннего сервера.
Работа DNS в сети интернет
В настоящее время интернет окружает нас повсюду — мы используем его в мобильных и настольных устройствах. Системы видеонаблюдения и даже чайники взаимодействуют друг с другом с помощью интернета, и для корректной связи с ними нужна система, с помощью которой пользователи смогут одним запросом в адресной строке подключиться к нужному сервису. Всё это ложится на плечи системы DNS, которая внутри себя хранит намного больше информации, чем просто IP-адрес и название устройств. Записи в DNS также отвечают за корректную отправку электронных писем, связывают друг с другом разные домены и доменные зоны.
DNS является распределённой системой, а значит она имеет множество узлов, каждый из которых ответственен за свою зону. Такое возможно благодаря тому, что сама по себе структура DNS является иерархической, то есть выделяет зоны ответственности, где каждый родитель знает о расположении своего дочернего сервера, и знает зону его ответственности.
Рассмотрим работу DNS и её составных частей поближе.
Терминология
Основными компонентами DNS являются:
Домен (доменное имя) — символьное имя для обозначения сервера в сети интернет. Доменные имена являются иерархической структурой, в которой каждый уровень отделяется точкой. Основными уровнями являются:
Корневой DNS-сервер — система, знающая расположение (IP-адреса) DNS-серверов доменов верхнего уровня.
Ресурсная запись — единица информации DNS-сервера. Каждая ресурсная запись имеет несколько полей:
Подключение
Необходимо понимать, что доменное имя — это всего лишь абстракция для людей. Сам компьютер и приложения (например, браузер) обращается к сервисам внутри сети интернет только по IP-адресам.
Возможны два варианта событий:
Так как домен является иерархической структурой, и все DNS-сервера знают IP-адреса корневых DNS-серверов, то к ним и происходит запрос на получение IP-адреса домена.
В соответствии со своей зоной ответственности DNS-сервер домена верхнего уровня возвращает IP-адрес DNS-сервера домена hexlet, на который посылается запрос на получение IP-адреса поддомена ru.
DNS-сервер возвращает IP-адреса поддомена ru, после чего DNS-сервер нашего провайдера возвращает полученный адрес на наш компьютер, который уже может обратиться к домену ru.hexlet.io по его IP-адресу.
Рекурсия в DNS
Можно заметить, что оба описанных выше варианта сильно различаются: в первом случае мы просто послали запрос и получили ответ, а во втором — возникла необходимость идти от самого корневого домена в процессе поиска нужной нам записи. Такой процесс является рекурсивным, потому что ближайший DNS-сервер непрерывно посылает запросы к другим DNS-серверам до тех пор, пока не получит необходимые ресурсные записи. Данный процесс можно визуализировать следующим образом:
При запросах 1 и 2 ближайший сервер будет получать информацию о местонахождении DNS-серверов, которые входят в зону ответственности того сервера, на который был послан запрос. При запросе 3 будут получены необходимые ресурсные записи домена hexlet и его поддоменов.
Рекурсивный поиск — это достаточно долгая операция, которая к тому же сильно нагружает сеть и сами DNS-сервера. Именно для того, чтобы избавиться от рекурсии каждый DNS-сервер кеширует информацию о записях, которые получает, для быстрой отдачи этой информации пользователю.
Как видно, рекурсивный поиск предполагает нахождение конечного ответа на наш запрос путём поиска записи по всем необходимым DNS-серверам, начиная с корневого. В противовес такому способу также существует итеративный запрос, который в отличие от рекурсивного выполняет всего лишь одну итерацию — это запрос ближайшему DNS-серверу, от которого мы можем получить как закешированный ответ, так и данные той зоны, за которую он ответственен. Важно отметить, что итеративный запрос предполагает всего один такой запрос.
Чаще всего в интернете DNS-сервера умеют посылать рекурсивные запросы, потому что в таком случае ответ можно закешировать, что в дальнейшем позволит снизить нагрузку как на сам сервер, так и на другие DNS-сервера. Время, на которое DNS-сервер кеширует информацию, указывается в ресурсной записи DNS, о которой сейчас пойдёт речь.
Ресурсные записи DNS
Современный интернет подразумевает не только получение IP-адреса по доменному имени, но и пересылку электронной почты, подключение дополнительных сервисов аналитики к сайту, настройку защищённого протокола HTTPS. Это чаще всего делается с помощью ресурсных записей DNS.
Рассмотрим, какие ресурсные записи используются, и на что они указывают. Основными ресурсными записями DNS являются:
A-запись — одна из самых важных записей. Именно эта запись указывает на IP-адрес сервера, который привязан к доменному имени.
MX-запись — указывает на сервер, который будет использован при отсылке доменной электронной почты.
NS-запись — указывает на DNS-сервер домена.
CNAME-запись — позволяет одному из поддоменов дублировать DNS-записи своего родителя. Делается это для того, чтобы перенаправить запрос с одного домена на другой (чаще всего для перенаправления домена с поддоменом www на домен без такого поддомена).
TXT-запись — в этой записи хранится текстовая информация о домене. Часто используется для подтверждения прав на владение доменом, посредством добавления определённой строки, которую присылает нам интернет-сервис.
Ресурсные записи почти всегда одинаковые, но для некоторых записей могут появляться другие поля, например в MX-записях также присутствует значение приоритета. В основном ресурсные записи имеют следующую структуру:
Имя записи — указывается домен, которому принадлежит данная ресурсная запись.
TTL (time to live / время жизни) — время в секундах, на которое будет закешировано значение ресурсной записи. Это необходимо для разгрузки DNS-серверов. Благодаря кешированию и возможна ситуация, что ближайший DNS-сервер знает IP-адрес запрашиваемого домена.
Класс — предполагалось, что DNS может работать не только в сети интернет, поэтому в записи указывается и её класс. На сегодняшний день поддерживается только одно значение — IN (Internet).
Тип — указывает тип ресурсной записи, основные из которых были разобраны выше.
Значение — непосредственно значение ресурсной записи. В зависимости от типа ресурсной записи значения могут быть представлены в разном виде.
Посмотрим, в каком виде эти записи хранятся на DNS-серверах на примере домена ya.ru. Для этого воспользуемся утилитой dig, которая получает все доступные ресурсные DNS-записи от DNS-сервера и выводит их пользователю.
Утилита dig является DNS-клиентом и входит в состав одного из самых распространённых DNS-серверов BIND.
Пример реальных записей DNS
Не пугайтесь такого длинного вывода. Уже сейчас можно понять почти всё, что тут указано. Разберём вывод каждой секции более детально.
Вывод состоит из нескольких частей:
Шапка запроса
Здесь указывается проставленные флаги нашего запроса, количество запросов и ответов, а также другая служебная информация.
Секция запроса
В секции запроса указывается домен, к которому происходит обращение, класс записи и те записи, которые мы хотим получить. ANY указывает на то, что нужно вывести все доступные ресурсные записи, но если вы хотите поэкспериментировать с утилитой сами, то можете с помощью специального ключа получить вывод только конкретных записей, которые интересуют в настоящий момент.
Секция ответа
Секция ответа достаточно большая, поэтому для удобства разобьём её по типам ресурсных записей.
Как запись A, так и AAAA-запись указывают на IP-адрес, который привязан к нашему домену. A-запись указывает IP в формате IPv4, а запись AAAA — в формате IPv6.
MX-запись также имеет параметр приоритета. Так как серверов для отправки почты может быть несколько, то и записей может быть много, поэтому для определения основного сервера указывается приоритет записи. Чем меньше число, тем выше приоритет.
Запись SOA (Start of Authority) указывает на несколько различных параметров:
Бывают и некоторые более специфичные ресурсные записи, о которых здесь не было речи, но это не значит, что они бесполезны. Полный перечень таких записей всегда можно найти в документации (например по DNS-серверу BIND).
Выводы
DNS-сервера сейчас составляют основу всего интернета и используются почти в каждом действии пользователя в сети, будь то переход на сайт, отправка электронной почты, работы с интернет-приложением на телефоне и так далее. Поэтому знания о принципах работы DNS-серверов и основных ресурсных записях, благодаря которым и возможно перемещение по сети интернет, являются важными для разработчика.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Введение в DNS терминологию, компоненты и концепции
Оглавление: Компьютерные сети
6. Канальный уровень передачи данных
7. Маршрутизация данных
8. Служебный протокол ICMP
10. Настройка сетевых подключений в командной строке Linux
11. Определение проблем работы сети
12. Туннелизация
Введение
DNS или Domain Name System (система доменных имён), часто является очень сложной частью обучения настройке веб-сайтов и серверов. Понимание того, как работает DNS, поможет вам диагностировать проблемы с настройкой доступа к вашим веб-сайтам и расширит ваше понимание того, что происходит за кулисами.
В данной первой части мы обсудим некоторые фундаментальные концепции DNS, которые помогут понять работу DNS и которые сделают осмысленной и облегчат настройку вашего DNS сервера. После прохождения всех частей вы получите полное представление о работе DNS, о настройке своей собственной DNS и выполнению запросов к DNS серверам.
В других частях будут рассмотрены все основные аспекты DNS: теория данной технологии, инфраструктура DNS, затем мы рассмотрим самостоятельную настройку DNS сервера и рассмотрим прикладные программы для DNS запросов.
Доменная терминология
Нам следует начать с определения терминов. Хотя некоторые из этих тем знакомы из других областей веб технологий и IT, существует много специальных терминов, используемых при разговоре о доменных именах и DNS, которые не слишком часто используются в других областях вычислительной техники.
Система доменных имён (domain name system)
Система доменных имён, более известная как «DNS», является сетевой системой, которая позволяет нам преобразовывать понятные для человека имена в уникальные адреса.
Доменное имя (Domain Name)
URL «google.com» связан с серверами, принадлежащими Google Inc. Система доменных имён позволяет нам обращаться к серверам Google, когда мы вводим «google.com» в наших браузерах.
IP адрес
IP-адрес — это то, что мы называем network addressable location, то есть сетевое расположение, к которому можно обратиться по адресу. Каждый IP-адрес должен быть уникальным в своей сети. Когда мы говорим о веб-сайтах, эта сеть представляет собой весь интернет.
Наиболее популярной формой адресов являются IPv4, которые пишутся как четыре набора чисел, каждый набор может иметь от одной до трёх цифр, наборы разделены точкой. Например «111.222.111.222» может быть правильным IPv4 адресом. С помощью DNS мы сопоставляем имя с этим адресом, чтобы вам не приходилось запоминать сложный набор чисел для каждого места, которое вы хотите посетить в сети.
Домен верхнего уровня (Top-Level Domain)
Домен верхнего уровня, или TLD, является наиболее общей частью домена. Домен верхнего уровня — это самая дальняя часть справа (отделённая точкой). Распространёнными доменами верхнего уровня являются «com», «net», «org», «gov», «edu» и «io».
Домены верхнего уровня находятся на вершине иерархии с точки зрения доменных имён. Некоторым сторонам ICANN (Internet Corporation for Assigned Names and Numbers — Интернет-корпорация по присвоению имён и номеров) предоставляет административный контроль над доменами верхнего уровня. Эти стороны могут затем распространять доменные имена в рамках TLD, обычно через регистратора доменов.
Хосты
Вы можете иметь другие установленные хосты в общем домене. Вы можете получить доступ к API через хост «api» (api.example.com) или получить доступ по ftp, определив хост с именем «ftp» или «files» (ftp.example.com или files.example.com). Имена хостов могут быть произвольными, если они уникальны для домена.
Субдомен (SubDomain)
Субдомены связаны с хостами.
DNS работает в иерархии. У доменов верхнего уровня может быть много доменов. Например, в домене «com» есть и «google.com», и «ubuntu.com». Термин «субдомен» относится к любому домену, который является частью более крупного домена. В этом случае «ubuntu.com» можно назвать поддоменом «com». Обычно это называется доменом, или часть «Ubuntu» называется SLD, что означает домен второго уровня (second level domain).
Аналогично, каждый домен может управлять субдоменами следующих уровней (третьего, четвёртого и т.д.), которые находятся под ним. Именно это мы подразумеваем под поддоменами. Например, у вас может быть поддомен для исторического факультета вашей школы по адресу «www.history.school.edu». Часть «history» является поддоменом.
Разница между именем хоста и поддоменом заключается в том, что хост определяет компьютер или ресурс, в то время как поддомен расширяет родительский домен. Это метод разделения самого домена.
Говоря о поддоменах или хостах, вы можете начать видеть, что самые левые части домена являются наиболее специфичными. Также работает и DNS: если смотреть слева направо, то от наиболее конкретного к наименее конкретному.
Полностью определённое имя домена (Fully Qualified Domain Name)
Это означает, что он указывает каждый родительский домен, включая TLD. Правильное полное доменное имя заканчивается точкой, обозначающей корень иерархии DNS. Примером полного доменного имени является «mail.google.com.». Иногда программное обеспечение, которое запрашивает полное доменное имя, не требует конечной точки, но конечная точка должна соответствовать стандартам ICANN.
Сервер имён (Name Server)
Сервер имён — это компьютер, предназначенный для перевода доменных имён в IP-адреса. Эти серверы выполняют большую часть работы в системе DNS. Поскольку общее количество переводов доменов слишком велико для какого-либо одного сервера, каждый сервер может перенаправить запрос на другие серверы имён или делегировать ответственность за подмножество поддоменов, за которые они отвечают.
Серверы имён могут быть «авторитативными» (authoritative), что означает, что они дают ответы на запросы о доменах, находящихся под их контролем. В противном случае они могут указывать на другие серверы или обслуживать кэшированные копии данных других серверов имён.
Файл зоны (Zone File)
Файл зоны — это простой текстовый файл, который содержит сопоставления между доменными именами и IP-адресами. В конечном счёте именно так система DNS выясняет, какой IP-адрес следует вернуть в ответе, когда пользователь запрашивает определённое доменное имя.
Файлы зон находятся на серверах имён и, как правило, определяют ресурсы, доступные в определённом домене, или место, где можно получить эту информацию.
Записи (Records)
Внутри файла зоны хранятся записи. В своей простейшей форме запись это, по сути, одно сопоставление между ресурсом и именем. Они могут сопоставить доменное имя с IP-адресом, определить серверы имён для домена, определить почтовые серверы для домена и т. д.
Как работает DNS
Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, пришло время ответить на вопрос: как на самом деле работает DNS система?
Система очень проста в обзоре высокого уровня, но очень сложна, когда вы смотрите на детали. В целом, это очень надёжная инфраструктура, которая была необходима для принятия Интернета, каким мы его знаем сегодня.
Корневые серверы (Root Servers)
Как мы уже говорили выше, DNS по своей сути является иерархической системой. В верхней части этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и делегируемыми полномочиями от ICANN (Интернет-корпорация по присвоению имён и номеров).
В настоящее время работают 13 корневых серверов. Тем не менее поскольку существует невероятное количество имён, о которых ежеминутно приходят запросы, каждый из этих серверов фактически имеет зеркала. Интересной особенностью этой настройки является то, что каждое из зеркал для одного корневого сервера имеет один и тот же IP-адрес. Когда запросы сделаны для определённого корневого сервера, запрос будет направлен к ближайшему зеркалу этого корневого сервера.
Что делают эти корневые серверы? Корневые серверы обрабатывают запросы информации о доменах верхнего уровня. Поэтому, если поступает запрос о чём-то, что сервер имён более низкого уровня не может обработать, выполняется запрос к корневому серверу этого домена.
Корневые серверы на самом деле не знают, где находится домен. Тем не менее они смогут направить запрашивающего на серверы имён, которые обрабатывают запрошенный в данном случае домен верхнего уровня.
Таким образом, если запрос к «www.suip.biz» будет отправлен на корневой сервер, корневой сервер не найдёт результат в своих записях. Он проверит файлы своей зоны на наличие списка, который соответствует «www.suip.biz», но не найдёт ни одного.
Вместо этого он найдёт запись для TLD «biz» и даст запрашивающей организации адрес сервера имён, ответственного за адреса «biz».
TLD-серверы
Затем запрашивающая сторона отправляет новый запрос на IP-адрес (предоставленный ему корневым сервером) TLD-сервера, который отвечает за домен верхнего уровня для данного запроса.
Итак, чтобы продолжить наш пример, он отправил бы запрос серверу имён, ответственному за хранение информации о «biz», чтобы узнать, не известно ли ему, где находится «www.suip.biz».
DNS сервер TLD также будет искать «www.suip.biz» в своих файлах зоны, но не найдёт эту запись в своих файлах.
Тем не менее он найдёт запись с указанием IP-адреса сервера имён, ответственного за «suip.biz». В этом момент мы становится намного ближе к ответу, который нам нужен.
Серверы имён на уровне домена
На этом этапе запрашивающая сторона имеет IP-адрес сервера имён, который отвечает за знание фактического IP-адреса ресурса. Он отправляет новый запрос на сервер имён, снова спрашивая, может ли он разрешить (преобразовать в IP) «www.suip.biz».
Сервер имен проверяет свои файлы зон и обнаруживает, что у него есть файл зоны, связанный с «suip.biz». Внутри этого файла есть запись для хоста «www». Эта запись сообщает IP-адрес, где находится этот хост. Сервер имён возвращает окончательный ответ запрашивающей стороне.
Иллюстрация вышеописанной цепочки DNS запросов
Проиллюстрируем вышесказанное реальными запросами к DNS серверам.
Первой командой мы отправляем запрос корневому серверу d.root-servers.net об A записи доменного имени suip.biz
Сервер ничего не прислал о самом доменном имени www.suip.biz, но в разделе AUTHORITY SECTION перечислены DNS сервера, которые должны знать о доменной зоне biz (доменах верхнего уровня biz):
В дополнительном разделе присланы A записи о перечисленных выше DNS серверах:
Вновь мы не получили A запись для домена suip.biz, но раздел AUTHORITY SECTION содержит имена сервером имён ns1.marosnet.ru и ns2.marosnet.ru, которые указаны как сервера имён для домена suip.biz, то есть они должны уже знать IP этого сайта:
Обращаемся с DNS запросом к любому из присланных нам серверов имён:
И только теперь мы действительно получили A запись с IP интересующего сайта:
Что такое разрешающий сервер имён (Resolving Name Server)?
В приведённом выше сценарии мы употребили слово «запрашивающий/запросчик». Что является «запросчиком» в этой ситуации?
Почти во всех случаях запросчиком будет то, что мы называем «разрешающим сервером имён». Разрешающим сервером имён является тот, который настроен для того, чтобы задавать вопросы другим серверам. Это в основном посредник для пользователя, который кэширует результаты предыдущих запросов для повышения скорости и знает адреса корневых серверов, чтобы иметь возможность «разрешать» (резолвить) запросы, сделанные для имён, о которых он ещё не знает.
Как правило, у пользователя обычно есть несколько разрешающих серверов имён, настроенных в его компьютерной системе. Разрешающие серверы имён обычно предоставляются Интернет-провайдером или другими организациями. Например, Google предоставляет разрешающие DNS-серверы, к которым вы можете отправлять DNS запросы. Они могут быть настроены на вашем компьютере автоматически или вручную.
Когда вы вводите URL-адрес в адресной строке вашего браузера, ваш компьютер сначала проверяет, может ли он определить локально, где находится ресурс. Он проверяет файл «hosts» на компьютере и в нескольких других местах. Затем он отправляет запрос на разрешающий сервер имён и ожидает получения IP-адреса ресурса.
Затем разрешающий сервер имён проверяет свой кеш для ответа. Если он не находит его, он проходит шаги, описанные выше.
Разрешающие серверы имён в основном сжимают запрашивающий процесс для конечного пользователя. Клиенту просто достаточно обратиться с запросом к разрешающим серверам имён: где находится ресурс? И клиент может быть уверен, что они сделают необходимые запросы и изучат нужный маршрут, а затем вернут окончательный ответ.
Зональные файлы (Zone Files)
В упомянутом выше процессе мы упомянули идею «файлов зон» (zone files) и «записей» (records).
Если он сконфигурирован для обработки рекурсивных запросов, как разрешающий сервер имён, он найдёт ответ и вернёт его. В противном случае он сообщит запрашивающей стороне, где искать дальше.
Чем больше файлов зон будет у сервера имён, тем на большее число запросов он сможет авторитативно ответить.
Файл зоны описывает DNS «зону», которая в основном является подмножеством всей системы именования DNS. Обычно он используется для настройки только одного домена. Он может содержать ряд записей, которые определяют, где находятся ресурсы для рассматриваемого домена.
$ORIGIN зоны — это параметр, равный максимальному уровню полномочий (authority) зоны по умолчанию, который выражается как домен определённого уровня. То есть если для настройки домена «example.com» используется файл зоны, то $ORIGIN будет установлен на example.com..
Это либо настраивается в верхней части файла зоны, либо его можно задать в файле конфигурации DNS-сервера, который ссылается на файл зоны. В любом случае, этот параметр описывает, для какого уровня зона будет авторитативной.
Аналогично, $TTL настраивает «время жизни» предоставляемой информации. В принципе это таймер. Сервер имён кэширования может использовать ранее запрошенные результаты для ответа на вопросы, пока не истечёт значение TTL.
Типы DNS записей
В файле зоны у нас может быть много разных типов записей. Мы рассмотрим здесь некоторые из наиболее распространённых (или обязательных типов).
Запись SOA
Запись Start of Authority (начало полномочий) или SOA, является обязательной записью во всех файлах зоны. Это должна быть первая реальная запись в файле (хотя спецификации $ORIGIN или $TTL могут отображаться выше). Она является также одной из самых сложных для понимания.
Начало SOA записи выглядит примерно так:
Давайте объясним, для чего каждая часть:
A и AAAA записи
Обе эти записи связывают хост и IP-адрес. Запись «A» используется для сопоставления хоста с IP-адресом IPv4, а записи «AAAA» используются для сопоставления хоста с адресом IPv6.
Общий формат этих записей таков:
Так как наша SOA-запись вызывает основной главный сервер по адресу «ns1.domain.com», нам нужно также сопоставить его с IP-адресом, поскольку «ns1.domain.com» находится в зоне «domain.com», которая этот файл определяет.
Запись может выглядеть примерно так:
Обратите внимание, что нам не нужно давать полное имя. Мы можем просто указать хост без полного доменного имени, а DNS-сервер заполнит остальное значением $ORIGIN. Тем не менее мы могли бы так же легко использовать полное доменное имя, если захотим быть семантическими:
В большинстве случаев именно здесь вы определяете свой веб-сервер как «www»:
Мы также должны указать, где разрешается базовый домен. Мы можем сделать это так:
Мы могли бы использовать «@» для ссылки на базовый домен:
Также у нас есть возможность использовать подстановочный символ «*», чтобы резолвить всё, что находится под управлением этого домена и что не задано явно:
Все это работает так же с записями AAAA для адресов IPv6.
Записи MX
Записи MX применяются для определения почтовых обменов, которые используются для этого домена. Это помогает правильно доставлять сообщения электронной почты на ваш почтовый сервер.
В отличие от многих других типов записей, почтовые записи обычно не сопоставляют хост с чем-либо, потому что они применяются ко всей зоне. Таким образом, они обычно выглядят так:
Обратите внимание, что в начале нет имени хоста.
Также обратите внимание, что там есть дополнительный номер. Это номер предпочтения, который помогает компьютерам решить, на какой сервер отправлять почту, если определено несколько почтовых серверов. Меньшие числа имеют более высокий приоритет.
Запись MX, как правило, должна указывать на хост, определённый с помощью записи A или AAAA, а не на хост, определённый в CNAME.
Итак, допустим, у нас есть два почтовых сервера, тогда должны быть записи, которые выглядят примерно так:
В этом примере хост «mail1» является предпочтительным сервером обмена электронной почтой.
Мы могли бы также написать это так:
Записи NS
Этот тип записи определяет серверы имён (name servers, NS), которые используются для этой зоны.
Как и записи MX, это параметры всей зоны, поэтому они также не принимают хосты. В общем, они выглядят так:
Для правильной работы у вас должно быть как минимум два сервера имён, определённых в каждом файле зоны — это нужно на тот случай, если с одним из серверов возникнет проблема. Большинство программного обеспечения DNS-серверов считает файл зоны недействительным, если существует только один сервер имён.
Как всегда, включите сопоставление для хостов записями A или AAAA:
Записи PTR
Вот пример записи PTR для 111.222.33.4:
В этом примере записи PTR для адреса IPv6 показан формат отрывка обратного IPv6 DNS-сервера Google 2001:4860:4860::8888.
Инструмент командной строки dig с флагом -x можно использовать для поиска обратного DNS-имени IP-адреса. Вот пример команды dig. Опция +short добавлена для сокращения вывода, который будет ограничен обратным DNS-именем.
Выходными данными для приведённой выше команды dig будет имя домена в записи PTR для IP-адреса:
Серверы в Интернете используют записи PTR, чтобы размещать доменные имена в логах, принимать обоснованные решения по обработке спама и отображать легко читаемые сведения о других устройствах.
Наиболее часто используемые почтовые серверы будут искать PTR-запись IP-адреса, с которого получена электронная почта. Если с исходным IP-адресом не связана запись PTR, отправляемые электронные письма могут рассматриваться как спам и отклоняться. Не важно, что полное доменное имя в PTR совпадает с именем домена отправляемого электронного письма. Важно то, что существует действительная запись PTR с соответствующей и совпадающей прямой записью A.
Обычно сетевые маршрутизаторы в Интернете получают записи PTR, которые соответствуют их физическому местоположению. Например, вы можете увидеть ссылки на «NYC» или «CHI» для маршрутизатора в Нью-Йорке или Чикаго. Это полезно при запуске traceroute или mtr при анализе пути интернет-трафика.
Большинство провайдеров, предлагающих выделенные серверы или службы VPS, дают клиентам возможность установить запись PTR для своего IP-адреса.
Примечание. Важно, чтобы полное доменное имя в записи PTR имело соответствующую и совпадающую прямую запись A. Пример: 111.222.333.444 имеет PTR server.example.com, а server.example.com является записью A, указывающей на 111.222.333.444.
Существует довольно много других типов записей, которые вы можете использовать, но приведённые выше, вероятно, являются наиболее распространёнными типами, с которыми вы столкнётесь. Рассмотрим ещё несколько типов DNS записей, которые менее распространены, но всё равно являются интересными.
Записи CAA
Записи CAA используются для указания, каким центрам сертификации (CA) разрешено выдавать сертификаты SSL/TLS для вашего домена. По состоянию на 8 сентября 2017 года все центры сертификации должны проверить эти записи перед выдачей сертификата. Если запись отсутствует, любой центр сертификации может выдать сертификат. В противном случае только указанные центры сертификации могут выдавать сертификаты. Записи CAA могут применяться к отдельным хостам или целым доменам.
Ниже приведён пример записи CAA:
Хост, IN и тип записи (CAA) являются общими полями DNS. Приведённая выше специфическая информация о CAA — это часть 0 issue «letsencrypt.org». Она состоит из трёх частей: флаги (0), теги (issue) и значения («letsencrypt.org»).
Вы можете использовать dig для получения записей CAA, используя следующие параметры:
Записи TXT
Запись TXT (сокращение от текстовой записи) — это тип записи ресурса в Системе доменных имен (DNS), используемый для предоставления возможности связать произвольный текст с хостом или другим именем, таким как читаемая человеком информация о сервере, сети, центр обработки данных или другая учётная информация.
Он также часто используется более структурированным образом для записи небольших объёмов машиночитаемых данных в DNS.
Домен может иметь несколько записей TXT, связанных с ним, при условии, что реализация DNS-сервера поддерживает это. Каждая запись, в свою очередь, может иметь одну или несколько строк символов. Традиционно эти текстовые поля использовались для различных нестандартных применений, таких как полное название компании или организации или адрес хоста.
В 1993 RFC 1464 предложил простой подход к хранению атрибутов и их значений в этих текстовых полях. Этот тип записей сейчас широко используется в:
В качестве неструктурированного текста организации могут использовать строку TXT любым способом, который они определяют, например:
RFC 1464 определяет структурированный формат, который можно использовать для определения атрибутов и их значений в одной записи, как в следующих примерах:
На практике сервисы, использующие записи TXT, часто не следуют этому RFC, а вместо этого имеют свой собственный специфический формат.
Пример использования для DMARC:
Использовать для проверки сайта:
Пример Amazon’s Simple Email Service:
Записи SRV
Запись SRV имеет вид:
Пример записи SRV в текстовой форме, которая может быть найдена в файле зоны:
Это указывает на сервер с именем sipserver.example.com, прослушивающий TCP-порт 5060 для служб протокола SIP. Приоритет здесь равен 0, а вес равен 5.
Как и в MX-записях, хост в SRV-записи должен указывать на адрес (A- или AAAA-запись). Hostname-псевдоним (CNAME-запись) не может быть использован как допустимый параметр.
Записи CNAME
Запись канонического имени (Canonical Name, сокращенно CNAME) — это тип записи ресурса в системе доменных имён (DNS), которая отсылает одно доменное имя (псевдоним) на другое (каноническое имя). Записи CNAME определяют псевдоним канонического имени для вашего сервера (определённый с помощью записи A или AAAA).
Например, мы могли бы иметь запись имени A, определяющую хост «server1», а затем использовать «www» в качестве псевдонима для этого хоста:
Имейте в виду, что эти псевдонимы приводят к некоторым потерям производительности, поскольку они требуют дополнительного запроса к серверу. В большинстве случаев тот же результат может быть достигнут при использовании дополнительных записей A или AAAA.
Одним из случаев, когда рекомендуется CNAME, является предоставление псевдонима для ресурса за пределами текущей зоны.
Это может оказаться удобным при запуске нескольких служб (например, FTP-сервер и веб-сервер, каждый из которых работает на разных портах) с одного IP-адреса. Можно, например, указать ftp.example.com и www.example.com на запись DNS для example.com, которая в свою очередь имеет запись A, которая указывает на IP-адрес. Затем, если IP-адрес когда-либо изменится, нужно только записать изменение в одном месте в сети: в записи DNS A для example.com.
Записи CNAME всегда должны указывать на другое доменное имя, а не на IP-адрес.
Записи CNAME обрабатываются специально в системе доменных имён и имеют несколько ограничений на их использование. Когда резолвер (распознаватель) DNS обнаруживает запись CNAME при поиске обычной записи ресурса, он отправляет новый запрос, используя каноническое имя вместо исходного имени. (Если определителю специально предписано искать записи CNAME, вместо перезапуска запроса возвращается каноническое имя (правая сторона).) Каноническое имя, на которое указывает запись CNAME, может находиться в любом месте DNS, независимо от того, является ли оно локальным или на удалённом сервере в другой зоне DNS.
Например, если есть следующая зона DNS:
когда выполняется поиск записи A для bar.example.com, распознаватель увидит запись CNAME и перезапустит проверку на foo.example.com, а затем вернет 192.0.2.23.
Записи DNAME
Запись DNAME или Delegation Name (запись имени делегирования). Запись DNAME создает псевдоним для всего поддерева дерева доменных имён. В отличие от этого, запись CNAME создаёт псевдоним для одного имени, а не его поддоменов. Как и запись CNAME, поиск DNS будет продолжен путём повторной попытки поиска с новым именем. Сервер имён синтезирует запись CNAME, чтобы фактически применить запись DNAME к запрошенному имени — CNAME для каждого узла в поддереве имеют тот же эффект, что и DNAME для всего поддерева.
Например, если есть следующая зона DNS:
Поиск записи A для foo.example.com не вернёт никаких данных, поскольку DNAME не является CNAME и нет записи A непосредственно в foo.
Однако поиск для xyzzy.foo.example.com будет сопоставлен DNAME и вернёт запись A для xyzzy.bar.example.com, то есть 192.0.2.24; если запись DNAME была бы записью CNAME, этот запрос вернул бы имя не найдено.
Наконец, запрос для foobar.foo.example.com будет сопоставлен DNAME и вернёт 192.0.2.25.
Записи DS
Запись, используемая для идентификации ключа подписи DNSSEC делегированной зоны.
RRSIG
Подпись для набора записей, защищённого DNSSEC. Использует тот же формат, что и запись SIG.
Часть DNSSEC — используется для доказательства того, что имя не существует. Использует тот же формат, что и (устаревшая) запись NXT.
Заключение
Теперь вы должны хорошо понимать, как работает DNS. Хотя общую идею относительно легко понять, при настройке DNS сервера всё ещё могут возникнуть трудности, поэтому мы продолжим знакомство в DNS в последующих статьях, которые также рекомендуются для ознакомления.
Продолжение и дополнительный материал
Для продолжения знакомства с DNS рекомендуются следующие статьи:
[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]
Источники
Данный раздел написан/переведён преимущественно на основе: