Перенос сайта на другой сервер: как прописать 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-запросы:

  1. Браузер получает запрос от пользователя и направляет его DNS-серверу сети, который ищет совпадение доменного имени и сетевого адреса. Если ответ обнаружен, то страница сайта загружается сразу. В противном случае запрос будет отправлен серверу более высокого уровня или корневому.
  2. Корневой сервер направляет запрос серверу первого уровня, который в свою очередь передает его серверу второго уровня. Это движение продолжается до тех пор, пока не будет найдено совпадение имени и IP-адреса.
  3. Браузер получает ответ на свой запрос, направляет его к хостингу, и страница открывается.

Также возможна обратная процедура — поиск имени домена в 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-записей:

  1. A – адресная запись, которая отвечает за привязку доменного имени к определенному IP-адресу по протоколу IPv4.
  2. AAAA – аналогична предыдущей, только действительна на основе интернет-протокола IPv6.
  3. CNAME – данный тип записи указывает на каноническое имя для псевдонима. С ее помощью к одному поддомену привязываются все ресурсные записи домена первого уровня.
  4. DKIM-подпись – подтверждает подлинность отправителя электронного письма. Именно эта ресурсная запись добавляет в сообщение цифровую подпись. Тем самым снижается вероятность попадания письма в папку «Спам».
  5. MX – регистрирует почтовые серверы, используя при этом протокол SMTP. Отвечает за доставку электронного письма на указанный сервер.
  6. NS – указывает на DNS-серверы, которые обслуживают домен. Чуть ли не одна из самых важных записей, без которой функционирование домена дало бы сбой.
  7. PTR – действует обратно записям A и AAAA, то есть показывает соответствие IP-адреса и доменного имени. Многие почтовые серверы во время фильтрации писем проверяют ее наличие.
  8. SOA – используется для указания на новую зону и авторитетность указанной в ней информации.
  9. SPF – защищает домен от подделки, показывает список доверенных серверов, с которых отправляются электронные письма. Это нужно для того, чтобы предотвратить рассылку спама от вашего доменного имени.
  10. SRV – хранит данные о местоположении серверов, обеспечивающих работу тех или иных служб.
  11. 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-сервер».

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector