- Как настроить параметры конфигурации DNS веб-сайта
- Что такое настройки DNS сайта и как их настроить?
- Предотвращение ошибок конфигурации DNS
- Настройка параметров конфигурации DNS
- Как прописать DNS для домена в Личном кабинете REG.RU
- Держи домен близко, а хостинг еще ближе!
- Как настроить DNS-серверы для домена
- Не получается прописать DNS, что делать
- Что дальше
- Записки IT специалиста
- Создаем свой сайт. Настройка DNS-зоны
- От теории к практике
Как настроить параметры конфигурации DNS веб-сайта
Это больше, чем просто посещение веб-сайта, чем просто ввести имя домена и нажать клавишу Enter. За кулисами скрываются и другие слои для защиты вашей конфиденциальности и безопасности во время серфинга в Интернете.
Интернет-запросы от браузеров не могут прочитать доменные имена. Вместо этого они понимают только числовые IP-адреса, зарегистрированные для этих доменов. Domain Name Server, или DNS, куда браузеры обращаются, чтобы получить правильный IP-адрес, связанный с доменом.
Параметры конфигурации DNS вашего сайта — это то, что позволяет посетителям по-прежнему получать доступ к вашему сайту даже после того, как вы перешли к новому хостинг-провайдеру.
Что такое настройки DNS сайта и как их настроить?
Для большинства людей доменные имена намного легче запомнить, чем последовательность цифр. Для серверов и компьютеров в Интернете верно обратное. DNS-сервер обрабатывает перевод, так что обе стороны счастливы.
Ваша домашняя сеть обычно полагается на DNS-сервер, предоставленный провайдером, для IP-адреса вашего собственного интернет-маршрутизатора. На самом деле вы можете изменить настройки IP-адреса вашего маршрутизатора, чтобы переключать DNS-серверы с автоматического (определяемого вашим провайдером) на общедоступные, такие как DNS 8.8.8.8 и 8.8.4.4 Google.
Настройки DNS веб-сайта немного отличаются от этого. Настройки конфигурации DNS сайта важны для владельцев сайта. Каждый раз, когда вы выбираете смену веб-хостов, вы меняете физический сервер, на котором находится сайт. Это также означает, что вы меняете IP-адреса.
Изменение параметров конфигурации DNS, чтобы всегда указывать людям, ищущим ваше доменное имя, на правильный IP-адрес, будет поддерживать работу сайта даже при переходе на новый хостинг.
Большинство владельцев веб-сайтов должны понимать, что если параметры DNS введены неправильно, весь веб-сайт может быть отключен на длительный период времени.
Имейте в виду, что изменения DNS не являются мгновенными, поэтому, если вы совершите ошибку, вполне вероятно, что никто не будет иметь доступа к сайту, пока ваше исправление не будет реплицировано на все DNS-серверы в Интернете. Даже после исправления ошибки исправление может занять до 72 часов.
Предотвращение ошибок конфигурации DNS
Во-первых, чтобы избежать ошибок, убедитесь, что у вас есть общее представление о том, что делают записи A , CNAME , NS , TXT и MX .
- A — Запись A также известна как запись адреса IPv4. Он используется для указания доменного имени на один или несколько IP-адресов. Если вы используете провайдера управляемого хостинга, такого как WordPress.com, а также используете его серверы имен, вам не понадобится запись A.
- CNAME — это запись канонического имени (CNAME). Если у вас уже есть запись A, вы не будете использовать CNAME. Запись CNAME сообщает любому, кто посещает поддомен, также использовать те же записи DNS, что и другой домен или поддомен.
Подобные вещи удобны при запуске нескольких сервисов с одного IP-адреса. Записи CNAME работают только для поддоменов и всегда должны указывать на другой домен или поддомен, а не напрямую на IP-адрес.
- NS — Эти записи являются серверами имен. Без них ваш сайт не будет работать вообще. Обычно у вас будет по крайней мере две из этих записей в настройках конфигурации DNS. Если вы никогда не меняли свои, они, вероятно, выглядят очень общими, как ns1.name.com и ns2.name.com.
В NS записи хранятся в Top Level Domain сервера (TLD), для которых существует более 1000. Это ваши .com, .gov, .net, и другие, более общие. Запись NS полностью контролирует направление и перенаправление доменов.
- MX — это ваши записи Mail Exchange. Они используются для создания адресов электронной почты из домена. Записи MX будут указывать почтовым серверам принимать входящую почту для вашего домена и куда следует направлять полученные письма.
Хотя существует больше записей, с которыми вы, вероятно, столкнетесь, но эти наиболее важные из них вы должны знать.
Настройка параметров конфигурации DNS
Для этого урока мы будем использовать Hostinger в качестве нашего веб-хостинга. Войдите в свою учетную запись и перейдите в раздел Домены , а затем на вкладку Зона DNS .
Здесь вы найдете все свои записи DNS.
Чтобы изменить любую из этих записей, нажмите кнопку «Добавить +» , расположенную в правом нижнем углу любой из них.
Это действительно так просто. Чтобы лучше понять, на что вы смотрите и как их изменить, давайте воспользуемся записью А.
@ в вашей А-записи доменного имени указывает на IP адрес. Изменяя это, вы будете перенаправлять весь трафик, направляемый на ваше доменное имя, на IP-адрес, который вы вводите. При переходе на новый хост управления веб-сайтом, например, с WordPress на SquareSpace, вам придется изменить Точки на @ записи, используя IP-адрес, предоставленный SquareSpace.
При вводе имени хоста это можно сделать одним из двух способов:
Полное имя хоста, за которым следует точка — full.hostname.com или полный поддомен.
Допустим, вы хотите перенаправить ваш домен WordPress, чтобы он указывал на сервер домена Hostinger. Есть два способа сделать это. Первый и самый простой способ заключается в смене серверов имен у вашего регистратора доменных имен.
Причина, по которой этот метод рекомендуется, заключается в том, что ваша DNS-зона будет автоматически настроена в соответствии с IP-адресом хостинга. Этот способ также позволит вам передать управление настройками вашего домена в Hostinger hPanel.
- Вам нужно найти серверы имен в зоне DNS, которая находится в разделе NS.
- Затем войдите в панель управления вашего регистратора доменов. Если вы незнакомы или забыли название компании, вы можете использовать whois lookup.
- В их версии зоны DNS удалите все значения из полей сервера имен и введите серверы имен Hostinger.
- Затем сохраните изменения.
Этот метод может занять до 24 часов для полного распространения DNS. Второй способ более технический, так как вам нужно указать доменное имя с помощью записи A.
Вам нужно будет изменить IP-адрес, связанный с записями DNS. Это сохранит контроль вашего домена в регистраторе. Если вы точно знаете, что IP-адрес будет оставаться статическим, этот процесс не требуется.
Измените IP-адреса записи A и укажите имя вашего домена на Hostinger. В большинстве случаев для этого потребуются две записи A для домена — одна с поддоменом www, а другая без.
Например, если у вас есть домен с именем ilovecoffee.com, и вы хотите указать его как 212.1.212.65 в качестве его IP-адреса, вам нужно создать записи A, которые выглядят так:
Это может выглядеть иначе, чем у вашего регистратора. Просто заполните аналогичные значения, как показано на рисунке. Поля будут следующими: Имя / Хост, TTL и Точки на / Запись.
Среднее значение Time To Live (TTL) , составляет 86400 секунд, что составляет 24 часа. Когда дело доходит до того, что вы должны установить, посмотрите на другие записи. В этом случае наши настройки DNS показывают 14400, что составляет 4 часа. 4 часа в выпадающем меню Hostinger не существует, поэтому рекомендуется использовать среднее значение.
После завершения этого шага вы можете перейти к изменению записи MX для электронной почты. Конечно, этот шаг необходим только в том случае, если вы в настоящее время используете сервер электронной почты, предлагаемый вашим хостом.
Этот процесс прост.
- Перейдите к записи MX в зоне DNZ и запишите поле «Точки на».
- Возьмите этот адрес и замените запись MX пункта назначения вашего домена на адрес MX Hostinger.
Единственное отличающееся здесь поле от записи А — это Приоритет. Это поле определяет приоритет каждого вашего сервера. Наименьшее число представляет наивысший приоритет. Если у вас есть только один сервер, лучше всего поместить число от 0 до 5 в поле приоритета.
За дополнительной помощью и рекомендациями по настройке конфигурации DNS обращайтесь к своему веб-хосту. Многие вещи, включая доступ к настройкам DNS, могут различаться в зависимости от хост-провайдера. Воздерживаться от внесения серьезных изменений без получения помощи.
Как только вы освоитесь, внесение изменений в настройки конфигурации DNS может быть простым и безболезненным процессом.
Источник
Как прописать DNS для домена в Личном кабинете REG.RU
В статье мы расскажем, как указать или сменить DNS серверы для домена. Используйте инструкцию, если вы ещё не знаете Какие DNS-серверы прописать для домена.
Важно: чтобы изменения вступили в силу, DNS-серверам нужно обновиться. Обновление DNS-серверов занимает до 24 часов. Почему так происходит читайте в статье Что такое DNS простыми словами.
Держи домен близко, а хостинг еще ближе!
Ваш домен обслуживается в REG.RU, а хостинг — у другого провайдера? У нас есть для вас специальное предложение!
Перенесите сайт на обслуживание в REG.RU и получите промокод на 1 месяц использования виртуального хостинга или VPS.
Как настроить DNS-серверы для домена
Как изменить DNS-серверы для домена:
Нажмите на фильтр Домены и выберите нужный домен из списка:
Во вкладке «Управление» кликните по строке DNS-серверы и управление зоной или нажмите кнопку Изменить:
Затем кликните по области DNS-серверы или нажмите Изменить:
Во всплывающей шторке выберите DNS-серверы провайдера REG.RU или добавьте свои.
Варианты | Какие серверы выбрать |
---|---|
Вы хотите управлять зоной домена в Личном кабинете | ns1.reg.ru, ns2.reg.ru |
У вас заказан хостинг сайтов в REG.RU | ns1.hosting.reg.ru, ns2.hosting.reg.ru |
У вас заказан VPS или выделенный сервер | ns5.hosting.reg.ru, ns6.hosting.reg.ru |
У вас заказан сторонний хостинг (не в REG.RU) или вы хотите указать DNS-серверы на базе своего домена | Свой список DNS-серверов |
Вы не хотите делегировать свой домен (только для зон .RU, .SU, .PФ) | Не указывать DNS-серверы |
Информацию о различиях между DNS-серверами ns1.reg.ru/ns2.reg.ru и ns1.hosting.reg.ru/ns2.hosting.reg.ru читайте в статье.
Чтобы изменить DNS-серверы, кликните по нужному варианту. Например, вы решили сменить пару серверов ns1.reg.ru и ns2.reg.ru на хостинговые серверы. Для этого нажмите на строку ns1.hosting.reg.ru, ns2.hosting.reg.ru:
Как правильно прописать адрес DNS
Чтобы подключиться к сторонним сервисам или указать DNS-серверы на базе своего домена, выберите блок Свой список DNS-серверов:
Если вы хотите указать DNS-серверы на базе своего домена, введите имена серверов. В появившихся строках укажите IP-адреса серверов и нажмите Продолжить:
Если вы хотите подключиться к сторонним сервисам, введите соответствующие имена серверов и нажмите Продолжить:
Кликните Да, чтобы подтвердить изменение DNS-серверов:
Изменение DNS серверов
Готово. Изменения вступят в силу после обновления DNS-серверов. Этот процесс занимает в среднем до 24 часов. Теперь вы знаете, как прописать или поменять DNS для домена, чтобы ваш сайт работал исправно.
Не получается прописать DNS, что делать
При настройке DNS-серверов вы можете столкнуться с ошибкой «Неверное имя хоста DNS-сервера». Эта ошибка появляется в том случае, если вы добавили лишний пробел до или после имени DNS-сервера. Для устранения ошибки необходимо убрать лишние пробелы.
Что дальше
После обновления корневых DNS-серверов ваш домен будет отображаться в сети интернет.
Теперь можно приступать к настройке зоны доменного имени. Для дальнейшей работы не забудьте прописать IP-адрес для домена и настроить ресурсные записи.
Источник
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
- Главная
- Создаем свой сайт. Настройка DNS-зоны
Создаем свой сайт. Настройка DNS-зоны
Продолжая тему сайтостроения поговорим о таком важном аспекте, как работа системы доменных имен — DNS. С настройкой и расположением DNS-зоны связаны многие вопросы, касающиеся первоначального размещения, а также переноса сайтов между различными серверами и хостингами. Понимание принципов работы системы доменных имен позволяет с легкостью управлять собственными доменами и связанными с ними сайтами и прочими службами.
Что такое доменное имя? Для многих это синоним адреса сайта, например, www.interface31.ru. Набирая этот адрес вы твердо уверены, что попадете именно на этот сайт, а не куда-нибудь еще. В тоже время доменное имя может обозначать не только сайт, но и сервер электронной почты, обмена короткими сообщениями или иной другой интернет и сетевой сервис. Доменные имена входят в доменные зоны, которые расположены внутри друг друга в иерархическом порядке.
В общем понимании домен — это символьное имя, позволяющее однозначно адресовать автономную область имен в сети интернет. И не только адресовать, но и позволить любому клиенту быстро найти необходимый узел, даже не имея ни малейшего представления о его размещении. Можно без преувеличения сказать, что система DNS — основа современной сети интернет в том виде, в которой мы все ее знаем и привыкли.
Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:
Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru, сom, org и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.
Домены первого уровня являются привычными нам доменными зонами и могут управляться как национальными, так и международными организациями и иметь свои условия использования. Каждая доменная зона первого уровня позволяет размещать неограниченное количество доменов второго уровня, которые знакомы каждому пользователю интернета как адреса сайтов.
В свою очередь домены второго уровня тоже являются доменными зонами и позволяют размещать в себе домены третьего уровня, в которые, как в матрешку, помещать домены четвертого, пятого и т.д. уровней. Для того, чтобы можно было однозначно определять узлы, находящиеся в разных зонах, введено понятие полностью определенное имя домена (FQDN, Fully Qualified Domain Name), которое включает в себя все имена родительских доменов в иерархии DNS. Например, для нашего сайта FQDN будет: interface31.ru. Именно так, с окончанием на точку, обозначающее корневую зону.
Это очень важный момент. В повседневном использовании завершающую точку принято отбрасывать, но в записях DNS отсутствие последней точки обозначает, что данное доменное имя принадлежит текущей доменной зоне, т.е. DNS-сервер прибавит к такому имени собственную доменную зону и все вышестоящие зоны вплоть до корня.
Например, на нашем сервере в зоне interface31.ru мы добавляем запись типа CNAME, которая будет указывать на сторонний сервер, скажем, Яндекс-почты. Правильно запись должна выглядеть так:
В данном случае имя mail не является FQDN и будет дополнено до mail.interface31.ru., если же мы забудем поставить точку в конце имени домена Яндекса, то это имя также не будет восприниматься как FQDN и должно быть дополнено до полного имени домена. Ниже показана неправильная запись:
Неподготовленным взглядом разницу заметить сложно, но вместо веб-интерфейса почты Яндекса такая конструкция отправит нас на несуществующий адрес: domain.mail.yandex.net.interface31.ru.
Еще один момент. Все записи для доменной зоны вносятся администраторами зон на собственных DNS-серверах, каким образом данные записи становятся известны системе DNS? Ведь мы же не оповещаем вышестоящие DNS-сервера, что изменили какую-либо запись.
Любая DNS-зона содержит записи только о входящих в нее узлах и дочерних зонах. Информация об узлах нижестоящей зоны хранится на ее собственных серверах. Это называется делегированием и позволяет снизить нагрузку на корневые сервера и предоставить необходимую автономию владельцам дочерних доменных зон.
Итак, вы купили домен, скажем, example.org, после чего вы должны его делегировать, т.е. указать сервера имен (DNS-сервера), которые будут содержать записи данной файловой зоны. Это могут быть как ваши собственные сервера, так и публичные сервисы, например, DNS Яндекса.
В этом случае в доменной зоне org будет добавлена запись:
Которая будет указывать, что все записи этой зоны расположены на сервере dns1.yandex.net. По правилам, каждая доменная зона должна иметь не менее двух NS-серверов, расположенных в разных подсетях. На практике часто обходятся одним сервером, приобретая для него два IP-адреса из разных диапазонов.
Теперь разберем, каким образом происходит поиск необходимой нам DNS-записи и почему запись, сделанная на вашем сервере, позволяет попасть на ваш сайт посетителям из любой точки земного шара.
Допустим, пользователь хочет посетить популярный ресурс Яндекс Маркет, он набирает в адресной строке браузера соответствующее имя сайта и нажимает кнопку Enter. Для того, чтобы отобразить пользователю содержимое страницы браузер должен отправить запрос обслуживающему сайт веб-серверу, а для этого нужно знать его IP-адрес. Поэтому браузер обращается к DNS-клиенту с целью узнать, какой адрес соответствует введенному пользователем доменному имени.
В свою очередь DNS-клиент проверяет записи в файле hosts, затем в локальном кэше и, не обнаружив там нужных записей, передает запрос указанному в сетевых настройках DNS-серверу. Скорее всего это будет локальный кэширующий DNS-прокси, например, dnsmasq или локальный DNS-сервер предприятия. Данные решения обычно не являются полноценными серверами глобальной системы DNS и не входят в нее, обслуживая только локальную зону и кэшируя DNS-запросы, поэтому такой запрос, если данных не оказывается в кэше, передается вышестоящему DNS-серверу, как правило это сервер провайдера.
Получив запрос, сервер провайдера проверит собственные записи, затем собственный кэш, и, если результат будет найден, сообщит его клиенту, в противном случае сервер вынужден будет прибегнуть к рекурсии — поиску в глобальной системе DNS. Чтобы лучше понять механизм данного процесса мы подготовили следующую схему:
Итак, клиент отправляет DNS-запрос серверу провайдера с целью узнать адрес домена market.yandex.ru, сервер провайдера не располагает подобной информации, поэтому обращается к одному из корневых серверов, передавая ему запрос. Корневой сервер также не имеет нужных записей, но отвечает, что знает сервер, отвечающий за зону ru — a.dns.ripn.net. Вместе с данным именем корневой сервер может сразу сообщить его IP-адрес (и в большинстве случаев сообщит), но может и не сделать этого, если не располагает такой информацией, в таком случае, перед тем как обратиться к данному серверу, нужно будет выполнить еще один рекурсивный запрос, только уже для определения его имени.
Выяснив адрес сервера, отвечающего за зону ru, сервер провайдера передаст запрос ему, но данный сервер также не имеет нужных записей, но сообщит, что за зону yandex отвечает сервер ns1.yandex.ru и обязательно сообщит его адрес. Иначе рекурсию завершить не удастся, так как за зону yandex отвечает сервер, находящийся в зоне yandex. Для этого в вышестоящей зоне, кроме NS-записи об обслуживающих зону серверах имен, создается «связанная» А-запись, которая позволяет узнать адрес такого сервера.
Наконец, отправив запрос серверу, обслуживающему зону yandex, сервер провайдера получит адрес искомого домена и сообщит его клиенту. Также он поместит полученный результат в кэш на время, предусмотренное значением TTL в SOA-записи этого домена. На практике, так как рекурсивные запросы весьма затратны, время кэширования записей у провайдеров может игнорировать значения TTL домена и достигать значений от двух-четырех часов до нескольких дней или даже недели.
Теперь рассмотрим еще один момент. Запросы могут быть рекурсивными или нерекурсивными. Рекурсивный запрос предусматривает получение готового ответа, т.е. IP-адреса или сообщения что домен не существует, не делегирован и т.п. Нерекурсивный запрос предусматривает ответ только о той зоне, за которую отвечает данный сервер или возврат ошибки.
Так как рекурсивные запросы являются достаточно ресурсоемкими большинство серверов сети DNS обрабатывают рекурсивные запросы нерекурсивно. Либо могут делать это выборочно, например, DNS-сервера провайдера выполняют рекурсивные запросы только для своих клиентов, а остальные нерекурсивно.
В нашем случае клиент послал серверу провайдера рекурсивный запрос, который, в свою очередь, последовательно отправлял нерекурсивные запросы пока не нашел требуемый сервер, который дал необходимый ответ. При этом в кэш сервера провайдера помещаются не только результаты пользовательского запроса, но и результаты промежуточных запросов, что позволяет выполнять следующие такие запросы нерекурсивно или с минимальным количеством запросов.
Например, если пользователь после посещения Яндекс Маркета решит воспользоваться почтовым сервисом, то сервер сразу направит запрос к ns1.yandex.ru, так как уже знает, какой сервер содержит записи для зоны yandex.
От теории к практике
Когда вы приобретаете у регистратора домен, вам будет предложено его делегировать, т.е. указать DNS-сервера, на которых будет расположена доменная зона. Это могут быть сервера регистратора (обычно бесплатно), сервера хостера, публичные DNS-сервисы или собственные сервера имен, если он будет расположен в этой же доменной зоне, то вам потребуется также указать IP-адреса. Например, так выглядит окно делегирования домена у одного известного регистратора:
Что именно туда указывать? Это зависит от того, где и как вы будете размещать свой сайт. Если вы используете виртуальный хостинг, то все необходимые записи создаются хостером автоматически, при добавлении в панели управления хостингом вашего сайта, все что вам надо — это делегировать домен на NS-сервера хостера, т.е. указать их в данном окне. Этот способ хорошо подходит начинающим, благодаря своей простоте, но есть и обратная сторона, возможность управления DNS-зоной со стороны пользователя отсутствует или минимальна. Кроме того, на виртуальном хостинге IP-адрес сайта может быть изменен администраторами без уведомления пользователя, поэтому, если вы не хотите использовать NS-сервера хостера, то этот вопрос следует обязательно обсудить с техподдержкой.
Если вы переносите сайт к другому хостеру, то вам потребуется перенести сайт и поменять у регистратора сервера имен старого хостера на сервера нового. Но учтите, что информация в кэше DNS-серверов обновляется не мгновенно, а, как минимум, по истечении значения TTL-домена, поэтому в течении некоторого времени ваш сайт может быть доступен еще по старому адресу. Если вам надо срочно с ним работать, то можете, не дожидаясь обновления DNS-кэша вашего провайдера, добавить в файл hosts запись следующего содержания:
Где 1.2.3.4 и example.com соответственно новый IP-адрес и имя вашего домена.
Если у вас свой VPS или вы хотите полностью контролировать доменную зону, то следует воспользоваться серверами регистратора или публичными сервисами. Создание собственного сервера имен, на наш взгляд, не оправдывающая себя затея, если только вы не делаете собственный хостинг.
В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:
Символ «собачки» в DNS-записях обозначает сам домен, кроме того обязательно следует создать запись для поддомена www, чтобы пользователи, набравшие адрес сайта с www, также могли получить к нему доступ.
Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье: Почтовый сервер для начинающих. Настраиваем DNS зону.
При переносе сайта вам потребуется изменить только IP-адреса в A-записях и дождаться обновления DNS информации. Обычно, это самый неприятный момент — вроде бы все сделано, но ничего изменить вы не можете, остается только ждать. Но если выполнить некоторые рекомендации, то данный процесс можно провести максимально безболезненно и незаметно для посетителей.
Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:
В нашем случае это 4 часа:
Поэтому заранее, не менее 4 часов (старое значение TTL) до планируемого переноса, измените значение TTL на более низкое, например, 900 (15 минут). Затем переведите свой сайт в режим «только чтение» и перенесите его на новый сервер. Выключать или переводить на техобслуживание сайт не следует, он может и должен оставаться доступным. Но вы должны исключить изменение и добавление информации пользователями, т.е. запретить регистрацию, комментирование, размещение заказов и т.п. Также не забудьте разместить на видном месте сообщение о технических работах и примерный срок их завершения.
Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.
После успешного переноса значение TTL следует увеличить до прежних значений, чтобы не создавать лишней нагрузки на сервера имен.
Мы рассмотрели самую простую схему, но на практике, кроме сайта, обычно есть еще офисная сеть, многие ресурсы которой должны быть также доступны извне. Рассмотрим следующую схему:
У нас имеются публичные сервера для сайта и электронной почты и офисная сеть, для которой мы выделили поддомен office. Если с почтой и веб-сервером особых вопросов нет, то с офисной зоной есть варианты. Обычно локальная зона обслуживается собственным DNS и никак не связана с материнской зоной. Для глобальной системы DNS зона office.example.com не существует, но существует одноименный хост. Это оправдано, если сеть предприятия находится за NAT и ее узлы имеют только серые адреса, а доступ извне осуществляется только к шлюзу, на который проброшены соответствующие порты от внутренних узлов.
В этом случае DNS записи зоны example.com могут выглядеть следующим образом:
Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com, которые указывают на внутренние «серые» адреса». Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.
В локальной сети DNS-запросы клиентов обслуживает локальный сервер, которые имеет соответствующие записи, за ее пределами запросы будут направлены серверу, обслуживающему зону example.com. При этом все корпоративные ресурсы, которые в локальной сети представлены различными серверами, извне доступны по единственному адресу: office.example.com. Поэтому самое время вспомнить о записи псевдонима или CNAME. Данная запись позволяет связывать с реальным именем хоста дополнительные мнемонические имена или псевдонимы. При этом учтите, что использовать в других записях псевдонимов недопустимо. В нашем случае следует добавить записи:
Теперь клиент, вне зависимости от своего местоположения, может использовать для доступа к ресурсам одно и тоже имя, но результат получать при этом будет разный. В локальной сети он получит реальный адрес сервера и подключится напрямую, а за ее пределами будет направлен на шлюз сети.
Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие — CNAME запись должна указывать на реальное имя в формате FQDN.
Еще одно применение псевдонимов — это сокращение адреса. Допустим, в качестве почтового сервера для всего домена example.com мы хотим использовать сервер, который расположен в московском офисе и имеет адрес mail.office.msk.example.com, согласитесь, выглядит не слишком привлекательно. Гораздо удобнее был бы адрес вида mail.example.com, нет ничего проще, добавим следующую запись:
Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:
Источник