Работаю в хостинге: размещаем сайты пользователей на своих серверах.

Ввиду гигантского количества вопросов, которые нам задают и начинающие, и опытные пользователи, при помощи Пикабу хочу разъяснить некоторые принципы, аспекты и особенности этого ответвления IT-сферы. Не уверен, что количество вопросов от наших пользователей уменьшится, но попытаться стоит.

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

Еще на первом посте о DNS, думал, что тема будет закрыта. Но пикабушники считают иначе (пользуясь случаем, передаю привет @redisukropovich, @CitizenL), а кто я такой, чтобы идти против пикабушников, жаждущих утоления информационного голода? Поэтому, пост про DNS номер три.

Нужно сделать ремарку в самом начале: я никогда не видел лично внутренности корневых DNS-серверов (нулевого уровня), а также DNS-серверов, отвечающих за определённые доменные зоны (первого уровня): пока не дорос до таких высот. То, как они устроены я могу себе представить только примерно, поэтому нагружать вас недостоверной информацией не буду. Под моим управлением есть два DNS-сервера, хранящих информацию о размещённых на нашей технической площадке доменах. То есть, опираясь на предыдущий пост, писать буду о DNS-серверах второго уровня.

Для общего понимания, пойдём с самого начала цепочки.

Вы создали сайт и задались целью разместить этот сайт в Сети. Был выбран относительно простой вариант: размещение сайта за абонентскую плату у специализированной компании (хостер, хостинг-компания). Вы выбрали понравившееся вам свободное доменное имя pikabu.ru, зарегистрировали его по самой выгодной цене, которую наши. Затем нашли хостинг-компанию с интересными для вас ценовыми предложениями по размещению сайтов. Купили у них услуги хостинга, разместили сайт по их инструкциям на их сервере. А сайт при наборе домена pikabu.ru в адресной строке браузера не открывается. Что пошло не так?

Когда вы купили домен pikabu.ru, компания-регистратор, которая вам этот домен продала, направила DNS-серверу зоны .RU (на уровень 1) информацию о новом домене. Также они направили этому серверу информацию о DNS-серверах (сервера уровня 2), на которые нужно ссылаться при запросе IP-адреса веб-сайта этого домена. Поскольку при покупке домена вы еще не определились с компанией-хостером, то и DNS-сервера никакие для домена не указывали. В этом случае регистратор либо присваивает домену собственные DNS-сервера (второго уровня), либо не присваивает никаких.

Чтобы ваш сайт открывался с хостинга, услуги которого вы приобрели, вам нужно прописать в настрйоках купленного домена DNS-сервера (второго уровня) этой хостинг-компании. Делается это либо вами вручную, либо через тех. поддержку компании-регистратора, где вы приобрели домен pikabu.ru. Список самих DNS-серверов хостер должен предоставить вам по первому требованию.

Внесении изменений в список DNS у регистратора выглядит примерно так:

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

DNS-сервер изнутри — это база данных, которая хранит записи об обслуживаемых доменах.

Каждая запись состоит как минимум из трёх полей: содержимое записи, тип записи, значение записи. Например:

pikabu.ru — A — 91.228.155.94

Если с содержимым (pikabu.ru) и значением (91.228.155.94) всё понятно, то что такое тип записи, который в нашем случае предстаёт буквой «A»?

На данный момент в DNS существует около четырёх десятков типов записей. Часть из них используется очень часто, часть — довольно редко. Самые часто используемые типы записей:

1. A — адрес. То есть, непосредственно IP-адрес домена.

2. AAAA — адрес в формате IPv6.

3. MX — mail exchanger. Указывает на адрес почтового сервера для домена.

4. NS — name server. Хранит информацию о DNS-сервере домена.

5. SOA — start of autority. Запись, указывающая на сервер с эталонной информацией по этому домену.

6. TXT — text string. Произвольная запись с любыми данными. Не длиннее 255 байт.

7. CNAME — canonical name. Имя для псевдонима записи, на которую будет производится перенаправление запросов.

8. SRV — указатель на сервера с какими-либо сервисами.

На примере домена pikabu.ru посмотрим, какие записи хранят DNS-сервера (второго уровная) хостинг-провайдера сайта этого домена:

Первой идёт запись типа TXT:

pikabu.ru. TXT "v=spf1 include:_spf.google.com ~all"

