Ликбез по домену для онлайн школы

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

Так же я предлагаю не зацикливаться на одной конкретной школе, а в целом рассмотреть сам процесс. Так как плюс/минус процедура подключения доменного имени к онлайн школе одинаковая на всех школах, с той лишь разницей, что сами менюшки находятся в разных местах. Логика же подключения абсолютно идентичная.

Что такое домен и зачем это нужно?

Официально про домен пишут примерно следующее: Доменное имя — символьное имя, служащее для идентификации областей, которые являются единицами административной автономии в сети Интернет, в составе вышестоящей по иерархии такой области.

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

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

Причиной появления и телефонной книжки и доменов примерно одинаковая. Точно так же, как идентификация абонента в телефонной сети происходит посредством номера телефона представленного числами, точно так же все интернет-ресурсы идентифицируются таким же числовым представлением, только называется это представление IP-адресом. Числовое представление удобно для компьютеров, но не удобное для человека. Людям не особенно охота запоминать кучу чисел. Гораздо удобнее выбрать имя абонента или ввести т.н адрес сайта, как раз тот самый домен. После ввода домена в адресную строку, браузер обращается к серверу имен и узнает, какой IP-адрес закреплен за этим доменом, получает его и уже после этого ваш браузер устанавливает соединение с запрашиваемым Web-ресурсом.

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

Домен и его записи: A, MX, TXT, NS, CNAME

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

A- и CNAME- записи

Основная запись домена — это запись типа А, в большинстве случаев A-запись указывает непосредственно на IP-адрес сервера нашего ресурса. В основном используется для подключение сайта к домену и субдомену/поддомену. Например, мой блог, сайты на тильде и многие другие подключаются как раз через настройку A-записи.

Отдельного внимания заслуживает запись типа CNAME. Эту запись можно и нужно применять в тех случаях, когда у вас или на каком-либо сервере уже есть привязанный к домену ресурс. Для примера возьмем мой блог, у меня уже есть запись типа А указывающая на IP-адрес сервера, на котором размещен мой блог. Но недавно я приобрел еще один домен. И хочу, что бы когда пользователь вводит адрес blog.alexdevop.live открывался мой сайт. В этом случае для поддомена blog домена alexdevop.live могу указать CNAME-запись которая будет указывать на мой основной домен getcourseapi.ru.

Аналогичным образом, к примеру, настраивается и подключение GetCourse для поддомена. У этой площадки есть свой поддомен fwd.getcourse.ru и их сервера настроены таким образом, что бы этот адрес можно было использовать для CNAME-записей и подключать свои поддомены к серверам GetCourse. Аналогично поступает и сервис SendPulse, они используют CNAME для настройки отслеживания кликов по ссылкам в письме, используя при этом домен владельца профиля. CNAME-запись работает только для поддоменов.

TXT-запись

Данный тип записей в панели управления доменом используют в основном для служебных целей. Когда необходимо подтвердить владение доменом (так поступает рекламные кабинеты разных запрещенных и не очень платформ) либо сервисы вроде Mail.ru Postmaster. В качестве примера использования TXT-записи смотрите на скрине ниже.

Когда вы вносите данные в TXT-запись, а затем в нужном сервисе нажимаете кнопку «Подтвердить», этот сервис делает запрос к домену, получает список его TXT-записей и ищет в них код, который просил вас там разместить. Если код найден и совпадает, сервис расценивает это как подтверждение владения, посколько только владелец или доверенный администратор домена может вносить изменения в список записей. Аналогично, TXT-записи активно используют почтовые сервисы и те которые рассылают письма и те которые получают. Зачастую именно в TXT-полях хранится информация с уникальным ключом цифровой подписи письма (DKIM) и списка почтовых серверов с которых разрешено отправлять письма от имени указанного домена (SPF). Эти записи более подробно мы рассмотрим позже, пока нужно просто понимать, что для размещения такого рода служебной информации нужны TXT-записи. Почтовые сервера и при отправке и при получении писем запрашивают DKIM и SPF и сравнивают информацию этих записей с информацией которая приходит в служебных заголовках писем, таким образом верифицируют подлинность письма и его отправителя.

MX-запись

Раз уж мы затронули тему настроек почтовых сервисов, у нас не выйдет пройти мимо записи типа МХ. Задача этой записи схожа с предназначением А-записи, но с одним существенным отличием. Если А-запись используют для того, что бы получить IP-адрес ресурса, то MX запись необходима для указания адреса почтового сервера (сервера EMAIL). Допустим мы делаем рассылку. Наш почтовый сервис отправляет письмо на адрес test@gmail.com. В этом случае, условный сервер GetCourse делает запрос на получение MX-записи на домене gmail.com. А затем выполняет подключение уже к почтовому серверу Google и передает ему данные отправленного письма. В некоторых случая MX-записей может быть несколько, в этом случае порядок обработки сообщений будет определятся приоритетом. Чем меньше указано число в графе приоритета, тем более высокий приоритет будет назначен серверу.

