Делаем свой локальный DNS (PDNSD), с блэкджеком и быстрее Google Public DNS. Делаем свой локальный DNS (PDNSD), с блэкджеком и быстрее Google Public DNS Результаты тестирования в NameBench

DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.

В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.

Требования

• Понимание базовых типов DNS-серверов. Ознакомиться с подробностями можно в .
• Две машины, из которых хотя бы одна работает на Ubuntu 14.04. Первая машина будет настроена как клиент (IP-адрес 192.0.2.100), а вторая – как DNS-сервер (192.0.2.1).

Вы научитесь настраивать клиентскую машину для отправки запросов через 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;

listen-on-v6 { any; };
};

Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.

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

Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.

Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.

Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).

acl goodclients {
};
options {
. . .

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

acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
. . .

Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:

options {
directory "/var/cache/bind";
recursion yes;

. . .

Блок 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):

. . .
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {

8.8.8.8;

8.8.4.4;

};
. . .

В результате конфигурация выглядит так:

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: error (chase DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8#53
Jun 25 15:03:29 cache named: error (no valid DS) resolving "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53

Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.

. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .

Сохраните и закройте файл. Настройка перенаправляющего DNS-сервера завершена.

4: Проверка настроек и перезапуск Bind

Теперь нужно убедиться, что настройки работают должным образом.

Чтобы проверить синтаксис конфигурационных файлов, введите:

sudo named-checkconf

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

Если вы получили сообщение об ошибке, исправьте ее и повторите проверку.

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

sudo service bind9 restart

После нужно проверить логи сервера. Запустите на сервер команду:

sudo tail -f /var/log/syslog

Теперь откройте новый терминал и приступайте к настройке клиентской машины.

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:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.

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

Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.

Устанавливаем Bind 9 (named) в CentOS 7

Первым делом проверим, установлен ли у нас днс сервер в системе:

# rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch

У меня не установлен, так как во время выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind :

# systemctl start named-chroot # systemctl enable named-chroot ln -s "/usr/lib/systemd/system/named-chroot.service" "/etc/systemd/system/multi-user.target.wants/named-chroot.service"

Проверяем содержимое chroot каталога:

# ls -l /var/named/chroot/etc

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

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf . Открываем его и приводим к следующему виду:

# mcedit /var/named/chroot/etc/named.conf options { listen-on port 53 { any; }; listen-on-v6 port 53 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; allow-query { 127.0.0.1; 192.168.7.0/24; }; recursion yes; allow-recursion { 127.0.0.1; 192.168.7.0/24; }; forwarders { 8.8.8.8; }; version "DNS Server"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; dnssec-enable no; dnssec-validation no; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default_file; }; };

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

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

Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:

# cd /var/named/chroot/var/log && mkdir named && chown named. named

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

# mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. (2015092502 43200 3600 3600000 2592000) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231

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

Выставляем необходимые права:

# chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone

Zone "site1.ru" { type master; file "site1.ru.zone"; };

Перечитываем конфигурацию named с помощью rndc :

# rndc reconfig

Добавление в bind slave zone

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

Zone "site.ru" IN { type slave; masters { 10.1.3.4; }; file "site.ru.zone"; };

10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер.

Нужно добавить группе named разрешение на запись, чтобы стало вот так:

После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone . Если у bind не будет прав для создания файла, в логе вы получите ошибку:

Dumping master file: tmp-7Swr6EZpcd: open: permission denied

Гораздо интереснее и полезнее разобраться с подробным логированием работы сервера. Я долгое время поверхностно хватался за всякие рекомендации и куски примерных конфигов в интернете, пока в не решил разобраться сам с этой темой и не полез в оригинальный мануал .

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

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

Channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes;

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:

• print-severity yes | no — указывает, писать или нет параметр severity в лог
• print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no , которое лично меня устраивает.

Category general { general; };

Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:

Logging { channel default { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel database { file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel security { file "/var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel config { file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel resolver { file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-in { file "/var/log/named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-out { file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel notify { file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel client { file "/var/log/named/client.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel unmatched { file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel network { file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update { file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update-security { file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel queries { file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel query-errors { file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dispatch { file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dnssec { file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel lame-servers { file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel delegation-only { file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel edns-disabled { file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rpz { file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rate-limit { file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default; }; category general { general; }; category database { database; }; category security { security; }; category config { config; }; category resolver { resolver; }; category xfer-in { xfer-in; }; category xfer-out { xfer-out; }; category notify { notify; }; category client { client; }; category unmatched { unmatched; }; category network { network; }; category update { update; }; category update-security { update-security; }; category queries { queries; }; category query-errors { query-errors; }; category dispatch { dispatch; }; category dnssec { dnssec; }; category lame-servers { lame-servers; }; category delegation-only { delegation-only; }; category edns-disabled { edns-disabled; }; category rpz { rpz; }; category rate-limit { rate-limit; }; };

Если мы хотим собирать все логи запросов из категории queries , то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

Querylog yes;

Перезапускаем bind :

# systemctl restart named-chroot.service

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

# cd /var/named/chroot/var/log/named # ls -l

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

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

Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.

Онлайн курсы по Mikrotik

• Знания, ориентированные на практику;
• Реальные ситуации и задачи;
• Лучшее из международных программ.

К эш DNS – это временная база данных, в которой хранится информация о предыдущих поисках DNS. Другими словами, всякий раз, когда вы посещаете веб-сайт, ваша ОС и веб-браузер будут вести учет домена и соответствующего IP-адреса. Это исключает необходимость повторяющихся запросов к удаленным DNS-серверам и позволяет вашей ОС или браузеру быстро разрешать URL-адреса веб-сайта.

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

В этой статье приведены инструкции по очистке кеша DNS в разных операционных системах и веб-браузерах.

Очистить/удалить кэш DNS в Windows

Процесс очистки DNS-кэша одинаков для всех версий Windows. Вам нужно открыть командную строку с правами администратора и запустить ipconfig /flushdns.

Windows 10 и Windows 8

Чтобы очистить кэш DNS в Windows 10 и 8, выполните следующие действия:

1. Введите cmd в строке поиска Windows.

2. ipconfig /flushdns

   Windows 7

   Чтобы очистить кэш DNS в Windows 7, выполните следующие действия:

   1. Нажмите на кнопку Пуск.
   2. Введите cmd в текстовое поле поиска меню «Пуск».
   3. Щелкните правой кнопкой мыши на командной строке и выберите Запуск от имени администратора. Это откроет окно командной строки.
   4. В командной строке введите следующую строку и нажмите Enter:

      ipconfig /flushdns

      В случае успеха система вернет следующее сообщение:

      Windows IP Configuration Successfully flushed the DNS Resolver Cache.

   Очистить/удалить кэш DNS в Linux

   В Linux отсутствует кэширование DNS на уровне ОС, если не установлена ​​и не запущена служба кэширования, такая как Systemd-Resolved, DNSMasq или Nscd. Процесс очистки DNS-кэша отличается в зависимости от дистрибутива и службы кэширования, которую вы используете.

   Systemd Resolved

   В большинстве современных дистрибутивов Linux, таких как , используется системный разрешенный сервис для кэширования записей DNS.

   Чтобы узнать, запущена ли служба, выполните:

   sudo systemctl is-active systemd-resolved.service

   Если служба работает, команда напечатает active, иначе вы увидите inactive.

   Чтобы очистить DNS-кэш Systemd Resolved, вы должны ввести следующую команду.

   sudo systemd-resolve --flush-caches

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

   Dnsmasq

   Dnsmasq – это облегченный сервер кэширования имен DHCP и DNS.

   Если ваша система использует DNSMasq в качестве сервера кеширования, для очистки кеша DNS вам необходимо перезапустить службу Dnsmasq:

   sudo systemctl restart dnsmasq.service

   sudo service dnsmasq restart

   Nscd

   Nscd – это демон кэширования, и он является предпочтительной системой кэширования DNS для большинства дистрибутивов на основе RedHat.

   Если ваша система использует Nscd, для очистки кеша DNS вам необходимо перезапустить службу Nscd:

   sudo systemctl restart nscd.service

   sudo service nscd restart

   Очистить/удалить кэш DNS на MacOS

   Команда очистки кэша в MacOS немного отличается в зависимости от используемой версии. Команда должна быть запущена как пользователь с правами системного администратора (пользователь sudo).

   Чтобы очистить кэш DNS в MacOS, выполните следующие действия:

   1. Откройте Finder.
   2. Перейдите в Приложения> Утилиты> Терминал. Это откроет окно терминала.
   3. В командной строке введите следующую строку и нажмите Enter:

      sudo killall -HUP mDNSResponder

      Введите свой пароль sudo и снова нажмите Enter. В случае успеха система не возвращает никаких сообщений.

   Для более ранних версий MacOS команда очистки кэша отличается.

   MacOS версии 10.11 и 10.9

   sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder

   MacOS версия 10.10

   sudo discoveryutil mdnsflushcache sudo discoveryutil udnsflushcaches

   MacOS версии 10.6 и 10.5

   sudo dscacheutil -flushcache

   Очистить /удалить кэш DNS браузера

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

   Google Chrome

   Чтобы очистить DNS-кеш Google Chrome, выполните следующие действия:

   1. Откройте новую вкладку и введите в адресную строку Chrome: chrome://net-internals/#dns.
   2. Нажмите кнопку «Очистить кэш хоста».

   Если это не работает для вас, попробуйте очистить кэш и куки.

   1. Нажмите, CTRL+Shift+Del чтобы открыть диалоговое окно «Очистить данные просмотра».
   2. Выберите диапазон времени. Выберите «Все время», чтобы удалить все.
   3. Установите флажки «Файлы cookie и другие данные сайта» и «Кэшированные изображения и файлы».
   4. Нажмите кнопку «Очистить данные».

   Этот метод должен работать для всех браузеров на основе Chrome, включая Chromium, Vivaldi и Opera.

   FireFox

   Чтобы очистить DNS-кэш Firefox, выполните следующие действия:

   1. В верхнем правом углу щелкните значок гамбургера, ☰чтобы открыть меню Firefox:
   2. Нажмите на ⚙ Options (Preferences)ссылку.
   3. Нажмите на вкладку «Конфиденциальность и безопасность» или «Конфиденциальность» слева.
   4. Прокрутите вниз до Historyраздела и нажмите на Clear History…кнопку.
   5. Выберите временной диапазон, чтобы очистить. Выберите «Все», чтобы удалить все.
   6. Выберите все поля и нажмите «Очистить сейчас».

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

   1. Откройте новую вкладку и введите about:configв адресную строку Firefox.
   2. Найдите network.dnsCacheExpiration, временно установите значение 0 и нажмите ОК. После этого измените значение по умолчанию и нажмите ОК.
   3. Найдите network.dnsCacheEntries, временно установите значение 0 и нажмите ОК. После этого измените значение по умолчанию и нажмите ОК.

   Заключение

   Вы узнали, как очистить или очистить кэш DNS в операционных системах Windows, Linux и MacOS.

   Linux и MacOS могут использовать команду dig для запроса DNS и устранения проблем с DNS.

   Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Назначение DNS это перевод доменных имен, легко запоминаемых человеком в IP адреса которые понимают компьютеры, этот процесс называется-Разрешение имен. Что нам даст установка собственного кеширующего DNS сервера? Это немного ускорит отклик сайтов + Linux не очень хорошо воспринимает имена NetBios, а ведь иногда приходится находить компьютеры или принтеры внутри локальной сети, а хочется это делать по именам.

Запоминать IP адреса- не удобно, а постоянно лазить к журнал работы DHCP сервера- тоже не наш метод. Вот для таких случаев и нужен DNS в локальной сети. Сама установка пакета bind9 не отличается сложностью, затыки, обычно возникают на стадии его конфигурирования, т.к. после легко читаемых конфигурационных файлов системы, на человека сваливается непонятный синтаксис, кстати, очень похожий на язык программирования С. Т.к. сервер будет работать внутри локальной сети, то не имеет смысла переносить его в chroot окружение и вся настройка занимает совсем немного времени. На этом, лирическую часть, можно завершить, переходим к установке и настройке.

Установим DNS сервер Bind9:

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

Находим секцию, она находится в самом начале конфигурационного файла, кроме нее там больше ничего нет…

Секция forwarders, отвечает за то, куда будет передаваться DNS запрос на разрешение имени, в случае если его нет в собственной базе. Последнее время меня совсем не радует, работа этих серверов у провайдера по этому можно подключить сторонние например гугловские, запомнить IP очень легко 8.8.8.8, на его примере я и буду вести настройку, но никто не мешает использовать, те что вам нравятся больше.

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

В эту секцию лучше вписать IP того сервера который у вас указан в файле /etc/resolv.conf или вписать туда в секциюnameserver этот IP. Сохраняем изменения и выходим. Перезапускаем сервер и проверяем. Набираем в командной строке nslookup mail.ru
Должно выдать:

Это говорит о том, что наш сервер не является, главным в обслуживании этой зоны (mail.ru), но запросы добавил в кеш!
Теперь нужно создать ДНС зону для нашей сети чтобы машины могли находить различные сетевые сервисы - могут быть, например, сетевые принтеры, они могут быть как самостоятельными так и расшаренными на других рабочих станциях.
Нашу зону можно назвать orgname –т.е. название организации.
Первым делом создаем зону, для этого отредактируем named.conf.local

и добавим в него следующее:

Сохраняем и выходим
Теперь нам необходимо создать файл настройки зоны

и вставляем в него следующее:
(Прошу отнестись внимательно к синтаксису конфигурационного файла, даже точки имеют значение)

Теперь, при добавлении нового сетевого устройства, вам необходимо сделать 2 вещи:
1) Зарезервировать IP адрес на DHCP сервере, о том, как это сделать, можно прочитать в статье- Настройка DHCP сервера
2) Создать DNS зону для этого IP, вида devicename IN A XXX.XXX.XXX.XXX. Где: devicename-сетевое имя устройства; XXX.XXX.XXX.XXX-его IP адрес который зарезервирован на DHCP сервере.

теперь нам необходимо отредактировать файл resolv.conf

и вписать туда:

все что там было можно закоментировать поставив #
перезапускам сервер

# reboot

Сделано это для того чтобы сервер искал все в собственной базе, а уже потом BIND будет перенаправлять запросы к серверу 8.8.8.8 IP которого вписан в директиве forwarders .
Теперь можно проверять работоспособность:
Если тестирование происходит из под Windows:

Если тестируем из под Linux:

Должны пойти пинги на тот IP который вы указали вместо XXX.XXX.XXX.XXX

Можно так же проверять скорость обработки запросов коммандой dig

# dig @127.0.0.1 tut.by ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @127.0.0.1 tut.by ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310

Внимание

Для корректной установки и настройки dnsmasq, перейдите в сеанс cуперпользователя:

На запрос пароля, введите пароль привилегированного пользователя или локального администратора.

DNS — кэш предназначен для ускорения загрузки страниц веб-сайтов, путем сохранения в памяти их IP-адресов. Для настройки кэширования используйте утилиту dnsmasq .

Yum install dnsmasq

С помощью текстового редактора vi или nano откройте файл, расположенный по адресу /etc/dnsmasq.conf

Vi /etc/dnsmasq.conf

Nano /etc/dnsmasq.conf

Отредактируйте следующие параметры:

Resolv-file=/etc/resolv.dnsmasq no-poll listen-address=127.0.0.1 cache-size=150 conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig

А так же допишите следующий параметр:

All-servers

• resolv-file - файл с IP-адресами dns — серверов
• no-poll - параметр, запрещающий автоматическое применение изменений в файлах с именем resolv.
• listen-address - параметр, указывающий какой адрес слушать.
• cache-size - размер кэша. Значение по умолчанию позволяет хранить 150 хостов.
• c onf-dir - параметр, отвечающий за дополнительный файл конфигурации.
• all-servers - перенаправляет dns-запрос всем доступным dns-серверам и возвращает ответ от первого откликнувшегося сервера. Параметр нужно записать вручную.

Также можно указать следующие параметры:

• no-negcache - не кэшировать негативные ответы от серверов.
• b ind-interface s - позволяет запускать копии процесса.
• d ns-forward-max - максимальное количество dns-запросов. По умолчанию - 150. Параметр нужно записать вручную.

Теперь создайте файл resolv.dnsmasq с помощью текстового редактора vi или nano и запишите туда адреса dns-серверов.

Vi /etc/resolv.dnsmasq

Nano /etc/resolv.dnsmasq

Потом добавьте IP-адрес 127.0.0.1 в файл resolv.conf . Для этого, используйте утилиту «Сетевые соединения» , расположенную в «Меню» → «Параметры» → «Сетевые соединения» в графическом окружении Cinnamon или «Система» → «Параметры» → «Сетевые соединения» в графическом окружении Mate . Выберите ваше активное подключение, нажмите кнопку «Изменить», перейдите на вкладку «Параметры IPv4» , поменяйте «Метод» на «Автоматический (DHCP, только адресс)» , а в поле «Дополнительные серверы DNS » напишите адрес 127.0.0.1 , нажмите применить и перезапустите NetworManager.

Редактирование файла resolv.conf с помошь текстовых редакторов не рекомендуется. Файл перезапишется со следующим перезапуском системы.

Systemctl restart NetworkManager.service

Чтобы убедиться, что изменения вступили в силу, посмотрите содержимое файла resolv.conf :

Cat /etc/resolv.conf

Содержимое должно быть таким:

# Generated by NetworkManager nameserver 127.0.0.1

Описанные выше операции позволят перенаправлять все dns-запросы на локальную машину.

Добавьте службу dnsmasq в автозапуск и перезайдите в сеанс:

Systemctl enable dnsmasq.service --now

Для того, чтобы сбросить кэш, просто перезапустите службу:

Systemctl restart dnsmasq.service

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

Проверьте, включена ли служба:

Systemctl status dnsmasq.service

Проверьте порт 53:

Netstat -ntlp | grep:53 tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 7319/dnsmasq tcp6 0 0:::53:::* LISTEN 7319/dnsmasq

Теперь попробуйте с помощью утилиты dig несколько раз обратиться к cайту google.com

Dig google.com | grep "Query time" ;; Query time: 135 msec

Если кэширование dns-запросов работает, то практически во всех следующих запросах выделенная строчка query time будет равна нулю.

;; Query time: 0 msec

В противном случае она будет варьироваться от 0 и выше с каждым новым запросом.

В результате, основной DNS-сервер сети будет испытывать гораздо меньше нагрузки.

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