Она означает, что для домена pikabu.ru в DNS-сервере хостера хранится некая TXT запись, с какой-то белибердой в содержимом. Забегая чуть вперёд, скажу, что эта запись помогает почте с домена pikabu.ru ходить через сервера google и успешно доставляться в ящики адресатов. Про работу почты вообще и SPF-записей я сделаю отдельный пост, информации на эту тему довольно много.

Затем мы видим SOA-запись:

pikabu.ru. SOA ns1.fornex.com. hostmaster.fornex.com. (

2469468516 ; serial

46800 ; refresh (13 hours)

1800 ; retry (30 minutes)

3600000 ; expire (5 weeks 6 days 16 hours)

21600 ; minimum (6 hours)

)

Разберём запись.

pikabu.ru — имя записи

SOA — тип записи

ns1.fornex.com — первичный DNS-сервер, который хранит наиболее полную информацию о предмете записи (о pikabu.ru, стало быть)

Электронная почта ответственного за содержимое записи; символ собаки здесь заменён точкой ввиду формата записей внутри dns.

Серийный номер (serial) — номер версии записи зоны. Положительное число, которое должно меняться с каждым изменением содержимого записи. Нужно для того, чтобы вторичные серверы могли по изменению серийного номера понять, что DNS-записи по домену были изменены.

Обновление (refresh) — параметр времени (цифра в секундах), говорящий вторичным DNS-серверам, с какой частотой нужно обращаться к первичному DNS-серверу, чтобы узнать, не менялся ли срийный номер записи.

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

Время истечения (expire) — в секундах показывает время, в течение которого вторичный сервер может использовать без обновления данные записи, которые он получил ранее.

Минимальное время кэширования негативного ответа (minimum) — временной параметр в секундах, указывающий, как долго должны кэшироваться ответы, утверждающие, что для данного домена нет соответствующего IP.

Далее мы наблюдаем четыре записи NS:

pikabu.ru. NS ns1.fornex.com.

pikabu.ru. NS ns2.fornex.com.

pikabu.ru. NS ns3.fornex.com.

pikabu.ru. NS ns4.fornex.com.

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

После NS записей идут MX-записи. Также в количестве нескольких штук:

pikabu.ru. MX 10 ASPMX5.GOOGLEMAIL.com.

pikabu.ru. MX 1 ASPMX.L.GOOGLE.com.

pikabu.ru. MX 5 ALT1.ASPMX.L.GOOGLE.com.

pikabu.ru. MX 5 ALT2.ASPMX.L.GOOGLE.com.

pikabu.ru. MX 10 ASPMX2.GOOGLEMAIL.com.

pikabu.ru. MX 10 ASPMX3.GOOGLEMAIL.com.

pikabu.ru. MX 10 ASPMX4.GOOGLEMAIL.com.

Рассмотрим эти записи на примере одной. Сначала, как мы уже привыкли, идёт имя домена записи: pikabu.ru. Затем тип записи MX, который говорит нам, что эта запись сообщает имя почтового сервера домена. После неё следует цифра, в нашем случае от 1, 5 или 10. Это приоритет MX-записи. То есть, запись с приоритетом 1 будет срабатывать первой. С приоритетом 10 — последней.

Почему их несколько? Причина неизменна: дублирование для повышения отказоустойчивости. Почтовый сервис google, которым пользуется pikabu.ru, огромен, и некоторые его сервера периодически могут уходить на профилактику, в этом случае начинает работать запись со следующим приоритетом, и почта начинает обрабатываться другим почтовым сервером.

И последняя в нашем списке запись

pikabu.ru. A 91.228.155.94

С ней мы уже разобрались в самом начале: домен pikabu.ru имеет IP-адрес сайта 91.228.155.94. Именно по этому адресу браузеру и нужно обращаться за содержимым сайта pikabu.ru.

Со стороны хостера всё это добрище выглядит примерно так:

Благодарю всех, кто осилил прочитать это до конца. Если возникли вопросы, задавайте в комментариях, попробую ответить.

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

Ввиду гигантского количества вопросов, которые нам задают и начинающие, и опытные пользователи, при помощи Пикабу хочу разъяснить некоторые принципы, аспекты и особенности этого ответвления IT-сферы. Не уверен, что количество вопросов от наших пользователей уменьшится, но попытаться стоит.

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

В своём первом посте я затронул тему, которая вызывает очень много вопросов у пользователей: принципы работы DNS. Сейчас, по просьбе @NupkiYia попробую «по-человечески» рассказать, что такое DNS и зачем он нужен.

Боюсь, без небольшого экскурса в историю не обойтись, поэтому прошу вас набраться терпения. Постараюсь без занудства.

Самой первой относительно большой сетью из компьютеров была ARPANET. Количество узлов (непосредственно компьютеров) в ней было невелико. Все узлы имели уникальные имена. Сетью пользовались исключительно профессионалы, которым не составляло труда хранить в собственной памяти «карту» сети, которая выглядела в определённый момент так:

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

Время шло, и количество компьютеров, включенных в сеть, росло. Карта расширялась и запомнить её становилось всё сложнее. Тогда умные люди придумали сохранять карту сети прямо на узлах сети в виде простого текстового файла. Файл получил имя hosts. Содержал файл адрес узла и его имя, например:

10.0.15.220 SCOTT

Файл заполнялся вручную и скачивался с определённой периодичностью на каждый компьютер. Однако, с ростом сети, файл разрастался и становилось трудно уследить за корректностью его заполнения.

Вскоре ARPANET переходит на новый сетевой стандарт: TCP/IP. Это служит толчком также и к разработке нового сервиса для работы с адресами узлов сети. Так появляется DNS: централизованная база данных со ссылками на децентрализованные базы данных, каждая из которых содержит записи о подчинённом ей пространству адресов (имён компьютеров).

Надеюсь, не устали. Экскурс в историю закончен.

Хочу сделать отдельную ремарку относительно файла hosts. Синтаксис его наполнения (то, как он должен правильно заполняться) не изменился до сих пор. И файл этот есть на каждом компьютере, который работает под управлением операционной системы с поддержкой сети.

Например, в Windows вы можете посмотреть его содержимое так:

Пуск — Выполнить - «notepad.exe %SystemRoot%\system32\drivers\etc\hosts»

Только не рекомендую вносить в этот файл каких-то изменений, если, конечно, вы не знаете, что делаете.

Но я отвлёкся. Чем всё-таки занимается DNS? Одной фразой: DNS занимается «разрешением» имён. Принцип этого процесса я описал в своём предыдущем посте.

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

Внутри системы всё подчинено строгой иерархии. Всё начинается с 13 корневых серверов DNS, которые содержат в своей базе ссылки на DNS-сервера доменов верхнего уровня (ru, com, net, org, biz и т. д.), так называемых Top Level Domain (TLD), обслуживающие свою непосредственную зону ответственности.

По правде говоря, сейчас корневых серверов не 13, а чуть больше 200. Но эти две сотни на самом деле являются зеркалами первоначальных 13, и цель их существования — то самое дублирование, повышающее общую отказоустойчивость системы. Они разбросаны по всемй планете и обуспечивают интернет бесперебойным доступом к DNS

Далее идут DNS-сервера тех самых TLD, которые обслуживают свою узкую зону ответственности. Они также имеют зеркала. Внутри них содержатся ссылки на DNS-сервера доменов второго уровня, которые уже содержат непосредственные IP-адреса доменов второго уровня.

Итак, обобщённо схема пространства имён DNS выглядит так:

Уровень 0.

Корневой DNS сервер — обозначается точкой.

Содержит ссылку на DNS сервер верхнего уровня.

Уровень 1.

DNS-сервер домена верхнего уровня — обозначается сочетанием букв, например RU.

Содержит ссылку на DNS сервер каждого конкретного домена второго уровня в домене RU.

Уровень 2.

DNS сервер, содержащий конечные адреса для домена второго уровня.

Например, для домена pikabu.ru DNS-сервером второго уровня являются несколько серверов: ns1.fornex.com, ns2.fornex.com, ns3.fornex.com, ns4.fornex.com.

Как видите, домен pikabu.ru, относясь к родительскому домену .ru, обслуживается на DNS-сервере, имеющем собственное имя в зоне .com. То есть, DNS-сервер на уровне 2 может содержать конечные адреса для доменов любых уровней выше второго, находящихся в любой зоне TLD.

Почему у домена pikabu.ru четыре DNS-сервера? Это тоже вопрос отказоустойчивости. Если у одного из серверов возникают какие-то проблемы, то три оставшихся его подстраховывают. По этой же причине у любого домена в сети должно быть как минимум два DNS-сервера второго уровня.

Зачем всё так сложно? На самом деле ничего сложного. Всё просто, если экстраполировать DNS на реальную жизнь, например, на армию:

