Кэширующий dns сервер для linux

Серверы Linux. Часть III. Сервер DNS

Глава 4. Вводная информация о серверах DNS

4.3. Кэширующие серверы DNS

Сервер DNS , не обслуживающий зону DNS , но соединенный с другими серверами имен для кэширования запросов, называется кэширующим сервером DNS . Кэширующие серверы DNS не работают с базами данных зон DNS , содержащими ресурсные записи. Вместо этого они соединяются с другими серверами имен и кэшируют соответствующую информацию.

Существует два вида кэширующих серверов DNS. Это серверы DNS, использующие перенаправляющие серверы DNS , а также серверы DNS, использующие корневые серверы DNS .

4.3.1. Кэширующий сервер DNS, не использующий перенаправляющий сервер

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

На иллюстрации ниже показан процесс отправки клиентом запроса информации об IP-адресе для доменного имени linux-training.be. Наш кэширующий сервер соединится с корневым сервером и будет перенаправлен на сервер, обслуживающий домен верхнего уровня .be. После этого он соединится с сервером, обслуживающим домен верхнего уровня .be, и будет перенаправлен на один из серверов имен организации Openminds. Один из этих серверов имен (в данном случае nsq.openminds.be) ответит на запрос, передав IP-адрес сервера с доменным именем linux-training.be. После того, как наш кэширующий сервер передаст данную информацию клиенту, клиент сможет соединиться с рассматриваемым веб-сайтом.

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

4.3.2. Кэширующий сервер DNS, использующий перенаправляющий сервер

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

На иллюстрации выше показан сервер DNS в локальной сети компании, который использует предоставляемый интернет-провайдером сервер DNS в качестве перенаправляющего сервера DNS . В том случае, если IP-адресом предоставляемого интернет провайдером сервера DNS является адрес 212.71.8.10, в файле конфигурации named.conf сервера DNS компании должны присутствовать следующие строки:

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

4.3.3. Итеративный или рекурсивный запрос

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

4.4. Авторитативные серверы DNS

Сервер DNS, осуществляющий управление зоной DNS, называется авторитативным сервером DNS ( authoritative DNS server ) для данной зоны. Помните о том, что зона DNS является всего лишь набором ресурсных записей .

4.5. Первичные и вторичные серверы DNS

Первый авторитативный сервер DNS для зоны DNS называется первичным сервером DNS ( primary DNS server ). Этот сервер будет работать с копией базы данных зоны DNS , доступной как для чтения, так и для записи. При необходимости повышения сохранности данных в случае сбоев, повышения производительности сервера или балансировки нагрузки вы можете ввести в строй другой сервер DNS , который также будет управлять данной зоной DNS. Этот сервер будет называться вторичным сервером DNS ( secondary DNS server ).

4.6. Процесс передачи данных зон DNS

Вторичный сервер получает копию базы данных зоны DNS от первичного сервера в процессе передачи данных зоны DNS ( zone transfer ). Запросы осуществления передач данных зон DNS отправляются вторичными серверами через определенные временные интервалы. Длительность этих временных интервалов устанавливаются в рамках ресурсной записи SOA .

Вы можете инициировать принудительное обновление данных зоны DNS с помощью утилиты rndc . В примере ниже инициируется передача данных зоны DNS fred.local , а также выводится соответствующий фрагмент файла системного журнала /var/log/syslog .

4.7. Ведущие и ведомые серверы DNS

При добавлении вторичного сервера DNS в зону DNS вы можете настроить этот сервер таким образом, что он окажется ведомым сервером DNS ( slave DNS server ) по по отношению к первичному серверу . Первичный же сервер DNS окажется ведущим сервером DNS ( master DNS server ) по отношению к вторичному серверу.

Чаще всего первичный сервер DNS является ведущим сервером , работающим со всеми ведомыми серверами. Иногда ведомый сервер может являться одновременно и ведущим сервером для ведомых серверов следующего уровня. На иллюстрации ниже сервер с именем ns1 является первичным сервером, а серверы с именами ns2, ns3 и ns4 — вторичными серверами. Хотя ведущим сервером для серверов с именами ns2 и ns3 и является сервер с именем ns1, ведущим сервером для сервера с именем ns4 является сервер с именем ns2.

4.8. Ресурсная запись SOA

Ресурсная запись SOA содержит значение частоты обновления данных зоны DNS с именем refresh . В том случае, если это значение устанавливается равным 30 минутам, ведомый сервер будет отправлять запросы на передачу копии данных зоны DNS через каждые 30 минут. Также данная запись содержит значение продолжительности периода ожидания с именем retry . Данное значение используется в том случае, если ведущий сервер не отвечает на последний запрос передачи данных зоны DNS. Значение с именем expiry time устанавливает период времени, в течение которого ведомый сервер может отвечать на запросы от клиентов без обновления данных зоны DNS.

Ниже приведен пример использования утилиты nslookup для чтения данных ресурсной записи SOA зоны DNS (linux-training.be).

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

Ниже приведен снимок окна сниффера Wireshark с данными, перехваченными в процессе передачи данных зоны DNS.

4.9. Полные или частичные передачи данных зон DNS

Передача данных зоны DNS может быть как полной, так и частичной. Решение об использовании того или иного режима зависит от объема данных, который необходимо передать для полного обновления базы данных зоны DNS на ведомом сервере. Частичная передача данных зоны предпочтительна в том случае, когда полный объем измененных данных меньше объема всей базы данных. Полные передачи данных зон DNS осуществляются с использованием протокола AXFR , а частичные передачи данных зон DNS — с использованием протокола IXFR .

Источник

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Установка локального сервера кеширования DNS на Linux

Время поднимать кэширующий сервер

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

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Как кэширующий DNS-сервер может пригодиться?

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

Эта идея может показаться бесполезной. Подумаешь, какие-то там секунды. Но если DNS сервера провайдера тратят много времени на разрешение имени, то в результате падает скорость Интернет серфинга. Например, домашняя страница новостного канала MSNBC для корректной работы обращается более чем к 100 уникальным доменам. Даже если на запрос тратится одна десятая секунды, в итоге получается 10 секунд ожидания, что по нынешним меркам слишком много.

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

И наконец, system-resolved поддерживает новейшие стандарты вроде DNSSEC и DNSoverTLS или DoT. Эти технологии увеличивают безопасность при работе в Интренет.

Какой локальный кэширующий сервер выбрать?

В этом руководстве будет использован сервер systemd-resolved . Эта утилита является частью набора управления системой systemd . Если в вашей системе используется systemd , а большинство дистрибутивов Linux используют это, то в системе уже установлен systemd-resolved , но не запущен. Большинство систем не используют эту утилиту.

systemd-resolved запускает небольшой локальный кэширующий DNS-сервер, который мы настроим на запуск при загрузке системы. Затем мы изменим конфигурацию всей системы так, чтобы DNS запросы шли на локальный сервер.

Как проверить используется ли systemd-resolved?

В некоторых дистрибутивах, например Ubuntu 19.04, по умолчанию используется systemd-resolved .

Если у вас уже запущен systemd-resolved , тогда не нужно что-то настраивать в системе. Но нужно проверить на корректность утилит управления сетевыми настройками, такие как NetworkManager, так как они могут игнорировать системные настройки сети.

Перед тем как перейти к следующему разделу проверьте запущен ли в вашей системе systemd-resolved :

Если в ответ получите сообщение ниже, значит в системе не настроен systemd-resolved :

И наоборот, если на выходе видите что-то подобное, то systemd-resolved уже работает:

Включение и настройка systemd-resolved

Отдельно устанавливать systemd-resolved не нужно, так как этот сервис является частью systemd . Всё что нужно сделать это запустить его и добавить в автозагрузку. Для включения данной службы введите команду ниже:

Далее нужно ввести следующую команду, чтобы добавить службу в автозапуск.

И наконец нужно прописать DNS сервера, куда будет обращаться локальный сервер для разрешения имен. Есть много разных сервисов, но приведённые ниже самые быстрые, бесплатные и оба поддерживают DNSSEC и DoT:

Google Public DNS

Cloudflare Public DNS

Для этого откройте конфигурационный файл systemd-resolved любым текстовым редактором:

Отредактируйте строку, которая начинается на:

И пропишите одну из вышеуказанных пар. Мы используем Cloudflare Public DNS:

Сохраните изменения и перезапустите службу systemd-resolved :

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

Настройка системы для использования systemd-resolved

Есть несколько путей настройки системы на использование локального DNS сервера. Мы рассмотрим два наиболее используемых метода. Первый – рекомендуемый метод, второй конфигурация в режиме совместимости. Разница в том, как будет обрабатываться файл /etc/resolv.conf .

В файле /etc/resolv.conf содержатся IP адреса серверов разрешения имен, которые используются программами. Программы при необходимости разрешения доменного имени обращаются к этому файлу в поисках адресов серверов разрешения имен.

Итак, первый метод конфигурации заключается в создании символьной ссылки на /run/systemd/resolve/stub-resolv.conf . В этом случае файл /etc/resolv.conf управляется службой systemd-resolved .

Это может вызвать проблемы в том случае, если другие программы пытаются управлять файлом /etc/resolv.conf . Режим совместимости оставляет /etc/resolv.conf не тронутым, позволяя программам управлять им. В этом режиме, в настройках программ, управляющих файлом /etc/resolv.conf в качестве системного сервера разрешения имен должен быть указан IP 127.0.0.53 .

Конфигурация в рекомендуемом режиме

При этом режиме конфигурация проводится вручную. Сначала нужно удалить или переименоваться оригинальный файл /etc/resolv.conf . Лучше переименовать, чтобы при необходимости можно было использовать информацию в нем

Затем создаем символьную ссылку:

И наконец перезапускаем службу systemd-resolved :

Настройка в режиме совместимости

В режиме совместимости, нужно убедиться, что локальный сервер разрешения имен system-resolved запущен и используется системными службами. Откройте файл /etc/resolv.conf любым редактором:

Удалите все строки, которые содержать ключевое слово nameserver и добавьте одну единственную строку:

Этот файл мажет быть изменён любой программой. Чтобы предотвратить это нужно настроить программы так, чтобы в качестве DNS они использовали адрес 127.0.0.53 .

Отладка systemd-resolved

Посмотреть, как система выполняет DNS запросы после внесённых изменений сложно. Самый эффективный метод – это включить режим отладки для службы 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 :

Измените файл следующим образом:

Сохраните изменения и перезапустите службу systemd-resolved .

Пока прописанные DNS сервера поддерживают эти две функции все DNS запросы будут защищены. DNS сервера Google и CloudFlare поддерживают эти механизмы защиты.

Заключение

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

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Источник