Кэширующий DNS сервер на BIND.
BIND9 один из самых известных DNS серверов под Линукс. Это полноценный сервер со всеми нужными возможностями, на котором вы можете поднять авторитетный, кэширующий или какой угодно другой dns сервер.
Установка сервера очень проста :
apt-get install bind9
Теперь сделаем основные настройки и кэширование запросов DNS, если конечно ваш сервер будет вообще принимать запросы ) Отредактируем файл настроек /etc/bind/named.conf.options
Перезапустим сервис и можем пользоваться свои кэширующим dns сервером ).
Настройка зоны.
Скажем у вас есть домен test.com для которого вы ходите сделать свой dns сервер зоны. Первым делом открываем файл /etc/bind/named.conf.local и вписывает туда настройки зоны :
Теперь создадим файл test.com.db :
Рассмотрим подробнее написанное:
$TTL 3600 — Time to live время жизни, по умолчанию ставим 1 час.
test.com IN SOA ns01.test.com. root.test.com. — сама зона, которая обслуживается данным сервером.
1; Serial — ее серийный номер DNS записи.
600; Refresh — указывает подчиненным DNS серверам как часто им обращаться, для поиска изменений к master серверу.
3600; Retry — говорит о том, сколько Slave сервер должен подождать, прежде чем повторить попытку.
1w; Expire — Максимальный срок жизни записей, после которой они потеряют актуальность (1 неделя).
300; Minimum TTL — минимальный срок жизни записи 5 мин.
NS ns01.test.com. — NS сервер который обслуживает эту зону.
NS ns02.test.com. — NS сервер который обслуживает эту зону.
A 192.168.10.20 — если требуется попасть по адресу test.com, то клиенту будет выдан этот IP.
ns01 A 192.168.10.5 — Записи для поиска наших NS серверов.
ns02 A 192.168.10.6
www A 192.168.10.1 — Если клиент запросит адрес www.test.com, то ему будет выдан IP 192.168.10.2
test A 192.168.10.12 — Если клиент запрашивает адрес test.test.com, какой будет выдан ему IP.
Перезапускаем сервис и не забываем указать ваш dns сервер в настройка регистратора домена. Успехов.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Установка локального сервера кеширования DNS на Linux
Время поднимать кэширующий сервер
На самом деле поиск DNS это не то, что требует частого внимания. Но иногда приходится заботиться об этом. Например, если у вашего провайдера слабые сервера или же в вашей сети часто происходят DNS обращения, то нужно настроить локальный кэширующий DNS сервер.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Как кэширующий DNS-сервер может пригодиться?
Кэширующий DNS-сервер занимается обработкой DNS запросов, которые выполняет ваша система, затем сохраняет результаты в памяти или кэширует их. В следующий раз, когда система посылает DNS запрос для того же адреса, то локальный сервер почти мгновенно выдает результат.
Эта идея может показаться бесполезной. Подумаешь, какие-то там секунды. Но если DNS сервера провайдера тратят много времени на разрешение имени, то в результате падает скорость Интернет серфинга. Например, домашняя страница новостного канала MSNBC для корректной работы обращается более чем к 100 уникальным доменам. Даже если на запрос тратится одна десятая секунды, в итоге получается 10 секунд ожидания, что по нынешним меркам слишком много.
Локальный кэширующий DNS увеличивает скорость не только дома или в офисе, он также помогает работе серверов. Например, у вас есть почтовый сервер с анти-спам фильтром, который выполняет очень много DNS запросов. Локальный кэш намного увеличить скорость его работы.
И наконец, system-resolved поддерживает новейшие стандарты вроде DNSSEC и DNSoverTLS или DoT. Эти технологии увеличивают безопасность при работе в Интренет.
Какой локальный кэширующий сервер выбрать?
systemd-resolved запускает небольшой локальный кэширующий DNS-сервер, который мы настроим на запуск при загрузке системы. Затем мы изменим конфигурацию всей системы так, чтобы DNS запросы шли на локальный сервер.
Как проверить используется ли systemd-resolved?
Перед тем как перейти к следующему разделу проверьте запущен ли в вашей системе systemd-resolved :
Если в ответ получите сообщение ниже, значит в системе не настроен systemd-resolved :
И наоборот, если на выходе видите что-то подобное, то systemd-resolved уже работает:
Включение и настройка systemd-resolved
Далее нужно ввести следующую команду, чтобы добавить службу в автозапуск.
И наконец нужно прописать DNS сервера, куда будет обращаться локальный сервер для разрешения имен. Есть много разных сервисов, но приведённые ниже самые быстрые, бесплатные и оба поддерживают DNSSEC и DoT:
Cloudflare Public DNS
Для этого откройте конфигурационный файл systemd-resolved любым текстовым редактором:
Отредактируйте строку, которая начинается на:
И пропишите одну из вышеуказанных пар. Мы используем Cloudflare Public DNS:
Сохраните изменения и перезапустите службу systemd-resolved :
Итак, systemd-resolved уже запущен и готов для выполнения быстрых и безопасных DNS запросов, как только мы настроим систему соответствующим образом.
Настройка системы для использования systemd-resolved
В файле /etc/resolv.conf содержатся IP адреса серверов разрешения имен, которые используются программами. Программы при необходимости разрешения доменного имени обращаются к этому файлу в поисках адресов серверов разрешения имен.
Конфигурация в рекомендуемом режиме
Затем создаем символьную ссылку:
И наконец перезапускаем службу systemd-resolved :
Настройка в режиме совместимости
В режиме совместимости, нужно убедиться, что локальный сервер разрешения имен system-resolved запущен и используется системными службами. Откройте файл /etc/resolv.conf любым редактором:
Удалите все строки, которые содержать ключевое слово nameserver и добавьте одну единственную строку:
Отладка systemd-resolved
systemd-resolved можно перевести в режим отладки созданием специального служебного файла, в котором содержатся настройки отладки. Делается это следующей командой:
Вставьте в файл следующие строки:
После этого служба systemd-resolved автоматический перезапуститься. Откройте второй терминал и просмотрите логи в journald :
Строка, которая содержит слова “Using DNS server” показывает, какой DNS сервер используется для разрешения имён. В нашем случае это DNS сервера Cloudflare
Слова “Cache miss” в начале строки означает, что для данного домена нет закэшированной информации:
И наконец слова “Positive cache” в начале строки означает, что systemd-resolved уже запрашивал информацию об этом домене и теперь ответы возвращает из кэша:
Не забудьте отключить режим отладки, так как в это время создается большой файл логов. Сделать это можно командой:
а затем удалить добавленные выше две строки.
Использование защищенных DNS запросов
systemd-resolved один из немногих DNS серверов, которые поддерживает DNSSEC и DNSoverTLS. Эта два механизма позволяют убедиться, что полученная DNS информация подлинная (DNSSEC) и он не был изменён по пути (DoT).
Эти функции легко включаются редактированием основного конфигурационного файла system-resolved :
Измените файл следующим образом:
Пока прописанные DNS сервера поддерживают эти две функции все DNS запросы будут защищены. DNS сервера Google и CloudFlare поддерживают эти механизмы защиты.
Заключение
Теперь ваша система будет выполнять DNS запросы быстро и эффективно даже если провайдер не работает достаточно быстро. Кроме этого, ваша цифровая жизнь лучше защищена новейшими механизмами защиты DNS запросов.
Как настроить локальный DNS-сервер на Linux?
Если у вашего домашнего или офисного интернет-провайдера медленные серверы имен или ваш сервер выполняет много операций поиска, то вам нужен локальный кеширующий DNS-сервер.
Как мне поможет локальный DNS-сервер?
Кеширующий DNS-сервер работает, выполняя все DNS-запросы, которые обрабатывает ваша система, а затем сохраняя или кэшируя результаты в памяти. Как только результаты кэшируются в памяти, каждый раз, когда вы делаете повторный запрос для домена, результат будет почти мгновенно получен из памяти.
Локальный DNS-сервер не только поможет в вашем доме или офисе, но и на вашем сервере. Если у вас есть приложение, которое выполняет множество операций поиска DNS, например, почтовый сервер, на котором запущено антиспамовое программное обеспечение, оно получит повышение скорости от локального кэширующего DNS-сервера.
Наконец, утилита systemd-resolved поддерживает самые последние, безопасные стандарты DNS DNSSEC и DNSoverTLS или DoT. Они помогают защитить вас и сохранить вашу конфиденциальность в Интернете.
Какой локальный кеширующий DNQS мы будем использовать?
systemd-resolved работает, запустив небольшой локальный кеширующий DNS-сервер, который мы настроим для запуска при загрузке. Затем мы перенастроим остальную часть системы, чтобы направлять их DNS-запросы в DNS-систему с локальным кэшированием.
1. Как проверить, используете ли вы уже systemd-resolved?
В некоторых дистрибутивах Linux по умолчанию уже используется systemd-resolved, например Ubuntu 19.04.
Если вы уже запустили systemd-resolved, вам не нужно включать его или настраивать систему для его использования. Однако вам может потребоваться убедиться, что инструменты управления сетью, такие как NetworkManager, настроены правильно, поскольку они могут игнорировать конфигурацию сети системы.
Прежде чем перейти к следующему разделу, выполните следующую команду, чтобы проверить, запущен ли уже systemd-resolved:
Если вы получили сообщение:
Вы не используете systemd-resolved и должны перейти к следующему разделу. Если вместо этого вы видите вывод, который начинается примерно так:
Тогда вы уже используете systemd-resolved и вам не нужно его включать.
2. Включение и настройка systemd-resolved
Запустите следующую команду в терминале от имени пользователя sudo для запуска systemd-resolved:
Затем выполните следующую команду, чтобы запустить systemd-resolved при загрузке системы:
Откройте основной файл конфигурации с разрешением systemd в вашем любимом текстовом редакторе, здесь я использовал nano:
Измените строку начинающуюся с:
Уберите комментарий со строки и вставьте желаемый Public DNS из списка выше. В моем случае я выберу Cloudflare Public DNS.
Сохраните и выйдите из текстового редактора. Теперь нам нужно перезапустить systemd-resolved, чтобы он начал использовать серверы имен:
systemd-resolved теперь запущен и готов начать обработке и защите DNS-запросов, как только мы настроим систему для ее использования.
Конфигурация системы для использования systemd-resolved
Ваша система может быть настроена несколькими способами для использования systemd-resolved, но мы рассмотрим две конфигурации, которые покрывают большинство случаев использования. Первые два режима системного разрешения сосредоточены вокруг того, как управляется содержимое этого файла. В рекомендуемом режиме /etc/resolv.conf делается символическая ссылка на /run/systemd/resolve/stub-resolv.conf.
Два режима системного разрешения сосредоточены вокруг того, как управляется содержимое этого файла. В рекомендуемом режиме /etc/resolv.conf делается символическая ссылка на /run/systemd/resolve/stub-resolv.conf. Этот файл управляется systemd-resolved и, следовательно, systemd-resolved управляет информацией о конфигурации DNS для всех других программ в системе.
Это может вызвать проблемы, когда другие программы пытаются управлять содержимым /etc/resolv.conf. Режим совместимости оставляет /etc/resolv.conf на месте, позволяя другим программам управлять им, в то время как systemd-resolved использует эту информацию DNS. В этом режиме другие программы, управляющие /etc/resolv.conf, должны быть настроены для установки 127.0.0.53 в качестве системного сервера имен в /etc/resolv.conf.
Настройка рекомендуемого режима
Затем создайте символическую ссылку:
Наконец, перезапустите systemd-resolved:
Настройка режима совместимости
В этом режиме вам нужно убедиться, что локальный сервер имен, запущенный systemd-resolved запущен системными службами. Откройте /etc/resolv.conf в текстовом редакторе. Я использую редактор nano:
Удалите все встречающиеся строки, начинающиеся с «nameserver», и добавьте эту строку:
3. Отладка systemd-resolved
Вставьте следующие строки в редактор, затем сохраните и выйдите:
Служба с разрешением systemd будет автоматически перезагружена при успешном сохранении и выходе.
Откройте второй терминал на том же сервере и просмотрите журнал journald для службы с разрешением systemd:
Строка, которая начинается с «Using DNS server», например:
Сообщает вам, какой именно DNS-сервер используется для DNS-запросов. В этом случае DNS-сервер Cloudflare на 1.1.1.1 был запрошен.
Строки «Cache miss» указывают на то, что доменное имя не было кэшировано. Например:
Строки, начинающиеся с «Positive cache hit», например:
Укажите, что systemd-resolved ранее запрашивал этот домен, и ответ был получен из кэша в локальной памяти.
Вы должны отключить режим отладки, когда вы закончите работать с systemd-resolved, так как он создаст очень большой файл журнала в загруженной системе. Вы можете отключить ведение журнала отладки, выполнив:
4. Использование безопасных DNS-запросов
Эти параметры легко включить, открыв основной файл конфигурации systemd-resolved в текстовом редакторе:
И редактируем файл так, чтобы были установлены следующие две строки:
Сохраните и выйдите из редактора, затем перезагрузите systemd-resolved:
Пока на DNS-сервере вы установили поддержку DNSSEC и DoT, ваши DNS-запросы будут защищены. Оба публичных DNS-сервера Google и Cloudflare поддерживают эти протоколы.
Заключение
Теперь ваша система настроена на быстрое и эффективное выполнение DNS-запросов, даже если DNS-сервер вашего интернет-провайдера не отвечает так быстро, как следовало бы. Кроме того, ваша цифровая активность становится более безопасной, поскольку вы используете новейшие безопасные протоколы DNS для защиты своих запросов.
Настройка Bind как кэширующего или перенаправляющего DNS-сервера в Ubuntu 14.04
DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.
В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.
Требования
Вы научитесь настраивать клиентскую машину для отправки запросов через DNS-сервер.
Кэширующий DNS-сервер
Серверы этого типа также называются определителями, поскольку они обрабатывают рекурсивные запросы и, как правило, могут выполнить поиск данных DNS не других серверах.
Когда кэширующий DNS-сервер отслеживает ответ на запрос клиента, он возвращает ответ клиенту, а также сохраняет его в кэше в течение периода времени, разрешенного значением TTL соответствующих DNS-записей. Затем кэш можно использовать в качестве источника ответов на последующие запросы, чтобы ускорить общее время обработки запроса.
Почти все DNS-серверы в вашей сетевой конфигурации будут кэширующими. Кэширующий DNS-сервер – хороший выбор для многих ситуаций. Если вы не хотите полагаться на DNS-серверы вашего хостинг-провайдера или другие общедоступные DNS-серверы, настройте собственный кэширующий DNS-сервер. Чем меньше расстояние от DNS-сервера к клиентским машинам, тем меньше время обслуживания запросов DNS.
Перенаправляющий DNS-сервер
С точки зрения клиента перенаправляющий DNS-сервер будет выглядеть почти идентично кэширующему серверу, но механизмы и рабочая нагрузка у них совершенно разные.
Перенаправляющий DNS-сервер имеет те же преимущества, что и кэширующий сервер. Однако на самом деле он не выполняет ни одного рекурсивного запроса. Вместо этого он перенаправляет все запросы на внешний разрешающий сервер, а затем кэширует результаты для последующих запросов.
Это позволяет перенаправляющему серверу обслуживать запросы из своего кэша, не обрабатывая при этом рекурсивных запросов. Таким образом, этот сервер обрабатывает только одиночные запросы (перенаправленные запросы клиента), а не всю процедуру рекурсии. Это может быть преимуществом в средах с ограниченной внешней пропускной способностью, в которых необходимо часто менять кэширующие серверы, и в ситуациях, когда нужно перенаправить локальные запросы на один сервер, а внешние – на другой.
1: Установка Bind на DNS-сервер
Пакет Bind можно найти в официальном репозитории Ubuntu. Обновите индекс пакетов и установите Bind с помощью менеджера apt. Также нужно установить пару зависимостей.
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
После этого можно начать настройку сервера. Конфигурацию кэширующего сервера можно использовать в качестве шаблона для настройки перенаправляющего сервера, поэтому сначала нужно настроить кэширующий DNS-сервер.
2: Настройка кэширующего DNS-сервера
Сначала нужно настроить Bind в качестве кэширующего DNS-сервера. Такая конфигурация заставит сервер рекурсивно искать ответы на клиентские запросы на других DNS-серверах. Он будет последовательно опрашивать все соответствующие DNS-сервера, пока не найдет ответ.
Конфигурационные файлы Bind хранятся в каталоге /etc/bind.
Большую часть файлов редактировать не нужно. Главный конфигурационный файл называется named.conf (named и bind – два названия одного приложения). Этот файл ссылается на файлы named.conf.options, named.conf.local и named.conf.default-zones.
Для настройки кэширующего DNS-сервера нужно отредактировать только named.conf.options.
sudo nano named.conf.options
Этот файл выглядит так (комментарии опущены для простоты):
options <
directory «/var/cache/bind»;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;
Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.
Нужно защитить DNS-сервер, обрабатывающий рекурсивные запросы, от злоумышленников. Атаки DNS-усиления особенно опасны, поскольку могут вовлечь сервер в распределенные атаки на отказ в обслуживании.
Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.
Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.
Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).
В этом блоке перечислите IP-адреса или сети, у которых будет доступ к этому DNS-серверу. Поскольку сервер и клиент работают в подсети /24, можно ограничить доступ по этой подсети. Также нужно разблокировать localhost и localnets, которые подключаются автоматически.
Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:
Блок options явно включает рекурсию, а затем настраивает параметр allow-query для использования списка ACL. Для ссылки на группу ACL можно также использовать другой параметр, например allow-recursion. При включенной рекурсии allow-recursion определит список клиентов, которые могут использовать рекурсивные сервисы.
Однако если параметр allow-recursion не установлен, Bind возвращается к списку allow-query-cache, затем к списку allow-query и, наконец, к спискам по умолчанию localnets и localhost. Поскольку мы настраиваем только кэширующий сервер (он не имеет собственных зон и не пересылает запросы), список allow-query всегда будет применяться только к рекурсии. Это самый общий способ определения ACL.
Сохраните и закройте файл.
Это все настройки, которые нужно добавить в конфигурационный файл кэширующего DNS-сервера.
Примечание: Если вы хотите использовать только этот тип DNS, переходите к проверке конфигураций, перезапустите сервис и настройте свой клиент.
3: Настройка перенаправляющего DNS-сервера
Если вашей инфраструктуре больше подходит перенаправляющий DNS-сервер, вы можете немного откорректировать настройку.
На данный момент файл named.conf.options выглядит так:
acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
directory «/var/cache/bind»;
recursion yes;
allow-query < goodclients; >;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;
Можно использовать тот же список ACL, чтобы ограничивать DNS-сервер конкретным списком клиентов. Однако при этом необходимо немного изменить конфигурацию, чтобы сервер больше не пытался выполнять рекурсивные запросы.
Не меняйте значение recursion на no. Перенаправляющий сервер все-таки поддерживает рекурсивные сервисы. Чтобы настроить перенаправляющий сервер, нужно создать список кэширующих серверов, на которые он будет перенаправлять запросы.
Это делается в блоке options <>. Сначала нужно создать в нем новый блок forwarders, где будут храниться IP-адреса рекурсивных серверов имен, на которые нужно перенаправлять запросы. В данном случае это будут DNS-серверы Google (8.8.8.8 и 8.8.4.4):
Далее нужно в директиве forward установить значение only, поскольку сервер должен только перенаправлять все запросы и не пытаться разрешить их самостоятельно.
В результате конфигурация выглядит так:
acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
directory «/var/cache/bind»;
recursion yes;
allow-query < goodclients; >;
forwarders <
8.8.8.8;
8.8.4.4;
>;
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;
Последнее изменение касается параметра dnssec. При текущей конфигурации и в зависимости от настройки DNS-серверов, на которые перенаправляются запросы, в логах могут появиться такие ошибки:
Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving ‘in-addr.arpa/DS/IN’: 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving ‘111.111.111.111.in-addr.arpa/PTR/IN’: 8.8.4.4#53
Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.
Сохраните и закройте файл. Настройка перенаправляющего DNS-сервера завершена.
4: Проверка настроек и перезапуск Bind
Теперь нужно убедиться, что настройки работают должным образом.
Чтобы проверить синтаксис конфигурационных файлов, введите:
Если в файлах нет ошибок, командная строка не отобразит никакого вывода.
Если вы получили сообщение об ошибке, исправьте ее и повторите проверку.
После этого можно перезапустить демон Bind, чтобы обновить настройки.
sudo service bind9 restart
После нужно проверить логи сервера. Запустите на сервер команду:
Теперь откройте новый терминал и приступайте к настройке клиентской машины.
5: Настройка клиента
Войдите на клиентскую машину. Убедитесь, что клиент был указан в группе ACL настроенного DNS-сервера. В противном случае DNS-сервер откажется обслуживать запросы этого клиента.
Отредактируйте файл /etc/resolv.conf, чтобы направить сервер на сервер имен.
Изменения, внесенные здесь, будут сохраняться только до перезагрузки, что отлично подходит для тестирования. Если результаты тестовой настройки вас удовлетворят, вы сможете сделать эти настройки постоянными.
Откройте файл с помощью sudo в текстовом редакторе:
sudo nano /etc/resolv.conf
В файле нужно перечислить DNS-серверы, которые будут использоваться для разрешения запросов. Для этого используйте директиву nameserver. Закомментируйте все текущие записи и добавьте строку nameserver, указывающую на ваш DNS-сервер:
nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3
Сохраните и закройте файл.
Теперь можно отправить тестовый запрос, чтобы убедиться, что он разрешается правильно.
Для этого можно использовать ping:
Это значит, что клиент может подключиться к google.com с помощью DNS-сервера.
Более подробную информацию предоставит инструмент dig. Попробуйте подключиться к другому домену:
Как видите, обработка запроса заняла 36 миллисекунд. Повторите запрос. Сервер должен извлечь данные из кэша, что укорит обработку запроса:
Теперь запрос обрабатывается гораздо быстрее.
Также можно протестировать обратное преобразование. Для этого используйте найденный IP (в данном случае 140.211.169.4) и dig с флагом –x:
Как видите, обратное преобразование выполнено успешно.
Вернитесь на DNS-сервер. Если во время настройки клиента возникли какие-либо ошибки, вы увидите их. К примеру, часто случается такая ошибка:
Это значит, что сервер пытается разрешить данные IPv6, но он не настроен для поддержки IPv6. Чтобы устранить ошибку, нужно настроить Bind для обслуживания только IPv4.
sudo nano /etc/default/bind9
Сохраните и закройте файл.
sudo service bind9 restart
После этого в логах не должно быть ошибок.
Сохранение настроек клиента DNS
Параметры файла /etc/resolv.conf сбрасываются после перезапуска. Чтобы эти настройки использовались на постоянной основе, нужно отредактировать файлы, которые обращаются к этому файлу.
Откройте этот файл:
sudo nano /etc/network/interfaces
Найдите параметр dns-nameservers. Удалите текущую запись и замените ее данными о вашем DNS-сервере или просто добавьте новый DNS-сервер в качестве одного из значений.
Сохраните и закройте файл.
В системах CentOS и Fedora для этого нужно открыть файл /etc/sysconfig/network/network-scripts/ifcfg-eth0:
sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
В нем найдите строки, которые начинаются с DNS. Среди них будет строка DNS1, в ней нужно указать ваш DNS-сервер. Если вы не хотите пользоваться другими DNS-серверами, удалите остальные записи.
Сохраните и закройте файл.
Заключение
Теперь вы умеете настраивать кэширующий и перенаправляющий DNS-сервер. Это поможет вам ускорить обработку DNS-запросов.