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
Доброго времени, читатели. Продолжая теоретический материал о , в текущей статье хочу рассмотреть практический пример установки и настройки разных конфигураций сервера BIND. В статье я опишу настройку DNS-кэша и полноценного DNS master сервера . Начну описание с общих понятий и необходимых шагов для организации любого DNS сервера .
Общие сведения
Named - это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен . Демон named может реализовывать функции серверов любого типа: master, slave, cache . На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND . Бинарник, который выполняет основную работу, расположен в /usr/sbin/named . Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind . В основном конфиге описывается рабочий каталог асервера , зачастую это каталог /var/cache/bind , в котором лежат файлы описания зон и другие служебные файлы. Соответствие названия зоны и файла описания зоны задает раздел zone с параметром file . Раздел zone так же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров ).
Эта общая схема работы, которая поможет в дальнейшем не запутаться, при рассмотрении конкретных конфигураций.
Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND . Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.
Исходные данные
Для корректной работы DNS нем необходимо иметь . DNS в текущей статье будет настроен на дистрибутиве Debian, особенности других дистрибутивов тоже будут отмечены. Конфиг сети стенда следующий:
Dns:~# cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.0.152 netmask 255.255.255.0 gateway 10.0.0.254 auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0
где 10.0.0.152/24 - внешний интерфейс (подсеть, выделенная провайдером), 192.168.1.1/24 - внутренний (Локальная сеть). Настраиваемая зона будет иметь имя example.com. В примере со slave сервером , вторичный сервер будет расположен на IP 10.0.0.191 .
Установка BIND9
Для работы DNS сервера необходимо bind9 (в некоторых дистрибутивах - bind ). Как отмечено на схеме - основным конфигурационным файлом BIND является файл named.conf (данный файл может быть размещен в каталоге /etc , иногда в /etc/bind ).
Параметры (синтаксис) named.conf
Синтаксис файла named.conf придерживается следующих правил:
IP-адреса - список IP должен быть разделен символом ";" , возможно указывать подсеть в формате 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (для исключения IP перед ним нужно поставить знак!), возможно указывать имена "any", "none", "localhost" в двойных кавычках.
Комментарии - строки начинающиеся на #, // и заключенные в /* и */ считаются комментариями.
В файлах описания зон - символ @ является "переменной" хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны.
Каждая завершенная строка параметров должна завершаться символом; .
Раздел Acl
Acl (access control list) - позволяет задать именованный список сетей. Формат раздела: acl "имя_сети" {ip; ip; ip; };
Раздел Options
Раздел Options задает глобальные параметры конфигурационного файла, управляющие всеми зонами. Данный раздел имеет формат: options {операторы_раздела_Options}; . Options может быть "вложен" в раздел Zone , при этом он переопределяет глобальные параметры. Часто используемые операторы options :
- allow-query {список_ip } - Разрешает ответы на запросы только из список_ip . При отсутствии - сервер отвечает на все запросы.
- allow-recursion {список_ip } - На запросы из список_ip будут выполняться рекурсивные запросы. Для остальных - итеративные. Если не задан параметр, то сервер выполняет рекурсивные запросы для всех сетей.
- allow-transfer {список_ip } - Указывает список серверов, которым разрешено брать зону с сервера (в основном тут указывают slave сервера)
- directory /path/to/work/dir - указывает абсолютный путь к рабочему каталогу сервера. Этот оператор допустим только в разделе options.
- forwarders {ip порт, ip порт.. .} - указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
- forward ONLY или forward FIRST - параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
- notify YES|NO - YES - уведомлять slave сервера об изменениях в зоне, NO - не уведомлять.
- recursion YES|NO - YES - выполнять рекурсивные запросы, если просит клиент, NO - не выполнять (только итеративные запросы). Если ответ найден в кэше, то возвращается из кэша. (может использоваться только в разделе Options)
Раздел Zone
Определяет описание зон(ы). Формат раздела: zone {операторы_раздела_zone }; Операторы , которые наиболее часто используются:
- allow-update {список_ip } - указывает системы, которым разрешено динамически обновлять данную зону.
- file "имя_файла " - указывает путь файла параметров зоны (должен быть расположен в каталоге, определенном в разделе options оператором directory)
- masters {список_ip } -указывает список мастер-серверов. (допустим только в подчиненных зонах)
- type "тип_зоны
" - указывает тип зоны, описываемой в текущем разделе,тип_зоны может принимать следующие значения:
- forward - указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону.
- hint - указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)
- master - указывает работать в качестве мастер сервера для текущей зоны.
- slave - указывает работать в качестве подчиненного сервера для текущей зоны.
Дополнительные параметры конфигурации
Значения времени в файлах зон по умолчанию указывается в секундах, если за ними не стоит одна из следующих букв: S - секунды, M - минуты, H- часы, D - дни, W - недели. Соответственно, запись 2h20m5s будет иметь значение 2 часа 20 минут 5 секунд и соответствовать 8405 секунд.
Любое имя хоста/записи, не оканчивающиеся точкой считается неFQDN именем и будет дополнено именем текущей зоны. Например, запись domen в файле зоны examle.com будет развернуто в FQDN-имя domen.examle.com. .
В конфигурационных файлах BIND могут применяться следующие директивы :
- $TTL - определяет TTL по-умолчанию для всех записей в текущей зоне.
- $ORIGIN - изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется "выше" (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
- $INCLUDE - включает указанный файл как часть файла зоны.
Отдельно хочется описать параметр allow-transfer { 10.0.0.191; }; . Данный параметр описывает серверы, которым разрешено скачивать копию зоны - т.н. slave серверА . В следующем примере мы разберем настройку slave DNS .
Для корректной работы логирования необходимо создать соответствующий каталог и присвоить необходимые права:
Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep named bind 4298 0.0 3.4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0.0 0.1 3304 772 pts/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns:~# ls -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 Июл 6 18:18 /var/log/bind/
Dns:~# cat /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601 ; serial 8H ; refresh 2H ; retry 2W ; expire 1D) ; minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @
а так же в домене in-addr.arpa.
Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * IN PTR examle.com. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. * IN PTR examle.com.
Наша сеть небольшая, предполагается, что в сети совсем мало машин. Все сервисы сети размещены на одном хосте example.com., поэтому и master DNS (ns.example.com.) и почтовый сервер (mx.example.com.) указывает на одну машину (10.0.0.152).
Вторичный (secondary, slave) авторитетный сервер зоны
Основная функция slave сервера - автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по , посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).
Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.
Прежде чем приступить к настройке slave DNS сервера , необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:
Root@debian:~# dig @10.0.0.152 example.com. axfr ; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr ; (1 server found) ;; global options: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)
- Скопировать конфигурационный файл named.conf с master сервера;
- Заменить параметр type master на type slave
- Параметр allow-transfer { 10.0.0.191; }; заменить на masters { 10.0.0.152;}; в тех зонах, для которых он будет вторичным;
- Удалить зоны , которые не будет обслуживать текущий сервер , в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
- Создать каталоги для логов, как в предыдущем примере.
Итого, мы получаем конфиг slave сервера:
Root@debian:~# cat /etc/bind/named.conf options { directory "/var/cache/bind"; allow-query { any; }; // отвечать на запросы со всех интерфейсов recursion no; // запретить рекурсивные запросы auth-nxdomain no; // для совместимости RFC1035 listen-on-v6 { none; }; // IPv6 нам не нужен version "unknown"; // не отображать версию DNS сервера при ответах }; // нижеописанные зоны определяют сервер авторитетным для петлевых // интерфейсов, а так же для броадкаст-зон (согласно RFC 1912) zone "localhost" { type master; file "localhost"; }; zone "127.in-addr.arpa" { type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" { type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" { type master; file "255.in-addr.arpa"; }; // описание основной зоны zone "example.com" { type slave; file "example.com"; masters { 10.0.0.152; }; }; //описание обратной зоны zone "0.0.10.in-addr.arpa" { type slave; file "0.0.10.in-addr.arpa"; masters { 10.0.0.152; }; }; // настройки логирования logging { channel "misc" { file "/var/log/bind/misc.log" versions 4 size 4m; print-time YES; print-severity YES; print-category YES; }; channel "query" { file "/var/log/bind/query.log" versions 4 size 4m; print-time YES; print-severity NO; print-category NO; }; category default { "misc"; }; category queries { "query"; }; };
после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:
Root@debian:~# ls -la /var/cache/bind/ итого 28 drwxrwxr-x 2 root bind 4096 Июл 8 18:47 . drwxr-xr-x 10 root root 4096 Июл 8 15:17 .. -rw-r--r-- 1 bind bind 416 Июл 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind bind 455 Июл 8 18:32 example.com ........
В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.
Настройка netfilter () для DNS BIND
Собственно, настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 53/udp порту. Почитав статью о том, и ознакомившись с , можно создать правила фильтрации сетевого трафика:
Dns ~ # iptables-save # типовые правила iptables для DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # разрешить доступ локальной сети к DNS серверу: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # разрешить доступ DNS серверу совершать исходящие запросы -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT COMMIT
Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.
Устранение неполадок
Основным источником для выявления проблем с DNS является . Вот пример ошибок при запуске, когда я ошибся с путем к файлу зоны коревых серверов :
Jul 5 18:12:43 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:12:43 dns-server named: built with "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" Jul 5 18:12:43 dns-server named: adjusted limit on open files from 1024 to 1048576 Jul 5 18:12:43 dns-server named: found 1 CPU, using 1 worker thread Jul 5 18:12:43 dns-server named: using up to 4096 sockets Jul 5 18:12:43 dns-server named: loading configuration from "/etc/bind/named.conf" Jul 5 18:12:43 dns-server named: reading built-in trusted keys from file "/etc/bind/bind.keys" Jul 5 18:12:43 dns-server named: using default UDP/IPv4 port range: Jul 5 18:12:43 dns-server named: using default UDP/IPv6 port range: Jul 5 18:12:43 dns-server named: listening on IPv4 interface lo, 127.0.0.1#53 Jul 5 18:12:43 dns-server named: listening on IPv4 interface eth1, 192.168.1.1#53 Jul 5 18:12:43 dns-server named: generating session key for dynamic DNS Jul 5 18:12:43 dns-server named: could not configure root hints from "/etc/bind/db.root": file not found Jul 5 18:12:43 dns-server named: loading configuration: file not found # файл не найден Jul 5 18:12:43 dns-server named: exiting (due to fatal error) Jul 5 18:15:05 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:15:05 dns-server named: built with "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" Jul 5 18:15:05 dns-server named: adjusted limit on open files from 1024 to 1048576 Jul 5 18:15:05 dns-server named: found 1 CPU, using 1 worker thread Jul 5 18:15:05 dns-server named: using up to 4096 sockets Jul 5 18:15:05 dns-server named: loading configuration from "/etc/bind/named.conf" Jul 5 18:15:05 dns-server named: using default UDP/IPv4 port range: Jul 5 18:15:05 dns-server named: using default UDP/IPv6 port range: Jul 5 18:15:05 dns-server named: listening on IPv4 interface lo, 127.0.0.1#53 Jul 5 18:15:05 dns-server named: listening on IPv4 interface eth1, 192.168.1.1#53 Jul 5 18:15:05 dns-server named: automatic empty zone: 254.169.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 2.0.192.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 100.51.198.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 113.0.203.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: D.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 8.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 9.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: A.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: B.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Jul 5 18:15:05 dns-server named: zone 0.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone 127.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone 255.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone localhost/IN: loaded serial 2 Jul 5 18:15:05 dns-server named: running # запуск прошел удачно
Отличным инструментом для диагностики являются .
Резюме
В текущей статье я описал настройку основных конфигураций DNS сервера BIND. Целью статьи было - дать представление о работе сервера BIND в UNIX. Я практически не затронул вопросы безопасности ДНС и мало затронул такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения я предоставлю список дополнительных источников, в которых, я надеюсь, удастся получить нужную информацию. На этом ставлю точку. До новых встреч.
Система доменных имен
: http://citforum.ru/internet/dns/khramtsov/
RFC 1034
- Domain Names - Concepts and Facilities: http://tools.ietf.org/html/rfc1034
RFC 1035
- Domain Names - Implementation and Specification: http://tools.ietf.org/html/rfc1035
RFC 1537
- Common DNS Data File Configuration Errors: http://tools.ietf.org/html/rfc1537
RFC 1591
- Domain Name System Structure and Delegation: http://tools.ietf.org/html/rfc1591
RFC 1713
- Tools for DNS Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606
- Reserved Top Level DNS Names: http://tools.ietf.org/html/rfc2606
Безопасность DNS (DNSSEC):
http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator Reference Manual
: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Secure BIND Template
: http://www.cymru.com/Documents/secure-bind-template.html
Хорошо расписаны параметры конфига на
русском
: http://www.bog.pp.ru/work/bind.html
Автоматическое создание файла зоны
: http://www.zonefile.org/?lang=en#zonefile
artem
30.10.2013
10379
Настройка кэширующего DNS-сервера для решения проблемы зависания chan_sip.so.
SIP-модуль Asterisk синхронно разрешает DNS-имена, если DNS-сервер, по каким-либо причинам, перестанет отвечать на запросы, код SIP-модуля прекращает выполнение до наступления таймаута DNS-запроса. Результатом этого является неработаспособность всех клиентов и провайдеров, подключенных по SIP, клиенты не могут регистрироваться и совершать вызовы.
Способы решения проблемы:
1. Не указывать DNS-имена в параметре SIP-пиров ‘host’ и в строках SIP-регистраций, указывать только IP-адреса (позволяет полностью исключить возможность возникновения проблемы, но невозможно с некоторыми провайдерами).
2. Настроить кэширующий DNS-сервер на хосте Asterisk.
В данной статье будет описан способ решения проблемы с помощью DNS-сервера BIND (инструкция верна для CentOS 5-6)
Настройка DNS-сервера BIND
1. Устанавливаем BIND, копируем шаблоны настроек и файлы стандартных зон
yum install bind bind-chroot
cp /etc/localtime /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.root.hints /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.rfc1912.zones /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.conf /var/named/chroot/etc
cp /usr/share/bind-*/sample/var/named/localdomain.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/localhost.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.broadcast /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.ip6.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.root /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.zero /var/named/chroot/var/named
2. Правим конфиг BIND /var/named/chroot/etc/named.conf
В конфиг нужно внести следующие правки:
> Добавить в раздел options строчку:
Можно указать свои DNS-серверы. Если не указывать эту строчку, то BIND будет опрашивать корневые DNS-серверы, что медленнее
> Разрешить рекурсивные запросы для view-зоны ‘localhost_resolver’ (заменить ‘recursion no’ на ‘recursion yes’, если этого не сделать, то сам хост не сможет делать рекурсивные запросы через DNS-сервер). Рекурсивные запросы и запросы кэша для остальных зон можно отключить
> Закомментировать или удалить разделы, отвечающие за настройку внутренних зон и DDNS, т.к. их просто не будет
Листинг полученного конфига:
//
// Sample named.conf BIND DNS server ‘named’ configuration file
// for the Red Hat BIND distribution.
// See the BIND Administrator’s Reference Manual (ARM) for details, in:
// file:///usr/share/doc/bind-*/arm/Bv9ARM.html
// Also see the BIND Configuration GUI: /usr/bin/system-config-bind and
// its manual.
options
{
// Those options should be used carefully because they disable port
// randomization
// query-source port 53;
// query-source-v6 port 53;
// Put files that named is allowed to write in the data/ directory:
directory “/var/named”; // the default
dump-file “data/cache_dump.db”;
statistics-file “data/named_stats.txt”;
memstatistics-file “data/named_mem_stats.txt”;
max-cache-size 2097152;
forwarders { 8.8.8.8; 8.8.4.4; };
};
//logging
//{
/* If you want to enable debugging, eg. using the ‘rndc trace’ command,
* named will try to write the ‘named.run’ file in the $directory (/var/named).
* By default, SELinux policy does not allow named to modify the /var/named directory,
* so put the default debug log file in data/ :
*/
// channel default_debug {
// file “data/named.run”;
// severity dynamic;
// };
//};
// All BIND 9 zones are in a “view”, which allow different zones to be served
// to different types of client addresses, and for options to be set for groups
// of zones.
// By default, if named.conf contains no “view” clauses, all zones are in the
// “default” view, which matches all clients.
// If named.conf contains any “view” clause, then all zones MUST be in a view;
// so it is recommended to start off using views to avoid having to restructure
// your configuration files in the future.
view “localhost_resolver”
{
/* This view sets up named to be a localhost resolver (caching only nameserver).
* If all you want is a caching-only nameserver, then you need only define this view:
*/
match-clients { localhost; };
match-destinations { localhost; };
recursion yes;
/* these are zones that contain definitions for all the localhost
* names and addresses, as recommended in RFC1912 – these names should
* ONLY be served to localhost clients:
*/
include “/etc/named.rfc1912.zones”;
};
view “internal”
{
/* This view will contain zones you want to serve only to “internal” clients
that connect via your directly attached LAN interfaces – “localnets” .
*/
match-clients { localnets; };
match-destinations { localnets; };
recursion no;
Allow-query-cache { none; };
// all views must contain the root hints zone:
include “/etc/named.root.hints”;
// include “named.rfc1912.zones”;
// you should not serve your rfc1912 names to non-localhost clients.
// These are your “authoritative” internal zones, and would probably
// also be included in the “localhost_resolver” view above:
//zone “my.internal.zone” {
// type master;
// file “my.internal.zone.db”;
//};
//zone “my.slave.internal.zone” {
// type slave;
// file “slaves/my.slave.internal.zone.db”;
// masters { /* put master nameserver IPs here */ 127.0.0.1; } ;
// // put slave zones in the slaves/ directory so named can update them
//};
//zone “my.ddns.internal.zone” {
// type master;
// allow-update { key ddns_key; };
// file “slaves/my.ddns.internal.zone.db”;
// // put dynamically updateable zones in the slaves/ directory so named can update them
//};
};
//key ddns_key
//{
// algorithm hmac-md5;
// secret “use /usr/sbin/dns-keygen to generate TSIG keys”;
//};
view “external”
{
/* This view will contain zones you want to serve only to “external” clients
* that have addresses that are not on your directly attached LAN interface subnets:
*/
match-clients { any; };
match-destinations { any; };
recursion no;
// you’d probably want to deny recursion to external clients, so you don’t
// end up providing free DNS service to all takers
allow-query-cache { none; };
// Disable lookups for any cached data and root hints
// all views must contain the root hints zone:
include “/etc/named.root.hints”;
// These are your “authoritative” external zones, and would probably
// contain entries for just your web and mail servers:
//zone “my.external.zone” {
// type master;
// file “my.external.zone.db”;
//};
};
3. Запускаем BIND, включаем запуск при старте системы
service named start
Если в синтаксисе конфига допущены ошибки или каких-либо файлов не хватает, сообщение об ошибке будет выведено в консоль и записано в лог /var/log/messages
К эш DNS – это временная база данных, в которой хранится информация о предыдущих поисках DNS. Другими словами, всякий раз, когда вы посещаете веб-сайт, ваша ОС и веб-браузер будут вести учет домена и соответствующего IP-адреса. Это исключает необходимость повторяющихся запросов к удаленным DNS-серверам и позволяет вашей ОС или браузеру быстро разрешать URL-адреса веб-сайта.
Однако в некоторых ситуациях, таких как устранение неполадок в сети или после смены преобразователей DNS, вам необходимо очистить кэш DNS. Это очистит кэшированные записи DNS и выполнит последующий поиск для разрешения домена на основе вновь настроенных параметров DNS.
В этой статье приведены инструкции по очистке кеша DNS в разных операционных системах и веб-браузерах.
Очистить/удалить кэш DNS в Windows
Процесс очистки DNS-кэша одинаков для всех версий Windows. Вам нужно открыть командную строку с правами администратора и запустить ipconfig /flushdns.
Windows 10 и Windows 8
Чтобы очистить кэш DNS в Windows 10 и 8, выполните следующие действия:
- Введите cmd в строке поиска Windows.
ipconfig /flushdns
Windows 7
Чтобы очистить кэш DNS в Windows 7, выполните следующие действия:
- Нажмите на кнопку Пуск.
- Введите cmd в текстовое поле поиска меню «Пуск».
- Щелкните правой кнопкой мыши на командной строке и выберите Запуск от имени администратора. Это откроет окно командной строки.
- В командной строке введите следующую строку и нажмите 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, выполните следующие действия:
- Откройте Finder.
- Перейдите в Приложения> Утилиты> Терминал. Это откроет окно терминала.
- В командной строке введите следующую строку и нажмите 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, выполните следующие действия:
- Откройте новую вкладку и введите в адресную строку Chrome: chrome://net-internals/#dns.
- Нажмите кнопку «Очистить кэш хоста».
Если это не работает для вас, попробуйте очистить кэш и куки.
- Нажмите, CTRL+Shift+Del чтобы открыть диалоговое окно «Очистить данные просмотра».
- Выберите диапазон времени. Выберите «Все время», чтобы удалить все.
- Установите флажки «Файлы cookie и другие данные сайта» и «Кэшированные изображения и файлы».
- Нажмите кнопку «Очистить данные».
Этот метод должен работать для всех браузеров на основе Chrome, включая Chromium, Vivaldi и Opera.
FireFox
Чтобы очистить DNS-кэш Firefox, выполните следующие действия:
- В верхнем правом углу щелкните значок гамбургера, ☰чтобы открыть меню Firefox:
- Нажмите на ⚙ Options (Preferences)ссылку.
- Нажмите на вкладку «Конфиденциальность и безопасность» или «Конфиденциальность» слева.
- Прокрутите вниз до Historyраздела и нажмите на Clear History…кнопку.
- Выберите временной диапазон, чтобы очистить. Выберите «Все», чтобы удалить все.
- Выберите все поля и нажмите «Очистить сейчас».
Если это не работает для вас, попробуйте следующий метод и временно отключите кэш DNS.
- Откройте новую вкладку и введите about:configв адресную строку Firefox.
- Найдите network.dnsCacheExpiration, временно установите значение 0 и нажмите ОК. После этого измените значение по умолчанию и нажмите ОК.
- Найдите network.dnsCacheEntries, временно установите значение 0 и нажмите ОК. После этого измените значение по умолчанию и нажмите ОК.
Заключение
Вы узнали, как очистить или очистить кэш DNS в операционных системах Windows, Linux и MacOS.
Linux и MacOS могут использовать команду dig для запроса DNS и устранения проблем с DNS.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
Выпуск WordPress 5.3 улучшает и расширяет представленный в WordPress 5.0 редактор блоков новым блоком, более интуитивным взаимодействием и улучшенной доступностью. Новые функции в редакторе […]
После девяти месяцев разработки доступен мультимедиа-пакет FFmpeg 4.2, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и […]
Linux Mint 19.2 является выпуском с долгосрочной поддержкой, который будет поддерживаться до 2023 года. Он поставляется с обновленным программным обеспечением и содержит доработки и множество новых […]
Представлен релиз дистрибутива Linux Mint 19.2, второго обновления ветки Linux Mint 19.x, формируемой на пакетной базе Ubuntu 18.04 LTS и поддерживаемой до 2023 года. Дистрибутив полностью совместим […]
Доступны новые сервисные релизы BIND, которые содержат исправления ошибок и улучшения функций. Новые выпуски могут быть скачано со страницы загрузок на сайте разработчика: […]
Exim – агент передачи сообщений (MTA), разработанный в Кембриджском университете для использования в системах Unix, подключенных к Интернету. Он находится в свободном доступе в соответствии с […]
После почти двух лет разработки представлен релиз ZFS on Linux 0.8.0, реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Работа модуля проверена с ядрами Linux c 2.6.32 по […]
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола ACME (Automatic Certificate Management Environment) […]
Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, подвёл итоги прошедшего года и рассказал о планах на 2019 год. […]
Вышла новая версия Libreoffice – Libreoffice 6.2