Где найти настройки dns на компьютере. Настройка получения IP и DNS адреса автоматически и вручную

Чаще всего DNS-сервер, предоставляемый провайдером, справляется со своими задачами. Но иногда возникают проблемы:

1. Перестают грузиться некоторые сайты.
2. Доступ к контенту блокируется по географическим причинам.
3. На сервере провайдера нет надёжной защиты.

И тут рекомендуется воспользоваться сторонними сервисами. Самые популярные - Google Public DNS и OpenDNS. Google Public DNS обеспечит стабильную загрузку сайтов. OpenDNS, кроме этого, может предложить расширенную функциональность: встроенный фильтр, защиту от фишинга и функцию родительского контроля. Для этого надо зарегистрироваться .

Смена DNS-сервера на Windows

Если у вас Windows 10, кликните правой кнопкой мыши по значку соединения и выберите «Параметры сети и интернет».

Прокрутив страницу вниз, откройте «Центр управления сетями и общим доступом».

Если у вас Windows 7, 8, 8.1, так же нажмите правой кнопкой на значок сети и сразу выберите «Центр управления сетями и общим доступом». Последующие действия одинаковы для всех версий Windows.

Вам нужно попасть в меню «Изменение параметров адаптера».

Кликните правой кнопкой по нужному сетевому соединению и перейдите в его свойства. Выберите «IP версии 4», нажмите на кнопку «Свойства».

Поменяйте галочку на «Использовать следующие адреса DNS-серверов» и пропишите новые параметры. Для Google Public DNS это будут 8.8.8.8 и 8.8.4.4. Для OpenDNS - 208.67.222.222 и 208.67.220.220.

Смена DNS-сервера на macOS

Зайдите в системные настройки и кликните на иконку «Сеть». Далее выберите карточку вашей сети слева - в большинстве случаев это будет Wi-Fi. Нажмите на кнопку «Дополнительно».

Когда вы попадёте в дополнительные настройки, откройте мини-вкладку DNS. Там вы сможете добавить новый адрес сервера в список. Если увидите запись, выделенную серым цветом, просто не обращайте на неё внимания и кликните по кнопке «+» в колонке DNS-серверы, чтобы добавить новую запись.

Если вы хотите использовать серверы Google Public DNS, нужно добавить две новые записи в список DNS-серверов: 8.8.8.8 и 8.8.4.4. Если вам больше нравится OpenDNS, используйте эти два адреса: 208.67.222.222 и 208.67.220.220.

Смена DNS-сервера на Android

Зайдите в настройки Wi-Fi на своём телефоне. Длинным нажатием выберите нужное подключение и в появившемся меню выберите «Изменить сеть».

Затем нажмите «Дополнительно» и в пункте «Настройки IP» выберите «Статический».

Остаётся ввести адреса в поля DNS1 и DNS2. Для Google Public DNS это 8.8.8.8 и 8.8.4.4, для OpenDNS - 208.67.222.222 и 208.67.220.220.

Смена DNS-сервера на iOS

Зайдите в настройки Wi-Fi на своём устройстве и нажмите на синий кружок с буквой i рядом с нужным подключением.

Затем в строке DNS введите адрес сервера. Выберите один из адресов Google Public DNS (8.8.8.8 или 8.8.4.4) или OpenDNS (208.67.222.222 или 208.67.220.220).

Вот и всё! Сменить DNS оказалось просто и быстро. Можете наслаждаться стабильным интернет-соединением.

Хотя существует несколько различных способов для установки и конфигурирования DNS, наиболее простой и полный из них подразумевает вызов сначала мастера добавле­ния ролей (Add Roles Wizard), а затем - мастера настройки сервера DNS (Configure a DNS Server Wizard).

Процесс установки DNS на сервере Windows Server 2008 R2 довольно прост и не требует перезагрузки системы. Ниже перечислены шаги, необходимые для выполнения установки и настройки службы DNS на компьютере с Windows Server 2008 R2.

1. Выделите узел Roles (Роли) и щелкните на ссылке Add Roles (Добавить роли).
2. На странице Before You Begin (Прежде чем приступить к работе) ознакомьтесь с ото­бражаемыми сведениями и щелкните на кнопке Next (Далее).
3. Отметьте флажок рядом с ролью DNS Server (Сервер DNS) и щелкните на кнопке Next (Далее).
4. На странице Introduction to DNS Server (Вводные сведения о DNS-сервере) щелкните на кнопке Next.
5. На странице Confirmation (Подтверждение) щелкните на кнопке Install (Установить), чтобы запустить процесс установки роли DNS-сервера.
6. По завершении процесса установки щелкните на кнопке Close (Закрыть), чтобы выйти из мастера добавления ролей (Add Roles Wizard).

Настройка DNS сервера

После выполнения этих шагов роль DNS Server (DNS-сервер) будет установлена на ком­пьютере с Windows Server 2008 R2, но не сконфигурирована. Далее описаны шаги, необхо­димые для ее настройки.

1. Откройте консоль Server Manager (Диспетчер сервера).
2. Разверните последовательно узлы Roles (Роли), DNS Server (DNS-сервер) и DNS, по­сле чего щелкните на имени сервера DNS.
3. В меню Action (Действие) выберите пункт Configure a DNS Server (Конфигурация DNS-сервера).
4. На странице приветствия мастера настройки сервера DNS (Configure a DNS Server Wizard) щелкните на кнопке Next (Далее).
5. Выберите переключатель Create Forward and Reverse Lookup Zones (Recommended for Large Networks) (Создать зоны прямого и обратного просмотра (рекомендуется для больших сетей)) и щелкните на кнопке Next.
6. Выберите вариант Yes, Create a Forward Lookup Zone Now (Recommended) (Да, соз­дать зону прямого просмотра сейчас (рекомендуется)) и щелкните на кнопке Next.
7. Укажите, зону какого типа требуется создать, в данном случае выбрав вариант Primary Zone (Первичная зона), и щелкните на кнопке Next. Если сервер является контрол­лером домена с доступом для записи, для выбора будет также доступен флажок Store Zone in Active Directory (Сохранить зону в Active Directory).
8. В случае сохранения зоны в Active Directory выберите область репликации и щелкни­те на кнопке Next.
9. Введите полностью определенное доменное имя зоны (FQDN) в поле Zone Name (Имя зоны) и щелкните на кнопке Next.
10. На этом этапе в случае создания не интегрируемой с AD зоны можно либо создать новый текстовый файл для зоны, либо импортировать уже существующий. В данном случае выберите вариант Create a New File with This File Name (Создать новый файл с таким именем) и оставьте предлагаемые по умолчанию параметры, после чего для продолжения щелкните на кнопке Next.
11. На следующей странице будет предложено разрешить или запретить прием дина­мических обновлений сервером DNS. В рассматриваемом примере разрешите DNS-серверу принимать динамические обновления, выбрав переключатель Allow Both Nonsecure and Secure Updates (Разрешать как безопасные, так небезопасные обнов­ления), и щелкните на кнопке Next.
12. На следующей странице предлагается создать зону обратного просмотра. В данном случае выберите переключатель Yes, Create a Reverse Lookup Zone Now (Да, создать зону обратного просмотра сейчас) и щелкните на кнопке Next.
13. Укажите, что зона обратного просмотра должна представлять собой первичную зону, выбрав перелючатель Primary Zone (Первичная зона), и щелкните на кнопке Next.
14. В случае сохранения этой зоны в Active Directory выберите область репликации и щелкните на кнопке Next.
15. Оставьте выбранным предлагаемый по умолчанию вариант IPv4 Reverse Lookup Zone (Зона обратного просмотра IPv4) и щелкните на кнопке Next.
16. Введите идентификатор сети для зоны обратного просмотра и щелкните на кноп­ке Next. (Как правило, в качестве сетевого идентификатора вводится первый набор октетов из IP-адреса зоны. Например, если в сети используется диапазон IP-адресов класса С 192.168.3.0/24, то в качестве сетевого идентификатора могут быть введено значение 192.168.3.
17. В случае создания не интегрируемой с AD зоны будет снова предложено либо создать новый файл для зоны, либо импортировать уже существующий. В рассматриваемом примере выберите переключатель Create a New File with This File Name (Создать но­вый файл с таким именем) и щелкните на кнопке Next.
18. После этого появится приглашение указать, должны ли быть разрешены динами­ческие обновления. Для целей этого примера выберите переключатель Allow Both Nonsecure and Secure Updates (Разрешать как безопасные, так и небезопасные об­новления) и щелкните на кнопке Next.
19. На следующей странице будет предложено настроить параметры ретрансляторов, о которых более подробно речь пойдет в разделе "Зоны DNS" далее в главе. В рассмат­риваемом примере выберите переключатель No, It Should Not Forward Queries (Нет, не следует переадресовывать запросы) и щелкните на кнопке Next.
20. На последнем экране будут представлены сводные сведения о выбранных для внесе­ния и добавления в базу данных DNS изменениях и зонах. Щелкните на кнопке Finish (Готово), чтобы внести все эти изменения и создать нужные зоны.

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

Встроенный DNS-сервер существует в серверной версии Windows, но благодаря стараниям маркетологов Microsoft его нет в десктоп-редакции (Windows 2000/XP/Vista), поэтому, как это часто бывает, обратимся к щедрому миру Unix. Самые известные DNS-сервера - это BIND , djbdns , PowerDNS , MaraDNS и Unbound . BIND рассматривать нет желания, djbdns в силу своих особенностей жестко привязан к Unix, у PowerDNS Windows-версия не обновляется, поэтому остаются MaraDNS и Unbound. Вы можете попробовать или один или другой, однако, следует помнить, что одновременно они работать не будут.

Руководство будет в стиле краткого HowTo для подготовленного пользователя (скорее, системного администратора), поэтому, если ничего не понятно - позовите знакомого «компутерщика».

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

Unbound

Заходим на сайт http://unbound.net/ в раздел Downloads , находим строки:

Windows 32-bit version compiled from the source.
Installer:

По ссылке (на момент написания статьи - unbound_setup_1.3.0) скачиваем дистрибутив. Запускаем файл, нажимаем «Next», читаем лицензионное соглашение, если согласны нажимаем «I Agree», убираем галочку с «DLV - dlv.isc.org» (проверять DNSSEC-сигнатуры нам не нужно), нажимаем «Next», «Next», «Install», «Finish». Сервис автоматически устанавливается и стартует. Все что нужно для работы (включая README.txt) находится в C:\Program Files\Unbound.

MaraDNS

Запуск MaraDNS под Windows, как оказалось, довольно нетрививальное занятие, поэтому, если очень хочется - можете попробовать сами.

Настройка Windows

Итак, DNS-сервер мы установили и запустили, необходимо теперь настроить Windows.

В свойствах соединения с интернетом («Пуск», «Настройка», «Сетевые подключения», нужное соединение, контекстное меню, «Свойства») на вкладке «Общие» открываем «Протокол интернета TCP/IP», если стоит настройка «Получить адрес DNS-сервера автоматически» необходимо сменить её на «Использовать следующие адреса DNS-серверов» и прописать адрес 127.0.0.1. В случае если у вас активирован параметр «Использовать следующие адреса DNS-серверов» и указаны адреса DNS-серверов провайдера, удалить или оба или один из них (предварительно записав на бумажку) и прописать тот же 127.0.0.1. Указывать один и тот же адрес (127.0.0.1) два раза нет необходимости. Нажимаем «OK», «OK», ждем пока все сохранится и пробуем открыть какой-нибудь сайт. Другой метод проверки - для настоящих админов. Заходим в консоль, запускаем nslookup, далее выполняем:

> server 127.0.0.1 Default Server: localhost Address: 127.0.0.1 > www.mail.ru Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: www.mail.ru Addresses: 194.67.57.26, 194.67.57.126, 194.67.57.226, 194.67.57.20 > exit

В данном случае у нас успешно разрешилась запись (A-типа) для www.mail.ru.

Если не получается, проверяем что у вас подключен интернет, сделав ping на шлюз провайдера (узнать можно через ipconfig /all). Если подключен, смотрим в Диспетчере задач, чтобы был запущен процесс DNS-сервера. Если не запущен, смотрим оснастку «Службы» (в консоли запустить services.msc): пробуем запустить сервис и проверяем, чтобы стоял автоматический запуск. Если не помогает - либо читаем документацию (DNS-сервера), включаем лог и проверяем свой firewall и конфигурационный файл DNS-сервера (хотя, он должен быть по умолчанию уже настроен), либо зовем кого-то более квалифицированного, либо удаляем программу, возвращаем настройки назад, и [грустим | идем гулять | пить пиво | ...].

Однако, теоретически ничего сложного в описанном процессе нет, поэтому должно заработать (как у автора).

Примечания:

• Обычно все сервера идут со сравнительно безопасными настройками по-умолчанию, но нелишним будет проверить, что ваш DNS-сервер слушает 53 порты TCP и UDP на 127.0.0.1, а не на 0.0.0.0 (все локальные адреса). Сделать это можно с помощью TCPView . В «Options» активируйте параметр «Show Unconnected Endpoints» и деактивируйте «Resolve Adresses». Найдите процесс DNS-сервера, для него должно быть две записи: TCP с Local Adress 127.0.0.1:53 и State LISTENING и UDP с тем же адресом и пустым полем State.
• Автор не пользуется DNS-серверами под Windows, и соответственно материалом этой статьи на практике, поэтому просьба не писать писем в стиле «у меня не работает, что делать?».
• Для написания статьи автор использовал Windows XP, если у вас другая версия Windows - адаптируйте пути и команды под свою версию ОС.
• Если вы пытаетесь сделать это на компьютере в организации, то лучшим решением будет попросить вашего сисадмина настроить офисный шлюз в Интернет под GNU Linux/*BSD с настоящим (под Unix) DNS-сервером, а если он этого не может - найти такого человека.
• Статья предельно упрощена, поэтому если вы нашли ошибку, неточность или неясный момент - пишите, если вам кажется, что материал раскрыт недостаточно широко (например, не описано в чем разница между рекурсивными и авторитетным/полномочным/authoritative DNS-сервером) - писать не стоит, в Интернете достаточно руководств по устройству DNS (включая документацию на сайтах программ).
• Windows - не лучшая платформа для работы DNS-сервера (как минимум - портированного из Unix) поэтому все это может работать не идеально (в первую очередь, в плане скорости).
• В обычном случае общения «десктоп - DNS-сервер провайдера» для разрешения имени в подавляющем большинстве случаев отсылается один запрос и получается один ответ. В нашем случае запросов и ответов будет в несколько раз больше, т. к. мы берем функции провайдерского DNS-сервера на себя. На общем трафике это скажется незначительно, поскольку DNS-запросы и ответы очень маленькие, но может сказаться на скорости начала открытия сайтов. Но, поскольку запросы кэшируются, заметно это будет, скорее всего, только в первые минуты работе в Интернете.

Вот и все, спасибо за внимание.

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

Что такое доменное имя? Для многих это синоним адреса сайта, например, www.сайт . Набирая этот адрес вы твердо уверены, что попадете именно на этот сайт, а не куда-нибудь еще. В тоже время доменное имя может обозначать не только сайт, но и сервер электронной почты, обмена короткими сообщениями или иной другой интернет и сетевой сервис. Доменные имена входят в доменные зоны, которые расположены внутри друг друга в иерархическом порядке.

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

Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:

Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru , сom , org и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.

Домены первого уровня являются привычными нам доменными зонами и могут управляться как национальными, так и международными организациями и иметь свои условия использования. Каждая доменная зона первого уровня позволяет размещать неограниченное количество доменов второго уровня, которые знакомы каждому пользователю интернета как адреса сайтов.

В свою очередь домены второго уровня тоже являются доменными зонами и позволяют размещать в себе домены третьего уровня, в которые, как в матрешку, помещать домены четвертого, пятого и т.д. уровней. Для того, чтобы можно было однозначно определять узлы, находящиеся в разных зонах, введено понятие полностью определенное имя домена (FQDN, Fully Qualified Domain Name ), которое включает в себя все имена родительских доменов в иерархии DNS. Например, для нашего сайта FQDN будет: сайт. Именно так, с окончанием на точку, обозначающее корневую зону.

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

Например, на нашем сервере в зоне сайт мы добавляем запись типа CNAME, которая будет указывать на сторонний сервер, скажем, Яндекс-почты. Правильно запись должна выглядеть так:

MailIN CNAMEdomain.mail.yandex.net.

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

Mail IN CNAME domain.mail.yandex.net

Неподготовленным взглядом разницу заметить сложно, но вместо веб-интерфейса почты Яндекса такая конструкция отправит нас на несуществующий адрес: domain.mail.yandex.net.сайт.

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

Любая DNS-зона содержит записи только о входящих в нее узлах и дочерних зонах. Информация об узлах нижестоящей зоны хранится на ее собственных серверах. Это называется делегированием и позволяет снизить нагрузку на корневые сервера и предоставить необходимую автономию владельцам дочерних доменных зон.

Итак, вы купили домен, скажем, example.org , после чего вы должны его делегировать, т.е. указать сервера имен (DNS-сервера), которые будут содержать записи данной файловой зоны. Это могут быть как ваши собственные сервера, так и публичные сервисы, например, DNS Яндекса.

В этом случае в доменной зоне org будет добавлена запись:

Example IN NS dns1.yandex.net.

Которая будет указывать, что все записи этой зоны расположены на сервере 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

Где 1.2.3.4 и example.com соответственно новый IP-адрес и имя вашего домена.

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

В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:

@ IN A 1.2.3.4
www IN A 1.2.3.4

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

Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье:

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

Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:

Nslookup -typr=soa сайт

В нашем случае это 4 часа:

Поэтому заранее, не менее 4 часов (старое значение TTL) до планируемого переноса, измените значение TTL на более низкое, например, 900 (15 минут). Затем переведите свой сайт в режим "только чтение" и перенесите его на новый сервер. Выключать или переводить на техобслуживание сайт не следует, он может и должен оставаться доступным. Но вы должны исключить изменение и добавление информации пользователями, т.е. запретить регистрацию, комментирование, размещение заказов и т.п. Также не забудьте разместить на видном месте сообщение о технических работах и примерный срок их завершения.

Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.

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

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

У нас имеются публичные сервера для сайта и электронной почты и офисная сеть, для которой мы выделили поддомен office . Если с почтой и веб-сервером особых вопросов нет, то с офисной зоной есть варианты. Обычно локальная зона обслуживается собственным DNS и никак не связана с материнской зоной. Для глобальной системы DNS зона office.example.com не существует, но существует одноименный хост. Это оправдано, если сеть предприятия находится за NAT и ее узлы имеют только серые адреса, а доступ извне осуществляется только к шлюзу, на который проброшены соответствующие порты от внутренних узлов.

В этом случае DNS записи зоны example.com могут выглядеть следующим образом:

@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8

Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com , которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.

В локальной сети DNS-запросы клиентов обслуживает локальный сервер, которые имеет соответствующие записи, за ее пределами запросы будут направлены серверу, обслуживающему зону example.com . При этом все корпоративные ресурсы, которые в локальной сети представлены различными серверами, извне доступны по единственному адресу: office.example.com . Поэтому самое время вспомнить о записи псевдонима или CNAME. Данная запись позволяет связывать с реальным именем хоста дополнительные мнемонические имена или псевдонимы. При этом учтите, что использовать в других записях псевдонимов недопустимо. В нашем случае следует добавить записи:

Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.

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

Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.

Еще одно применение псевдонимов - это сокращение адреса. Допустим, в качестве почтового сервера для всего домена example.com мы хотим использовать сервер, который расположен в московском офисе и имеет адрес mail.office.msk.example.com , согласитесь, выглядит не слишком привлекательно. Гораздо удобнее был бы адрес вида mail.example.com , нет ничего проще, добавим следующую запись:

Mail IN CNAME mail.office.msk.example.com.

Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:

Example.com. IN MX 10 mail

Правильно будет так:

Example.com. IN MX 10 mail.office.msk

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

Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.

ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Теперь при обращении по адресу, скажем mail.office.msk.example.com сервера имен зоны example.com будут выдавать имя и адрес сервера, обслуживающего зону msk.example.com . Это позволяет администраторам зоны самостоятельно вносить необходимые изменения, не затрагивая при этом функционирования вышестоящей зоны и не обращаясь к ее администраторам по любому вопросу, требующему изменения записей.

• Теги:

Please enable JavaScript to view the