1. Есть несколько полковников, каждый из которых лично знаком с некоторым количеством подполковников.

2. Каждый подполковник — специалист в своей области, имеет в подчинении большое количество майоров.

3. Каждый майор имеет в подчинении различных специалистов-исполнителей абсолютно разных званий и направлений деятельности.

Пользователь в этой схеме выступает в качестве генерала. Через своего секретаря (интернет-провайдер) направляет ближайшему полковнику чёткий, сформулированный по определённым армейским правилам запрос. Полковник читает запрос, распознаёт, из какой области этот запрос и направляет его нужному подполковнику. Подполковник читая запрос, сверяется со своей амбарной книгой, чтобы узнать, для какого из майоров подходит сформированный запрос. Найдя нужные записи в амбарной книге, он направляет запрос всем майорам из полученного из амбарной книги списка. Запрос обрабатывает тот майор, который ответил на него быстрее всех. Майор, в свою очередь, читая запрос находит уже своей картатеке нужного исполнителя запроса. В итоге, ответ на ваш запрос исполнитель отдаёт вам через вашего секретаря с соблюдением всех формальностей и использованием специального протокола.

Таким образом, в случае потери кого-либо из цепочки, всегда найдётся замещающий потерю специалист.

P.S.:

Прошу прощения за очень длинный пост. Я редактировал его несколько раз, убирая избыточную информацию, но шибко в этом не преуспел. Благодарю за терпение. Если что-то непонятно - спрашивайте отвечу в комментариях.

Работаю в хостинге: размещаем сайты пользователей на своих серверах.

Ввиду гигантского количества вопросов, которые нам задают и начинающие, и опытные пользователи, при помощи Пикабу хочу разъяснить некоторые принципы, аспекты и особенности этого ответвления IT-сферы. Не уверен, что количество вопросов от наших пользователей уменьшится, но попытаться стоит.

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

По сути, домен (доменное имя), например, pikabu.ru - это упрощённое символьное представление адреса сервера, на котором расположен сам сайт. Чтобы показать в вашем браузере сайт, ваше устройство (компьютер, планшет, смартфон и т.д.), после введения вами в адресной строке браузера имени сайта, запускает довольно запутанную на первый взгляд цепочку запросов.

Что происходит, когда вы набираете в браузере адрес сайта (домен), например "pikabu.ru"?

1. Бразузер направляет запрос на сервер вашего интернет-провайдера.

2. Сервер интернет-провайдера смотрит в свой DNS-кэш, и если там адреса pikabu.ru не находит, обращается к корневому DNS-серверу зоны .RU, т.к. именно в этой зоне находится домен нужного нам сайта.

3. Корневой сервер, получая запрос, смотрит в свою базу и ищет там записи с именами и IP-адресами DNS хостинг-провайдера, который размещает на своих серверах сайт, именуемый в народе pikabu.ru. Найдя эти записи он передаёт их серверу интернет-провайдера.

4. Обращаясь к DNS хостинг-провайдера, сервер Интернет-провайдера получает IP сервера, на котором размещён сайт с именем pikabu.ru, и кладёт его в базу своего DNS-кэша. А также обращается по этому IP напрямую к серверу, где размещён сайт.

5. Сервер хостинг-провайдера по запрошенному доменному имени находит в своих внутренностях нужные данные и передаёт их обратно.

6. Интернет-провайдер передаёт полученные данные в ваш браузер, который отрисовывает вам сайт.

В схеме, как видите, несколько узлов, которые общаются друг с другом, пока вы ждёте. В идеальных услових, всё общение между ними происходит за доли секунды. И после введения адреса в браузер, вы получаете сайт в течение пары секунд, большую часть которых занимает передача данных сайта по каналу связи межлу хостинг-провайдером и вашим компьютером.

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

Скорость обновления DNS-кэша у интернет-провайдеров разная: от четырёх часов до четырёх суток. В среднем, они обновляют кэш DNS в течение 12 часов. В крупных городах, обновление происходит чаще: 2-4 часа.

Прошу прощения за возможное косноязычие. Перевод с IT на человеческий даётся довольно сложно, но я стараюсь. Если что-то всё ещё не понятно - пишите вопросы в комментах, попробую ответить.

За несколько лет, пока я в этой сфере кручусь, было много всякого-разного. Если пост зайдёт, буду писать ещё. Познавательного материала - бесконечное количество.