Кэширующий dns сервер windows

Многим из нас знакома ситуация, когда DNS сервер провайдера выходит из строя. Из-за такой мелочи не работает ни почта, ни серфинг, вообще ничего.
Но решение есть ! Это кеширующий DNS сервер.
Ставить будем ISC BIND. Стоп ! Скажете Вы. Он же под UNIX ! А вот и нет ! Точнее да, под UNIX, но есть и порт под Windows.
Вот его мы и будем ставить.

Предупреждаю сразу — никаких окошек типа «кликни сюда, потом сюда» Вы не увидите. Ну только одно, при установке.
Всю настройку придется проводить, вручную редактируя файлы конфигурации.
Настоящие сисадмины не любят пропахшие мышами интерфейсы ! (С) не помню кто

Итак, сначала выкачиваем бинарники отсюда: http://ftp.isc.org/isc/bind/contrib/ntbind-9.3.2/BIND9.3.2.zip
Распаковываем, видим кучу exe-шников и других файлов и… правильно, ни малейшего наменка на setup.exe
Но есть BINDInstall.exe. Вот его-то мы и запустим.
Что мы видим ?
Target directory — куда ставим. Дабы потом не было разночтений по путям согласимся.
Service account name — имя юзера, из-под которого будет работать служба BIND. Логично оставить как есть.
Service account password — пароль юзера.
Confirm Service account password — подтверждение пароля.
Группа Options:
Automatic startup — стартовать службу при запуске Windows
Keep config files after uninstall — оставить Ваши бесценные файлы конфигурации после деинсталляции (например при апгрейде на новую версию).
Start BIND service after install — не ставить, службу запустите после создания файлов конфигурации.

Заполняем поля пароля, подтверждаем его в поле confirm… и давим Install.
Процесс протекает быстро, должно появиться окошко типа completed successfully.
Типа все OK Если нет, значит, скорее всего — у вас нет прав администратора на этой машине.

Переходим в каталог, куда поставили BIND (проводник не рекомендуется, лучше Far или WIndows Commander).
Видим два каталога bin и etc. В bin лежат exe файлы, а вот в etc файлы конфигурации. Точнее, должны лежать.
Мы сейчас займемся их созданием. Дабы Вам не заниматься этим самостоятельно, я приготовил заготовки.
Остались от предыдущей версии. Создаем в C:\WINDOWS\system32\dns еще один каталог — namedb.
Там будут лежать наши «файлы зон» — базы данных с информацией о зонах.
В etc — файлы конфигурации, говорящие BIND о там, как эти файлы зон использовать. Ну и вообще что делать и как.
Главный файл — named.conf Вот его заготовка:

———————————— cut here —————————————-——————

acl corpnets { 127.0.0.1; 192.168.1.0/24; };
options {
            directory «c:/windows/system32/dns/namedb»; // Working directory
            allow-query { corpnets; };
            pid-file «c:/windows/system32/dns/named.pid»;
           forwarders { 194.8.160.90; 195.131.52.130; 81.222.160.251; };
};

key «rndc-key» {
            algorithm hmac-md5;
            secret «y6ENOS2cmUeO4yR8STYU9Q==»;
};

controls {
            inet 127.0.0.1 port 953
            allow { 127.0.0.1; } keys { «rndc-key»; };
};

// Provide a reverse mapping for the loopback address 127.0.0.1
zone «0.0.127.in-addr.arpa» {
             type master;
             file «localhost.rev»;
             notify no;
};

zone «20.30.172.in-addr.arpa» {
             type master;
             file «172.20.30.rev»;
             notify no;
};

zone «1.168.192.in-addr.arpa» {
            type master;
            file «192.168.3.rev»;
           notify no;
};

zone «.» {
           type hint;
           file «root.hints»;
};

zone «voskova.net» {
          notify no;
          type master;
          file «voskova.net»;
};
———————————— cut here —————————————-——————

