Как прописать dns в linux

BIND – наиболее распространенное open-source приложение, в котором реализованы протоколы DNS, предоставляющие возможность преобразования доменных имен в IP-адреса и наоборот.

Данная статья представляет собой руководство по быстрой настройке DNS-сервера в Linux при помощи BIND. Мы не будем подробно разбирать, что такое система DNS и как она работает, а сосредоточимся на примере настройки своей зоны и файла конфигурации для домена/узла с поддержкой сервисов www и электронной почты.

В нашем примере мы будем использовать следующие параметры:
IP-адрес, на котором будет установлен сервер имен: 172.31.0.122
имя домена/узла: itproffi.ru
авторитативные сервера имен для зоны itproffi.ru: ns1.itproffi.ru (172.31.1.10) и ns2. itproffi.ru (172.31.1.11)
службы www и электронной почты для itproffi.ru будут использовать адрес 172.31.1.10

Установка сервера bind

Установка bind очень проста – нужно воспользоваться менеджером пакетов. В Debian и Ubuntu выполните следующую команду:

В CentOS или Fedora:

Пакет dnsutils необязателен для запуска сервера bind, но для тестирования конфигурации мы будем пользоваться командой dig из этого пакета.

Создание файла зоны DNS

Дальнейшие примеры будут для Ubuntu/Debian, но также подходят и для Centos/RedHat, только директория с настройками зон в CentOS будет находиться в /etc/named/ , а основной файл конфигурации /etc/named.conf . Для начала нам потребуется создать новый файл зоны для домена itproffi.ru. Перейдите в директорию /etc/bind/ . создайте в ней поддиректорию zones/master/ и перейдите в нее, выполнив следующую последовательность команд:

Директория /etc/bind/zones/master будет содержать файл зоны для домена itproffi.ru. При желании можно использовать другую директорию. Файл зоны db.itproffi.ru будет содержать запись DNS, которая поможет серверу имен установить соответствие полного доменного имени IP-адресу. Создайте этот файл со следующим содержимым:

Рассмотрим ключевые строки этого файла:

• Запись SOA: авторитативный сервер имен для itproffi.ru – это ns1.itproffi.ru, адрес ответственного за зону DNS администратора – admin@itproffi.ru
• Записи NS: два сервера имен для зоны itproffi.ru – ns[1,2].itproffi.ru
• Запись MX: почтовый сервер для itproffi.ru. Число 10 означает уровень приоритета
• Записи A: A означает «адрес» (address). Другими словами, ns1 в зоне itproffi.ru будет иметь адрес 172.31.1.10
• Запись CNAME (Canonical Name – каноническое имя): привязывает одно доменное имя к другому (каноническому), например, устанавливает соответствие mail.itproffi.ru и itproffi.ru.

Настройка обратной зоны

На данном этапе DNS-сервер bind может выдать IP-адрес, связанный с узлом itproffi.ru. Теперь нам нужно научить наш сервер имен обратному процессу, то есть устанавливать соответствие имени IP-адресу. Для этого создадим еще один файл db.172.31.1 со следующим содержимым:

Запись 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 www.itproffi.ru

Теперь проверим обратную зону:

dig @172.31.0.122 -x 172.31.1.10

Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.

nslookup 172.31.1.10 172.31.0.122

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

Служба DNS (англ. Domain Name System — система доменных имён) используется для получения информации о доменах. Основное её предназначение — увязывать IP-адрес и доменное имя хоста. Посмотреть, к какому DNS-серверу подключен компьютер с Linux на борту, не просто, а очень просто. Как просто и поменять DNS в Linux.

Если Linux снабжён графическим интерфейсом, достаточно открыть сведения о сетевом соединении и посмотреть в строчку DNS.

По понятным причинам нас этот способ не очень интересует. Да и элементы интерфейса могут у разных сред рабочего стола различаться. Рассмотрим просмотр и настройку DNS в терминале Linux.

Традиционно DNS в Linux настраивалась через файл /etc/resolv.conf. Сейчас, однако, он может оказаться бесполезным. Откроем его любым консольным текстовым редактором, например nano:

Мы можем увидеть следующее:

Это значит, что в системе есть systemd, который содержит свой локальный сервер DNS. Его адрес и прописан в этом файле. Однако, в конечном итоге, используются другие DNS-серверы! Посмотреть их можно по-разному. Можно использовать команду

Вы увидите нечто подобное тому, что на скриншоте ниже. Если в системе несколько сетевых интерфейсов, информация будет предоставлена по каждому.

Другой способ — использовать утилиту nmcli. Введите команду

Как изменить DNS? Если в системе нет systemd, то это можно сделать редактированием файла /etc/resolv.conf. Откройте его любым текстовым редактором, найдите строку nameserver и впишите адреса DNS-серверов. Если их несколько, введите их адреса последовательно. Например:

Если в ОС есть systemd, вышеописанных способ бесполезен, поскольку настройки будут перезаписываться при перезагрузке системы. В данном случае нам нужно редактировать файл /etc/systemd/resolved.conf.

В разделе Resolve отредактируйте строку DNS. При необходимости уберите символ # для раскомментирования. Адреса DNS-серверов прописываются через запятую.

Как видим на этом примере, systemd несколько усложнил операционную систему Linux. Однако настроить DNS в ней до сих пор не составляет труда. Кроме того, в Linux можно пользоваться и файлом hosts.

