Webmin не поддерживает работу со всеми типами записей, которые знает BIND. Поддерживается работа только с теми, что более распространены. Ниже будут описаны типы записей, с которыми Webmin умеет работать. Кроме того, будет дана краткая характеристика каждому из этих типов.
Типы записей доступных в прямой зоне :
Address (A) - адресный тип записи. Этот тип ассоциирует IP адрес с hostname(имя хоста). Любая система, к которой вы захотите подключится через HTTP, telnet или иной протокол, имеющая закрепленное за ней hostname(имя хоста), должна иметь адресную запись, чтобы по имени хоста(hostname) можно было отыскать IP адрес хоста. Помните, одно имя хоста(hostname) может иметь несколько адресных записей(записей A типа) . Это часто используется для распределения нагрузки на веб-сайт между несколькими системами. Кроме того, можно создать несколько адресных записей с различными hostname(имя хоста), но одним и тем же IP адресом, как если бы создавались name-based(имя-основанные ) виртуальные сервера Apache.
При создании или редактировании адресной записи, поле Address(IP адрес ) предназначено для записи IP адреса, который будет ассоциирован с hostname(имя хоста). Поле Update reverse?(Обновить обратную зону ?) , отвечает за автоматическое создание и изменение записи Reverse Address(Запись обратного адреса , тип PTR) в Reverse zone(Обратной зоне ) . Смотри Добавление и редактирование записей , для подробностей.
Name Server (NS) - тип записи определяющий имя сервера, отвечающего за обслуживание зоны. Каждая зона должна иметь хотя бы одну NS запись и кроме того, может иметь дополнительные NS записи для поддоменов этой зоны. Если вы настраиваете дополнительный(второй, secondary) DNS сервер для некоторой зоны, то незабудьте проверить, добавлена ли NS запись для этой зоны на главном(основном, master) DNS сервере. В этом случае(если настраиваете дополнительный DNS сервер), имя записи должно быть каноническим для зоны, например example.com(т.е. полностью с родительской(ими) зоной(ами)) .
При создании или редактировании записи этого типа, поле Name Server(Имя сервера; hostname; имя хоста) предназначено для ввода IP адреса или hostname(имя хоста), DNS сервера, отвечающего за обслуживание зоны. Если вы введете hostname(имя хоста), то необходима ещё адресная запись(Address record; A-запись) с IP адресом для этого hostname(имя хоста), расположенного в некоторой зоне, на вашем DNS сервере.
Name Alias (CNAME) - этот тип записи позволяет создавать алиасы(псевдонимы, ссылки, привязки) к уже существующим адресным(Address; тип A) и обратным адресным(Reverse Address, тип PTR) записям. Когда DNS клиент запрашивает IP адрес, этого типа(Name Alias), то он получает тот IP адрес, прописанный в той записи, к которой сделана привязка. Это может быть полезным, если вы хотите, чтобы некоторый хост был доступен под несколькими именами. Конечно, это может быть достигнуто созданием нескольких адресных записей, но вариант с алиасами удобней в том, что если у некоторого хоста сменился IP адрес, то нет необходимости что-то менять в алиасах. В то время как, если использовать множетство адресных записей - придется вносить изменения каждую запись связанную с этим некоторым сервером.
Форма создания и редактирования записи Name Alias содержит поле Real Name(Реальное имя), предназначенное для ввода канонического реального имени записи на которую будет указывать алиас(например webserver.example.com).
Mail Server (MX) - тип записи, который сообщает почтовым программам, вроде Sendmail или Qmail, где находится почтовый сервер(сервер к которому, нужно обратится, для доставки почты в этом домене). Без этой записи, почта для этого домена, будет доставлена на ту систему(тот сервер, хост), чей IP адрес указан в адресной записи(Address, тип А) для этой зоны.
Каждая MX запись имеет приоритет, что позволяет разгрузить нагрузку между несколькими почтовыми серверами. Соответственно, приоритет сообщает почтовым программам(доставщикам), к какому из серверов обратится первому. И далее по убывающей, например если сервер с высоким приоритетом не отвечает.
Примечание : Высокий приоритет в данном контексте означает не самое большое число, а самое маленькое, т.е. 10 выше чем 50.
Сервера с низким MX приоритетом, предназначены для того, чтобы пересылать почту на некоторый хост, который бы хранил почту. Затем, когда почтовый сервер с наивысшим приоритетом освободится, он возьмет письма из хранилища и отправит их по адресу.
При добавлении или редактировании MX записи вам доступны два поля. В первое необходимо внести каноническое hostname(имя хоста) или ссылку на него(на имя хоста), почтового сервера. Второе поле предназначено для введения приоритета MX записи. Обычно, для главного сервера устанавливают приоритет равный 5. Если у вас всего один почтовый сервер, то приоритет не имеет значения. Кроме того, вы можете установить для двух почтовых серверов одинаковый приоритет. В таком случае сервер, который доставит письмо адресату, будет определен случайным образом.
Host Information (HINFO) - типа записи используемый для хранения информации об архитектуре и операционной системе некоторого хоста. Например, вам может понадобится создать запись для сервера test.example.ru, что он(сервер) есть x86 PC под FreeBSD. Однако, это очень редко применяется, так как такая информация может быть использована злоумышленниками при подготовке атак.
При добавлении или редактировании этого типа записи, поля Hardware(Архитектура) и Operating System(Операционная система) предназначены для ввода архитектуры и операционной системы хоста, соответственно. Вводить данные в эти поля следует без пробелов, заменяя пробелы знаком «земля», то есть «_» без кавычек.
Text (TXT) - тип записи, который ассоциирует произвольную текстовую информацию с выбранной зоной(доменом). То есть, нельзя добавить TXT запись просто куда-нибудь. Её можно добавить только, при редактировании некоторой зоны. Так вот к редактируемой зоне и будет присоединена эта текстовая информация. Этот тип может использоватся для присоединения комментариев к некоторой зоне(домену). Будьте осторожны, так как эту информацию может прочитать любой, запросивший информацию о зоне(домене), поэтому не располагайте в комментариях конфиденциальную информацию.
При добавлении или редактировании этого типа записи, поле Message(Сообщение), предназначено для ввода комментария к хосту. Этот текст может содержать и пробелы.
Well Known Service (WKS) - тип записи, который ассоциирует hostname(имя хоста), порт и протокол некоторого сервиса(например, почта) с выбранной зоной. Это может быть, к примеру, использовано, для указания клиентам, какой хост является почтовым сервером. Однако большинство программ не запрашивает WKS записи, поэтому на практике этот тип записей, часто бесполезен.
При добавлении или редактировании этого типа записи, поля Address(IP адрес), Protocol(Протокол) и Services(Сервисы), предназначены для ввода IP адреса хоста некоторого сервиса, который оказывается для этой зоны(домена); сетевого протокола, который используется сервисом - TCP или UDP; номера порта на котором, предоставляется данный сервис, соответственно.
Responsible Person (RP) - тип записи, который ассоциирует человека или группу людей ответственных за эту зону(домен). Поля E-mail address(E-mail адрес) и Text Record Name(Имя), предназначены для ввода E-mail адреса ответственного лица и его имени(имени и фамилии), соответственно. Этот тип записей используется редко.
Location (LOC) - тип записи, который используется для указания физического расположения хоста. В координатах широты и долготы. Возможно, будет полезным для больших организаций, сервера, которых в разных странах.
При добавлении или редактировании этого типа записи, поле Latitude(Широта) and Longtitude(Долгота) предназначено для ввода широты и долготы. Пример, для хоста cambridge-net.kei.com есть 42 21 54 N 71 06 18 W -24m 30m .
Service Address (SRV) - тип записи, который ассоциирует доменное имя, имя сервиса и протокол с некоторым хостом. Другими словами, эта запись используется для указания расположения некоторого сервиса на некотором хосте. К примеру, этот тип записи может быть использован, если вы хотите указать, что POP3 сервер для example.ru это mail.example.ru, а веб-сервер это www.example.ru.
При добавлении или редактировании этого типа записи, поля Protocol(Протокол) и Service Name(Имя сервиса), предназначены для ввода протокола, который использует сервис(TCP, UDP, TLS) и имени(названия) сервиса(это имя можно взять из файла /etc/services) соответственно. Названия сервисов могут быть такими - pop3, telnet и другие. Когда клиент ищет некоторую SRV запись, то вид запроса записи следующий: _telnet._tcp.example.ru(Например, может быть таким). Webmin автоматически преобразует вами созданную запись к такому(правильному) виду. Это означает, что нет необходимости создавать или редактировать такого типа записи вручную.
Поле Priority(Приоритет) предназначено для ввода приоритета для этого сервера, означающий(приоритет) то же самое, что и приоритет для MX записей. Поле Weight(Вес) предназначено для ввода числа, означающего «вес» этого хоста. Обращения пользователей будут преимущественно к серверу имеющему бОльший «вес».
Поле Port предназначено для ввода номера порта, на котором предоставляется данный сервис.
Public Key (KEY) - тип записи, который ассоциирует «ключ» к некоторому хосту. Этот ключ используется для IPsec VPN.
Типы записей доступных в обратной зоне :
Reverse Address (PTR) - тип записи, который ассоциирует hostname(имя хоста) с IP адресом в обратной зоне. Для DNS клиентов, необходимо отыскивать hostnames(имена хостов) по заданному IP адресу. Вам следует создавать по одной записи этого типа для каждого хоста. Однако, в большинстве случаев это может быть автоматизировано. Webmin может добавлять адресную запись в обратную зону, сразу после того, как соответствующая адресная запись добавлена в прямую зону. То есть Webmin умеет синхронизировать прямую и обратную зоны.
При добавлении или редактировании этого типа записи, поля Address(IP адрес) и Hostname(Имя хоста) предназначены для ввода IP адреса(Например, 192.168.1.5; Этот адрес будет автоматически конвертирован Webmin"ом в формат in-addr.arpa, используемый DNS сервером для обратной зоны) и hostname(имя хоста) в канонической форме(Например, test.example.ru. ), соответственно.
ВНИМАНИЕ: При вводе Hostname(Имя хоста), обязательно поставьте в конце точку. Это не опечатка.
Name Server (NS) - тип записи NS в обратной зоне, предназначен для того же, что и в прямой - он сообщает другим DNS серверам, IP адрес или hostname(имя хоста) сервера обслуживающего некоторую зону(домен) или некоторый поддомен.
Поле Zone Name(Имя зоны, домена) предназначено для ввода имени зоны, которую обслуживает этот сервер. Обычно то имя зоны, совпадает с именем зоны, в которую добавляется эта запись. В этом поле вам следует вводить значение в формате in-addr.arpa(Так как нет синхронизации, как в адресных записях - тип А и PTR). Поэтому вид имени зоны(Zone Name) для 192.168.1 будет выглядеть как 1.168.192.in-addr.arpa. (Точка обязательна в конце, это не опечатка) В поле Name Server(Сервер имён), вы должны ввести IP адрсе или hostname(имя хоста) в канонической форме(например, ns1.example.ru).
Name Alias (CNAME) - тип записи в обратной зоне, предназначен для того же, что и в прямой - алиас, ссылка, привязка к некоторой записи. В полях Name(Имя) и Real Name(Реальное имя) вам следует вводить значение в формате in-addr.arpa, так как Webmin не делает это автоматически.
Любой пользователь Интернет имеющий домены на серверах хостинг-провайдеров могут создавать и редактировать свои DNS записи. DNS записи имеют Имя, Тип записи и Адрес. Эти названия в различных панелях могут меняться. Например, может быть так:
Имя/Хост/Псевдоним; Тип записи ; Значение/Ответ/Назначение/Адрес.
Во всех вариантах «Тип записи» остается неизменным.
Имя записи, оно же хост/псевдоним это доменное имя, к которому принадлежит или привязана создаваемая запись.
При создании записи в поле «Имя» доменное имя указывается полностью. Имя субдомена или псевдонима не нужно указывать полностью. Достаточно указать имя третьего уровня: mail, www, ftp. Если вводите полное имя, обязательно поставьте точку в конце. То есть имя mail и mail.example.ru. это одно и то же имя в поле Имя/хост/псевдоним.
Рассмотрим основные типы DNS записей, с которыми предстоит сталкиваться при обслуживании своих доменов.
Тип записи: А (address record) или (адрес Internet 4) . Этот тип записи привязывает конкретное доменное имя на определенный, точный IP-адрес.
Можно добавить больше одного IP адреса для одного домена (имени хоста). Это нужно если используется firewall. Для этого нужно добавить вторую запись типа A, аналогично первой. Указав только другой IP.
В теории можно для одного IP адреса, указать более одного домена. Но этого делать не нужно, так как система доменных имен (DNS) имеет запись специально предназначенную для создания псевдонимов. Называется эти запись типа CNAME.
Тип записи: AAАA (address record для IPv6) или (адрес Internet 6) . Тоже. Что и тип записи А, но IP адрес имеет внешний вид по протоколу IPv6. Например: IPv6-2a03:4900:0:3::99:155
CNAME (каноническое имя -canonical name record) . Запись типа CNAME позволяет иметь и использовать на сервере более одного имени домена (хоста).
Сначала создается одна запись типа А, для одного IP адреса. Имя домена в записи типа А, называется каноническим именем. Другие домены называют мнемонические. Мнемонические имена могут быть псевдонимами (произвольными именами) или субдоменами. Здесь пример CNAME записи:
popov.example.ru. CNAME example.ru. (не забываем точки в конце).
Сервер может иметь любое количество псевдонимов. Для каждого псевдонима нужно создать запись типа CNAME.
Еще пример записи CNAME:
hosting-1 IN A 8.8.8.8
www IN CNAME hosting-1
ftp IN CNAME hosting-1
Покупаем второй IP и на второй IP переводим поддомен ftp:
hosting-1 IN A 8.8.8.8
hosting-2 IN A 8.8.8.9
www IN CNAME hosting-a
ftp IN CNAME hosting-b , переносим на второй хостинг FTP –сервер.
Еще пример записи CNAME:
hosting-1 IN A 8.8.8.8
peter IN CNAME hosting-1
oleg IN CNAME hosting-1
Следующими записями CNAME привязываем псевдонимы:
example.com. IN CNAME example.ru.
www.example.com. IN CNAME example.ru.
test.example.com. IN CNAME example.ru.
тем самым мы связываем домены example.com, www.example.com, test.example.com с каноническим доменом example.ru. Точки в конце обязательны.
Еще пример переадресация (редирект) с помощью записи типа CNAME
www.example.ru. IN CNAME example.ru.
Обычно, сервера по умолчанию создают записи CNAME только для поддоменов основного домена и не делают их для других доменов (как на фото).
MX (почтовый сервер). Эта запись создает поддомен, который обслуживается внутренним (своим) почтовым сервером.
Например: Имя/хост/псевдоним — example.ru; Тип записи -MX (почтовый сервер); Значение/ответ/назначение/Адрес – mail. Этой записью вы создаете почтовый поддомен mail.example.ru. Если используется внутренний почтовый сервис сервера, то для поддомена mail.example.ru нужно создать тип записи «А». Имя:mail- A (тип записи)- Адрес: IP сервера.
В качестве почтового сервиса можно использовать сторонние почтовые сервера. Для этого вам нужно привязать свой домен к стороннему почтовому серверу. На нем вам создадут, автоматом, MX запись. Если не создадут, то дадут адрес почтового сервера. После этого вам нужно создать записи типа CNAME и MX на своем сервере.
Записью CNAME переадресуйте почтовый домен mail.example.ru. на адрес почтового домена. А записью типа MX для самого домена example.ru. задайте адрес вашего стороненого почтового ящика. В качестве примера можно использовать почтовый сервер Яндекс.
Имя/хост/псевдоним — example.ru; Тип записи -MX (почтовый сервер); Значение/ответ/назначение/Адрес – mx.yandex.ru. Приоритет 10.
Имя/хост/псевдоним – mail; Тип записи –CNAME; Значение/ответ/назначение/Адрес –domain.mail.yandex.ru. Приоритет 10.
На почтовом сервере Яндекс , можно без делегирования домена, подключить его только к почтовому серверу Яндекс, создав там, почтовый ящик.
Кроме Яндекс, с помощью MX записей можно привязать домен к почтовым серверам Google, Mail.ru и другим:
Тип записи NS (сервер имён). Это, пожалуй, самый важный тип записи. Он определяет домены (адреса) DNS серверов, обслуживающих этот домен.
TXT (текстовая запись) . Это информационная запись. Она не несет функциональной нагрузки.
Запись типа SOA показывает, где храниться на каком сервере лежит основная информация об этом домене. В записи типа SOA указывается полное, уточненное доменное имя зоны. Уточненное доменное имя должно оканчиваться точкой. В записи SOA может стоять символ @, вместо уточненного имени. В этом случае, доменное имя будет взято из файла конфигурации.
Приведу пример записи SOA, для Microsoft DNS
В панели ISPManager DNS записи редактируются на вкладке: Доменные имена→ «Клик» по домену.
В панели DirectAdmin DNS записи редактируются на вкладке: Управление DNS.
Что такое DNS. Сроки обновления DNS-записей. Как побыстрее начать работу с новым доменом. Типы записей DNS. Как настроить автоматические субдомены. Правильная переадресация на адрес без www в начале.
Интернет – сеть, связывающая миллионы компьютеров по всему миру. Некоторые компьютеры в этой сети включены круглосуточно – это сервера с сайтами и электронной почтой. Каждому компьютеру при подключении к интернету назначается числовой идентификатор – ip-адрес. Но обращаться к серверам по числовому идентификатору людям не удобно, поэтому были введены буквенные домены.
DNS (Domain Name System) – это система, обеспечивающая соответствие доменов ip-адресам. За хранение DNS-записей в интернете отвечает отдельный класс серверов – ns-сервера. Часть из них поддерживается администраторами доменных зон, другая – хостерами и интернет-провайдерами. У этих серверов есть своя иерархия, и обновляются записи на серверах не сразу: на некоторых – очень быстро, на других – в течение пары суток. Наиболее популярное программное обеспечение для ns-серверов называется BIND.
Распространённый вопрос у начинающих – когда заработает новый домен. Попробуем ответить и заодно разберемся, можно ли как-то ускорить этот процесс.
Итак, вы хотите, чтобы новый домен начал работать. Для этого нужно добавить записи в DNS и ждать, пока они растекутся по интернету. Время обновления записей составляет от нескольких часов до трех суток. Ограничения вызваны принципами работы DNS, являющейся распределенной и высоконагруженной системой.
После регистрации домена, или смены записей DNS, ваш сайт будет доступен для различных пользователей через различное время, в зависимости от особенностей работы их интернет-провайдеров. То есть для вас сайт может быть еще недоступен, а для кого-то доступен. Или наоборот. Это связано с тем, что каждый интернет-провайдер сам определяет время обновления кэша DNS на своих серверах.
Что касается субдоменов, то зачастую, при их создании, они становятся доступны либо сразу, либо в течение 5-20 минут (должны обновиться записи на ns-серверах хостера).
Если вы зарегистрировали домен, либо изменили записи DNS, и вам срочно нужно начать работу с сайтом, вы можете добавить одну строчку в файл hosts вашей операционной системы (в Windows файл находится по адресу C:\WINDOWS\system32\drivers\etc , папка по умолчанию скрыта, и необходимо включить отображение скрытых папок в панели управления):
xxx.xxx.xxx.xxx site.ru
где xxx.xxx.xxx.xxx – ip-адрес сервера, site.ru – доменное имя вашего сайта.
Чтобы домен начал работать, вам необходимо задать для него несколько DNS-записей.
Запись NS необходима для указания DNS-сервера, обслуживающего ваш домен. Услуги своего DNS-сервера может предложить регистратор домена или хостинг-провайдер. Другой вариант – настроить собственный NS-сервер, и использовать его.
Запись A необходима для указания IP-адреса вашего сайта. IP-адрес предоставляет ваш хостинг-провайдер.
Запись AAAA используется для указания IP-адреса версии 6 (IPv6). На данный момент эти адреса еще не получили повсеместной поддержки.
Запись MX указывает на IP-адрес вашего почтового сервера. Необходима для доставки почты на почтовые ящики вашего домена.
Запись CNAME служит для указания одного домена в качестве адреса другого домена, то есть задает вашему домену или субдомену такой же IP-адрес, как и у домена, ссылку на который вы укажете в записи.
Запись PTR – это обратная запись, которая позволит при запросе IP-адреса вашего сайта, получить полное доменное имя. Важно, если вы используете для домена почтовый сервер, поскольку правильность PTR-записи проверяется многими почтовыми серверами (чтобы определить, не является ли письмо спамом). Эту запись устанавливает хостинг-провайдер. Проверить правильность записи можно с помощью специального сервиса . Зачастую проблем не возникает, и запись изначально установлена правильно.
Wildcard запись – это DNS-запись отвечающая за все субдомены *.site.ru . Указание такой записи может понадобиться, к примеру, для CMS (WordpressMU, Drupal), используемой для управления субдоменами.
Для создания такой записи необходимо зайти в раздел управления DNS-записями домена и добавить запись типа A, в качестве субдомена указать символ *, а в качестве адреса – IP-адрес сервера, зачастую совпадающий с IP-адресом, указанным для основного домена. Если вам не удается это сделать, нужно обратиться в техническую поддержку.
Заодно рассмотрим, как сконфигурировать Apache для работы с wildcard субдоменами. Пусть в конфигурационном файле сервера есть секция, описывающая виртуальный хост:
DocumentRoot "/home/site.ru"
ServerName "site.ru"
ServerAlias "www.site.ru"
ErrorLog logs/site.ru-error.log
CustomLog logs/site.ru-access.log common
Вам необходимо лишь добавить псевдоним *.site.ru:
ServerAlias "www.site.ru" "*.site.ru"
Часть пользователей ссылается на ваш сайт, добавляя к адресу www. Другие www не добавляют. Это может негативно сказываться на продвижении в поисковых системах. Устраним проблему на примере сервера Apache:
1. Убедитесь, что на сервере включен модуль ModRewrite: в файле httpd.conf cтрока LoadModule rewrite_module modules/mod_rewrite.so должна быть раскомментирована. Если вы его включили, то перезапустите Apache.
2. Добавьте следующие строки в файл.htaccess , заменив site.ru адресом вашего сайта:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.site.ru$
3. Попробуйте зайти на сайт, используя адрес www.site.ru в адресной строке браузера. Адрес должен измениться на site.ru .
4. Можно внести в файл.htaccess строки:
RewriteCond %{HTTP_HOST} !^site\.ru$
RewriteRule ^(.*)$ http://site.ru/$1
Это позволит правильно обработать запросы к вашему сайту, когда в конце домена стоит точка: site.ru. вместо site.ru
Надеемся, статья помогла получить представление о работе с доменами. Вопросы и замечания просьба оставлять в комментариях.
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS - страшная и непонятная штука. Эта статья - попытка развеять такой страх. DNS - это просто , если понять несколько базовых концепций.
DNS расшифровывается как Domain Name System . Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .
Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, - прим. пер. ).
Давайте взглянем на маппинг между именем и адресом:
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов - AAAA . Давайте взглянем на ответ:
Оставшаяся часть ответа описывает сам ответ:
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. , когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig "у, если бы информация не был закэширована:
Информация выводится в иерархической последовательности. Помните как dig вставил точку. после хоста, web01.bugsplat.info ? Так вот, точка. это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!
Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае - f.root-servers.net .
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» - прим. от ). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect . Вот пример из админки Namecheap:
Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:
Этот IP принадлежит Namecheap"у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:
Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию .dns
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS - страшная и непонятная штука. Эта статья - попытка развеять такой страх. DNS - это просто , если понять несколько базовых концепций.
DNS расшифровывается как Domain Name System . Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .
Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, - прим. пер. ).
Давайте взглянем на маппинг между именем и адресом:
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов - AAAA . Давайте взглянем на ответ:
Оставшаяся часть ответа описывает сам ответ:
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз , когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig "у, если бы информация не был закэширована:
Информация выводится в иерархической последовательности. Помните как dig вставил точку. после хоста, web01.bugsplat.info ? Так вот, точка. это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!
Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае - f.root-servers.net .
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» - прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect . Вот пример из админки Namecheap:
Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:
Этот IP принадлежит Namecheap"у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:
Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию .dns Добавить метки
