Управление DNS, работа с NS и А записями на примерах. Что такое NS-сервер и как он работает

Данная статья не является каким-то конкретным и детальным руководством по всем нюансам с NS серверами, я лишь расскажу о небольшом личном опыте с решением вопросов на конкретных примерах. Каждый вебмастер сталкивается с подобными ситуациями, когда нужно было прописывать NS, создавать, изменять и т.п. — это часть работы с доменам и хостингами. Опытным уже все дается достаточно просто, а вот для начинающих разобраться порой не так легко. Поэтому приготовил парочку историй из жизни, так сказать.

Итак, для начала немного терминов. Вообще DNS — система доменных имен, грубо говоря задает соответствие между доменным именем и реальным IP адресом сайта, вы вводите домен и попадаете по нужному адресу. Для каждого домена после регистрации вы можете указывать различные DNS записей, которые помогают сайту быть найденным в глобальной паутине:

  • Запись A (запись адреса) — указывает IP адрес хостинга, где находится наш сайт.
  • Запись MX (адрес посты) — определяет IP адрес постового сервера для домена, как правило, совпадает с записью A.
  • Запись NS (name server) — указывает на DNS-сервер для конкретного домена.

Рассмотрим данные нюансы на примере работы с регистратором доменов Webnames . Для любого домена у нас есть 2 варианта задания соответствия между доменом и хостингом:

1. Указание записей A и MX, которые будут содержать IP хостинга с нашим сайтом:

При этом данное соответствие будет «храниться» в NS записях регистратора (webnames). Поэтому при создании хостинг аккаунтов вы можете использовать NS регистратора — в данном случае это ns1.nameself.com и ns2.nameself.com. При этом во вкладке DNS сервера в вашей учетной записи найдете:

2. В том же разделе меню управление DNS для домена вы также можете указать NS сервера хостера, например:

Теперь, по сути, вся ответственность по заданию соответствия между IP адресом и вашим доменом лежит на компании, которая эти DNS предоставляет. В данном случае это хостинг CoolVDS . Там, кстати, можно прикупить выделенный сервер в США, что хорошо подойдет по MFA сайты. Для того чтобы там «подключить» домен нужно обратиться в тех.поддежку на почту [email protected]: в теме письма пишите «домен для ваш_сервер.coolvds.com», где в тексте указываете домен, ip и опять имя сервера, например:

mydomain.com:193.333.555.777:ваше_имя.coolvds.com

Может слегка запутано, но только в первый раз. Другие хостинги могут при покупке хостинга спрашивать какие DNS использовать. Например, так делается в Hostpro, и если вы выберете использовать их DNS, тогда просто для своего домена нужно будет указать их NS сервера — master.hostsila.com и slave.hostsila.net без всяких A и MX записей.

Точно также 2 варианта, о которых я сказал выше есть у большинства нормальных регистраторов доменов. Еще один пример — Getnic.name . Здесь вы можете воспользоваться услугой бесплатного управления DNS или указать сторонние NS сервера.

Для этого выбираете домен и заходите в его учетную запись — здесь можете указать существующие NS другого хостера либо кликнуть по ссылке «управление DNS». Во втором случае сможете задать A, MX и все необходимые записи для домена и использовать бесплатные NS от getnic.name.

Создание собственных NS записей

Для некоторых своих проектов я покупал виртуальные сервера у Hostpro — расположение в Украине, поддержка адекватная и очень дружелюбная. После приобретения вам выдают 2 IP адреса — основной и дополнительный, а также просьбу зарегистрировать NS вида ns1.mydomain.ru и ns2.mydomain.ru.

Для webnames заходим опять же в раздел «Управление зоной» для своего домена, где добавляем нужные записи типа NS:

Для украинского регистратора iname.ua делается аналогичным образом: добавляете запись типа NS и указываете выданные IP.

Теперь для новых зарегистрированных доменов, сайты которых располагаются на вашем сервере сможете указывать не только A запись со ссылкой на IP, а и просто определять через свои NS — ns1.mydomain.ru и ns2.mydomain.ru. Кстати, напоследок ссылка на статью про то как можно не ждать обновления DNS — редактируем файл hosts после чего сможете приступать к работе над своим проектом пока глобальные DNS еще не обновились (дело нескольких часов).

Вот такой получился небольшой ликбез по управлению DNS, созданию NS, A, MX записей для доменов. Возможно, вы работаете с теми же регистраторами и хостингами, тогда данная статья должна быть полезной подсказкой, если какие-то вопросы возникают (особенно новичкам). Хотя, в принципе, конечно, всегда можно обратиться в тех.поддержку как регистратора домена, так и там где вы покупаете хостинг — в хороших, уважающих себя и клиентов, компаниях должны помочь, с другими лучше дела не иметь.

P.S. Купить книгу теперь можно и онлайн, заходите в специальный книжный интернет магазин выбираете товар, оплачиваете кредиткой и получаете доставку.

Как это работает система DNS?

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

DNS-сервер обращается к одному из корневых NS-серверов интернета, ip-адреса которых жестко заданы и известны и в ответ Корневой сервер отдает DNS-серверу список ip-адресов серверов, на которых расположена зона.COM Выглядит этот список примерно так:

A.gtld-servers.net. 160060 IN A 192.5.6.30 a.gtld-servers.net. 160060 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 160060 IN A 192.33.14.30 b.gtld-servers.net. 160060 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 160060 IN A 192.26.92.30 d.gtld-servers.net. 160060 IN A 192.31.80.30 e.gtld-servers.net. 160060 IN A 192.12.94.30 f.gtld-servers.net. 160060 IN A 192.35.51.30 g.gtld-servers.net. 160060 IN A 192.42.93.30 h.gtld-servers.net. 160060 IN A 192.54.112.30 i.gtld-servers.net. 160060 IN A 192.43.172.30 j.gtld-servers.net. 160060 IN A 192.48.79.30 k.gtld-servers.net. 160060 IN A 192.52.178.30 l.gtld-servers.net. 160060 IN A 192.41.162.30 m.gtld-servers.net. 160060 IN A 192.55.83.30

DNS-сервер обращается к одному из NS-серверов зоны.COM (Допустим, a.gtld-servers.net - 192.5.6.30) и запрашивает список NS-серверов для домена MYDOMAIN.COM. Эти NS-сервера называются NS-серверами, на которые делегирован домен.

Ns1.mydomain.com. 172800 IN A 66.96.142.148 ns2.mydomain.com. 172800 IN A 65.254.254.172 ns3.mydomain.com. 172800 IN A 66.96.142.146 ns4.mydomain.com. 172800 IN A 65.254.254.170

После чего обращается к одному из полученного списка NS-серверов и запрашивает уже информацию относительно домена MYDOMAIN.COM. Пример ответа:

Mydomain.com. 3248 IN MX 0 mail.mydomain.com. mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all" mydomain.com. 2208 IN SOA ns1.mydomain.com. hostmaster.mydomain.com. 1335787408 16384 2048 1048576 2560 mydomain.com. 248 IN A 65.254.242.180 mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; AUTHORITY SECTION: mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com. 167564 IN A 66.96.142.148 ns2.mydomain.com. 167564 IN A 65.254.254.172 ns3.mydomain.com. 126551 IN A 66.96.142.146 ns4.mydomain.com. 126551 IN A 65.254.254.170

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

Что такое делегирование домена

Делегированием домена называется передача корневым сервером зоны права размещения домена на определенном NS-сервере. Для примера, корневые сервера ДЕЛЕГИРУЮТ зону.COM на серверы, которые будут за нее отвечать, а серверы зоны.COM ДЕЛЕГИРУЮТ домен MYDOMAIN.COM на NS-сервера хостинг-провайдера или на какие-либо другие. Само делегирование означает, что на корневом сервере для домена присутствуют записи IN NS, указывающие на NS-сервер, на котором размещена информация по домену. Обратите внимание, делегирование предполагает наличие ТОЛЬКО записей IN NS и никаких других. Поэтому домену второго уровня нельзя прописать, к примеру, запись CNAME.