NS-запись

Последняя запись о которой я расскажу, это запись NS. В этой записи указано, где именно следует размещать все остальные записи домена. Условно говоря указывает, где, на какой группе серверов будет хранится наша «доменная телефонная книжка». Необходимость изменять значение NS-записей может возникнуть, если вы приобрели домен у регистратора reg.ru, но хотите управление записями доменов перенести, допустим на GetCourse. Последний, кстати, принудительно заставляет переносить домен на свои NS-сервера, если в качестве адреса школы будет использован домен верхнего уровня (например домен вида academy.com).

Здесь нужно учитывать, что для домена верхнего уровня не получится задать запись CNAME и таким образом направить нужный домен на GetCourse или другой сервис. CNAME-запись работает только для поддоменов. И по непонятной мне причине, команда GetCourse не дает данные IP-адреса для A-записи. По этому для подключения основного домена к этой платформе придется прописывать NS-сервера на указанные в GetCourse, тем самым передавая управление доменом на эту площадку.

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

[masterslider id=»2″]

Практически все панели устроены в виде таблицы. В одной из колонок тип записи, в другой селектор, в следующей значение записи. Всё плюс/минус идентично.

Записи в домене

Этот раздел статьи в большей степени основан на моем личном опыте в настройке доменов. В процессе работы я стал разделять записи на статические, динамические и редактируемые. Это не официальная классификация, а придуманная мною, однако именно такая классификация довольно точно отражает суть основных записей домена.

Статические записи

В эту категорию я выделяю доменные записи которые известны заранее и которые не изменяются в процессе. Не большой список статических записей привожу ниже:

• CNAME-запись GetCourse — fwd.getcourse.ru
• Селектор @ | MX-запись mail.ru — emx.mail.ru
• Селектор @ | MX-запись yandex.ru — mx.yandex.net
• CNAME-запись Bizon365 — users.bizon365.ru
• Селектор _dmarc | TXT-запись — v=DMARC1; p=quarantine

Селектор это условно говоря поддомен. Конечно, это не совсем корректное, но понятное объяснение. В разных панелях управления колонка селектора называется по разному. Например в nic.ru селектор указывается в колонке Хост. В GoDaddy селектор прописан в колонке Name. В GetCourse селекторы прописаны в колонке Имя, а в ADM Tools прямо в колонке Субдомены и точно так же реализовано и в 2domains и reg.ru.

Динамические записи

К таковым я отношу любые записи в доменной панели, значение которых заведомо не известно, т.к эти значения уникальны и индивидуальны. Это те значения, которые выдает нам тот же GetCourse или AXL либо сервис, который требует подтверждения домена. В основном в эту категория я отношу все А-записи, а так же TXT-запись которая содержит подпись DKIM.

Редактируемая запись

К категории редактируемых записей я отношу TXT-записи SPF и частично к этой же категории относится _dmarc. Дело всё в том, что эту категорию я выделил по той причине, что в отличии от всех остальных, записи SPF и DMARC могут существовать не более одной для домена. И когда возникает задача подключить к существующему домену дополнительный сервис рассылок, то мы конечно же можем дописать еще одну MX-запись сдвинув приоритеты, мы можем дописать отдельный DKIM (в этом случае у нас будут разные селекторы и записи между собой не конфликтуют), а вот SPF должна быть только одна. Но если оставить исходную запись, то сторонний сервис для рассылок работать не сможет. Некоторые, например SendPulse умеет считывать существующую SPF-запись, дописывает свои сервера к уже имеющимся в записи и просит просто заменить SPF в панели управления доменом. Но так делают не все сервисы, и временами нужно обновлять SPF вручную.

Аналогичная ситуация может случится и с DMARC. Для настройки почты в GetCourse очень желательно указать эту подпись в TXT-записи даже не смотря на то, что GetCourse явно эту подпись не требует и не генерирует. В то же время сервис рассылки может попросить вас изменить подпись DMARC и тоже самое попросит у вас и AXL при переезде с другой площадки.

Именно по указанным выше причинам я и отношу эти записи к отдельной категории.

Зачем нужны эти категории?

