Astra linux настройка dns
Сразу отметим, что речь в данной статье пойдет исключительно о клиентской части системы DNS в linux. О серверной части мы поговорим в другой статье (она-то как раз гораздо проще для восприятия). Итак, начнем.
Разобраться, как работает DNS в вашей системе, можно только поняв, как устроена та программа, которую вы запускаете. Серьезно, только сама программа определяет, как она будет работать с DNS, а не операционная система в целоми и не linux в частности. Нужно смотреть, как была написана вот эта вот конкретная программа. Но не огорчайтесь сразу, вам скорее всего не понадобится срочно изучать все возможные языки программирования, только чтобы настроить вашу программу на работу с DNS. Указанный выше случай справедлив больше для программ собраных статически, разнообразных самопалов или чисто академических творений всемозможных энтузиастов.
Современные программисты достаточно ленивы и собирают свои программы динамически, т.е. с использованием разделяемых библиотек. Они позволяют им не заботиться о ряде функциональных возможностей, таких как работа с сетью, шифрованием или DNS. Действительно, вам бы не понравилось переносить один и тот же код из программы в программу только ради того, чтобы дать ей возможность преобразовывать имена в IP адреса. А если в этом коде потом обнаружиться баг или серьезная уязвимость? Нет. Вся функциональность нынче вынесена в библиотеки. И так уж получилось, что в linux самой популярной библиотекой для преобразования имен является libnss. Т.е. повторюсь, это совсем не обязательно, что ваша программа будет собрана с использованием libnss. Да, большинство (99% программ) будут следовать законам libnss, однако имейте ввиду, что возможна сборка с какой-нибудь другой библиотекой, или вообще статически с самописным кодом. Это будет лишь означать, что настраиваться DNS в этих немногочисленных случаев по-особому.
- какие модули libnss будет использовать для перобразования имен в адреса
- в каком порядке (приоритет) их вызывать.
И только когда libnss, пройдясь по всем модулям, так и не сможет найти соответствующий запрашиваемому имени IP адрес, тогда вам будет возвращен ответ примерно такого вида
Заглянем в /etc/nsswitch.conf
passwd: files mymachines systemd
group: files mymachines systemd
shadow: files
hosts: files mymachines myhostname dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
Мы видим много разных строчек. Действительно, libnss отвечает далеко не только за преобразование имен хостов в IP-адреса, а также за преобразование имен пользователей в uid, групп в gid, имен протоколов в номера портов и т.д. Заострим наш взгляд на строке начинающейся с "hosts:", ведь именно о ней-то мы и говорим. Здесь все очень просто - мы определяем, какие модули мы хотим использовать для преобразования имен хостов в IP-адреса и в какой последовательности. Почти наверняка на первом месте у вас будет "files", что означает, что при поступлении запроса на резолвинг, мы сначала вызываем модуль "files", который в свою очеред заглядывает в /etc/hosts в поисках интересующего пользователя имени. Рассмотрим самые распространенные модули, что они делают и как настраиваются на диаграмме
Подведем промежуточный итог:
files
Модуль files не настраивается. Работает с /etc/hosts в качестве базы данных имен и адресов. Синтаксис /etc/hosts предельно простой: IP адрес, полное имя (FQDN) набор алиасов (дополнительных имен)
resolve
myhostname
Модуль myhostname не настраиваются. Тоже часть systemd. Резолвит локальные имена машины сами в себя. Например можно пингануть hippo.localhost и вы получите результат. Зачем она надо, спросите вы, если уже есть /etc/hosts? Модуль myhostname надежнее. Редактируя /etc/hosts, человек может совершить ошибку, тогда как myhostname общается напрямую с ядром и ошибок не совершает
mymachines
Модуль mymachines позволяет резолвить имена контейнеров, запущенных systemd.
Модуль dns настраивается через /etc/resolv.conf, в качестве базы данных использует DNS сервера, обращаясь к ним через сеть. Соответственно узнать или прописать адреса DNS серверов можно в указанном файле. И тут стоит быть осторожным. Так как модуль dns является самым популярным способом резолвинга имен хостов в linux, файл /etc/resolv.conf является объектом пристального внимания разнообразных автоматических конфигураторов сети, таких как NetworkManager и т.п. Если вы работаете с одним из таких конфигураторов, то менять настройки надо в их собственных конфигурационных файлах, а не напрямую в /etc/resolv.conf, так как весьма вероятно, что им это не понравится, и ваша конфигурация будет перезаписана. Синтаксис /etc/resolv.conf простой и задается в формате ключ/значение: nameserver указывает на IP адрес DNS сервера, search позволяет указать домен поиска при использовании коротких имен без доменной части.
Настало время поговорить о кэшэ DNS в linux. Кэш по-умолчанию в вашем дистрибутиве скорее всего выключен, однако мест, где его можно поискать не так уж и много. Понимая модульность libnss, вы наверняка уже догадались, что кэш можно встретить
- на этапе вызова модуля (например systemd-resolved, имеют свой собственный кэш)
- в самом libnss (демон nscd если запущен, то скорее всего кэширует результаты резолвинга)
- в демонах кэша, которые еще называют stub-resolver, такие как dnsmasq и systemd-resolved, с недавних пор получивший функцию stub-resolver'а
- на самих DNS серверах
Проверить, запущен ли nscd, можно с помощью systemctl
systemctl status nscd
ps -A | grep nscd
Настраивается nscd через /etc/nscd.conf. Его синтаксис перекликается с таковым у /etc/nsswitch.conf, например, имена сервисов и там, и там одинаковые. Кроме того, поддерживается ряд глобальных параметров
Т.е. для включения кэша в nscd (этот кэш первичный, т.е. отрабатывает ДО вызова любого модуля из /etc/nsswitch.conf) вам достаточно убедиться в наличии строки
enable-cache hosts yes
Простого перезапуска nscd бывает недостаточно для очистки кэша. Для очистки кэша резолвинга имен хостов в nscd используйте команду
Этой же командой вы можете очистить кэш и других сервисов, например passwd или groups. Просто замените "hosts" на нужный сервис
systemd-resolved
О systemd-resolved мы уже писали в статье Переходим на systemd-resolved. Но на всякий случай напомним. Для очистки кэша systemd-resolved в большинстве случаев достаточно просто перезапустить systemd-resolved командой
Пакет bind9 входит в стандартные дистрибутивы ОС Astra Linux. Установку службы DNS bind9 можно выполнить из графического менеджера пакетов, или из командной строки:
sudo apt install bind9
При установке пакета bind9 будет автоматически уставновлен пакет инструментов командной строки bind9utils . Из этих инструментов следует отметить:
- named-checkconf — инструмент проверки синтаксиса файлов конфигурации;
- named-checkzone — инструмент проверки файлов зон DNS;
- rndc — инструмент управления службой DNS.
В дополнение к пакетам bind9 и bind9utils , рекомендуем сразу установить пакет инструментов командной строки dnsutils , предназначенных для работы с DNS:
В составе пакета dnsutils будут установлены следующие инструменты:
- dig - инструмент для опроса DNS-серверов и проверки их реакции
- nslookup - инструмент для проверки преобразования имен в IP-адреса
(далее в тексте используется термин "разрешение имён") - nsupdate - инструмент для динамического обновления записей DNS
Многие устаревшие материалы в сети Интернет рекомендуют для работы bind создать учётную запись и группу named.
Этого делать не следует, так как при установке пакета будут автоматически созданы учётная запись пользователя и группа, причем не named, как написано в устаревших метериалах, а учетная запись bind и группа bind.
Соответственно, сервис будет работать от имени bind:bind, а не от имени named:named, о чем следует помнить при работе с устаревшими примерами из сети Интернет.
После настройки службы DNS не забудьте перенастроить службу DHCP,
чтобы клиентам автоматически выдавались правильные адреса серверов DNS.
Конфигурационные файлы BIND9 находятся в каталоге /etc/bind.
При установке BIND9 автоматически создаются следующие конфигурационные файлы:
| /etc/bind/named.conf | Основной файл конфигурации. Этот файл изменять не следует, так как он содержит в себе только сслылки на остальные конфигурационные файлы (см. ниже) |
| /etc/bind/named.conf.options | Файл для глобальных настроек службы |
| /etc/bind/named.conf.local | Файл для настроек зоны DNS |
| /etc/bind/named.conf.default-zones | Файл конфигурации зон "по умолчанию". В частности, этом файле содержатся ссылки на автоматически созданные файлы конфигурации зоны localhost /etc/bind/db.local и /etc/bind/127.db |
Подробности о конфигурационных параметрах см. в руководстве man named.conf (5).
Настройка BIND9 для работы с Samba AD
Параметры настройки BIND9 и BIND9_DLZ для использования в качестве DNS-сервера домена см. BIND9 как DNS-сервер для Samba AD
Вариант простейшей настройки "Кеширующий сервер DNS"
Если у вас уже есть настроенный и доступный DNS-сервер (собственный, или сервер провайдера), создание в локальной сети дополнительного кеширующего DNS-сервера позволит без особых затрат ускорить работу с Интернет за счет ускорения разрешения имен по запросам различных сетевых служб и/или пользовательскими программами.
Установленная по умолчанию служба bind9 сразу настроена на выполнение роли кеширующего сервера, однако при этом запросы будут направляться к внешним серверам, входящим в т.н. список корневых DNS-серверов, что может быть не всегда оптимальным вариантом.
Для примера предположим, что у нас в сети уже есть настроенный сервер DNS с IP-адресом 192.168.32.1, а новый сервер DNS установлен на сервере с IP-адресом 192.168.32.100. Для перенаправления запросов на ранее настроенный сервер (и, для примера, на серверы Google 8.8.8.8 и 4.4.4.4) следует раскомментировать в файле конфигурации /etc/bind/named.conf.options внутри секции options строки
и указать адреса серверов, которым нужно передавать запросы:Можно , но не обязательно, ещё добавить список интерфейсов компьютера, через которые сервис DNS должен принимать запросы, а также запретить работу по IPv6:
sudo systemctl restart bind9
Проверить работоспособность и эффективность кеширующего DNS-сервера можно с помощью инструмента dig :
Посылаем первый запрос:
;; Query time: 15 msec
В ответе на запрос видно, что время ответа составило 15 msec. Посылаем второй запрос например через через 5 секунд:
Время ответа на запрос при работающем кешировании должно существенно сократиться.
Вариант простой настройки "Локальный сервер DNS"
Это вариант настройки собственного полноценного DNS-сервера, обслуживающего собственную локальную сеть (собственный DNS-домен).
Создание DNS-сервера в локальной сети позволяет организовать единое пространство имён для всех сетевых служб и пользователей.
В отличие от кеширующего сервера из предыдущего примера, этот сервер самостоятельно обрабатывает запросы, относящиеся к его зоне ответственности.
Для примера, предположим, что у нас есть
Настройка конфигурации bind:
- на сервере DNS файл конфигурации /etc/bind/named.conf.options используем из предыдущего примера:
- внесём информацию о домене в файл конфигурации /etc/bind/named.conf.loca l. Исходно в этом файле содержатся только комментарии. Добавляем следующие строки:
- создаём каталог для хранения файлов данных, и копируем в созданный каталог образцы файлов данных:
- вносим измения в файл /etc/bind/zones/ db. 32.168.192 реверсивной зоны:
- проверяем созданную конфигурацию с помощью соответствующих инструментов :
systemctl restart bind9
Проверить работу сервера можно выполнив на сервере команду:
Добавляем резервный сервер.
Как и в примере ранее, предположим, что у нас есть
Для добавления резервного сервера
- на основном сервере DNS внесём информацию о резервном сервере в файл конфигурации /etc/bind/named.conf.loca l, и перезапустим сервис. Добавляемые строки выделены:
- на резервном сервере DNS файл конфигурации /etc/bind/named.conf.options используем из предыдущего примера, но с одним отличием - резервный сервер слушает адрес 192.168.32.212:
- вносим изменения в файл конфигурации /etc/bind/named.conf.loca l.
- проверяем корректность конфигурации и перезапускаем сервис
named-checkconf
systemctl restart bind9
Добавляем служебные записи (SRV-записи).
Служебная запись (SRV-запись) — стандарт в DNS, определяющий имя хоста и номер порта серверов для определённых служб. Определяется в RFC 2782.
Могут использоваться в различных протоколах, например, в Kerberos.
- service - символьное имя сервиса;
- proto - транспортный протокол используемый сервисом, как правило _tcp или _udp;
- name - доменное имя, для которого эта запись действует;
- TTL - стандарт DNS, время жизни;
- class- стандарт DNS, поле класса (это всегда IN);
- priority - приоритет целевого хоста, более низкое значение означает более предпочтительный;
- weight - относительный вес для записей с одинаковым приоритетом;
- port - Порт TCP или UDP, на котором работает сервис;.
- target - канонические имя машины, предоставляющей сервис.
Примеры служебных записей (Kerberos и NTP)
Для того, чтобы сервер не тратил ресурсы на попытки опроса недоступных корневых серверов, работающих по протоколу IPv6 (например, когда протокол IPv6 не поддерживается сетью), в файл парамеров сервера можно добавить секцию:
Настройка клиентов
Клиентским компьютерам после стандартной установки ОС настройка не требуется.
Как обычно, если не указано иное, команды выполняются от имени пользователя root .
Исходные данные
Сервер установлен, но установка сделана не безопасным способом. Нужно выполнить несколько дополнительных действий, описанных подробнее в Debian Wiki - Bind.
Будем запускать сервер в изолированном окружении:
Теперь нужно изменить расположение PIDFILE. Для этого в файле /etc/init.d/bind9 нужно переопределить переменную PIDFILE .
Чтобы сервер понимал, что его запускают в изолированном окружении, нужно изменить параметры его запуска, внеся небольшие коррективы в файл /etc/default/bind9
Перенастроим логирование rsyslog
Безопасность
Основные настройки сервера хранятся в файле /etc/bind/named.conf.options (на самом деле сейчас это всего лишь символическая ссылка, но на суть дела это не влияет). Добавим пару параметров для пущей безопасности в разделе options :
Включение в конфигурацию новой доменной зоны
В файле /etc/bind/named.conf.default-zones добавим указание на файлы прямой и обратной зоны, чтобы сервер мог обслуживать локальную сеть:
Прямая доменная зона
Обратная зона
Создадим файл, на который ссылается обратная зона, и заполним его по образцу:
Если всё сделано правильно, точки расставлены и IP-адреса указаны верно, можно попробовать запустить наш сервер:
Если вместо кучи ошибок сервер просто написал, что всё хорошо, можно проверить разрешение имен:
Данные утилиты из состава пакета bind9utils укажут на ошибки в конфигурационных файлах.
Существует несколько способов настроить обращение к DNS-серверу на клиентских машинах. По скольку речь идет об операционной системе для социальной группы 'siloviki', выбор инструментальных средств невелик - wicd , /etc/network/interfaces и /etc/resolv.conf .
Первый способ отметаем сразу же, поскольку с wicd довольно много проблем. Не буду останавливаться на них подробно, но обычно первое, что приходится делать на свежеустановленной системе - убрать его из автозагрузки:
BIND – наиболее распространенное open-source приложение, в котором реализованы протоколы DNS, предоставляющие возможность преобразования доменных имен в IP-адреса и наоборот.
Данная статья представляет собой руководство по быстрой настройке DNS-сервера в Linux при помощи BIND. Мы не будем подробно разбирать, что такое система DNS и как она работает, а сосредоточимся на примере настройки своей зоны и файла конфигурации для домена/узла с поддержкой сервисов www и электронной почты.
Установка сервера bind
Установка bind очень проста – нужно воспользоваться менеджером пакетов. В Debian и Ubuntu выполните следующую команду:
В CentOS или Fedora:
Пакет dnsutils необязателен для запуска сервера bind, но для тестирования конфигурации мы будем пользоваться командой dig из этого пакета.
Создание файла зоны DNS
Рассмотрим ключевые строки этого файла:
Настройка обратной зоны
Запись PTR: DNS-запись, используемая для определения соответствия IP-адреса имени узла.
Настройка файла конфигурации bind
На данный момент у нас должно быть два файла:
Теперь требуется вставить имена обоих файлов зоны в файл конфигурации bind /etc/bind/named.conf.local . Для этого добавьте в файл следующие строки:
Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.
Замените следующий блок текста в файле named.conf.options:
на блок текста с адресом стабильного DNS-сервера
Если вы планируйте что к вашему серверу будут подключаться другие компьютеры, то нужно разрешить в опциях внешние подключения. Для этого в основном файле конфигурации, в секции options добавьте или замените следующие правила
А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение
Если этого не сделать, то при попытке обращения к серверу с другого компьютера вы получите ошибку
Проверка файлов зоны и конфигурации
Прежде чем попытаться запустить сервер имен с новой зоной и конфигурацией, можно воспользоваться некоторыми инструментами, чтобы проверить, что конфигурация корректна и не содержит ошибок.
Для проверки файлов конфигурации выполните следующую команду:
С этой командой работает простое правило: отсутствие результата – это хороший результат. Если команда ничего не возвращает, значит ошибок в ваших файлах конфигурации не обнаружено.
Для проверки файлов зоны DNS можно воспользоваться командой named-checkzone:
Проверка обратной зоны
Запуск и перезапуск сервера bind
Теперь мы можем запускать сервер bind:
Если сервер уже был запущен, его можно перезапустить командой restart:
Для того что бы перечитать конфигурацию не перезапуская сервер, используйте команду
Тестирование сервера bind
Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):
Теперь проверим обратную зону:
dig @172.31.0.122 -x 172.31.1.10
Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.
nslookup 172.31.1.10 172.31.0.122
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
В resolv.conf на обеих машинах:
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Настройки сети: объединить две сети, wifi и ethernet
На компе получаю инет через модуль wifi. Сетевой картой подключен к линукс железке. Хочу с железки.
Настройки домашней локальной сети и сети интернет
Здравствуйте! Недавно приобрел wi-fi роутер, но роутер не обычный, на нем только один порт.
Настройки статического имени для 1 ДНС имени
Можно ли сделать настройку на ДНС сервере под управление Microsof windows server 2008, по аналоги с.
Шифрование паролей в AstraLinux Qt4.8.3
Добрый день! Возникла проблема шифрования пароля в AstraLinux. Пароль шифруется по алгоритму md5.
Этим параметрам соответствует
network 192.168.73.0
Можете строку network вовсе закоментировать, адрес сети система вычислит сама по ip и netmask.
Впрочем, все выше сказанное в конкретном случае не принципиально - поскольку для разрешения имени сервера будет использоваться /etc/hosts, а не система dns.
2. Команды hostname и domainname дают верный вывод?
но "domain" и "search" исключают друг друга, применяется последний.Это разные параметры.
domain нужен для определения своего доменного имени.
search задает список доменов, добавляющихся поочередно к короткому имени при запросах для определении адреса.
В мане сказано, что каждая из них не должна повторяться более одног раза, в отличие, напр. от nameserver, которая может повторяться несколько раз.
Добавлено через 2 часа 0 минут
PS. peter_irich, прощу прощения, понадеялся на памать.
Сейчас проверил на одной из машин - Действительно, добавление search в конец /etc/resolv.conf полностью перебивает настройки domain.
Хотя, в умолчальном файле после установки Дебиан эти параметры дублируются.
1. В конфигурации заметил только одну ошибку.
Этим параметрам соответствует
network 192.168.73.0
Можете строку network вовсе закоментировать, адрес сети система вычислит сама по ip и netmask.
Впрочем, все выше сказанное в конкретном случае не принципиально - поскольку для разрешения имени сервера будет использоваться /etc/hosts, а не система dns.
2. Команды hostname и domainname дают верный вывод?
Это разные параметры.
domain нужен для определения своего доменного имени.
search задает список доменов, добавляющихся поочередно к короткому имени при запросах для определении адреса.
В мане сказано, что каждая из них не должна повторяться более одног раза, в отличие, напр. от nameserver, которая может повторяться несколько раз.
Добавлено через 2 часа 0 минут
PS. peter_irich, прощу прощения, понадеялся на памать.
Сейчас проверил на одной из машин - Действительно, добавление search в конец /etc/resolv.conf полностью перебивает настройки domain.
Хотя, в умолчальном файле после установки Дебиан эти параметры дублируются.
donainname выдает "(none)"
Подняла DNS, nslookup выдает верные данные сервера. работают также host и ping. Но под клиентом алд по прежнему не могу войти. Теперь нет даже запроса мандатных атрибутов, просто "вход неудачен". В доменной политике безопасности у обоих компьютеров статус "недоступно", ранее так было только у клиента. Команда ald-admin test-integrity показывает, что все ок
Читайте также: