Желаю здравия всем читателям.
От «нечего делать» по ночам возникла у меня идея записать все те частые ошибки или неверные мнения, с которыми встречаются люди при размещении сайтов в интернете. Не могу сказать, что эта информация адресована начинающим веб-мастерам (хотя я буду стараться все описать максимально подробно), как не могу сказать, что она адресована и профессионалам. Вместе с тем разработка сайтов, хостинг и сопутствующие понятия - это такая область, где можно быть профессионалом в одном и совершенно ничего не понимать в другом - это нормально. Так что если кому-то эти тексты будут полезны, я буду рад.
Начать хотелось бы с серии статей, в которых обсуждались бы типичные ошибки и заблуждения при создании файла зоны на DNS-серверах и делегировании доменов.
И первое заблуждение заключается в том, что DNS-серверы изменяются мгновенно. Вместе с тем, первая статья будет немного длинной, так как считаю необходимым пояснить все термины, которые будут упоминаться в дальнейшем.
Очень часто на просторах интернета можно увидеть восклицания: «Вот, я подал заявку на смену DNS-серверов, прошло уже 10 минут, а ничего не изменилось, сайт указывает на старый хостинг». Конечно, за 10 минут что-то может измениться, но, увы, это было бы результатом стечения очень многих факторов, весьма маловероятным.
Для начала напомню, что же такое DNS.
Сайт - это по факту набор файлов. Это могут быть файлы, содержащие исполнимый код, картинки, стили, данные в базах данных (таблицы в БД могут тоже физически представлять собой набор файлов) и так далее. Эти файлы хранятся на сервере (веб-сервере), который и выполняет обработку запросов к сайту, заключающуюся грубо в том, что при поступлении определенного запороса нужно выдать тот или иной документ.
Чтобы передать запрос на сервер, браузер (это программа, при помощи которой мы и просматриваем сайты на компьютере) должен знать IP-адрес сервера, на котором размещен запрашиваемый сайт, а у сайта в большинстве случаев есть доменное имя, то есть некая уникальная последовательность букв, цифр, дефисов и точек, которую нужно прописать в адресной строке браузера, чтобы попасть на сайт, например, test.ru. Слишком формальное описание, не так ли? Большинство людей в современном мире, думаю, не вспоминают про доменные имена - они просто вбивают в поисковую строку нужные слова, и переходят по ссылкам, предлагаемым поисковыми системами. Но ссылки эти в подавляющем большинстве случаев как раз и содержат то или иное доменное имя.
В девяностых и нулевых годах часто поисковые системы не использовали для поиска нужного содержимого, по крайней мере, в англоязычных странах, в частности, в США. Бытовал такой способ находить информацию: набить в адресной строке браузера то, что тебе нужно, добавить .com и перейти на появившийся сайт. В России все было несколько сложнее (кириллические домены существовали не всегда, да и сейчас особо не пользуются популярностью: до сих пор при их использовании можно наткнуться на кучу «подводных камней»). В общем, домен - это удобное для восприятия имя сайта.
Но чтобы соединиться с сервером, где хранится сайт, нужно знать его IP-адрес. Для сопоставления доменным именам IP-адресов в первую очередь и нужны DNS-серверы. То есть браузер обращается к функции операционной системы, позволяющей установить, на какой IP-адрес нужно установить соединение, чтобы получить данные с сайта, имеющего конкретное доменное имя. Что при этом происходит? Происходит обращение к DNS-серверу, который в ответ на запрос о том, какая A-запись имеется для переданного доменного имени, сообщает IP-адрес сервера, на котором расположен сайт, и уже с этим самым сервером и происходит соединение и обмен данными.
Домены (доменные имена) бывают разных уровней - по количеству наборов символов (слов), разделенных точкой, в их имени. Полное доменное имя всегда заканчивается точкой, но последнюю точку обычно опускают при написании. Например, ru. - доменное имя первого уровня, test.ru. (чаще пишут test.ru) - доменное имя второго уровня, www.test.ru. (www.test.ru) - домен третьего уровня и так далее. Тут стоит отметить, что многие до сих пор по старой привычке не обращают внимания на то, что www.test.ru и test.ru - это разные доменные имена третьего и второго уровней соответственно, и они могут адресовать разные ресурсы.
Также часто используется понятие поддомена и домена верхнего уровня, тут проще пояснить на примере:
- www.test.ru является поддоменом домена test.ru;
- test.ru является доменом верхнего уровня для www.test.ru;
- test.ru является поддоменом домена ru;
- ru является доменом верхнего уровня для test.ru.
Домены верхнего уровня часто называют «зонами», например, test.ru - это домен второго уровня в зоне ru, www.test.ru - домен третьего уровня в зоне test.ru (и это обусловлено тем, что поддомен создается путем добавления тех или иных записей в файл зоны (zone file) на DNS-сервере домена верхнего уровня).
У каждого домена есть администратор (грубо - владелец, но это не точно: домен - это не имущество, на него нет права собственности, но есть право администрирования) или регистрант (registrant) - это то лицо (юридическое или физическое), на которое оформлено доменное имя. Это лицо отвечает за то, что именно адресует данный домен, а также за регистрацию в нем поддоменов.
Также у доменов есть и регистратор (registrar в англоязычных терминах, не путайте с registrant: registrant - это администратор («владелец») домена, а registrar - это регистратор) - это организация, при помощи которой произведена регистрация домена.
Как устроена вся эта иерархия?
Я уже упоминал выше файлы зон на DNS-серверах. Понятно, что хранить огромные количества записей в виде соответствий «доменное имя - IP-адрес» на одном сервере было бы чересчур накладно: очень уж долго бы производился бы поиск конкретной записи. Для этого и придумана была иерархическая структура системы DNS.
Что же нужно сделать, чтобы определить IP-адрес, соответствующий доменному имени, в общем случае? Давайте разберем это на примере домена yandex.ru. Нам нужна A-запись для этого имени.
Для того, проследить за процессом «воочию», можно использовать команду nslookup (она есть в любой популярной операционной системе, доступна из командной строки) или ее более информативный аналог - dig для Unix-подобных систем.
Итак, сперва нужно обратиться к корневым DNS-серверам «всего интернета». Список этих серверов известен заранее: их список можно найти на сайте IANA: https://www.iana.org/domains/root/servers.
Давайте попробуем спросить, что корневые серверы знают про yandex.ru:
$ dig @a.root-servers.net yandex.ru a
; <<>> DiG 9.10.6 <<>> @a.root-servers.net yandex.ru a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47745
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 11
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;yandex.ru. IN A
;; AUTHORITY SECTION:
ru. 172800 IN NS a.dns.ripn.net.
ru. 172800 IN NS b.dns.ripn.net.
ru. 172800 IN NS d.dns.ripn.net.
ru. 172800 IN NS e.dns.ripn.net.
ru. 172800 IN NS f.dns.ripn.net.
;; ADDITIONAL SECTION:
a.dns.ripn.net. 172800 IN A 193.232.128.6
b.dns.ripn.net. 172800 IN A 194.85.252.62
d.dns.ripn.net. 172800 IN A 194.190.124.17
e.dns.ripn.net. 172800 IN A 193.232.142.17
f.dns.ripn.net. 172800 IN A 193.232.156.17
a.dns.ripn.net. 172800 IN AAAA 2001:678:17::193:232:128:6
b.dns.ripn.net. 172800 IN AAAA 2001:678:16::194:85:252:62
d.dns.ripn.net. 172800 IN AAAA 2001:678:18::194:190:124:17
e.dns.ripn.net. 172800 IN AAAA 2001:678:15::193:232:142:17
f.dns.ripn.net. 172800 IN AAAA 2001:678:14::193:232:156:17
;; Query time: 55 msec
;; SERVER: 198.41.0.4
;; WHEN: Wed Jun 10 02:17:51 MSK 2020
;; MSG SIZE rcvd: 350
Как видим, сервер a.root-servers.net не имеет сведений о A-записях для yandex.ru, но зато он нам может сообщить, какие DNS-серверы отвечают за домен ru - их пять.
В аналогичной проверке командой nslookup мы не увидим A-записи, и в ответ сразу можем спросить NS-записи.
$ nslookup
> server a.root-servers.net
Default server: a.root-servers.net
Address: 198.41.0.4
> yandex.ru
Server: a.root-servers.net
Address: 198.41.0.4
Non-authoritative answer:
*** Can't find yandex.ru: No answer
> set q=ns
> yandex.ru
Server: a.root-servers.net
Address: 198.41.0.4
Non-authoritative answer:
*** Can't find yandex.ru: No answer
Authoritative answers can be found from:
ru nameserver = a.dns.ripn.net.
ru nameserver = e.dns.ripn.net.
ru nameserver = f.dns.ripn.net.
ru nameserver = d.dns.ripn.net.
ru nameserver = b.dns.ripn.net.
a.dns.ripn.net internet address = 193.232.128.6
a.dns.ripn.net has AAAA address 2001:678:17::193:232:128:6
e.dns.ripn.net internet address = 193.232.142.17
e.dns.ripn.net has AAAA address 2001:678:15::193:232:142:17
f.dns.ripn.net internet address = 193.232.156.17
f.dns.ripn.net has AAAA address 2001:678:14::193:232:156:17
d.dns.ripn.net internet address = 194.190.124.17
d.dns.ripn.net has AAAA address 2001:678:18::194:190:124:17
b.dns.ripn.net internet address = 194.85.252.62
b.dns.ripn.net has AAAA address 2001:678:16::194:85:252:62
Итак, домен RU обслуживают пять DNS-серверов вида *.dns.ripn.net. И NS-записи со значениями, содержащими имена этих серверов, присутствуют в файле зоны на корневых DNS-серверах всего интернета. Это дословно означает, что домен ru делегирован на 5 DNS-серверов. Делегирование домена - это указание NS-записей для него на DNS-серверах домена вышестоящего уровня.
Многие, кстати, путают понятие делегирования домена с понятием передачи прав на домен другому человеку - нет, это не тот случай. В контексте доменных имен понятие делегирования можно объяснить так: DNS-серверы вышестоящего уровня не хранят информацию о домене, который мы у них запросили, но они делегировали функцию хранения этих данных другим серверам, куда и нужно обратиться для получения информации о домене.
Продолжим. Спускаемся на уровень ниже и спрашиваем у любого из 5 DNS-серверов, на которые делегирован домен RU, что они знают про домен yandex.ru.
$ dig @e.dns.ripn.net yandex.ru a
; <<>> DiG 9.10.6 <<>> @e.dns.ripn.net yandex.ru a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32351
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yandex.ru. IN A
;; AUTHORITY SECTION:
YANDEX.RU. 345600 IN NS ns1.yandex.RU.
YANDEX.RU. 345600 IN NS ns2.yandex.RU.
YANDEX.RU. 345600 IN NS ns9.z5h64q92x9.net.
;; ADDITIONAL SECTION:
ns1.yandex.RU. 345600 IN A 213.180.193.1
ns2.yandex.RU. 345600 IN A 93.158.134.1
ns1.yandex.RU. 345600 IN AAAA 2a02:6b8::1
ns2.yandex.RU. 345600 IN AAAA 2a02:6b8:0:1::1
;; Query time: 26 msec
;; SERVER: 193.232.142.17
;; WHEN: Wed Jun 10 02:25:08 MSK 2020
;; MSG SIZE rcvd: 210
$ nslookup
> server e.dns.ripn.net
Default server: e.dns.ripn.net
Address: 193.232.142.17
> set q=a
> yandex.ru
Server: e.dns.ripn.net
Address: 193.232.142.17
Non-authoritative answer:
*** Can't find yandex.ru: No answer
> set q=ns
> yandex.ru
Server: e.dns.ripn.net
Address: 193.232.142.17
Non-authoritative answer:
*** Can't find yandex.ru: No answer
Authoritative answers can be found from:
YANDEX.RU nameserver = ns9.z5h64q92x9.net.
YANDEX.RU nameserver = ns1.yandex.RU.
YANDEX.RU nameserver = ns2.yandex.RU.
ns1.yandex.RU internet address = 213.180.193.1
ns2.yandex.RU internet address = 93.158.134.1
ns1.yandex.RU has AAAA address 2a02:6b8::1
ns2.yandex.RU has AAAA address 2a02:6b8:0:1::1
Ситуация полностью аналогичная: на серверах *.dns.ripn.net, на которые делегирован домен ru (их еще называют «корневыми серверами зоны ru»), нет информации о том, на какой адрес «ссылается» домен yandex.ru, потому что домен yandex.ru делегирован на три других сервера (не пугайтесь, по данным Whois, домен z5h64q92x9.net тоже принадлежит «Яндексу», это не взлом).
Вывод описанных команд содержит несколько интересных особенностей, которые стоит обсудить. Мы обращались к корневому серверу зоны ru, который имел адрес e.dns.ripn.net, и спрашивали у него что-нибудь про домен yandex.ru. И тут видим, что домен yandex.ru делегирован на серверы, у двух из которых в имени… опять присутствует yandex.ru. То есть, для того, чтобы узнать что-нибудь о домене yandex.ru (и о его поддоменах, помните?) нам нужно обратиться к DNS-серверу, являющемуся поддоменом домена yandex.ru (например, ns1.yandex.ru). Но для того, чтобы к нему обратиться, нам нужно выяснить его IP-адрес, для этого нужно обратиться прежде всего к DNS-серверу, на который делегирован домен yandex.ru, но… Это ns1.yandex.ru, и чтобы выяснить его IP-адрес, нужно обратиться к DNS-серверу, на который делегирован yandex.ru, но это… Стоп.
Вот как раз чтобы не происходило таких ситуаций, для домена yandex.ru на DNS-серверах, обслуживающих домен ru, в том числе e.dns.ripn.net (к которому мы обращались), созданы так называемые glue-записи, которые содержат информацию об IP-адресе дочернего DNS-сервера. Дочерним будет являться DNS-сервер, доменное имя которого является поддоменом того домена, который на него делегирован. Ну то есть ns1.yandex.ru является дочерним DNS-сервером домена yandex.ru, а вот ns9.z5h64q92x9.net дочерним не является. Наличие glue-записей обязательно только для дочерних серверов, чтобы можно было найти их IP-адреса прямо на корневых серверах зоны верхнего уровня.
Соответственно, обращаться мы будем к ns1.yandex.ru так:
$ dig @213.180.193.1 yandex.ru a
; <<>> DiG 9.10.6 <<>> @213.180.193.1 yandex.ru a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63228
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yandex.ru. IN A
;; ANSWER SECTION:
yandex.ru. 300 IN A 77.88.55.77
yandex.ru. 300 IN A 5.255.255.77
yandex.ru. 300 IN A 5.255.255.80
yandex.ru. 300 IN A 77.88.55.70
;; Query time: 9 msec
;; SERVER: 213.180.193.1#53(213.180.193.1)
;; WHEN: Wed Jun 10 02:35:04 MSK 2020
;; MSG SIZE rcvd: 102
$ nslookup
> server 213.180.193.1
Default server: 213.180.193.1
Address: 213.180.193.1#53
> set q=a
> yandex.ru
Server: 213.180.193.1
Address: 213.180.193.1#53
Name: yandex.ru
Address: 77.88.55.77
Name: yandex.ru
Address: 77.88.55.70
Name: yandex.ru
Address: 5.255.255.77
Name: yandex.ru
Address: 5.255.255.80
И вот, наконец, мы получили ответ от DNS-севрера, который содержит Answer Section (секцию авторитативного ответа) с указанием нужных нам IP-адресов. Заметьте, что в выводе команды dig появился флаг aa - Authoritative answer (а из выдачи nslookup исчезла фраза «Non-authoritative answer, не заслуживающий доверия ответ»), что означит, что процесс поиска IP-адреса закончен, мы получили однозначный и окончательный ответ о запрошенных записях для домена yandex.ru от сервера, на который делегирован домен yandex.ru (то есть от сервера, который и отвечает за хранение этой информации).
Уфф. Долго, согласитесь? Если бы при каждом запросе IP-адреса доменного имени все бы происходило именно по этой схеме, интернет бы работал гораздо медленнее, а нагрузка на серверы была бы больше.
Так что происходит на самом деле? На самом деле есть кеши - как в операционной системе, так в системе DNS - на DNS-резолверах или кеширшующих DNS-серверах.
На самом деле когда вы в браузере набираете yandex.ru, во-первых, браузер или операционная система могут сразу иметь в своем кеше ответ: домену yandex.ru соответствует такой-то IP-адрес. Этот ответ ОС или браузер могли получить ранее и сохранить его в своем кеше (либо эта информация могла быть задана в файле hosts операционной системы, который позволяет указывать соответствия доменов IP-адресам для этого конкретного локального компьютера в обход системы DNS). Если информация в данном кеше есть, и она не устарела, то браузер сразу отправляет запрос по уже известному IP-адресу и получает данные сайта.
Если такой информации в кеше браузера/операционной системы нет, то производится запрос на получение IP-адреса к DNS-резолверу. DNS-резолверы - это те самые DNS-серверы, которые указываются в настройках интернет-подключения компьютера к интернету - вручную или автоматически по DHCP. Это может быть резолвер Вашего роутера, резолвер интернет-провайдера, публичный DNS-сервис вида 8.8.8.8 от Google и так далее.
Что делает резолвер? Резолвер, получив запрос, проверяет: есть ли готовый ответ в кеше и не устарел ли он. Если ответ есть в кеше, он его сразу отдает, и все быстро и замечательно заканчивается. Если ответа в кеше нет, то дальнейшие действия зависят от того, как устроен резолвер: если это, к примеру, резолвер в Вашем роутере, он, скорее всего, направит запрос DNS-резолверам Вашего интернет-провайдера (или тем, которые указаны в настройках сетевого подключения самого роутера), а если это уже резолвер провайдера, то он выполнит всю ту цепочку, которую мы вручную выполнили ранее: обратится к корневым серверам, потом к серверам следующего уровня - и так далее, пока не получит авторитативный ответ, а, получив его, он запишет его в свой кеш и вернет в ответ на запрос. Следующий запрос того же типа записи по тому же доменному имени будет уже выполнен быстрее, так как результат будет взят из кеша.
Теперь немного о том, как это все управляется. Полномочия администрирования доменов первого уровня выделены тем или иным организациям, которые осуществляют обслуживание поддерживающих их DNS-серверов и координацию регистраций поддонов в них. Причем за техническую часть может отвечать одна организация, а за административную - другая. Вот, например, информация о домене RU.
То есть по идее, чтобы зарегистрировать поддомен в домене RU, нужно обращаться в Координационный центр домена RU. Но напрямую это сделать невозможно, и это логично: ведь если бы все желающие зарегистрировать домен в одной зоне, обращались бы в одну компанию, эта компания либо захлебнулась бы, либо была бы «жирным» таким монополистом. Поэтому существует такое понятие, как регистратор доменов.
Когда вы регистрируете домен, Вы обращаетесь к регистратору доменов (domain registrar) или к его посреднику (реселлеру, партнеру), оплачиваете (при необходимости) стоимость регистрации домена, сообщаете данные администратора («владельца») домена, которые и будут переданы администратору зоны первого уровня для внесения в реестр (список поддонов), а также список DNS-серверов, на которые нужно делегировать доменное имя, которые будут внесены в виде NS-записей на DNS-серверы, обслуживающие зону.
То есть в случае с доменом RU процесс взаимодействия для регистрации домена будет следующим:
- вы обращаетесь к регистратору домена или его партнеру и сообщаете необходимый набор данных.
- Регистратор проверяет соответствие данных правилам регистрации (у каждой зоны могут быть свои правила) и передает данные в реестр зоны RU - в данном случае в компанию, осуществляющую техническое обслуживание реестра.
- Компания, обслуживающая реестр, сохраняет данные в своей БД и вносит их на корневые DNS-серверы зоны.
- Координационный центр контролирует, чтобы эти цепочки работали корректно.
Когда нужно поменять DNS-серверы для домена, происходит точно такой же процесс.
И вот тут мы подходим к теме статьи: почему это не происходит моментально. Опять же рассмотрим задержки на каждом шаге.
- Шаг первый. Внесение данных о новых DNS-серверах для домена самим администратором домена может производиться либо напрямую у регистратора домена, либо через партнера (реселлера) регистратора, через которого вы регистрировали домен. Если Вы обращаетесь к реселлеру (партнеру), то некоторое время должно пройти, чтобы данные о новых серверах были переданы регистратору: если этот процесс автоматизирован - это занимает несколько минут или даже секунд. Если партнер регистратора делает это вручную - может быть и дольше (до нескольких часов или даже дней (но это очень редко)). Регистратор должен сохранить полученные данные в своей базе данных. Обычно это занимает несколько секунд или минут. После сохранения данных в базе регистратора обычно в интерфейсе самого регистратора вы уже увидите новые DNS-серверы.
- Далее регистратор передает данные в реестр зоны, в которой зарегистрирован домен. Это происходит в автоматическом режиме, занимает несколько секунд или минут, но может и дольше - если есть большие «очереди» таких изменений, например, в начале регистрации доменов в новых зонах и других подобных случаях.
- Далее технический центр зоны сохраняет изменения в своей базе данных. Через несколько минут после этого данные о новых DNS-серверах появятся в Whois (если Whois предусматривает отображение DNS-серверов домена). Но это еще не конец!
- Далее эта информация в виде NS-записей должна попасть на DNS-серверы зоны верхнего уровня, это может занимать продолжительное время. Например, для зоны RU - в течение 1-2 часов (может и через 5 минут, а может - через 1 час 55 минут): изменения на серверах публикуются чаще всего «пачками», для зоны COM - быстрее, обычно десятки минут. И только после этого корневые серверы зоны будут отдавать новые DNS-серверы.
- Начиная с этого момента вы будете видеть такую ситуацию: на части устройств домен уже «указывает» на новые серверы, а на части - на старые. Дело как раз в тех самых кешах на DNS-резолверах, о которых я писал выше. Время жизни кеша на этих резолверах должно зависеть от параметров в файле зоны домена (там указывается TTL - время жизни записи в кеше), но может зависеть и от настроек самих резолверов.
То есть в общем и целом можно описать ситуацию так: после изменения DNS-серверов домен начнет «указывать» на новые DNS-серверы в период от нескольких часов до нескольких дней (ввиду наличия кешей на резонерах). На моей практике в одном случае максимальное время жизни старых записей в кешах о домене составило порядка недели, то есть в течение недели пользователи одной из сетей видели сайт со «старого» хостинга.
Причем замечу, что львиную долю задержек берут на себя именно процесс обновления информации на корневых DNS-серверах и обновление кешей на резолверах разных провайдеров, что никак не зависит ни от хостинга, ни от регистратора доменов. Система DNS весьма инертна.
