Как сделать свой dns сервер
Делаем свой локальный DNS (PDNSD), с блэкджеком и быстрее Google Public DNS
150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).
Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…
Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.
Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.
PDNSD
pdnsd — кэширующий DNS proxy. Помимо банального кэширования DNS запросов (с возможностью жестко задавать минимальный TTL — может быть нужно на очень плохом интернете), он умеет отсылать запрос одновременно на несколько «родительских» DNS серверов, и отдавать клиенту первый вернувшийся ответ.
Именно включение параллельного опроса и дает нам основное преимущество в скорости, т.к. при нахождении результата в кеше любого из провайдеров мы получаем результат очень быстро, и не ждем полного и медленного разресолвивания если у первого провайдера нет ответа в кэше.
Ставится в Ubuntu — банальным apt-get.
Пара моментов в конфиге
В принципе, кэширование можно сделать менее агрессивным (min_ttl=1m например), но за год работы проблем особых не возникло. В случае проблем — при желании можно вытереть одну запись из кэша:
или сразу все:
Результаты тестирования в NameBench
Видим, что для 50% запросов ответ мы получаем менее чем за 10мс, для 85% быстрее Google Public DNS, ну а дальше результаты естественно совпадают с гуглом.
По результатам тестов NameBench нам радостно сообщает:
Как запустить собственный DNS-сервер в локальной сети — CloudSavvy IT
jivacore / Shutterstock.com
Запуск собственного DNS-сервера — отличный способ повысить быстродействие вашей сети, снизить зависимость от общедоступной инфраструктуры и воспользоваться дополнительными функциями, такими как маршрутизация имени хоста. Вот как настроить DNS-сервер на Linux-машине с помощью Dnsmasq.
Что такое DNS?
DNS — это система, которая переводит доменное имя, например example.com, в числовой IP-адрес своего сервера. Это может выглядеть как 127.0.0.1. Всякий раз, когда вы делаете сетевой запрос с использованием доменного имени, ваша система будет выполнять поиск в DNS, чтобы определить адрес сервера, с которым она должна связаться.
Это увеличивает накладные расходы на каждый ваш запрос. Несмотря на то, что ваше устройство будет кэшировать ответы DNS, при посещении новых доменов DNS будет возвращаться до начала фактического запроса. Это происходит на уровне сетевого стека ОС, невидимым для вас как пользователя.
Интернет-провайдеры обычно используют DNS-серверы. Вы, вероятно, полагаетесь на сервер вашего интернет-провайдера, если используете настройки по умолчанию на вашем маршрутизаторе и устройствах. Другие общедоступные DNS-серверы доступны у таких поставщиков, как Cloudflare а также Google.
Зачем нужен собственный DNS?
Использование собственного DNS-сервера дает вам больший контроль над вашей сетью. Одна из распространенных мотиваций — это возможность настроить сопоставление доменов на уровне сети, например, веб-сервер на 192.168.0.101. Настройка маршрутизатора для использования DNS приведет к тому, что любое из ваших подключенных устройств сможет получить доступ к 192.168.0.101 через http: // веб-сервер.
Наличие собственного DNS-сервера позволяет централизовать настройки в одном месте вместо того, чтобы применять их индивидуально в / etc / hosts на каждом устройстве. Они будут применяться ко всему, что вы подключаетесь к своей сети, включая встроенное оборудование, которое не предоставляет другого способа настроить свой стек маршрутизации.
Собственный DNS-сервер также может повысить производительность и обеспечить дополнительный уровень устойчивости. Широкомасштабные сбои DNS не являются чем-то неслыханным; Использование настраиваемого сервера с долговечным кешем для критически важных служб, с которыми вы взаимодействуете, может помочь вам избежать простоев у выбранного вышестоящего провайдера.
DNS с Dnsmasq
Dnsmasq — это легкий DNS-сервер, входящий в состав большинства дистрибутивов Linux. Кроме того, его очень просто настроить.
Перед тем, как начать, стоит подумать о том, какие функции вам нужен ваш DNS-сервер. В этом руководстве мы рассмотрим настройку Dnsmasq с локальным кэшированием, некоторыми маршрутами пользовательских доменов и Google 8.8.8.8 в качестве нашего восходящего DNS-провайдера.
Схема маршрутизации будет выглядеть так:
Вам не нужно будет вносить какие-либо изменения в конфигурацию на ваших клиентских устройствах. Все, что находится за вашим маршрутизатором, в конечном итоге будет делать DNS-запросы через Dnsmasq. Однако стоит отметить, что все популярные настольные и мобильные операционные системы поддерживают настройку DNS-сервера, поэтому вы можете настроить отдельные устройства для использования Dnsmasq, не включая его на уровне маршрутизатора.
Начиная
Мы предполагаем, что у вас уже есть работающая машина Linux, готовая для размещения Dnsmasq. Dnsmasq не особо ресурсоемкий — если у вас мало клиентских устройств, он легко будет работать на Raspberry Pi.
У вашего хозяина должен быть Статический IP назначенный. С этого момента IP 192.168.0.1 относится к серверу Dnsmasq.
Убедитесь, что Dnsmasq установлен:
# Предполагая, что система Debian apt update apt install dnsmasq
Файл конфигурации Dnsmasq обычно находится в /etc/dnsmasq.conf. Это предварительно заполнено начальными настройками. Для эффективной работы Dnsmasq в сценарии локальной сети необходимо внести некоторые изменения. Запустите sudo nano /etc/dnsmasq.conf, чтобы открыть файл, затем используйте сочетание клавиш Ctrl + W, чтобы найти и раскомментировать следующие строки:
Удалите символ # в начале каждой строки. Вот что позволяют эти настройки:
Чтобы настроить исходящий DNS-сервер, добавьте новую строку в файл конфигурации:
сервер = 8.8.8.8 сервер = 4.4.4.4
Это указывает Dnsmasq пересылать неразрешенные запросы в 8.8.8.8. Если этот сервер недоступен, вместо него будет использоваться 4.4.4.4. Эти адреса являются первичными и вторичными преобразователями для службы DNS Google.
Затем настройте размер кеша. По умолчанию это относительно низкое значение — 150 кэшированных запросов. Увеличение этого параметра позволит Dnsmasq обрабатывать больше запросов из кеша, уменьшая задержку в сети. Найдите строку размера кеша, раскомментируйте ее и измените ее значение:
Сохраните и закройте файл сейчас.
Сопоставление имен хостов IP-адресам
Есть несколько разных способов сопоставить имена хостов с их IP-адресами. Самый простой — добавить записи в существующий файл вашего сервера / etc / hosts. Dnsmasq автоматически загружает правила из этого файла как часть своей конфигурации по умолчанию.
Откройте / etc / hosts и добавьте свои маршруты в конец файла. Сначала идет IP-адрес, а затем имя, которое нужно назначить:
192.168.0.101 веб-сервер 192.168.0.105 gateway.lan
Эти строки означают, что любой запрос к веб-серверу http: // будет направлен на адрес 192.168.0.101, а адрес http: //gateway.lan — на адрес 192.168.0.5. Сохраните и закройте файл, когда закончите сопоставление устройств.
Тестирование вашего сервера
Перезапустите Dnsmasq, чтобы применить все ваши изменения:
перезапуск службы sudo dnsmasq
Убедитесь, что сервер работает правильно:
статус службы sudo dnsmasq
Вы должны увидеть, что активный (работает) отображается зеленым цветом. Если вы этого не сделаете, проверьте строки журнала в нижней части информации о состоянии, чтобы выяснить, что не так.
Теперь вы готовы протестировать свой сервер. Вы можете делать попытки поиска DNS вручную с помощью инструмента dig. Возможно, вам сначала потребуется установить пакет dnsutils.
вы google.com @localhost вы gateway.lan @localhost
Обе эти команды должны отображать IP-адрес в РАЗДЕЛЕ ОТВЕТОВ. В случае gateway.lan результат должен быть 192.168.0.5 в соответствии с правилом маршрутизации, установленным в / etc / hosts. Часть команд @localhost инструктирует dig запросить ваш локальный DNS-сервер.
Настройка вашей сети
Последний шаг — настроить сетевой маршрутизатор для поиска DNS через сервер Dnsmasq. В шаги для этого будет варьироваться в зависимости от используемого вами оборудования маршрутизации.
Как только вы найдете страницу с правильными настройками, установите IP-адрес вашего сервера (192.168.0.1 в этом руководстве) в качестве основного DNS-сервера маршрутизатора. Рекомендуется настроить общедоступного поставщика DNS, например Google 8.8.8.8, в качестве вторичного сервера. Это гарантирует, что у вас по-прежнему будет доступ в Интернет, если ваш DNS-сервер выйдет из строя и отключится.
Теперь все устройства, подключенные к вашему маршрутизатору, будут делать DNS-запросы через ваш экземпляр Dnsmasq. Они смогут подключаться к вашим устройствам по назначенным им именам, таким как веб-сервер и gateway.lan, и смогут воспользоваться преимуществами кэширования DNS на сетевом уровне.
Заключение
DNS — сложная тема, но Dnsmasq упрощает запуск базового сервера. Здесь очень много больше настроек который вы можете изучить, когда у вас заработает основная функциональность. Они позволяют фильтровать запросы, управлять ретрансляторами и прокси, запускать сценарии при возникновении событий и настраивать другие типы записей DNS, такие как результаты MX для почтовых серверов.
После запуска Dnsmasq обычно не требует большого ручного вмешательства. Вы можете отслеживать журналы с помощью службы dnsmasq status или systemctl status dnsmasq. Теперь вы готовы использовать свой собственный DNS-сервер, максимизируя производительность и позволяя использовать внутренние доменные имена для доступа к устройствам в локальной сети.
Поднимаем свой DNS-over-HTTPS сервер
Различные аспекты эксплуатации DNS уже неоднократно затрагивались автором в ряде статей опубликованных в рамках блога. При этом, основной акцент всегда делался на повышение безопасности этого ключевого для всего Интернет сервиса.
До последнего времени, несмотря на очевидность уязвимости DNS трафика, который, до сих пор, по большей части, передаётся в открытом виде, для злонамеренных действий со стороны провайдеров, стремящихся повысить своих доходы за счёт встраивания рекламы в контент, государственных силовых органов и цензуры, а также просто преступников, процесс усиления его защиты, несмотря на наличие различных технологий, таких как DNSSEC/DANE, DNScrypt, DNS-over-TLS и DNS-over-HTTPS, буксовал. И если серверные решения, а некоторые из них существуют уже довольно долгое время, широко известны и доступны, то поддержка их со стороны клиентского программного обеспечения оставляет желать много лучшего.
К счастью, ситуация меняется. В частности, разработчики популярного браузера Firefox заявили о планах по включению по умолчанию режима поддержки режима DNS-over-HTTPS (DoH) в ближайшее время. Это должно помочь защитить DNS трафик пользователя WWW от вышеупомянутых угроз, однако потенциально способно вызвать новые.
1. Проблемы DNS-over-HTTPS
На первый взгляд, начинающееся массовое внедрение DNS-over-HTTPS в программное обеспечение работающее в Интернет вызывает только позитивную реакцию. Однако, чёрт, как говорится, кроется в деталях.
Первой проблемой, которая ограничивает сферу массового применения DoH, является его ориентация исключительно на веб-трафик. Действительно, протокол HTTP и его актуальная редакция HTTP/2, на которой базируется DoH, является основой WWW. Но Интернет это не только веб. Существует масса популярых сервисов, такие, как электронная почта, всевозможные мессенджеры, системы передачи файлов, стриминг мультимедиа и проч., которые не используют HTTP. Таким образом, несмотря на восприятие многими DoH как панацеи, он оказывается неприменим без дополнительных (да и не нужных) усилий, ни для чего иного, кроме браузерных технологий. К слову, на эту роль куда как более достойным кандидатом выглядит DNS-over-TLS, который реализует инкапсуляцию стандартного DNS трафика в защищённый стандартный протокол TLS.
Второй проблемой, которая потенциально куда как более значима, чем первая, является фактический отказ от присущей DNS by design децентрализации в угоду использования указываемого в настройках браузера единого DoH сервера. В частности, Mozilla предлагает использовать сервис от Cloudflare. Подобный сервис запустили также и другие заметные фигуры Интернет, в частности Google. Получается, что внедрение DNS-over-HTTPS в том виде, в котором это предлагается сейчас, лишь увеличивает зависимость конечных пользователей от крупнейших сервисов. Не секрет, что информация, которую может предоставить анализ DNS запросов способен собирать ещё больше данных о нём, а также повысить их точность и актуальность.
В этой связи, автор был и остаётся сторонником массового внедрения не DNS-over-HTTPS, а DNS-over-TLS совместно с DNSSEC/DANE как универсального, безопасного и не способствующего дальнейшей централизации Интернет средства для обеспечения безопасности DNS трафика. К сожалению, ожидать быстрое внедрение массовой поддержки альтернатив DoH в клиентский софт в силу понятных причин, не приходится и её уделом пока остаются энтузиасты безопасных технологий.
Но, коль уж мы теперь получаем DoH, то почему бы не использовать его, предварительно уйдя от потенциальной слежки по стороны корпораций посредством их серверов на свой собственный DNS-over-HTTPS сервер?
2. Протокол DNS-over-HTTPS
Если взглянуть в стандарт RFC8484 описывающий протокол DNS-over-HTTPS, то можно увидеть, что он, по сути, представляет собой веб API позволяющий инкапсулировать стандартный пакет DNS в протокол HTTP/2. Это реализуется посредством специальных HTTP-заголовков, а также конверсии бинарного формата передаваемых DNS данных (см. RFC1035 и последующие документы) в форму, позволяющую передавать и получать их, а также работать с необходимыми метаданными.
По стандарту поддерживается только HTTP/2 и защищённое соединение TLS.
Отправка DNS-запроса может производится стандартными методами GET и POST. В первом случае запрос трансформируется base64URL-encoded строку, а во-втором — через тело POST-запроса в двоичной форме. При этом при запросе и при ответе DNS используется специальный MIME-тип данных application/dns-message.
Обратите также внимание на заголовок cache-control: в ответе со стороны веб-сервера. В параметре max-age содержится значение TTL для возвращаемой записи DNS (или минимальное значение если возвращается их набор).
Исходя из вышеизложенного, функционирование DoH сервера состоит из нескольких этапов.
3. Свой DNS-over-HTTPS сервер
Наиболее простым, быстрым и эффективным способом запустить свой собственный DNS-over-HTTPS сервер представляется использование HTTP/2 веб-сервера H2O, о котором автор уже вкратце писал (см. «Высокопроизводительный веб-сервер H2O»).
В пользу этого выбора играет тот факт, что весь код собственного DoH сервра может быть полностью реализован средствами интегрированного в сам H2O интерпретатором mruby. Помимо стандартных библиотек, для обмена данными с DNS сервером необходима библиотека (mrbgem) Socket, которая, по счастью, уже включена в текущую девелоперскую версию H2O 2.3.0-beta2 присутствующую в портах FreeBSD. Впрочем, не трудно добавить её и в любую предыдущую версию клонировав репозиторий библиотеки Socket в каталог /deps перед компиляцией.
Конфигурация веб-сервера, в целом, стандартная.
Исключение составляет лишь обработчик URL /dns-query за который отвечает, собственно, наш DNS-over-HTTPS сервер h2odoh, написанный на mruby и вызываемый через опцию обработчика mruby.handler-file.
Обратие внимание, что за обработку пакетов DNS отвечает локальный кэширующий сервер, в данном случае Unbound из стандратной поставки FreeBSD. С точки зрения безопасности это оптимальное решение. Впрочем, ничто не мешает заменить localhost на адрес другого DNS, который вы предполагаете использовать.
Отстаётся перезапустить H2O и посмотреть что же из этого получилось.
4. Тестирование
Итак, проверим результаты отправив вновь пробный запрос и посмотрев сетевой трафик при помощи утилиты tcpdump.
В выводе видно, как запрос на разрешение адреса example.com был получен и успешно обработан DNS сервером.
Теперь осталось активировать наш сервер в браузере Firefox. Для этого на страницы конфигурации следует изменить несколько настроек about:config.
Во-первых, это адрес нашего API по которому браузер будет запрашивать в DNS информацию в network.trr.uri. Рекомендуется также указать IP домена из этого URL для безопасного разрешения в IP средствами самого браузера без обращения к DNS в network.trr.bootstrapAddress. И, наконец, собственно сам параметр network.trr.mode включающий использование DoH. Установка значения в «3» заставит браузер использовать исключительно DNS-over-HTTPS для разрешения имён, а более надёжное и безопасное «2» отдаст приоритет DoH отставив стандартное обращение к DNS в качестве резервного варианта.
5. PROFIT!
Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через форму доната (ниже).
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Применение фильтрующих DNS-серверов получило широкое распространение в последние годы, существует множество сервисов, преимущественно платных, предоставляющих возможность фильтрации запросов по определенным правилам. Обычно это блокировка рекламы, вредоносных сайтов и сайтов с нежелательным содержимым. Также пользователь может добавлять собственные фильтры. Но используя подобные сервисы следует понимать, что они могут собирать и использовать ваши запросы в собственных целях, например, для показа таргетированной рекламы. Особенно это касается бесплатных служб.
Установка Pi-hole
Pi-hole обладает достаточно скромными системными требованиями и, как можно предположить из названия, изначально предполагалась к установке на Raspberry Pi, это возможно и сегодня. Кроме того, поддерживается гораздо более широкий набор платформ, включая Docker. Из интересующих нас это Ubuntu 16.x / 18.x / 20.x архитектуры ARM / x86_64 и Debian 9 / 10 архитектуры ARM / x86_64 / i386. Из требований от 2 ГБ свободного пространства (рекомендуется 4 ГБ) и от 512 МБ ОЗУ.
Перед установкой поднимем права до суперпользователя командой:
Затем обновим список пакетов и выполним апгрейд системы:
И установим, если это не было сделано ранее, пакет curl:
Также обязательно настройте на вашем сервере статический IP-адрес. В последних версиях Ubuntu для этого следует использовать netplan.
Выполнив все предварительные настройки приступим к установке Pi-hole:
Данная команда скачает и запустит скрипт установки, после чего вы увидите псевдографический инсталлятор, который последовательно проведет вас через все этапы установки продукта. Сначала вам потребуется указать сетевой интерфейс, на котором DNS-сервер будет принимать запросы, будьте внимательны и указывайте только внутренние интерфейсы.
Затем укажите желаемого DNS-провайдера, который будете использовать в качестве вышестоящего сервера, в списке присутствуют основные публичные DNS-сервера, но после установки вы всегда сможете изменить эти настройки, в т.ч. указав собственные адреса.
Затем предлагается выбрать списки для блокировки рекламы (основное назначение Pi-hole по задумке разработчиков), в настоящий момент доступен только один список.
Соглашаемся с установкой веб-интерфейса:
И предлагаемым режимом работы веб-сервера, в качестве которого выбран легковесный, но производительный lighttpd:
Разрешаем ведение лога запросов:
После окончания работы инсталлятора установим пароль для веб-интерфейса:
Командный интерфейс Pi-hole достаточно информативный и наглядно показывает результат той или иной операции.
Для нормальной работы веб-интерфейса выполним еще ряд операций. Прежде всего установим владельца и новый набор прав на конфигурационные файлы и базы данных, если этого не сделать, то веб-интерфейс будет работать только на чтение, а при попытке создать любой новый объект вы получите ошибку: Error, something went wrong! While executing: attempt to write a readonly database.
Затем включим пользователя веб-сервера в группу pihole:
На этом установку можно считать законченной.
Начало работы с Pi-hole
Далее мы будем рассматривать работу через веб-интерфейс, который достаточно удобен и позволяет использовать все возможности продукта, не прибегая к командной строке. Чтобы попасть в панель управления наберем в адресной строке браузера http://IP_ADDRESS/admin
Начнем с раздела Settings, где расположены общие настройки сервера. Вкладка System содержит информацию о системе, кнопки для ее выключения и перезагрузки, выключения и очистки логов, перезагрузки DNS-сервера и очистки сетевой таблицы, куда помещаются MAC-адреса клиентских устройств.
Так как Pi-hole содержит под капотом хорошо известный нашим читателям dnsmasq, то кроме функции DNS-сервера он может также выступать DHCP-сервером вашей сети. По умолчанию DHCP-сервер выключен, вы можете включить и настроить его на одноименной вкладке, запутаться там определенно негде, настройки не сложнее чем в бытовом роутере.
И наконец на вкладке Teleporter можно выполнить резервное копирование и восстановление сервера, причем восстановление можно производить выборочно, например, восстановить только определенные списки или записи.
Если вы будете использовать Pi-hole в качестве основного DNS-сервера сети, то в разделе Local DNS можно добавлять собственные записи типа A или CNAME, после добавления не забывайте перезапустить DNS-сервер.
Для обновления следует либо выполнить в консоли команду:
Для обновления самого Pi-hole следует выполнить консольную команду:
Делать это можно даже из-под обычной учетной записи, в этом случае будет запрошен пароль sudo и повышение прав произойдет автоматически.
Затем внизу, в списке уже добавленных клиентов, в поле Group assignment укажите членство в желаемых группах. Возможен множественный выбор.
Также вы можете просто указать MAC или IP-адрес клиента, имя хоста, подсеть или интерфейс. Например, если у вас подключено несколько сетевых карт, то можно явно указать, что все запросы от клиентов с eth0 попадают в одну группу, а запросы с eth1 в другую. Затем перейдем к подключенным спискам и точно также укажем для каких групп они применяются.
Точно также мы можем добавить домены в белый список, который будет исключать их из блокировки вне зависимости от наличия в списках. Добавить домены в списки вы можете также в разделах Whitelist и Blacklist, но для того, чтобы назначить их группам вам все равно придется вернуться в Domain management, поэтому лучше все действия изначально выполнять здесь.
Добавили, проверяем. Как видим, все отлично работает.
Разрешенные домены добавляем в белый список и привязываем к этой же группе.
Но не все сайты будут нормально работать в таком режиме. Где-то поедет верстка, где-то пропадет важная функциональность. В этом случае нужно выявить связанные ресурсы и также добавить их в белый список. Например, на нашем сайте используется внешняя система комментариев Disqus, чтобы разблокировать ее перейдем в Query Log и внимательно изучим лог запросов, в котором обязательно обнаружатся связанные с интересующим нас узлом записи. Прямо отсюда добавляем их в белый лист, проверяем работу сайта и снова изучаем лог, последовательно разрешая связанные ресурсы до тех пор, пока сайт не начнет работать так, как нам надо.
Заключение
Как мы могли убедиться, Pi-hole это гораздо больше, чем просто блокировка рекламы. Фактически вам в руки попадает удобный и мощный фильтрующий DNS-сервер, который можно использовать в самых различных сценариях управления доступом к сети интернет, включая самые жесткие. Управлять всем этим полноценно можно из удобной веб-панели, что позволяет значительно снизить порог входа для освоения продукта и не требовать от оператора обязательного знания Linux-систем. В тоже время под капотом находятся понятные и привычные инструменты, а следовательно, опытный администратор будет иметь полный контроль над собственной системой.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 