Что такое дочерние NS-серверы

Иногда NS-серверы для домена находятся на его поддоменах. В вышеприведенном примере домен MYDOMAIN.COM делегирован на NS-серверы ns1.mydomain.com, ns2.mydomain.com и т.д. Как же это возможно? Ведь чтобы обратиться к этим NS-серверам нужно узнать их ip-адрес. Все просто - корневой сервер зоны.COM при таком варианте требует указания не только доменных имен NS-серверов, но и их ip-адресов. Поэтому DNS-сервер знает, куда обратиться за подробностями. Рассмотрим пример двух доменов - с дочерним NS-сервером и без: NS-запись у домена diphost.ru

;; ANSWER SECTION: diphost.ru. 292 IN NS ns1.bz8.ru.

NS-запись у домена bz8.ru

;; ANSWER SECTION: bz8.ru. 300 IN NS ns1.bz8.ru. ;; ADDITIONAL SECTION: ns1.bz8.ru. 95617 IN A 185.35.220.5 ns1.bz8.ru. 95617 IN AAAA 2a00:e460:2a00:c01d::9:aaaa

Как видите, все просто. Такая настройка у зарубежных регистраторов называется Child NameServers

Какие бывают NS-записи для домена

NS-запись - указывает, на каких NS-серверах находится домен. Эта запись должна повторять значения для домена, находящиеся на корневых серверах зоны. Только в этом случае домен будет ДЕЛЕГИРОВАН.

Mydomain.com. 1448 IN NS ns3.mydomain.com.

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

Mydomain.com. 248 IN A 65.254.242.180

AAAA-запись - указывает на IPv6 адрес сервера. Также, эта запись иногда упоминается как Квадра-А (четыре А)

MX-запись - указывает на ip-адрес или доменное имя сервера, отвечающего за прием почты на этот домен (MX-сервер). В нашем примере, вся почта на любой адрес домена MYDOMAIN.COM будет поступать на сервер mail.mydomain.com.

Mydomain.com. 3248 IN MX 0 mail.mydomain.com.

MX-записей тоже может быть несколько. MX-запись кроме имени сервера также имеет поле "Приоритет". Оно указывает, в каком порядке нужно обращаться к MX-серверам домена. Чем меньше значение приоритета, тем приоритетнее сервер.

TXT-запись - Сюда записывают различную служебную информацию, для которой нет выделенных полей. Можно записать контактные данные администратора, или что угодно. TXT-записи также используются для хранения SPF и DKIM записей, использующихся для защиты от спама.

Mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all"

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

SOA-запись - генерируется автоматически NS-сервером и содержит служебную информацию: адрес электронной почты ответственного за NS-сервер, дату и время последнего обновления домена, предельное время кеширования зоны (TTL) и т.д.

SRV-запись - служит для хранения адресов различных серверов, обслуживающих домен. Обычно они не совпадают с адресом web-сервера, указанного в A-записи и, как и MX-сервер, расположены на других адресах. В эту запись можно добавить адреса JABBER, TeamSpeak серверов и т.д.

Общие правила оформления записей на NS-сервере

Если в записи указано доменное имя, оно должно заканчиваться точкой, иначе к нему будет приклеено имя основного домена. Т.е. если указать запись

Mydomain.com. IN MX 10 mx.mail.ru

то MX-сервер домена будет определяться как mx.mail.ru.mydomain.com. Поэтому правильный вариант записи:

Mydomain.com. IN MX 10 mx.mail.ru.