Небольшие пояснения, чтобы было легче разобраться в этой абракадабре
acl corpnets — прописываем IP адреса сетей, которым дозволено пользоваться нашим DNS сервером.
Опции (блок options):
directory — рабочий каталог — здесь BIND будет работать. Относительно этого каталога указываются имена файлов в описании зон.
allow-query { corpnets; } — разрешаем пользоваться нашим DNS сервером только тем, кто прописан в acl corpnets.
pid-file «c:/windows/system32/dns/named.pid» — в этом файле BIND будет «отмечаться» — записывать в него свой Process ID (PID).
forwarders { 194.8.160.90; 195.131.52.130; 81.222.160.251; } — DNS сервера Вашего провайдера (в данном случае — Web Plus) и еще не помню чей.
Именно этим серверам Ваш BIND будет направлять запросы, если не найдет в кеше.
key «rndc-key» Этот блок описывает ключ для управления BIND (перезапуск / остановка сервиса, перезагрузка зон и тд)
controls — Здесь описываем тех, кому позволено управлять Вашим BIND через программу rndc (см. rndc-key)

Дальше идут описания зон.
zone «0.0.127.in-addr.arpa» — Обратная или reverse зона (для преобразования адреса в имя) для петлевого интерфейса (loopback)
                                              Как Вы можете видеть имя зоны состоит из IP адреса, записанного наоборот — это общепринятое правило.
zone «1.168.192.in-addr.arpa» — то же, но для локальной сети
zone «.» — а вот это самое главное — то, ради чего весь сыр-бор Кеш DNS сервера. 
               Если Вы внимательно рассмотрели описания зон, то могли заметить, что все они имеют type master — 
               т.е. Ваш DNS сервер является «мастером» для этих зон.
              Другими словами, он за них отвечает.
              Для этой же прописан тип «hint» — это и есть кеш.

zone «voskova.net» — Это описание моей домашней зоны. Это описание прямой зоны — для преобразования имен в IP адреса.
                                В данном случае voskova.net
                                Абсолютно необязательная вещь.  В большинстве случаев достаточно обратной зоны и кеша. 
                                Здесь это только для примера.

Теперь займемся заполнением файлов зон.
Начнем по порядку, сначала localhost.rev Как Вы могли заметить — это тот самый loopback

———————————— cut here —————————————-——————
$TTL 1D
@ IN SOA dmitry.voskova.net. admin.voskova.net. (
                   1 ; Serial
                   8H ; Refresh
                   2H ; Retry
                   1W ; Expire
                   1D) ; Minimum TTL

                   NS       dmitry.voskova.net.
1                PTR         localhost.
———————————— cut here —————————————-——————
Пояснения:
Первая строка — $TTL 1D — время жизни зоны (в данном случае — 1 день). По истечечении времени жизни зона считается устарешей и BIND снова считывает данные из файла зоны.
Далее идут записи данных зоны. Самая интересная и сложная — SOA (Start of authority) — начало полномочий. Сюда надо прописать (вместо dmitry.voskova.net.) имя Вашего компьютера и домена. Если у Вас нет своего домена — можете прописать все, что душе угодно — лишь бы не «пересечься» с уже имеющимися. Все равно их никто кроме Вас не увидит — помните про acl corpnets ?
Скажу сразу — домена voskova.net не существует
Обратите внимание: имя машины имеет на конце точку. Так надо делать всегда, если не хотите потом удивляться странным эффектам.
Вместо admin.voskova.net. поставьте Ваш e-mail адрес, заменив @ на точку, т.к. символ @ здесь недопустим.
А вот далее идут не совсем понятные числа — оставьте как есть — если надо будет — Яндекс Вам в помощь.
NS запись — имя DNS сервера, отвечающего за зону. Опять обратите внимание на точку в конце имени хоста !
Ну и последняя запись — для IP адреса 127.0.0.1 (Помните как записано имя зоны ? Если слева добавить 1, то как раз и получится перевернутый адрес 127.0.0.1).
Ну и тип записи — PTR (Pointer)

С остальными файлами зон надеюсь, разберетесь сами. Вот они:
Это 192.168.1.rev
———————————— cut here —————————————-——————
$TTL 1D
@ IN SOA dmitry.voskova.net. admin.voskova.net. (
                   5 ; Serial
                   8H ; Refresh
                   2H ; Retry
                   1W ; Expire
                   1D) ; Minimum TTL
                   NS dmitry.voskova.net.
1                PTR                 gw.voskova.net.
———————————— cut here —————————————-——————
gw.voskova.net. -общепринятое название шлюза (gateway). Это мой ADSL модем.

А вот так выглядит прямая зона. Файл voskova.net
———————————— cut here —————————————-——————
$TTL 1D
@ IN SOA ns.voskova.net. admin.voskova.net. (
                   5 ; serial
                   8H ; refresh, seconds
                   2H ; retry, seconds
                  1W ; expire, seconds
                  1D ) ; minimum, seconds
;
               NS ns ; Internet адрес сервера имен
               MX 10 mail.voskova.net. ; Основной почтовый сервер
;
localhost A         127.0.0.1
ns           A         192.168.1.2
mail        A         192.168.1.2
dimka     A         192.168.1.2
———————————— cut here —————————————-——————
Как Вы можете видеть, здесь имена хостов и IP адреса поменялись местами и тип записи другой — A
И присутствует запись типа MX — Mail eXchanger — почтовый сервер. Число после MX — приоритет. Чем меньше — тем приоритетнее.

Да, в каталоге etc присутствуют еще 2 файла со странным содержимым. Это описание тех самых «секретных ключей» для управления BIND.
Вот они:
Файл rndc.conf
———————————— cut here —————————————-——————

key «rndc-key» {
 algorithm hmac-md5;
 secret «y6ENOS2cmUeO4yR8STYU9Q==»;
};

options {
 default-key «rndc-key»;
 default-server 127.0.0.1;
 default-port 953;
};

———————————— cut here —————————————-——————
Файл rndc.key
———————————— cut here —————————————-——————
key «rndc-key» {
 algorithm hmac-md5;
 secret «CF6QioSLhWyaw13P3VYsOg==»;
};
———————————— cut here —————————————-——————

Пока создайте их так, как видите — позже разберетесь что к чему.
Рекомендую прочесть файл readme1st.txt в каталоге bin — если с английским нет проблем.
Там описано как создавать такие файлы.

И еще одна деталь. Как Вы могли заметить, я не стал описывать файл root.hints, а ведь без него Вы Интернет не увидите. Не увидите потому, что в этом файле описаны корневые DNS сервера. А не стал потому, что его можно скачать тут: ftp://ftp.internic.net/domain/named.root. Его необходимо положить в каталог namedb под именем root.hints.
Не забывайте периодически обновлять его, так как IP адреса серверов могут меняться. Каждый день конечно не стоит, но раз в месяц не повредит.

Теперь настало время навести последний лоск — и в путь !
Здесь нас поджидает засада N1 — дядя  Билли решил, что «нефик простым юзерам» видеть то, что им не положено и прикрыл доступ к некоторым «фичам». Откроем эти фишки. Проводник -> Меню «Сервис» -> Свойства папки -> Вид. Снимаем галку «Использовать простой общий доступ к файлам и папкам». Жмем OK.
Далее проводником доберемся до папки, куды засунули BIND (помните ?). Свойства этой папки -> Вкладка «Безопасность». Жмем «Добавить», в поле ввода вписываем named — помните, у нас от него должен работать BIND? Жмем OK,  даем named полный доступ к этой папке.
Иначе BIND работать не будет.
Засада N2 — не обязательно, но желательно — пароль который пользователю named необходимо прописать в конфигурации нашего сервиса.
Мой Компьютер -> Управление -> Службы и приложения -> Службы.
Видим службу ISC BIND. Свойства. Вкладка «вход в систему». Здесь пишем пароль пользователя BIND. Если успели забыть (не мудрено — столько мучений Локальные пользователи и группы -> Пользователи, выбираем нашего named, правой кнопкой, задать пароль.

А теперь, как говорилось в известном анекдоте «мы постараемся со всей этой фигней взлететь».
Пытаемся запустить службу ISC BIND, и… Как правило (или по закону подлости) с наскока запуск не удается.
В таком случае ищите сообщения об ошибках в журнале событий. Ищите строчки, отмеченные красным крестом и в поле «Источник» будет написано named. Внимательно читем что пишут и исправляем ашипки и ачепятки.
Если служба стартовала, все равно рекомендую заглянуть в журнал, должны появиться записи, извещающие нас о запуске службы, загрузке зон и тд.

Уффф. На сегодня все. Настройка клиентских ПК и тестирование отложим до завтра.
To be continued……….

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

Шаг первый. Кеширование DNS запросов.

Существуют различные программы для этой цели. Так как я противник комбайнов, где «все включено», мне болле симпатична следующая программа.
Deadwood — легкий(~35 kB) локальный DNS сервер, с функцией кеширования. Официально работает в Windows XP и CentOS Linux, другие ОС под вопросом.

Утановка проста. Разархивировав в нужную папку, достаточно установить службу выполнив в командной строке:
Deadwood —install
Для того, чтобы удалить, достаточно выполнить Deadwood —remove, предварительно остановив службу.

После установки, редактируем файл настроек dwood2rc.txt Запуская нашу службу с параметром:
-f file
в качестве файла настроек будет использоваться file

В кратце про используемые параметры:
upstream_servers — список DNS серверов к которым будут отсылаться запросы. Здесь можно указать DNS сервер провайдера, либо любой другой, какой нам симпатичен. Пусть будет = 208.67.222.222, 208.67.220.220 — сервис OpenDNS.
Тут есть одна интересная особенность в данном параметре. Он реализован как словарь переменных. Строку инициализации данного словаря можно увидеть в начале файла конфигурации:
upstream_servers = {}
Преймущества: для любого домена можно указать свой сервер.
Пример, если добавить после строки инициализации данное значение:
upstream_servers[«google.com.»] = «8.8.8.8»
все заканчивающееся на «google.com» будет запрашиваться у DNS сервера «8.8.8.8», а все остальное, согласно следующей строки, у OpenDNS!
bind_address — IP адрес нашего локального сервера. Так как, пока, не будем использовать в роли кеширующего сервера домашней сети — укажем равным 127.0.0.1
recursive_acl — список адресов, кому разрешено использовать данный DNS сервер. Пока, он будет использоваться как локальный сервер, разрешим тоько локальные соединения(в формате IP/маска) = 127.0.0.1/8.
random_seed_file — файл, со случайным содержимым. Deadwood прочитает оттуда только 256 первых байт. Желательно, для безопасности, чтобы содержимое данного файла изменялось при каждом входе в систему.
cache_file — в данном файле будет храниться кешируемая информация. В имени файла могут быть только прописные латинские буквы, символы «-» и «_», и для указания подпапки «/», все остальные символы должны быть заменены на «_».
Теперь можно запустить службу. Для Windows 2k и выше команда:
net start deadwood
После успешного запуска службы в папке программы будет создан лог файл — dwlog

Также, интересны и полезны могут быть некоторые ключи.
chroot_dir — пака из которой запускается служба;
dns_port — наш сервер будет слушать данный порт;
ip_blacklist — список нежелательных IP адресов;
max_inflights — максимальное количество одновременно обслуживаемых клиентов (по умолчанию 8);
maximum_cache_elements — максимальное количество кешируемых элементов (по умолчанию 1024);
Для защиты от атак, порт исходящих запросов постоянно меняется, настроить данную функцию помогут следующие два параметра:
recurse_min_bind_port — номер наименьшего порта с которого будет наш сервер отсылать запросы (по умолчанию 15000);
recurse_number_ports — количество исходящих портов (по умолчанию 4096).

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

Предварительная подготовка
Настройка файла конфигурации
Режим совместимости
Откат к старому методу разрешения имен

Окружение

• Версия РЕД ОС: 8
• Конфигурация: Рабочая станция, Сервер графический, Сервер минимальный
• Версия ПО: systemd-251.13-2

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

systemd-resolved поддерживает такие стандарты, как DNSSEC и DNSoverTLS (или DoT), которые увеличивают безопасность при работе в сети Интернет.

systemd-resolved входит в состав пакета systemd, который установлен в РЕД ОС по умолчанию.

Предварительная подготовка

Для настройки службы systemd-resolved используется конфигурационный файл /etc/systemd/resolved.conf.

Для проверки DNS-серверов, используемых systemd-resolved в данный момент, выполните команду:

resolvectl status

В ответе команды должно отображаться примерно следующее:

Global
       Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp0s3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.1 
       DNS Servers: 192.168.0.1 192.168.0.251 
        DNS Domain: example.com 

По умолчанию systemd-resolved считывает стандартные настройки DNS в сети.

Дополнительно рекомендуется проверить параметр hosts в файле /etc/nsswitch.conf, который определяет последовательность обращений программ к системным компонентам для разрешения доменных имен. В параметре hosts должен быть указан resolve:

hosts: files myhostname resolve [!UNAVAIL=return] dns

где:

• files – считывание настроек из файла /etc/hosts (имеет наивысший приоритет);

• myhostname – считывание имени текущего хоста;

• resolve [!UNAVAIL=return] – считывание настроек с помощью локального кеширующего DNS-сервера, systemd-resolved поддерживает внутренний каталог с собственным файлом resolv.conf;

• dns – обращение напрямую к DNS-серверам (имеет низший приоритет).

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

Для настройки DNS, к которым необходимо обращаться для преобразования доменных имен, в файл /etc/systemd/resolved.conf потребуется внести следующие изменения:

nano /etc/systemd/resolved.conf

• Указать список основных и запасных DNS. Для этого раскомментируйте параметры DNS= и FallbackDNS= и укажите свои значения.

  В параметре DNS= рекомендуется указывать IP-адрес DNS-сервера.

  В параметре FallbackDNS= рекомендуется указывать любые публичные DNS-серверы, например, 77.88.8.88 – бесплатный DNS-сервер от Яндекс.

• При необходимости раскомментируйте и укажите нужные значения для следующих параметров:

  • DNSSEC=yes – набор расширений протокола DNS, позволяющий минимизировать атаки, связанные с подменой IP-адреса при разрешении доменных имён;

  • DNSOverTLS=yes – стандартный протокол для выполнения разрешения удалённой системы DNS с использованием TLS;

  • MulticastDNS=no – многоадресный DNS для поиска устройства или службы по имени в локальной сети;

  • LLMNR=no – протокол стека TCP/IP, выполняющий разрешение имён хостов в локальной сети.

• Включите кеширование, раскомментировав параметр Cache= и установив значение yes.

После настройки конфигурационного файла выполните перезапуск службы systemd-resolved и проверьте её статус:

systemctl restart systemd-resolved
systemctl status systemd-resolved

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

Failed to get global data: The name is not activatable

Для решения данной проблемы запустите и добавьте службу systemd-resolved.service в автозагрузку с помощью команды:

systemctl enable systemd-resolved.service --now

Режим совместимости

Для совместимости с приложениями, которые не используют библиотечные вызовы, а обращаются к DNS-серверам напрямую, получая их из /etc/resolv.conf, потребуется наличие символической ссылки на файл resolv.conf, содержимое которого автоматически генерируется, исходя из настроек, заданных в /etc/systemd/resolved.conf.

В РЕД ОС 8 в конфигурации systemd-resolved по умолчанию реальный файл /etc/resolv.conf заменен на ссылку к автоматически генерируемому файлу /run/systemd/resolve/stub-resolv.conf.

Для проверки символической ссылки выполните:

 ls -la /etc/resolv.conf 
 
 lrwxrwxrwx. 1 root root 39 апр 15 08:34 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Файл /run/systemd/resolve/stub-resolv.conf содержит в себе отсылку на локальный псевдо-сервер DNS (local stub) на адресе 127.0.0.53 в качестве единственного DNS-сервера, а также список доменов для поиска (параметр search).

Отсылка на локальный псевдо-сервер DNS связана с тем, что в конфигурации по умолчанию в /etc/systemd/resolved.conf активирован механизм DNSStubListener (DNSStubListener=yes), который запускает отдельные TCP/UDP-прослушиватели на адресах 127.0.0.53%lo:53 и 127.0.0.54:53:

 ss -tunlp | sort 
 
tcp   LISTEN 0      4096   127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=531,fd=17))                
tcp   LISTEN 0      4096      127.0.0.54:53         0.0.0.0:*    users:(("systemd-resolve",pid=531,fd=19))

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

Откат к старому методу разрешения имен

Для того чтобы вернуться с старому методу разрешения имён необходимо:

1. Отключить сервис systemd-resolved:

systemctl disable systemd-resolved --now

2. Удалить /etc/resolv.conf и создать его как обычный файл:

rm /etc/resolv.conf && touch /etc/resolv.conf

3. Прописать в файл все необходимые DNS-сервера, например:

 nameserver 8.8.8.8 
 nameserver 77.88.8.8

Эта информация оказалась полезной? ДА НЕТ

Дата последнего изменения: 19.03.2025

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.