DNS-Hosting RU-CENTER

Введение

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

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

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

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

Зона-заглушка

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

Зоны-заглушки можно использовать в следующих целях:

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

Существует два списка DNS-серверов, участвующих в загрузке и поддержке зоны-заглушки:

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

Создадим зону заглушку или как еще ее называют stub zone.

Щелкаем правым кликом по зоны прямого просмотра и выбираем создать

Как настроить DNS сервер в windows server 2012R2-2 часть—17

Откроется мастер создания зоны.

Как настроить DNS сервер в windows server 2012R2-2 часть—18

Выбираем зона заглушка

Как настроить DNS сервер в windows server 2012R2-2 часть—19

задаем имя зоны

Как настроить DNS сервер в windows server 2012R2-2 часть—20

создать новый файл, в котором все будет храниться.

Как настроить DNS сервер в windows server 2012R2-2 часть—21

Пишем имя главного dns с которого будем запрашивать зону

Как настроить DNS сервер в windows server 2012R2-2 часть—22

Готово

Как настроить DNS сервер в windows server 2012R2-2 часть—23

Видим что файл зоны заглушки лежим в папке windows\system32\dns

Как настроить DNS сервер в windows server 2012R2-2 часть—24

Файл кстати открывается любым текстовым редактором.

Как настроить DNS сервер в windows server 2012R2-2 часть—25

Пример зоны-заглушки

Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная иActive Directory, содержит только два полномочных DNS-сервера — 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNSServer) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервереDns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia.microsoft.com, и запросы продолжают пересылаться лишь на два DNS-сервера, заданный в начальном делегировании.

Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.

В следующей статье мы поговорим про дополнительные настройки и вкладки DNS сервера windows server 2008R2-2012R2

Проверка работоспособности DNS сервера¶

Для проверки работоспособности DNS сервера используйте утилиты nslookup или host.

После того как вы создали DNS зону и добавили в нее записи, нужно посмотреть существующие записи в зоне с помощью команды:

cl-info -Z имя_зоны dns

Пример:

Ранее была создана зона test.ru и записи в ней.

Выполняем:

cl-info -Z domain.ru dns

Результат:

Information about master DNS zone domain.ru                    
+----------------------------+----------------+                
| Field                      | Value          |
+----------------------------+----------------+
| Zone name                  | domain.ru      |
| Master autoritative server | domain.ru      |
| NS record                  | domain.ru.     |
| A record                   | 10.0.0.5       |
| Email administrator        | root@domain.ru |
| Serial number              | 3              |
| Refresh                    | 8H             |
| Update                     | 2H             |
| Expiry                     | 2W             |
| Minimum                    | 2H             |
+----------------------------+----------------+
(10 rows)

Information about A records in master DNS zone domain.ru
+---------------------+-----------+
| Domain              | ip        |
+---------------------+-----------+
| localhost.domain.ru | 127.0.0.1 |
| calculate.domain.ru | 10.0.0.54 |
+---------------------+-----------+
(2 rows)

Используя любую из cуществующих А записей проверьте работоспособность DNS cервера с помощью команд:

nslookup имя_A_записи ip_DNS_сервера

host имя_A_записи ip_DNS_сервера

Пример:

ip адрес проверяемого DNS сервера 10.0.0.5 информация о зоне domain.ru приведена в предыдущем примере.

Выполняем проверку при помощи nslookup:

nslookup calculate.domain.ru 10.0.0.5

Server:         10.0.0.5
Address:        10.0.0.5#53

Name:   calculate.domain.ru
Address: 10.0.0.54

Выполняем проверку при помощи host:

host calculate.domain.ru 10.0.0.5

Результат при нормальной работе сервиса DNS:

Using domain server:
Name: 10.0.0.5
Address: 10.0.0.5#53
Aliases:

calculate.domain.ru has address 10.0.0.54

Настройка файла конфигурации bind

На данный момент у нас должно быть два файла:

/etc/bind/zones/master/db.itproffi.ru
/etc/bind/zones/master/db.172.31.1

Теперь требуется вставить имена обоих файлов зоны в файл конфигурации bind . Для этого добавьте в файл следующие строки:

zone "itproffi.ru" {
type master;
file "/etc/bind/zones/master/db.itproffi.ru";
};

zone "1.31.172.in-addr.arpa" {
type master;
file "/etc/bind/zones/master/db.172.31.1";
};

Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.

Замените следующий блок текста в файле named.conf.options:

// forwarders {
// 0.0.0.0;
// };

на блок текста с адресом стабильного DNS-сервера

forwarders {
8.8.4.4;
};

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

listen-on port 53 { any; };
allow-query { any; };

А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение

listen-on port 53 { 192.168.0.0/24; };
allow-query { 192.168.0.0/24; };

Если этого не сделать, то при попытке обращения к серверу с другого компьютера вы получите ошибку

Query refused

Пример проверки DNS записей с помощью MXtoolbox

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

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

При работе с сервисом рекомендуем в первую очередь проверить здоровье вашего домена Domain health.
Впишите в специальное поле доменное имя ресурса без http:// и www и нажмите на оранжевую кнопку.

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

Домен здоров, если не будет выявлено проблем, обозначенных красным цветом. Но результат проведенной проверки показал наличие ошибок, которые необходимо устранить — отсутствие записей SPF и DMARC.
Берем автоматически сгенерированные сервисом Estismail записи и совершаем настройки на хостинге. Дальше, проверяем корректность внесенных изменений.

Как проверить корректность записи DKIM?

Введите домен в поле проверки в следующем формате — example.com:estismail. Вводить без http:// и www. Вместо example.com вписываете ваш домен, а после двоеточия укажите селектор. Выбираем DKIM Lookup.

В открывшемся окне увидите «успешное» сообщение следующего вида:

Если после проведенной проверки открылась картина с сообщением, что DKIM не найдена, придется обновить DNS записи.

Как проверить SPF запись?

Проверка записи SPF, происходит так же, как и проверка DKIM. Из открывшегося списка выберите SPF Record lookup. В соответствующее поле введите имя домена без http:// и www. Если настройки корректны, увидите такую картину:

В нижней колонке в строке SPF Syntax Check высветится The record is valid.

Самая распространенная ситуация, помимо отсутствия записи SPF, это наличие 2 и более записей SPF. Если допущена подобная ошибка, в открывшемся окне увидите следующее:

В этом случае исправьте запись SPF — просто совместите в одной записи все узлы, с которых отправляете рассылки, как было указано на “правильном” предыдущем рисунке.

Как проверить DMARC запись?

При проведении проверки DMARC записи принцип, как и в первых 2 случаях. Из списка под оранжевой кнопкой выбираете функцию DMARC Lookup и вводите название домена без http:// и www.
Если введены корректные записи, увидите следующую таблицу и сообщение внизу в строке DMARC Syntax Check о том, что The record is valid.

Проверка файлов зоны и конфигурации

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

Для проверки файлов конфигурации выполните следующую команду:

named-checkconf

С этой командой работает простое правило: отсутствие результата – это хороший результат. Если команда ничего не возвращает, значит ошибок в ваших файлах конфигурации не обнаружено.

Для проверки файлов зоны DNS можно воспользоваться командой named-checkzone:

named-checkzone itproffi.ru /etc/bind/zones/master/db.itproffi.ru
zone itproffi.ru/IN: loaded serial 1
OK

Основной синтаксис

Любая 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-сервера и Доменные службы Active Directory

До установки ролей сервера, требуется задать имя будущему серверу, а также статический IP-адрес. Также, если имеются, указываем IP-арес шлюза.

1. Нажимаем правой клавишей мыши на «Этот компьютер» и выбираем «Свойства». В открывшемся окне — «Изменить параметры» — «Изменить». Задаём имя компьютера и нажимаем «ОК». Для того, чтобы изменения вступили в силу, перезагружаем компьютер.

2. Для того, чтобы открыть сетевые соединения, в поле «Поиск» набираем команду ncpa.cpl. Выбираем нужный сетевой интерфейс, правой клавишей мыши — «Свойства». IP версии 6(TCP/IPv6) выключаем, если не используем. Затем выбираем IP версии(TCP/IPv4). Заполняем поля:

IP-адрес: адрес сервера (например, 192.168.100.5)

Маска подсети: маска сети (например, 255.255.255.0)

Основной шлюз: шлюз, если имеется (например, 192.168.100.1)

Предпочитаемый DNS-сервер: (например, 192.168.100.5)

3. Теперь можно начать установку ролей сервера. Для этого выбираем «Диспетчер серверов».

4. В следующем окне — «Добавить роли и компоненты».

5. Читаем «Перед началом работы» и нажимаем «Далее». Затем оставляем по умолчанию чекбокс «Установка ролей или компонентов» и снова «Далее». В следующем окне выбираем сервер, на который будем устанавливать роли и «Далее».

6. Выбора ролей сервера — ставим галочки напротив «DNS-сервера» и «Доменные службы Active Directory». При появлении запроса о добавлении компонентов — «Добавить компоненты». Затем «Далее».

7. В следующих окнах нажимаем «Далее», а в окне «Подтверждение установки компонентов» выбираем «Установить». Этот мастер можно закрывать, по окончании установки появится предупреждение в диспетчере серверов.

8. После окончания установки выбранных ролей сервера, нажимаем на значок предупреждения в «Диспетчере серверов» и выбираем «Повысить роль этого сервера до уровня контроллера домена».

9. В следующем окне — «Добавить новый лес». Имя корневого домена — уникальное имя вашего домена.

10. В «Параметрах контроллера домена» оставляем по умолчанию режим работы леса и домена — «Windows Server 2016». Вводим пароль для режима восстановления служб каталогов (DSRM).Этот пароль может пригодиться, его обязательно надо запомнить или записать в надежное место.

11. В окне «Параметры DNS» — нажимаем «Далее».

12. В «Дополнительные параметры» — «Далее».

13. Расположение базы данных AD DS, файлов журналов и попок SYSVOL оставляем по умолчанию, нажимаем «Далее».

14. Проверяем параметры, затем «Далее».

15. После того, как сервер проверит соответствие предварительных требований, можно нажимать «Установить».

16. После настройки контроллера домена, можно перейти к настройке обратной зоны DNS-сервера. Для этого в «Диспетчер серверов» выбираем «Средства», далее «DNS».

17. В открывшемся окне выбираем наш сервер, затем «Зона обратного просмотра». Правой клавишей мыши — «Создать новую зону…».

18. В мастере создания новой зоны оставляем тип зоны — «Основная зона», затем «Далее».

19. Оставляем по умолчанию чекбокс на «Для всех DNS-серверов, работающих на контроллерах домена в этом домене, снова «Далее».

20. В следующем окне — «Зона обратного просмотра IPv4», затем «Далее».

21. Для настройки зоны обратного просмотра задаем «Идентификатор сети» (например 192.168.100). После этого появится автоматически зона обратного просмотра. Нажимаем «Далее».

22. В следующем окне оставляем по умолчанию «Разрешить только безопасные динамические обновления, затем «Далее».

23. Для завершения настройки создания новой зоны проверяем настройки и нажимаем «Готово».

24. Появится зона обратного просмотра для домена.

25. В «Диспетчере серверов» выбираем «Пользователи и компьютеры Active Directory». Проверяем работу Active Directory.

На этом установка и настройка выбранных ролей сервера заканчивается.

Посмотреть, что и как делать, можно здесь:

https://youtube.com/watch?v=X6MpJlWxM6M

Пример создания зоны и записей в ней¶

test.ru — ip 10.0.0.1 — WEB сервер, DNS сервер.
www.test.ru — ip 10.0.0.1 — WEB сервер (CNAME запись, тот же сервер что и test.ru)
ftp.test.ru — ip 10.0.0.5, FTP сервер
user1.test.ru — 10.0.0.100, компьютер пользователя

Для этого выполняем следующие команды после установки сервиса DNS:

Создаем зону test.ru с A записью (test.ru —> 10.0.0.1) и обратной зоной для сети 10.0.0.0/24
```
cl-dns-zoneadd -n test.ru --server test.ru --ipserver 10.0.0.1
```

Cоздаем CNAME запись (www.test.ru —> test.ru)

cl-dns-recadd -t cname --host www.test.ru --cname test.ru

Создаем A и PTR запись для FTP сервера
```
cl-dns-recadd --host ftp.test.ru --ip 10.0.0.5
```
Создаем A и PTR запись для компьютера пользователя
```
cl-dns-recadd --host user1.test.ru --ip 10.0.0.100
```

Создание зоны прямого просмотра на DNS сервере 2012 R2

На группе «Зоны прямого просмотра» щелкаем правой кнопкой мыши и выбираем «Создать новую зону»

После у нас запустится мастер создания новой зоны, жмем «Далее»