Учетная запись адреса (A) Учетная запись A отображает имя компьютера в виде числового адреса IP. Другими словами, эта запись указывает имя хоста и адрес IP определенного компьютера, чтобы имя хоста соответствовало определенному адресу IP. Это запись, которую именной сервер A должен отправить другому именному серверу и получить ответ на запрос. Ниже представлен пример того, как должна выглядеть запись A:
peter.gudzondns.com. IN A 36.36.1.6 Первый столбец содержит имя хоста компьютера. Список второго столбца, это класс записи. Для основной работы DNS Вам нужно только наличие IN обозначения, установленное для интернета. Следующий столбец обозначает тип записи, и последний столбец является собственно адресом IP. Возможно добавление более чем одного адреса IP для данного имени хоста. Это бывает необходимо, когда используется firewall и имеется две карты ethernet на одном компьютере. Все что Вы должны сделать - добавить вторую запись A, заполнив те же столбцы, за исключением адреса IP. Также возможно отображать более чем одно имя хоста для одного адреса IP. Но этого делать не рекомендуется, поскольку DNS имеет специальную запись позволяющую компьютерам иметь псевдонимы, которая называется записью CNAME.

  • Учетная запись канонического имени (CNAME) Учетная запись CNAME позволяет компьютеру иметь более чем одно имя хоста. Чтобы иметь возможность добавить псевдонимы, должна быть создана учетная запись A. Имя хоста компьютера, установленное для записи A называется каноническим или официальным именем компьютера. Другие записи должны указывать на каноническое имя. Вот пример записи CNAME: www.gudzondns.com. IN CNAME peter.gudzondns.com Вы можете увидеть сходство с предыдущей записью. Записи всегда читаются слева направо, слева располагается запрос, а справа ответ на запрос. Компьютер может иметь неограниченное число псевдонимов CNAME. Новая запись должна вводиться для каждого псевдонима.
  • Учетная запись почтового сервера (MX) Учетная запись MX - значительно более важная, чем может показаться. Она позволяет всю почту для домена, направлять одному хосту. Это чрезвычайно полезно для уменьшения нагрузки на внутренние хосты, на которые не должна направляться поступающая почта, а также для того, чтобы собирать всю почту, отправленную на любой адрес Вашего домена даже если этот конкретный адрес не имеет никакой связи с компьютером. Например, у Вас есть почтовый сервер, работающий на вымышленном компьютере peter.gudzondns.com. а Вы хотите, чтобы Ваш почтовый адрес был "[email protected]" а не "[email protected]". Это делается с помощью записи, показанной ниже: gudzondns.com. IN MX 10 peter.gudzondns.com. Самый левый столбец обозначает адрес, который Вы хотите использовать как почтовый адрес. Следующие два столбца были объяснены подробно в предыдущих записях. Следующий столбец, число "10", отличается от нормального формата записи DNS. Это число приоритета. Часто в больших системах имеются серверы резервной почты, возможно, более чем один. Они предназначены для получения почты, если не работает первичный сервер почты. Вы можете сделать это с помощью записей MX. Более низкое число в записи MX означает более высокий приоритет, и почта будет отправлена на сервер с самым низким числом (самый низкий из возможных - 0). Если что-то случается с этим сервером, то компьютер, доставляющий почту, будет пытаться ее направить на следующий сервер, указанный в таблицах DNS, в порядке приоритета. Вы можете иметь столько записей MX, сколько хотите. Использование записи MX полезно, даже если почта отправляется непосредственно на компьютер с записью A. Некоторые sendmail программы ищут только записи MX. Также возможно включать шаблоны записей MX. Если у вас есть домен, где каждый из пользователей имеет свой собственный компьютер, выполняющий роль почтового клиента, то почта может быть отправлена непосредственно на каждый компьютер. Вы можете добавить запись MX подобную этой: *.gudzondns.com. IN MX 10 peter.gudzondns.com. Она устанавливает, что любая почта, отправленная на любую индивидуальную рабочую станцию в домене gudzondns.com должна проходить через сервер peter.gudzondns.com. Следует проявить осмотрительность при использовании шаблонов, так как специфические записи имеют приоритет над тем, что содержится в шаблонах.
  • Учетные записи указателя (PTR) Хотя есть другие возможности устанавливать записи PTR, мы рассмотрим только наиболее часто используемый метод, называемый "in-addr.arpa".
    In-addr.arpa PTR записи являются точной противоположностью записям A. Они позволяют распознавать Ваш компьютер по его адресу IP. Это называется "обратным поиском". Он становится все более используемым, когда компьютер производит обратный поиск на вашем компьютере перед получением доступа к услугам (например, страницам в WWW). Обратный поиск является хорошей мерой безопасности для Вашего компьютера, так как проверяет, что ваш компьютер - именно тот, что должен быть. Запись In-addr.arpa выглядит так: 6.1.36.36.in-addr.arpa. IN PTR peter.gudzondns.com. Как Вы можете увидеть из примера для записи A, в начале этой записи имеется адрес IP обратный для имени хоста, расположенного в последней колонке.
  • Учетная запись именного сервера (NS) Запись NS - необходима для функционирования данных DNS. Она просто указывает на полномочия именных серверов для данного домена. Должно быть по крайней мере две записи NS для каждой записи DNS. NS записи выглядят так: gudzondns.com. IN NS draven.gudzondns.com. Там также должна быть запись A в Вашем DNS для каждого компьютера как запись A именного сервера Вашего домена.
  • Учетная запись начала полномочий (SOA) Запись SOA является наиболее решающей из записей DNS. Она передает больше информации, чем все другие записи вместе взятые. Эта запись названа началом полномочий, поскольку она обозначает запись DNS как официальный источник информации для своего домена. Вот пример записи SOA: gudzondns.com. IN SOA subdomain.gudzondns.com. hostmaster.gudzondns.com. (1998111201 ; Serial 10800 ; Refresh 3600 ; Retry 3600000 ; Expire 86400); Minimum
    Первый столбец содержит домен, для которого эта запись начинает полномочия. Следующие два данные должны выглядеть знакомыми. Запись "draven.gudzondns.com" является первичным именным сервером для домена. Последняя запись в этой колонке действительный адрес email, если Вы заменили "@" для первого ".". Он должен всегда быть действующим контактным адресом для записи SOA. Следующие данные – немного отличаются от тех, что мы уже использовали. Serial является записью того, как часто эта запись DNS может быть изменена. Каждый раз, когда производится изменение, Serial должен быть увеличен. Другие именные серверы, которые извлекают информацию для зоны из первичного, извлекают только зону если Serial в записи первичного именного сервера выше чем Serial в этой записи. Таким образом, именные серверы для домена могут изменяться сами. Рекомендуется использовать ваш Serial в формате YYYYMMDDNN, где NN – день, когда DNS был изменен. Все числовые значения времени в записи производится в секундах. Число"Refresh" показывает, как часто вторичный именной сервер должны проверять первичный для изменения в Serial. "Retry" - сколько вторичный сервер должен ждать, прежде чем попытаться пересоединяться с первичным сервером, если связь была потеряна. "Expire " сколько вторичный сервер должен использовать свой текущую запись, когда он не в состоянии выполнить восстановление, и " Minimum " означает, сколько Ваши именные серверы имени должны кешировать или сохранять эту запись.
    • Перевод

    Внимательный читатель найдет на этой картинке IPv6


    Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS - страшная и непонятная штука. Эта статья - попытка развеять такой страх. DNS - это просто , если понять несколько базовых концепций.

    Что такое DNS

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


    Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .

    Базовые штуки

    Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, - прим. пер. ).


    Давайте взглянем на маппинг между именем и адресом:


    $ dig web01.bugsplat.info

    Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:


    ; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:


    ;; QUESTION SECTION: ;web01.bugsplat.info. IN A

    dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов - AAAA . Давайте взглянем на ответ:


    ;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244

    Оставшаяся часть ответа описывает сам ответ:


    ;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56

    В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.


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


    Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig "у, если бы информация не был закэширована:


    $ dig +trace web01.bugsplat.info ; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms

    Информация выводится в иерархической последовательности. Помните как dig вставил точку. после хоста, web01.bugsplat.info ? Так вот, точка. это важная деталь, и она означает корень иерархии.


    Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.


    Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.


    В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!


    $ dig -x 192.5.5.241 ; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.

    Флаг -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:


    $ dig petekeen.net mx ; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93

    Заметьте, что MX -запись указывает на имя, а не на IP-адрес.


    Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:


    $ dig www.petekeen.net ; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86

    Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.

    Что не так с CNAME

    Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.


    Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.


    Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .

    Запросы к другим серверам

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


    $ dig www.petekeen.net @8.8.8.8

    Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

    Типичные ситуации

    Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

    Редирект домена на www

    Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect . Вот пример из админки Namecheap:



    Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:


    $ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118

    Этот IP принадлежит Namecheap"у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:


    $ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/

    CNAME для Heroku или Github

    Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.


    $ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com

    С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию .dns

  • домен
  • сеть
  • интернет
  • администрирование
  • Добавить метки

    Что такое DNS. Сроки обновления DNS-записей. Как побыстрее начать работу с новым доменом. Типы записей DNS. Как настроить автоматические субдомены. Правильная переадресация на адрес без www в начале.

    Что такое DNS

    Интернет – сеть, связывающая миллионы компьютеров по всему миру. Некоторые компьютеры в этой сети включены круглосуточно – это сервера с сайтами и электронной почтой. Каждому компьютеру при подключении к интернету назначается числовой идентификатор – ip-адрес. Но обращаться к серверам по числовому идентификатору людям не удобно, поэтому были введены буквенные домены.

    DNS (Domain Name System) – это система, обеспечивающая соответствие доменов ip-адресам. За хранение DNS-записей в интернете отвечает отдельный класс серверов – ns-сервера. Часть из них поддерживается администраторами доменных зон, другая – хостерами и интернет-провайдерами. У этих серверов есть своя иерархия, и обновляются записи на серверах не сразу: на некоторых – очень быстро, на других – в течение пары суток. Наиболее популярное программное обеспечение для ns-серверов называется BIND.

    Сроки обновления DNS-записей

    Распространённый вопрос у начинающих – когда заработает новый домен. Попробуем ответить и заодно разберемся, можно ли как-то ускорить этот процесс.

    Итак, вы хотите, чтобы новый домен начал работать. Для этого нужно добавить записи в 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

    Чтобы домен начал работать, вам необходимо задать для него несколько DNS-записей.

    Запись NS необходима для указания DNS-сервера, обслуживающего ваш домен. Услуги своего DNS-сервера может предложить регистратор домена или хостинг-провайдер. Другой вариант – настроить собственный NS-сервер, и использовать его.

    Запись A необходима для указания IP-адреса вашего сайта. IP-адрес предоставляет ваш хостинг-провайдер.

    Запись AAAA используется для указания IP-адреса версии 6 (IPv6). На данный момент эти адреса еще не получили повсеместной поддержки.

    Запись MX указывает на IP-адрес вашего почтового сервера. Необходима для доставки почты на почтовые ящики вашего домена.

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

    Запись PTR – это обратная запись, которая позволит при запросе IP-адреса вашего сайта, получить полное доменное имя. Важно, если вы используете для домена почтовый сервер, поскольку правильность PTR-записи проверяется многими почтовыми серверами (чтобы определить, не является ли письмо спамом). Эту запись устанавливает хостинг-провайдер. Проверить правильность записи можно с помощью специального сервиса . Зачастую проблем не возникает, и запись изначально установлена правильно.

    Как настроить автоматические субдомены для каждого пользователя. Создание wildcard DNS-записи

    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.site.ru на site.ru . Редирект 301

    Часть пользователей ссылается на ваш сайт, добавляя к адресу 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

    Надеемся, статья помогла получить представление о работе с доменами. Вопросы и замечания просьба оставлять в комментариях.