На самом деле идея разделения записей мне пришла в голову только с целью оптимизации времени на настройку домена для школы. Например тот же mail.ru не даст информацию об MX-записи пока не выполнишь верификацию домена. DMARC подпись некоторые сервисы вообще не выдают, а это весьма серьезно влияет на доставляемость писем. GetCourse не даст информацию о SPF и DKIM до тех пор пока на домене не будет внесена CNAME запись. А каждую такую запись необходимо внести, да и время обновления DNS иногда занимает 30-40 минут. И делать такие перерывы мне совершенно не хотелось бы. По этой причине я просто беру записи из своего статического списка и вношу их в панель управления домена. Через 10-15 минут все остальные данные уже готовы для получения. Такой подход на практике экономит от получаса до 2 часов моего времени.

Специфика работы с SPF и DMARC

Записи SPF и DMARC по сути работают в паре. Задача SPF регулировать, каким серверам разрешено отправлять письма от имени домена, а DMARC определяет, каким образом почтовые сервера будут вести себя с письмами которые попали под категорию спама.

Одна из сложностей, которая возникает при работе с этими сервисами, это, что допустимо наличие только одной записи DMARC и одной записи SPF, при том, что подписей (записей DKIM) на одном домене может быть произвольное количество.

В сети, одна из наиболее полных и подробных статей по DMARC можно прочитать здесь HowTo: DMARC. Если вам необходимо или интересно более подробно о возможных настройках, можно взглянуть в статье. Однако для минимального использования очень глубоко погружаться не нужно. Одним из самых оптимальных вариантов конфигурации DMARC является вариант

Это правило указывает на то, что 30% сообщений, которые приходят от вашего домена, но не проходят проверки DMARC, их нужно помещать в карантин. Тогда 30% писем будут проверяться на DKIM и отправляться в «Спам», если он не соответствует.К остальным сообщениям карантин применяться не будет.

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

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

Чтобы объединить несколько SPF-записей в одну, вам нужно выполнить следующие действия:

1. Соберите все имеющиеся SPF-записи для вашего домена.
2. Определите все разрешенные серверы, которые должны отправлять электронную почту от имени вашего домена.
3. Составьте единственную SPF-запись, которая включает в себя все разрешенные серверы, установленные в шаге 2, и добавьте ее в DNS-запись вашего домена.
4. Удалите все предыдущие SPF-записи для вашего домена.

Например, если у вас есть две SPF-записи для вашего домена:

то вы можете объединить их в одну запись следующим образом:

После того, как вы объединили свои SPF-записи в одну запись, убедитесь, что она правильно отображается в DNS-записи вашего домена, и что она содержит только разрешенные серверы. Директивы v=spf1 a mx и следующий за ними include: spf.domain.tld обязательно должны остаться, остальные же допустимые сервера следует перечислить используя директиву include.

Прежде чем вносить измененную запись в панели управления доменом обязательно проверьте отредактированный вами SPF

Домен в форме на сайте можете указать любой, а можно и домен школы, здесь уже на ваш выбор.

Если в результате вашей проверки на экране будет отображено нечто похожее на скриншот выше, значит вы успешно объединили SPF-записи и теперь можно вносить изменения. После того, как вы применили все изменения касающиеся «почтовых» записей, примерно через 2-3 часа настоятельно рекомендую сделать рассылку на один из сервисов-тестировщиков email.

Обязательно отправьте пробное письмо с обычным текстом вроде «Привет», не нужно навешивать оформления, писать длинный текст или использовать картинки. Так как проверяющие сервисы могут занизить рейтинг письма за содержание, и объективной картинки по настройке вы так и не увидите.

Если все проверки прошли успешно и всё настроено верно, рейтинг вашего письма должен быть не ниже 9 балов на сервисе mail-tester и не менее 18 пройденных тестов на smtp.bz Учитывайте, что для рассылок GetCourse максимальный рейтинг 9.5. Также обращаю ваше внимание на то, что если рассылка ведется от имени домена купленного менее чем за 2 недели до теста — рейтинг будет занижен. Так же рейтинг будет занижен, если отправка идет от доменных имен с плохой спам-репутацией. Так что, прежде чем делать окончательные выводы я рекомендую вчитываться в те ошибки, которые выявили эти сервисы и гуглить каждую из них.

Вместо заключения

Вот такая вышла статья, в ней я постарался изложить максимум информации и тонкостей касательно настройки домена для онлайн школы безотносительно того, о какой конкретной школе идет речь. В целом подключение домена подчиняется абсолютно одним и тем же правилам и законам, и на GetCourse и на AXL хоть на Антитренингах. Напоследок напомню, что обязательно нужно включать протокол https в настройках ваших сайтов и школ. Где-то такая настройка автоматическая, где-то это необходимо делать вручную. Пример корректной настройки для Tilda.

Аналогичная настройка https для GetCourse на скриншотах ниже.

И в меню «Настройки https» обязательно поставьте принудительный редирект на https.

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

Ну вот теперь уже точно всё. Если у вас остались вопросы или замечания — пишите мне в Telegram