Что является именем сервера
Имена сервера
Имена сервера задаются с помощью директивы server_name и определяют, в каком блоке server будет обрабатываться тот или иной запрос. См. также “Как nginx обрабатывает запросы”. Имена могут быть заданы точно, с помощью маски или регулярного выражения:
При поиске виртуального сервера по имени, если имени соответствует несколько из указанных вариантов, например, одновременно подходят и имя с маской, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета:
Имена с масками
Имя с маской может содержать звёздочку (“ * ”) только в начале или в конце имени, и только на границе, определяемой точкой. Имена “ www.*.example.org ” и “ w*.example.org ” являются некорректными, но их можно задать с помощью регулярных выражений, например, “
Имена, заданные регулярными выражениями
Регулярные выражения, используемые в nginx, совместимы с используемыми в языке программирования Perl (PCRE). Имя сервера, заданное регулярным выражением, должно начинаться с символа тильды:
иначе nginx откажется запускаться и выдаст сообщение об ошибке:
К именованному выделению в регулярном выражении можно впоследствии обратиться через переменную:
Библиотека PCRE поддерживает именованные выделения, используя следующий синтаксис:
? name > Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0 ?’ name ‘ Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0 ?P name > Python-совместимый синтаксис, поддерживается начиная с PCRE-4.0
Однако такое использование должно ограничиваться простыми случаями как в примере выше, поскольку нумерованные выделения легко могут быть перезаписаны.
Прочие имена
Некоторые имена имеют специальное значение.
Если необходимо обрабатывать запросы без поля “Host” в заголовке в блоке server, который не является сервером по умолчанию, следует указать пустое имя:
Если директива server_name не задана в блоке server, то nginx будет использовать пустое имя в качестве имени сервера.
Версии nginx вплоть до 0.8.48 в этом случае использовали имя хоста (hostname) машины в качестве имени сервера.
Если в запросе вместо имени сервера указан IP-адрес, то поле “Host” заголовка запроса будет содержать IP-адрес, и запрос можно обработать, используя IP-адрес как имя сервера:
В примерах конфигурации серверов, обрабатывающих все запросы, встречается странное имя “ _ ”:
Версии nginx вплоть до 0.6.25 поддерживали специальное имя “ * ”, которое многими неверно воспринималось как имя сервера для обработки всех запросов. Оно никогда так не работало, и не работало как имя с маской. Это имя действовало так же, как сейчас действует директива server_name_in_redirect. Специальное имя “ * ” объявлено устаревшим, а вместо него следует использовать директиву server_name_in_redirect. Заметьте, что с помощью директивы server_name нельзя задать ни имя сервера для обработки всех запросов, ни сервер по умолчанию. Это является свойством директивы listen, а не server_name. См. также “Как nginx обрабатывает запросы”. Можно настроить серверы, слушающие на портах *:80 и *:8080, и указать, что один из них будет сервером по умолчанию для порта *:8080, а другой — для порта *:80:
Интернационализованные имена
Для указания интернационализированных доменных имён (IDNs) в директиве server_name следует указывать Punycode-представление имени:
Выбор виртуального сервера
Сначала соединение создаётся в контесте сервера по умолчанию. Затем имя сервера может быть определено на следующих стадиях обработки запроса, каждая из которых участвует в выборе конфигурации:
предварительно во время операции SSL handshake согласно SNI
после обработки строки запроса
после обработки поля Host заголовка запроса
если после обработки строки запроса или поля Host заголовка запроса имя сервера не было выбрано, то nginx будет использовать пустое имя в качестве имени сервера.
На каждой из этих стадий могут применяться различные конфигурации сервера. Таким образом, некоторые директивы следует указывать с осторожностью:
Оптимизация
Точные имена, имена с масками, начинающиеся со звёздочки, и имена с масками, заканчивающиеся на звёздочку, хранятся в трёх хэш-таблицах, привязанных к слушающим портам. Размеры хэш-таблиц оптимизируются на фазе конфигурации таким образом, что имя может быть найдено с минимальным числом непопаданий в кэш процессора. Подробнее настройка хэш-таблиц обсуждается в отдельном документе.
В первую очередь имя ищется в хэш-таблице точных имён. Если имя не было найдено, то имя ищется в хэш-таблице имён с масками, начинающихся со звёздочки. Если и там поиск не дал результата, то имя ищется в хэш-таблице имён с масками, оканчивающихся на звёздочку.
Регулярные выражения проверяются последовательно, а значит являются самым медленным и плохо масштабируемым методом.
нежели чем использовать упрощённую форму:
Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив server_names_hash_max_size и server_names_hash_bucket_size на уровне http. Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора. Если значение по умолчанию равно 32 и имя сервера задано как “ too.long.server.name.example.org ”, то nginx откажется запускаться и выдаст сообщение об ошибке:
В этом случае следует увеличить значение директивы до следующей степени двойки:
Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:
В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.
Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта). За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.
Введение в терминологию, элементы и понятия DNS
Введение
DNS, или система доменных имен, зачастую очень трудная часть изучения настройки веб-сайтов и серверов. Понимание того, как работает DNS, поможет вам диагностировать проблемы с настройкой доступа к вашим веб-сайтам и позволит расширить понимание того, что происходит за кадром.
В этом руководстве мы обсудим некоторые фундаментальные понятия системы доменных имен, которые помогут вам разобраться с настройкой вашей DNS. После знакомства с этим руководством вы научитесь настраивать собственное доменное имя или свой собственный DNS-сервер.
Прежде чем мы приступим к настройке серверов для преобразования вашего домена или настройке наших доменов в панели управления, давайте познакомимся с некоторыми основными понятиями о работе DNS.
Терминология доменов
Мы должны начать с определения терминов. Хотя некоторые из этих тем могут быть вам знакомы из других сфер, есть много других терминов, используемых в разговоре о доменных именах и DNS, которые не слишком часто используются в других компьютерных областях. Давайте начнем с простого:
Система доменных имен
Система доменных имен, более известная как «DNS», является сетевой системой, которая позволяет нам преобразовать удобные для человека имена (обычно буквенные) в уникальные адреса.
Доменное имя
Доменное имя это удобная для человека форма имени, которую мы привыкли ассоциировать с интернет-ресурсом. Например, «google.com» является доменным именем. Некоторые скажут, что часть «Google» является доменом, но в целом мы можем считать эту комбинированную форму доменным именем.
URL-адрес «google.com» соединен с сервером, находящимся в собственности Google Inc. Система доменных имен позволяет нам соединиться с сервером Google при вводе «google.com» в браузере.
IP-адрес
IP-адресом мы называем сетевой адрес узла. Каждый IP-адрес должен быть уникальным в пределах своей сети. Когда мы говорим о веб-сайтах, этой сетью является весь интернет.
IPv4, наиболее распространенная форма адресов, записывается в виде четырех наборов цифр, каждый набор содержит до трех цифр, разделенных точкой. Например, «111.222.111.222» может считаться правильным IPv4 IP-адресом. С помощью DNS мы соединяем имя с этим адресом и избавляем себя от необходимости запоминать сложный набор цифр для каждого места посещения в сети.
Домен верхнего уровня
Домен верхнего уровня, или TLD, это самая общая часть домена. Является последней частью доменного имени справа (отделен точкой). Распространенными доменами верхнего уровня считаются «com», «net», «org», «gov», «edu» и «io».
Домены верхнего уровня находятся на вершине иерархии доменных имен. Некоторым компаниям предоставлен контроль над управлением доменами верхнего уровня структурой ICANN (Корпорация по управлению доменными именами и IP-адресами). Эти компании также могут распространять доменные имена под TLD, как правило, через доменного регистратора, который занимается регистрацией домена.
Узел
В пределах домена его владелец может определять собственные узлы, которые ссылаются на отдельные компьютеры или услуги, доступные через домен. Например, большинство владельцев доменов делают свой веб-сервер доступным через корневой домен (example.com), а также через «узел», определенный как «www» (www.example.com).
У вас могут быть другие определения узлов под общим доменом. Вы можете иметь API доступ через «api» узел (api.example.com) или FTP доступ, обозначив узел «FTP» или «files» (ftp.example.com или files.example.com). Имена узлов могут быть произвольными, при условии, что они являются уникальными для данного домена.
Поддомен
Объект, связанный с узлами, называется поддомен.
DNS работает в иерархии. Домены верхнего уровня могут иметь множество доменов под ними. Например, домен верхнего уровня «com» включает в себя «google.com» и «ubuntu.com». Поддомен это домен, который является частью домена более высокого уровня. В этом случае можно сказать, что «ubuntu.com» явлется поддоменом «com». Как правило, он называется просто доменом или часть «Ubuntu» называется SLD, что означает домен второго уровня.
Точно так же каждый домен может контролировать «поддомены», которые находятся под ним. Например, у вас мог бы быть поддомен для отдела истории в вашей школе по адресу «www.history.school.edu». В этом случае часть «history» считается поддоменом.
Разница между именем узла и поддомена в том, что узел указывает на компьютер или ресурс, в то время как поддомен расширяет родительский домен.
Читая о поддоменах или узлах, вы можете заметить, что самый левые части доменов наиболее конкретные. Это объясняет работу DNS: от наиболее конкретного к наименее конкретному, так как вы читаете слева направо.
Полностью определенное имя домена
Полностью определенное имя домена часто называют FQDN, или полное имя домена. Домены в системе DNS могут быть определены по отношению друг к другу и, по существу, неоднозначны. FQDN является полным именем, которое указывает его место в отношении к абсолютному корню системы доменных имен.
Это означает, что он указывает на каждый родительский домен, включая TLD. Правильный FQDN заканчивается точкой, указывая на корень иерархии DNS. Примером FQDN является «mail.google.com.». Иногда программное обеспечение, которое запрашивает FQDN, не нуждается в точке на конце, но завершающая точка требуется для соответствия стандартам ICANN.
DNS-сервер
DNS-сервер это компьютер, предназначенный для перевода доменных имен в IP-адреса. Эти серверы проделывают основную часть работы в системе доменных имен. Так как общее число доменных переводов слишком велико для любого сервера, каждый сервер может перенаправить запрос на другие DNS-сервера или делегировать ответственность за подмножество поддоменов, которое находится под их ответственностью.
DNS-сервера могут быть «авторитетными», что означает, что они предоставляют ответы на запросы о доменах под своим контролем. В противном случае они могут указать на другие серверы или предоставить кэшированные копии данных других DNS-cерверов.
Файл зоны
Файл зоны представляет собой простой текстовый файл, который содержит соединение между доменными именами и IP-адресами. С помощью него DNS выясняет, с каким IP-адресом необходимо связаться, когда пользователь запрашивает определенное доменное имя.
Файлы зоны находятся на DNS-серверах и в общем определяют ресурсы, доступные под конкретным доменом, или место, в котором можно запросить данную информацию.
Ресурсные записи
Записи хранятся в пределах файла зоны. В своей простейшей форме запись это простое соединение между ресурсом и именем. Эти записи могут соединять имя домена с IP-адресом, определять DNS-серверы и почтовые серверы для домена и т.д.
Как работает DNS
Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, возникает вопрос, как действительно работает система?
Система очень проста, если смотреть в общем, но очень сложна, если вы углубитесь в детали. В целом, это очень надежная инфраструктура, которая была необходима для адаптации интернета таким, каким мы знаем его сегодня.
Корневые серверы DNS
Как уже говорилось выше, DNS, по сути, является иерархической системой. В верхней части этой системы находится то, что мы называем корневым сервером DNS. Эти серверы находятся под контролем различных организаций, действующих по согласию с ICANN (Корпорация по управлению доменными именами и IP-адресами).
В настоящее время 13 корневых серверов находятся в эксплуатации. Тем не менее, так как каждую минуту появляется немыслимое количество имен для преобразования, каждый из этих серверов имеет зеркало. Интересно, что все зеркала для одного корневого сервера делят один IP-адрес. Когда выполняется запрос к определенному серверу, он будет перенаправлен к ближайшему зеркалу этого корневого сервера.
Что делают эти корневые серверы? Они обрабатывают запросы на информацию о доменах верхнего уровня. Поэтому если приходит запрос о чем-то, что DNS-сервер не может преобразовать, то запрос перенаправляется в корневой DNS-сервер.
Корневые серверы на самом деле не обладают информацией о том, где размещен домен. Они, однако, в состоянии направить запрашивающего к DNS-серверу, который обрабатывает нужный домен верхнего уровня.
Таким образом, если запрос «www.wikipedia.org» производится в корневой сервер, то он ответит, что не может найти результат в своих записях. Он проверит свои файлы зоны на наличие соответствий «www.wikipedia.org». И также не найдет их.
Вместо этого он найдет запись для домена верхнего уровня «org» и предоставит запрашивающему адрес DNS-сервера, отвечающего за адреса «org».
TLD Серверы
После этого запрашивающий отправит новый запрос на IP-адрес (предоставленный ему корневым сервером), который отвечает за необходимый домен верхнего уровня.
Продолжая наш пример, запрос был бы отправлен на DNS-сервер, отвечающий за информацию о домене «org», чтобы проверить, есть ли у него информация о том, где находится «www.wikipedia.org».
Опять же запрашивающий будет искать «www.wikipedia.org” в своих файлах зоны. И не найдет эту запись в своих файлах
Тем не менее он найдет запись с упоминанием IP-адреса DNS-сервера, ответственного за «wikipedia.org». И это приближает нас гораздо ближе к результату.
DNS-сервер на уровне домена
На этом этапе у запрашивающего есть IP-адрес DNS-сервера, который хранит информацию о фактическом IP-адресе ресурса. Он отправляет новый запрос на DNS-сервер с уточнением, может ли он предоставить «www.wikipedia.org».
DNS-сервер проверяет свои файлы зоны и обнаруживает, что у него есть файл зоны, соотносящийся с «wikipedia.org». Внутри этого файла находится запись для «WWW» узла. Эта запись указывает IP-адресу, где находится этот узел. DNS-сервер возвращает окончательный ответ на запрос.
Что такое публичный DNS-сервер?
В приведенном выше сценарии мы ссылались на «запрашивающего”. Что же это может значить?
Почти во всех случаях запрашивающим будет являться то, что мы называем «публичный DNS-сервер». Этот сервер настроен на отправку запросов другим серверам. По сути, это посредник для пользователя, который кэширует предыдущие результаты запроса для повышения скорости и знает адреса корневых серверов, способных преобразовать запросы, сделанные для данных, информацией о которых он уже не владеет.
Как правило, пользователь будет иметь несколько публичных DNS-серверов, настроенных на их компьютерной системе. Публичные DNS-серверы обычно предоставляются ISP или другими организациями. Например, Google предоставляет публичные DNS-сервера, которые вы можете запросить. Они могут быть настроены на вашем компьютере автоматически или вручную.
При вводе URL в адресной строке браузера ваш компьютер прежде всего проверяет, может ли он найти, где находится ресурс, на локальном уровне. Он проверяет «узлы» файлов на компьютере и других местах. Затем он отправляет запрос на публичный DNS-сервер и ожидает получить обратно IP-адрес ресурса.
Затем публичный DNS-сервер проверяет свой кэш на наличие ответа. Если он не найдет то, что необходимо, он проделает шаги, указанные выше.
Публичные DNS-серверы по сути сжимают процесс отправки запроса для конечного пользователя. Клиенты просто должны не забывать спрашивать публичный DNS-сервер, где находится ресурс, и быть уверенными, что они найдут окончательный ответ.
Файлы зоны
Мы уже упоминали в перечисленных выше процессах «файлы зоны» и «записи».
Файлы зоны это способ, с помощью которого DNS-сервер хранит информацию о доменах, которые он знает. Каждый домен, информация о котором есть у DNS-сервера, хранится в файле зоны. Если DNS-сервер настроен для работы c рекурсивные запросами, как публичный DNS-сервер, он найдет ответ и предоставит его. В противном случае он укажет пользователю, где искать дальше. Чем больше у сервера файлов зоны, тем больше ответов на запросы он сможет предоставить.
Файл зоны описывает DNS «зону», которая, по существу, является подмножеством всей системы DNS. Как правило, она используется для настройки только одного домена. Она может содержать некоторое количество записей, которые указывают, где находятся ресурсы для запрашиваемого домена.
Это настраивается на верхнем уровне файла зоны или может быть указано в настройках файла DNS-сервера, который ссылается на файл зоны. В любом случае этот параметр описывает то, за что зона будет ответственна.
Типы записи
В файле зоны может быть множество различных типов записей. Мы рассмотрим некоторые из наиболее распространенных видов (или обязательных) ниже.
Записи SOA
Начальная запись зоны выглядит примерно так:
Поясним, что означает каждая часть:
А и AAAA записи
Обе эти записи соединяют узел с IP-адресом. «А» запись используется для соединения узла с IPv4 IP-адреса, в то время как запись “AAAA» используется для соединения хоста для адреса IPv6.
Общий формат этих записей выглядит следующим образом:
host IN IPv4_address
host IN AAAA IPv6_address
Таким образом, если SOA запись обращается к основному мастер серверу в «ns1.domain.com», мы должны соединить этот адрес с IP-адресом, так как «ns1.domain.com» находится в зоне domain.com, которую определяет этот файл.
Запись может выглядеть примерно так:
ns1 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 записи указывает псевдоним для канонического имени вашего сервера (который определен А или 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-сервера, используемые для этой зоны.
Вы можете спросить: “Почему файлу зоны, находящемуся на DNS-сервере, необходимо ссылаться на себя самого?” DNS-сервер настолько удобен, потому что имеет несколько уровней кэширования. Одной из причин для указания DNS-серверов в файле зоны служит то, что файл зоны может быть фактически обслужен с кэшированной копии на другом DNS-сервере. Есть и другие причины, объясняющие необходимость DNS-серверов ссылаться на сами DNS-сервера, но мы не будем вдаваться в эти подробности.
Как MX записи, NS записи являются параметрами всей зоны, так что они также не соединяют узлы. Выглядят они так:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Вы должны иметь по крайней мере два DNS-сервера, указанные в каждом файле зоны для того, чтобы правильно действовать, если есть проблема с одним из серверов.
Большая часть программного обеспечения DNS-серверов считает файл зоны недействительным, если указан только один 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
Есть немало других типов записей, которые можно использовать, но это, вероятно, наиболее распространенные типы, которые вы встретите.
Вывод
Теперь у вас должно сформироваться достаточно хорошее представление о том, как работает 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 рекомендуются следующие статьи:
[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]
Источники
Данный раздел написан/переведён преимущественно на основе: