Перенос сайта на другой сервер: как прописать dns домена
Содержание:
- Примеры настроек
- Яндекс.Коннект
- Ключевые характеристики DNS
- Типы записей DNS[4]
- Как работают DNS-серверы
- View — ограничение видимости зон
- Способы проверки DNS-записей домена
- Основной синтаксис
- Уровни DNS
- Секция ответа
- Расширения
- Как настроить DNS
- Типы DNS-записей
- Какие бывают ресурсные записи для домена?
- Записи DNS
- Классификация
- Вывод
Примеры настроек
Настройка SPF для «Почты для доменов» от Mail.Ru
Если вы отправляете почту только с серверов Mail.Ru:
v=spf1 redirect=_spf.mail.ru
Если вы отправляете почту так же и с других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):
v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.mail.ru ~all
Настройка SPF для Яндекс.Почты
При использовании только серверов Яндекса:
v=spf1 redirect=_spf.yandex.net
При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):
v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.yandex.net ~all
Настройка SPF для Google
При использовании только серверов Google:
v=spf1 include:_spf.google.com ~all
При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):
v=spf1 ip4:IP1 ip4:IP2 include:_spf.google.com ~all
Другие примеры
v=spf1 a ip4:176.57.223.12 include:domain2.com -all
— принимать почту с IP-адресов, соответствующих A-записям текущего домена, с IP-адреса 176.57.223.12 и серверов, указанных в SPF-записи domain2.com; прочие письма отклонять.
v=spf1 mx/24 a:domain2.com/24 ~all
— принимать почту из подсети, в которую входят MX-серверы текущего домена, и из подсети, в которую входят A-записи домена domain2.com; прочие письма отклонять.
v=spf1 a ip4:176.57.223.12 include:domain2.com -all
— принимать почту с A-записи текущего домена, IP-адреса 176.57.223.12, а также с серверов, указанных в SPF домена domain2.com.
Яндекс.Коннект
Для использования почты на домене необходимо произвести следующие настройки.
Подключение домена
2. Выберите способ подтверждения домена.Наиболее простым способом является подтверждение через DNS-запись. Скопируйте предложенное значение TXT-записи.
4. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите «Настройки DNS».
5. Нажмите на «Добавить DNS-запись», выберите «TXT» и укажите запись, полученную в Яндекс.Коннекте.
6. Сохраните изменения с помощью кнопки «Добавить». Как правило, требуется 10-15 минут, чтобы изменения вступили в силу.
7. После того, как изменения будут применены, нажмите «Запустить проверку» в Яндекс.Коннекте. Дождитесь подтверждения домена (как правило, выполняется очень быстро).
8. Настройте для домена DNS-записи по инструкциям ниже.
MX-запись
2. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите «Настройки DNS».
3. Удалите имеющиеся MX-записи.
4. Нажмите на «Добавить DNS-запись», выберите «MX» и в открывшемся окне отметьте пункт «Яндекс.Почта»:
5. Сохраните изменения с помощью кнопки «Добавить».
6. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
SPF-запись
2. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите «Настройки DNS».
3. Удалите существующие TXT-записи (предварительно скопируйте значение SPF-записи, если вы планируете отправлять почту также и с указанных в ней серверов).
4. Нажмите на «Добавить DNS-запись», выберите «TXT» и в открывшемся окне разместите следующее значение:
v=spf1 redirect=_spf.yandex.net
5. Если вы хотите отправлять письма не только с серверов Яндекса, укажите дополнительные серверы в таком формате:
v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.yandex.net ~all
где IP1, IP2, IP3 — IP-адреса дополнительных серверов.
6. Сохраните изменения с помощью кнопки «Добавить».
7. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
DKIM-подпись
1. Получите TXT-запись с публичным ключом в Яндекс.Коннекте:
- Перейдите на вкладку «DKIM-подписи».
- Скопируйте DKIM-подпись для нужного домена.
3. Найдите домен, для которого планируется внести изменения, кликните на значок шестеренки и выберите «Настройки DNS».
4. Нажмите на «Добавить DNS-запись» и выберите «TXT».
5. В окне настроек:
- в поле «Хост» укажите «mail._domainkey»;
- в поле «Значение» внесите параметры DKIM, полученные на шаге 1.
6. Сохраните изменения с помощью кнопки «Добавить».
7. Подождите, пока изменения в DNS вступят в силу. Этот процесс может занимать до 72 часов.
Ключевые характеристики DNS
DNS обладает следующими характеристиками:
- Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
- Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
- Кэширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
- Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
- Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
DNS важна для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.
Типы записей DNS[4]
Тип DNS-записи | Сокращение | Определение |
---|---|---|
Запись | A | Host Record for IPv4; определяет IP-адрес узла. |
Quad-A Record | AAAAA | Host Record for IPv6; определяет IP-адрес узла. |
Alias Record | CName | Функции перенаправления доменного имени на другой домен. |
Почтовый обменник Запись | MX | Определяет имя хоста для почтового сервера. |
Регистрация местоположения обслуживания | СРВ | Позволяет пользователям найти конкретную услугу. |
Запись на сервере имен Запись | НАЦИОНАЛЬНЫЙ КООРДИНАТОР | Направить пользователей на другие DNS-серверы |
Начало полномочий | ГОМОСЕКСУАЛИСТ | Содержит данные в DNS-зоне, предоставляющие административную информацию об этой зоне и другие записи DNS. |
Обратный просмотр Запись указателя мыши | СУУ | Позволяет пользователям выполнять обратный поиск там, где они предоставляют IP-адрес и извлекать имя хоста. |
Запись сертификата | CERT | Записи, касающиеся сертификатов и соответствующих списков отзывов сертификатов (CRL) |
Запись текста | ТЕХАС | Содержит читабельную текстовую информацию, которая может быть полезна для других людей, имеющих доступ к серверу. |
Как работают DNS-серверы
Рассмотрим поэтапно функционирование приложений, предназначенных для ответа на DNS-запросы:
- Браузер получает запрос от пользователя и направляет его DNS-серверу сети, который ищет совпадение доменного имени и сетевого адреса. Если ответ обнаружен, то страница сайта загружается сразу. В противном случае запрос будет отправлен серверу более высокого уровня или корневому.
- Корневой сервер направляет запрос серверу первого уровня, который в свою очередь передает его серверу второго уровня. Это движение продолжается до тех пор, пока не будет найдено совпадение имени и IP-адреса.
- Браузер получает ответ на свой запрос, направляет его к хостингу, и страница открывается.
Также возможна обратная процедура — поиск имени домена в DNS-сервере, соответствующего запрашиваемому IP-адресу. К примеру, это происходит в случае работы с сервером электронной почты.
View — ограничение видимости зон
Использование ограничения видимости позволяет применять различные опции по отношению к различным клиентам.
Опция вступают в действие в зависимости от ip адреса клиента — источника запроса.
Это позволяет использовать разные данные по одной и той-же зоне для разных клиентов.
Для внутренних клиентов мы должны разрешить рекурсивные запросы, для внешних — запретить.
В конфигурационном файле необходимо запретить рекурсию по-умолчанию (закомментировать).
На рубеже версии 9.5 поведение этого флажка меняется, на новых версиях надо оставить строчку включенной.
На версии 9.8.4 поведение такое:
- allow-recursion { any; }; view recusion yes; — разрешает рекурсию. (на нерекурсивный запрос дает хинт root-list);
- allow-recursion { any; }; view recusion no; — запрещает рекурсию молча (no answer);
- allow-recursion { none; }; view recusion yes|no; — запрещает рекурсию (REFUSED);
- закомментарен allow-recursion { none; }; view recusion yes|no; — запрещает рекурсию (REFUSED);
Т.е. для нас актуальны первые два варианта.
Выключить проверку DNSSEC. Требуется если мы в лабораторных условиях сквоттим TLD.
Конфигурация зон /etc/bind/named.conf
Обратите внимание: при запрете рекурсии внутри view перестанут работать CNAME на посторонние зоны.
При дублировании зон в областях видимости не забывайте прописать после NS записи еще и A-запись для вашего dns-сервера.
Внешние клиенты тоже должны знать ip адрес вашего NS.
Пример:
Если этого не сделать, в ответ на запрос к любому имени в зоне сервер будет отвечать ошибкой «ServerFail»:
Способы проверки DNS-записей домена
А зачем проверять DNS-записи? Ошибки, допущенные в ресурсных записях, приводят к нарушению работоспособности сайта. Даже после внесения всех правок полноценный доступ к сайту появится не сразу, так как изменения, внесенные в ресурсные записи, вступают в силу в течение 72 часов.
Есть множество способов, позволяющих проверить DNS-записи. Можно воспользоваться как специальными командами в системе, так и онлайн-сервисами.
Встроенные в систему службы
nslookup. Действует на ОС Windows и Linux. С помощью этой утилиты можно точно узнать информацию об IP-адресе, а еще о настройке всех ресурсных записей. Утилита запускается через «Командную строку» в Windows и «Терминал» в Linux. Вводить команду нужно одинаково в обоих случаях и примерно вот так:
nslookup -type=тип_записи site.com
host. Эта утилита используется в ОС Linux. Она есть в стандартном пакете командной строки «Терминал». С ее помощью можно проверить все виды запросов к DNS-серверу. Вводится команда вот таким образом:
host site.com
Можно перед доменным именем добавить опцию -t и указать тип записи для получения более подробного поиска. Выглядеть это будет примерно вот так:
host -t A site.com host -t MX site.com
Проверка DNS-записей с помощью сторонних сервисов
Еще можно воспользоваться бесплатными онлайн-сервисами для проверки DNS записей.
2whois.ru – известный сайт, с помощью которого можно узнать DNS-записи самого разного типа. Просто нужно указать домен в соответствующей строке и начать проверку.
dns.nettools.ru – очень удобный сервис, в котором можно получить информацию не только о ресурсных записях, но и возможности выполнения рекурсивных запросов, а также проверки сервера на возможность выгрузки данных.
functions-online.com – здесь тоже очень удобно проверять настройки DNS-записей самых различных типов. Сервис дает полную информацию, а еще предоставляет PHP документацию на разных языках.
mail-tester.com – сервис поможет определить, попадет ли письмо, отправленное с вашего сервера, в «Спам». Еще здесь можно определить ошибки в ссылках и проверить качество форматирования писем.
xseo.in/dns – на данном ресурсе есть раздел для проверки самых разных DNS записей.
digwebinterface.com – навороченный онлайн-сервис с очень простым исполнением. С первого взгляда может показаться сложным, но на самом деле справиться с ним может даже новичок.
Основной синтаксис
Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1.
Далее указываются параметры (механизмы). Чаще всего используются следующие: all, ip4, ip6, a, mx, include, redirect. Также существуют, но используются значительно реже: ptr, exists, exp. Они все будут рассмотрены ниже.
Помимо механизмов используются префиксы (определители):
- «+» — Pass, принимать почту. Прописывать этот параметр необязательно, он установлен по умолчанию (т.е. значения «+a +mx» и «a mx» — идентичны).
- «-» — Fail, отклонять почту.
- «~» — SoftFail, «мягко» отклонять (принимать почту, но помещать ее в «Спам»).
- «?» — нейтрально (обрабатывать как обычное письмо).
all
Параметр «all» подразумевает все серверы, не упомянутые отдельно в SPF-записи. «All» задает обработку полученных с них писем и указывается в конце записи.
Например:
v=spf1 ip4:176.57.223.0/24 ~all
— принимать почту только из подсети 176.57.223.0/24; письма с других адресов должны быть помечены как спам.
v=spf1 a -all
— принимать почту только с A-записи домена; письма с других адресов должны отвергаться.
v=spf1 -all
— отвергать все письма с домена. Такую настройку можно использовать для доменов, с которых не должна отправляться вообще никакая почта.
В последующих примерах мы не будем дополнительно комментировать значения параметров ~all и -all в SPF-записях.
ip4 / ip6
Используется для указания конкретных адресов и подсетей, из которых могут отправляться письма. Синтаксис для IPv4 и IPv6 идентичен.
v=spf1 ip4:176.57.223.0/24 ~all
— принимать почту из подсети 176.57.223.0/24.
v=spf1 ip6:2001:db8::10 ~all
— принимать почту с IPv6-адреса 2001:db8::10.
a
IP отправителя проверяется на соответствие A-записи домена.
v=spf1 a ~all
— принимать почту с A-записи текущего домена.
v=spf1 a:sub.domain.com ~all
— принимать почту с A-записи домена sub.domain.com.
mx
IP отправителя проверяется на соответствие IP-адресам серверов, указанных в MX-записях домена. На текущий день для многих современных сервисов эта директива уже не так важна, так как серверы входящей и исходящей почты зачастую имеют разные IP.
v=spf1 mx mx:sub.domain.com -all
— принимать почту с MX-серверов текущего домена и домена sub.domain.com.
v=spf1 mx/24 -all
— принимать почту из подсети, в которую входят MX-серверы текущего домена.
include
Позволяет учитывать в SPF-записи настройки SPF другого домена.
v=spf1 a include:other-domain.com -all
— принимать почту с A-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com.
При такой настройке проверяется SPF домена other-domain.com; если это, допустим, «v=spf1 a -all», то далее IP отправителя проверяется на соответствие A-записи домена other-domain.com.
redirect
Технически, redirect является модификатором, а не механизмом. Он выполняет одну основную функцию: сообщает, что необходимо применять настройки SPF другого домена.
v=spf1 redirect=other-domain.com
— почта должна приниматься или отклоняться согласно настройкам домена other-domain.com.
Уровни DNS
Дерево DNS принято делить по уровням: первый, второй, третий и так далее. При этом начинается система с единственного корневого домена (нулевой уровень). Интересно, что про существование корневого домена сейчас помнят только специалисты, благодаря тому, что современная DNS позволяет не указывать этот домен в адресной строке. Впрочем, его можно и указать. Адресная строка с указанием корневого домена выглядит, например, так: «site.test.ru.» – здесь корневой домен отделен последней, крайней справа, точкой.
Как несложно догадаться, адреса с использованием DNS записываются в виде последовательности, отражающей иерархию имен. Чем «выше» уровень домена, тем правее он записывается в строке адреса. Разделяются домены точками. Разберем, например, строку www.site.nic.ru. Здесь домен www – это домен четвертого уровня, а другие упомянутые в этой строке домены расположены в домене первого уровня RU. Например, site.nic.ru – это домен третьего уровня
Очень важно понимать, что привычный адрес веб-сайта, скажем, www.test.ru, обозначает домен третьего уровня (www), расположенный внутри домена второго уровня test.ru.
Секция ответа
0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
C0 0C - NAME 00 01 - TYPE 00 01 - CLASS 00 00 18 4C - TTL 00 04 - RDLENGTH = 4 байта 5D B8 D8 22 - RDDATA
-
: Этой URL, чей IP-адрес содержится в данном ответе. Он указан в сжатом формате:
0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1| OFFSET | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Первые два бита установлены в значение 1, а следующие 14 содержат беззнаковое целое, которое соответствует смещению байт от начала сообщения до первого упоминания этого имени.
В данном случае смещение составляет c0 0c или двоичном формате:1100 0000 0000 1100
То есть смещение байт составляет 12. Если мы отсчитаем байты в сообщении, то можем найти, что оно указывает на значение 07 в начале имени example.com.
- и : Здесь используется та же схема имён, что и в секциях и выше, и такие же значения.
- : 32-битное беззнаковое целое, которое определяет время жизни этого пакета с ответом, в секундах. До истечения этого интервала результат можно закешировать. После истечения его следует забраковать.
- : Длина в байтах последующей секции . В данном случае её длина 4.
- : Те данные, которые мы искали! Эти четыре байта содержат четыре сегмента нашего IP-адреса: 93.184.216.34.
Расширения
- Составить запрос для произвольного доменного имени
- Запрос на другой тип записи
- Отправить запрос с отключенной рекурсией
- Отправить запрос с доменным именем, которое не зарегистрировано
Шестнадцатеричные
Десятичный | Hex | Двоичный | Десятичный | Hex | Двоичный |
---|---|---|---|---|---|
0000 | 8 | 8 | 1000 | ||
1 | 1 | 0001 | 9 | 9 | 1001 |
2 | 2 | 0010 | 10 | A | 1010 |
3 | 3 | 0011 | 11 | B | 1011 |
4 | 4 | 0100 | 12 | C | 1100 |
5 | 5 | 0101 | 13 | D | 1101 |
6 | 6 | 0110 | 14 | E | 1110 |
7 | 7 | 0111 | 15 | F | 1111 |
Как настроить DNS
Мы выяснили, где меняются ресурсные записи. Следующим шагом нужно войти в личный кабинет провайдера, чтобы изменить DNS. Дальнейшие действия зависят от провайдера, рассмотрим 2 самых распространенных варианта.
Если домен делегирован на Яндекс.Коннект
NS-записи такого вида в кабинете регистратора домена говорят о том, домен делегирован на Яндекс.Коннект, т.е. DNS-записи хранятся и редактируются в аккаунте Яндекса в настройках сервиса Вебмастер. Самое сложное в этом случае — найти доступы от аккаунта в Яндексе (вида @yandex.ru), под которым домен был заведен в Коннекте.
Чтобы изменить DNS, нужно кликнуть на «Управление DNS» соответствующего домена:
DNS-записи здесь уже заполнены, нужно только указать новый IP-адрес для записи типа А, которая связывает IP с доменным именем:
Готово! Обновление DNS-записей домена происходит в течение 72 часов, но по нашему опыту у некоторых провайдеров сайт начинает открываться уже через пару часов.
Если домен делегирован на хостинг
В личном кабинете регистратора домена можно также встретить NS-записи другого вида:
Конкретно в этом случае они означают, что домен делегирован на хостинг firstvds.ru, значит, и DNS-записи хранятся там. Дальнейшие действия зависят от того, куда переносим сайт.
Перенос сайта на другой сервер того же хостера
В этом случае в панели управления следует найти место, где меняются ресурсные записи домена, и в записи типа A указать IP-адрес нового сервера. Менять остальные DNS-записи не требуется.
Перенос сайта на другой хостинг
Если на прежнем сервере кроме этого сайта больше ничего не размещено, возникает необходимость переноса ресурсных записей на новый хостинг. Данный процесс осуществляется в несколько шагов:
Шаг 1: Перенос DNS на другой сервер
В Личном кабинете нового хостера необходимо найти место, где прописываются DNS, и прописать такие же записи, как у прежнего хостера, за исключением записи типа A — здесь нужно будет указать IP-адрес нового сервера.
Шаг 2: Проверка MX-записей домена
При переносе ресурсных записей существует опасность неправильной настройки MX-записей, которые сообщают различным почтовым программам о том, где находится нужный почтовый сервер. Если не перенести MX-записи с прежнего сервера или заполнить их некорректно, владелец сайта может остаться без почты на домене на долгий срок — он сможет отправлять письма, но входящие получать не будет. При этом отправитель письма на почтовый ящик на домене после отправки получит следующее уведомление:
Если в течение трех суток MX-записи не будут настроены правильным образом, то неполученные письма потеряются навсегда, при этом отправитель получит уведомление о том, что письмо не доставлено.
Если в указанный срок проблема все же будет устранена, то входящие письма не потеряются, а придут позже, когда DNS-серверы в интернете обменяются данными о новых DNS-записях. Обновление DNS-записей занимает от 2 до 72 часов.
Шаг 3: Настройка NS-записей
После настройки ресурсных записей необходимо указать NS-записи нового хостера в личном кабинете регистратора домена — перенаправить домен на новый хостинг. Узнать, как должны выглядеть NS-записи для нового хостинга можно в справочных материалах, который предоставляет хостер при покупке тарифа, либо обратившись в службу технической поддержки хостинга. Стоит быть особенно внимательными — при неправильном заполнении NS-записей домена сайт не заработает при обновлении DNS-серверов.
Выше мы рассмотрели ситуацию, когда DNS-записи редактируются на стороне хостера, и на прежнем сервере кроме переносимого сайта больше ничего не размещено. Существуют и другие ситуации:
- Владелец сайта хранит на прежнем хостинге несколько сайтов.
В этом случае переносить DNS-записи и перенаправлять NS-сервера домена в панели управления доменом на другой хостинг не обязательно — они могут храниться в прежнем месте. Необходимо только изменить записи типа A, указав IP-адрес нового сервера.
NS-записи и DNS-записи хранятся в одном месте — в панели управления доменом.
Так случилось с нашим клиентом — домен его сайта куплен через провайдера Majordomo, который кроме хостинга еще предоставляет услугу регистрации домена. У данного провайдера NS-записи и DNS хранятся и редактируются в одном месте. В этом случае так же не требуется правка NS-записей и перенос DNS в другое место, достаточно в записи типа А указать новый IP-адрес.
Типы DNS-записей
Функции ресурсных записей – это не только хранение, передача информации и привязка к IP адресу. Они также помогают настроить обработку запросов, перенаправляют их на другие серверы. Вот несколько наиболее важных типов DNS-записей:
- A – адресная запись, которая отвечает за привязку доменного имени к определенному IP-адресу по протоколу IPv4.
- AAAA – аналогична предыдущей, только действительна на основе интернет-протокола IPv6.
- CNAME – данный тип записи указывает на каноническое имя для псевдонима. С ее помощью к одному поддомену привязываются все ресурсные записи домена первого уровня.
- DKIM-подпись – подтверждает подлинность отправителя электронного письма. Именно эта ресурсная запись добавляет в сообщение цифровую подпись. Тем самым снижается вероятность попадания письма в папку «Спам».
- MX – регистрирует почтовые серверы, используя при этом протокол SMTP. Отвечает за доставку электронного письма на указанный сервер.
- NS – указывает на DNS-серверы, которые обслуживают домен. Чуть ли не одна из самых важных записей, без которой функционирование домена дало бы сбой.
- PTR – действует обратно записям A и AAAA, то есть показывает соответствие IP-адреса и доменного имени. Многие почтовые серверы во время фильтрации писем проверяют ее наличие.
- SOA – используется для указания на новую зону и авторитетность указанной в ней информации.
- SPF – защищает домен от подделки, показывает список доверенных серверов, с которых отправляются электронные письма. Это нужно для того, чтобы предотвратить рассылку спама от вашего доменного имени.
- SRV – хранит данные о местоположении серверов, обеспечивающих работу тех или иных служб.
- TXT – содержит общую вспомогательную информацию о домене, используется для указания SPF-записей, подтверждения прав собственности, обеспечения безопасности электронной почты и так далее.
Какие бывают ресурсные записи для домена?
Для того, чтобы настроить на своем домене сайт, почту или другие сервисы, потребуется в зоне домена указать соответствующие сервисам ресурсные записи.
Настройка ресурсных записей выполняется либо хостинг-провайдером автоматически, при создании сайта или почты в панели управления хостингом, либо администратором домена вручную с помощью специального редактора.
Базовые типы записей, с которыми работают администраторы и владельцы сайтов:
- NS-запись — главный тип, определяющий адреса DNS-серверов, обслуживающих домен.
- A-запись — привязывает доменное имя на один IP-адрес, используя протокол IPv4. Возможно использование более одного IP-адреса. Тогда добавляют вторую A-запись c другим IP-адресом. Если есть необходимость указания нескольких имен для одного IP, как правило, используют CNAME-запись для формирования псевдонимов (алиасов).
- AAAA — тип записи, аналогичный предыдущей, но с IPv6-адресами.
- CNAME — указывает, что данный домен выполняет функции псевдонима (алиаса) другого домена. Для псевдонима записи других типов не вносятся.
- MX-запись — указывает имя сервера, ответственного за прием почты для домена. В зоне домена может быть несколько MX-записей с разными приоритетами.
- TXT-запись — используется для хранения произвольной информации в DNS. Запись может использоваться для подтверждения владения доменом в р различных сервисах.
- SOA-запись — содержит служебную информацию: доменное имя, время последнего обновления зоны домена, адрес администратора зоны, настройки временных параметров и другую информацию.
Корректность заполнения ресурсных записей важна для успешного делегирования домена и дальнейшего функционирования службы name-серверов. Главное правило оформления NS-записей — не забывать ставить точку после имени. В противном случае возможны ошибки и служба DNS не сможет направить запрос по правильному адресу.
Записи DNS
Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:
- имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
- тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
- класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети,
- TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
- длина поля данных (RDLEN),
- поле данных (RDATA), формат и содержание которого зависит от типа записи.
Наиболее важные типы DNS-записей:
- Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
- Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
- Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
- Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
- Запись NS (name server) указывает на DNS-сервер для данного домена.
- Запись PTR (point to reverse) или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
- Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
- SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.
Интернациональные доменные имена
Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.
Классификация
Основные домены
-
Общие домены верхнего уровня (англ. generic top-level domain — gTLD):
- Неспонсируемые (основные) домены верхнего уровня.
- Спонсируемые домены верхнего уровня (sTLD).
- Домен верхнего уровня для инфраструктуры интернета.
- Зарезервированные домены верхнего уровня.
- Псевдо-домены верхнего уровня.
-
Национальные домены верхнего уровня (англ. country code top-level domain — ccTLD):
- 2-буквенный код страны (стандарт ISO 3166-1)
- Домены страны на её языке (интернационализованный домен страны) (англ. IDN ccTLD).
Общеупотребительные псевдодомены
Эти домены не присутствовали в адресном пространстве DNS, но они общеупотребимы при пересылке почты из Интернета в сети с другим способом адресации. Для обработки писем, отправляемых на адреса в этом домене, почтовое программное обеспечение на конкретной машине, через которую отправляется почта, должно быть настроено соответствующим образом.
- .uucp — для гейтования на машины, доступные при помощи UUCP.
- .bitnet — для отправки почты в сеть BITNET.
- .fidonet — для отправки почты в сеть Фидонет. В настоящее время, в связи с изменением общепринятой практики маршрутизации между сетями Интернет и Фидонет, вместо этого псевдодомена обычно используется домен .fidonet.org.
- ряд старых систем также использует домен верхнего уровня .local для адресов, применяемых в пределах одной машины или локальной компьютерной сети. Для адресации текущего компьютера также достаточно часто применяется адрес .localdomain.
Устаревшие и неиспользуемые домены
- .nato — структуры международной организации НАТО — в настоящее время не используется, по крайней мере, в публично доступной части сети Интернет, откуда был удалён в июле 1996 года.
- .web — домен, выделенный IANA для использования частным коммерческим регистратором Image Online Design. В связи с протестами общественности корневые серверы этого домена так и не были подключены к общей системе DNS. В настоящее время они продолжают функционировать, а на сайте регистратора находится сообщение о том, что он якобы проходит процедуру регистрации этого домена в ICANN.
- .csnet — домен, предназначенный для связи с Computer Science Network — университетской и научной почтовой сетью в США. Перестал использоваться, по всей видимости, после объединения CSNET и BITNET, произошедшего в 1988 году.
- .ddn — домен верхнего уровня, предназначенный для использования в американской оборонной сети Defence Data Network. Был запланирован, но так и не реализован.
Альтернативные и дополнительные домены верхнего уровня
- См. также: Альтернативные корневые серверы DNS
Теоретически кто угодно может установить и начать использовать свои собственные корневые серверы DNS. На практике в Интернет периодически появляются различные группы лиц и организации, которые открывают для публичного использования альтернативные корневые серверы DNS. Как правило, эти системы дополняют общепринятый набор доменов некоторым количеством новых доменов первого уровня, иногда — дополняют техническую реализацию. Например, до того, как DNS была расширена для возможности использовать в доменных именах символы национальных алфавитов, было предпринято несколько попыток создать дополнительные системы DNS, с доменными именами, в том числе первого уровня, содержащими символы того или иного национального алфавита, такие как русский домен я.ру. Эти попытки не получили широкого распространения, однако ряд таких проектов продолжает существовать и до сих пор.
Постольку, ICANN традиционно игнорирует альтернативные проекты, собственная деятельность этой организации по выдаче новых доменов верхнего уровня в своё время привела к конфликту вокруг домена .biz, на администрирование которого уже имелись два «исторических претендента». В результате этого ряд альтернативных систем DNS отказался распознавать домены, зарегистрированные в варианте ICANN .biz и полная совместимость их адресного пространства с DNS ICANN была потеряна.
Дополнительные домены верхнего уровня могут использоваться специализированным программным обеспечением, как правило — в пределах одного компьютера, для перехвата и последующей обработки части обращений к Интернет. Например, домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к , а домен .i2p -программным обеспечением анонимной сети I2P.
Вывод
DNS-сервер хранит информацию о соответствии домена IP-адресу, а также содержит сведения об остальных ресурсных записях.
Распределенная система доменных имен была создана в начале 1980-х годов. До настоящего времени она обеспечивает взаимодействие с адресным пространством всемирной паутины. Вместе с тем технологии DNS регулярно совершенствуются. Например, в 2010 году в России был внедрен национальный кириллический домен первого уровня .рф.
Значительное внимание уделяется усилению безопасности системы и снижению чувствительности к перебоям в работе. В наши дни интернет является существенной частью жизни, поэтому стихийные бедствия, перепады напряжения в сети и отключение электроэнергии не должны влиять на его производительность
Вы можете получить бесплатно первичные и вторичные DNS-серверы с базовой функциональностью при покупке веб-хостинга для сайта. Либо разместить DNS на собственном сервере. О том, как выбрать сервер такого формата, подробно рассказывается в статье «Как выбрать DNS-сервер».