Сразу отметим, что речь в данной статье пойдет исключительно о клиентской части системы DNS в linux. О серверной части мы поговорим в другой статье (она-то как раз гораздо проще для восприятия). Итак, начнем.

Разобраться, как работает DNS в вашей системе, можно только поняв, как устроена та программа, которую вы запускаете. Серьезно, только сама программа определяет, как она будет работать с DNS, а не операционная система в целоми и не linux в частности. Нужно смотреть, как была написана вот эта вот конкретная программа. Но не огорчайтесь сразу, вам скорее всего не понадобится срочно изучать все возможные языки программирования, только чтобы настроить вашу программу на работу с DNS. Указанный выше случай справедлив больше для программ собраных статически, разнообразных самопалов или чисто академических творений всемозможных энтузиастов.

Современные программисты достаточно ленивы и собирают свои программы динамически, т.е. с использованием разделяемых библиотек. Они позволяют им не заботиться о ряде функциональных возможностей, таких как работа с сетью, шифрованием или DNS. Действительно, вам бы не понравилось переносить один и тот же код из программы в программу только ради того, чтобы дать ей возможность преобразовывать имена в IP адреса. А если в этом коде потом обнаружиться баг или серьезная уязвимость? Нет. Вся функциональность нынче вынесена в библиотеки. И так уж получилось, что в linux самой популярной библиотекой для преобразования имен является libnss. Т.е. повторюсь, это совсем не обязательно, что ваша программа будет собрана с использованием libnss. Да, большинство (99% программ) будут следовать законам libnss, однако имейте ввиду, что возможна сборка с какой-нибудь другой библиотекой, или вообще статически с самописным кодом. Это будет лишь означать, что настраиваться DNS в этих немногочисленных случаев по-особому.

Итак, после того, как мы выяснили, что большинство программ в linux использует библиотеку libnss для преобразования имен в IP адреса, осталось лишь понять, как настроить этот самый libnss, и дело в шляпе. И тут мы натыкаемся на очередной сюрприз — libnss сам динамический. Да, это не конец цепочки Программа -> libnss -> dns-сервер. Оказывается, есть множество способов для резолвинга. Например, libnss, с помощью, опять же, подключаемых модулей, может заглянуть в файлик (например /etc/hosts) в поиске IP адреса, а потом спросить у местного MySQL, а далее еще пройти чере фильтр-сервер, отдающий запросы в соответствии со своим API по http протоколу. Т.е. вы уже начинаете понимать, что DNS сервера в этой цепочке-то может и не быть. Как же всем этим хозяйством управлять? Головным конфигурационным файлом для libnss является /etc/nsswitch.conf, именно там мы указываем:

• какие модули libnss будет использовать для перобразования имен в адреса
• в каком порядке (приоритет) их вызывать.

И только когда libnss, пройдясь по всем модулям, так и не сможет найти соответствующий запрашиваемому имени IP адрес, тогда вам будет возвращен ответ примерно такого вида

# ping google.com
ping: google.com: Name or service not known

Заглянем в /etc/nsswitch.conf

# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

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) набор алиасов (дополнительных имен)

# cat /etc/hosts
127.0.0.1 www.hippolab.ru hippolab.ru
127.0.0.1 localhost

resolve

Модуль resolve задействует механизм резолвинга имен внедренный в линукс командой, разрабатывающей systemd. Настраивается через /etc/systemd/resolved.conf. Соответственно узнать, какой DNS сервер сейчас используется можно посмотрев на диррективу "DNS=" в указанном файле. Если она закомментирована (перед строкой стоит решетка #), то systemd-resolved наследует конфигурацию либо у демона настройки сети systemd-networkd, либо берет информацию о доступных DNS серверах из /etc/resolv.conf. Если ему вообще не удается найти DNS сервера, то он попытается присоединиться к серверам Google: 8.8.8.8 и 8.8.4.4. Подробно о systemd-resolved в одной из наших предыдущих статей. В большинстве дистрибутивов по-умолчанию не задействован

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 позволяет указать домен поиска при использовании коротких имен без доменной части.

# cat /ets/resolve.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
search hippolab.ru

Модульная архитектура libnss позволяет действительно творить чудеса. Мы уже упомянули в начале статьи, что вы можете потенциально подключить модуль, который будет резолвить имена, используя базы данных MySQL или HTTP сервера. Возможности по истине безграничные

Настало время поговорить о кэшэ 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, например, имена сервисов и там, и там одинаковые. Кроме того, поддерживается ряд глобальных параметров

logfile
debug-level
threads
max-threads
server-user
stat-user
reload-count unlimited|
paranoia
restart-interval
enable-cache
positive-time-to-live
negative-time-to-live
suggested-size

check-files
persistent
shared
max-db-size
auto-propagate

Т.е. для включения кэша в nscd (этот кэш первичный, т.е. отрабатывает ДО вызова любого модуля из /etc/nsswitch.conf) вам достаточно убедиться в наличии строки

enable-cache hosts yes

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

Этой же командой вы можете очистить кэш и других сервисов, например passwd или groups. Просто замените "hosts" на нужный сервис

systemd-resolved

О systemd-resolved мы уже писали в статье Переходим на systemd-resolved. Но на всякий случай напомним. Для очистки кэша systemd-resolved в большинстве случаев достаточно просто перезапустить systemd-resolved командой

systemctl restart systemd-resolved

Или, не перезапуская сервис

dnsmasq

Кэш dnsmasq вычищается простым перезапуском