В следующем окне выбираем тип наше зоны, описание можете посмотреть непосредственно под каждым типов, я выбираю «Основную» жму «Далее»

Затем нам предстоит написать имя нашей зоны, в моем случае, так как сервер тестовый я выберу имя local, Вы в свою очередь пишете, название вашего домена, или если Ваш домен не будет иметь выхода в Интернет другими словами локальный (чисто в Вашей сети), то в принципе можете писать все что угодно.

Далее я выбираю «Создать новый файл», так как у меня другого DNS сервера нет, жму «Далее»

Затем предстоит выбрать «Тип динамического обновления» я пока такой функционал запрещу, но в последствии я всегда могу его включить, а Вы можете включить его, если, например, у Вас DNS сервер только для Вашей локальной сети, жму «Далее»

Заключительное окно, которое говорит нам, что все готово, мы соответственно и жмем «Готово»

Вот и все зона создана, давайте создадим запись типа A, например для нашего же сервера. Для этого по зоне щелкаем правой кнопкой мыши и жмем «Создать узел A или AAAA»

Затем вводим имя нашего узла, которое мы хотим, чтобы у него было, и соответственно какой у него IP адрес, это уже по факту. Жмем «Добавить узел»

Появится сообщение о том, что узел создан

И появится соответствующая запись

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

Как видите, система распознала по доменному имени его IP адрес. И на этом предлагаю заканчивать. Удачи!

Как подтвердить право владения доменом?

После подключения G Suite для домена подтвердите право владения доменом. В противном случае вы не сможете пользоваться подключенной услугой.

Если для домена прописаны DNS-серверы ns1.reg.ru и ns2.reg.ru, домен верифицируется автоматически через добавление ресурсной записи в зону и услуга сразу готова к использованию. Воспользуйтесь статьями:

Если для домена прописаны иные DNS-серверы (например, ns1.hosting.reg.ru и ns2.hosting.reg.ru), подтвердите право владения доменом вручную:

1.
Авторизуйтесь на сайте REG.RU и перейдите к списку услуг.
2.
Кликните по услуге G Suite (Google Apps) для домена…:
3.
На открывшейся странице в блоке «Общие сведения» кликните Панель управления администратора Google:

Для авторизации в панели администратора используйте логин и пароль, указанные в разделе Информация о включенных сервисах и паролях доступа:
4.
В панели администратора G Suite нажмите Начать настройку:
5.
В открывшемся окне нажмите Подтвердить:
6.
Нажмите Начать проверку:
7.
Кликните на вкладку Альтернативные способы, выберите пункт Размещение HTML-файла на сервере и нажмите на ссылку, чтобы скачать файл:

Далее вам нужно добавить файл на услугу хостинга.
8.
Откройте панель управления хостингом. В зависимости от того, какая панель управления установлена на вашем хостинге (ISPManager, Parallels Plesk, cPanel) следуйте дальнейшей инструкции:
9.
после загрузки файла в папку сайта снова перейдите на страницу G Suite (7 шаг), нажмите галочку «Я не робот» и нажмите Подтвердить:

Готово. Вы подтвердили право владения доменом.

Заключение

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

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

Перенаправляющий/кэширующий DNS-сервер можно настроить даже на домашнем компьютере Linux. Такой сервер может полностью заменить файл /etc/hosts для обращения к ресурсам локальной сети. А при поступлении запросов для получения IP доменных имён, этот сервер будет получать данные от внешнего кэширующего сервера (например, 8.8.8.8 и 8.8.4.4 — DNS-серверы от Google) и сохранять полученные ответы в своём кэше — это в том случае, если вы настроили перенаправляющий DNS-сервер. Если же вы выберите рекурсивный кэширующий DNS-сервер, то он будет делать несколько запросов, начиная с корневых DNS-серверов и получать в конечном счёте ответы исключительно от авторитативных DNS-серверов (а не от сторонних кэширующих серверов, как это обычно происходит). Полученные данные также будут храниться в кэше. В случае повторных запросов этих имён, локальный DNS сервер их будет брать из кэша, что может немного ускорить работу сети.

В наших следующих руководствах (смотрите ссылки ниже) мы покажем, как начать работу с некоторыми из этих конфигураций. Мы начнём с обучения настройке кэширующего и перенаправляющего DNS-сервера. Позже мы расскажем о том, как обслуживать ваши домены, настроив пару DNS серверов с только авторитативной функцией (Authoritative-Only).