Настройка dns сервера linux
Обновлено: 06.07.2024
Сервера DNS используются системой для преобразования сложных для запоминания IP адресов в простые доменные имена. Это делается потому что людям сложно запоминать несколько никак не связанных цифр, но очень просто запомнить слово.
Когда компьютеру нужно узнать IP адрес какого-либо домена, он отправляет запрос известному ему DNS серверу. Эти сервера могут быть получены автоматически от роутера по DHCP или же заданы в ручную. В этой статье мы рассмотрим как выполняется настройка DNS Ubuntu 16.04 и более старых версиях.
Настройка DNS в Ubuntu через GUI
Раньше, для настройки DNS серверов, которые будут использоваться системой было достаточно внести адреса нужных серверов в файл /etc/resolv.conf. Но сейчас всей конфигурацией сети в Ubuntu управляет NetworkManager, а этот файл теперь представляет собой только ссылку на файл NetworkManager.
Этот способ до сих пор работает, но в нем вы можете настроить DNS на LiveCD, или до перезагрузки. После перезагрузки все настройки собьются и придется все делать заново. Поэтому, чтобы все сохранилось нужно выполнять все действия через интерфейс NetworkManager. Сначала откройте контекстное меню для значка сети на панели и выберите "Изменить подключения":
Выберите ваше подключение и нажмите "Изменить":
В открывшемся окне перейдите на вкладку "Параметры IPv4":
Затем, в поле "Способ настройки" выберите "Автоматически (DHCP, только адрес)":
Теперь немного ниже появиться поле "Серверы DNS", где вам нужно прописать нужные серверы, можно несколько адресов через запятую. Например, можно указать сервера от Google:
Поле этого нажмите "Сохранить" и "Закрыть". Теперь можете переподключитесь к этому соединению и можете проверять текущий DNS сервер:
Собственно, это все, но есть еще один способ настройки через консоль, если этот не сработал или вы предпочитаете работать из консоли.
Настройка DNS через терминал Ubuntu
В Ubuntu есть унифицированный интерфейс настройки сети, который настраивается через конфигурационный файл /etc/network/interfaces. Сначала смотрим список сетевых интерфейсов:
Откройте файл для редактирования и найдите в нем имя своего сетевого интерфейса, например, auto enp0s3, если такой секции нет, ее нужно добавить:
sudo vi /etc/network/interfaces
auto enp0s3
iface enp0s3 inet dhcp
Затем, добавьте в эту секцию строчку:
Здесь адрес 8.8.8.8 - это адрес вашего DNS сервера. Но эта настройка сработает, только если ваш DHCP клиент не пытается назначить адрес самостоятельно. Чтобы указать DNS адрес на уровне DHCP сервера нужно добавить такую строчку в конфигурационный файл /etc/dhcp/dhclient.conf:
sudo vi /etc/dhcp/dhclient.conf
supersede domain-name-servers 8.8.8.8
Здесь тоже адрес 8.8.8.8 означает адрес DNS сервера. Для верности, вы можете добавить свои адреса DNS серверов в файл /etc/resolvconf/resolv.conf.d/base:
sudo vi /etc/resolvconf/resolv.conf.d/base
Чтобы настройки вступили в силу необходимо перезапустить сеть:
sudo systemctl restart networking
Возможно, даже лучше будет если вы полностью перезагрузите компьютер. Теперь вы можете открыть /etc/resolv.conf и посмотреть применялся ли новый адрес DNS:
Как видите, в моем примере все заработало. Подобно этому выполняется настройка dns linux для любого дистрибутива.
Выводы
В этой небольшой статье мы рассмотрели как выполняется настройка DNS Ubuntu 16.04 через графический интерфейс или терминал. В Ubuntu автоматической настройкой DNS могут заниматься множество утилит и это создает некоторые проблемы при настройке, но со всем можно разобраться. Надеюсь, эта информация была полезной для вас.
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.
Важным элементом управления конфигурацией и инфраструктурой сервера является поддержание удобного способа просмотра сетевых интерфейсов и IP-адресов по имени с помощью настройки корректной системы доменных имен (DNS). Использование полных доменных имен (FQDN), а не IP-адреса, для указания сетевых адресов облегчает настройку служб и приложений и повышает поддерживаемость файлов конфигурации. Настройка собственной DNS для вашей частной сети — это отличный способ совершенствования методов управления серверами.
Из этого руководства вы узнаете, как выполнить настройку внутреннего DNS-сервера с помощью программного обеспечения сервера имен BIND (BIND9) на Ubuntu 18.04, которое может быть использовано вашими серверами для предоставления частных имен хостов и частных IP-адресов. Это служит центральным средством для управления внутренними именами хостов и частными IP-адресами, что необходимо при расширении вашей среды до более чем нескольких хостов.
Версию CentOS, используемую в данном руководстве, можно найти здесь.
Предварительные требования
Для выполнения данного руководства вам потребуется следующая инфраструктура. Создайте каждый сервер в одном центре обработки данных *с активированной *опцией частной сети:
- Свежий сервер Ubuntu 18.04, который будет использоваться в качестве основного DNS-сервера, ns1.
- (Рекомендуется) Второй сервер Ubuntu 18.04, который используется в качестве дополнительного DNS-сервера, ns2.
- Дополнительные серверы в одном центре обработки данных, которые будут использовать ваши DNS-серверы.
На каждом из этих серверов необходимо настроить административный доступ с помощью пользователя sudo и брандмауэра согласно инструкциям нашего руководства по начальной настройке сервера Ubuntu 18.04.
Если вы не знакомы с концепцией DNS, рекомендуем ознакомиться минимум с первыми тремя частями нашего руководства Введение в управление DNS.
Пример инфраструктуры и целей
В рамках данной статьи мы предполагаем следующее:
Примечание: существующая настройка будет отличаться, примеры имен и IP-адресов будут использоваться для демонстрации того, как выполнить настройку DNS-сервера для получения работающей внутренней DNS. У вас должна быть возможность легко адаптировать данную настройку для вашей среды, заменив имена хостов и частные IP-адреса на собственные. Нет необходимости использовать имя региона центра обработки данных в схеме присвоения имен, но мы используем его для обозначения хостов, принадлежащих к частной сети конкретного центра обработки данных. Если вы используете несколько центров обработки данных, вы можете настроить внутреннюю DNS внутри каждого отдельного центра обработки данных.
К концу данного руководства мы получим основной DNS-сервер, ns1, и, в качестве опции, дополнительный DNS-сервер, ns2, который будет служит в качестве резервного сервера.
Давайте начнем с установки нашего основного DNS-сервера, ns1.
Установка BIND на DNS-серверах
На обоих DNS-серверах, ns1 и ns2, обновите кэш пакета apt с помощью следующей команды:
Теперь можно переходить к установке BIND:
Настройка режима IPv4 для Bind
Прежде чем продолжить, давайте настроим режим IPv4 в BIND, так как наша частная сеть использует исключительно IPv4. На обоих серверах отредактируйте файл настроек по умолчанию bind9 с помощью следующей команды:
Добавьте “-4” в конец параметра OPTIONS . Результат будет выглядеть следующим образом:
Сохраните файл и закройте его после завершения.
Перезапустите BIND для вступления изменений в силу:
Теперь, после установки BIND, давайте настроим основной DNS-сервер.
Настройка основного DNS-сервера
Конфигурация BIND состоит из множества файлов, которые включены в основной файл конфигурации, named.conf . Эти имена файлов начинаются с named , потому что это имя процесса, который запускает BIND (сокращение от “domain name daemon”). Мы начнем с настройки файла параметров.
Настройка файла параметров
На сервере ns1 откройте файл named.conf.options для редактирования:
Над существующим блоком options создайте новый блок ACL (список контроля доступа) под названием “trusted”. Именно здесь мы создадим список клиентов, для которых мы будем разрешать рекурсивные DNS-запросы (т. е. запросы от ваших серверов, находящихся в том же центре обработки данных, что и ns1). С помощью нашего примера частных IP-адресов мы добавим ns1, ns2, host1 и host2 в наш список надежных клиентов:
Теперь, когда у нас есть список доверенных DNS-клиентов, нам нужно отредактировать блок options . В настоящее время начало блока выглядит следующим образом:
Под директивой directory добавьте выделенные цветом строки конфигурации (и замените в соответствующем IP-адресе ns1), чтобы результат выглядел примерно следующим образом:
После завершения редактирования сохраните и закройте файл named.conf.options . Согласно конфигурация выше, только ваши собственные серверы (т. е. доверенные) смогут запрашивать у вашего DNS-сервера внешние домены.
Далее мы настроим локальный файл, чтобы задать ваши DNS-зоны.
Настройка локального файла
На сервере ns1 откройте файл named.conf.local для редактирования:
Добавьте зону прямого просмотра со следующими строками, заменив имя зоны на собственное, и закрытый IP-адрес дополнительного DNS сервера в директиве allow-transfer :
Если, согласно нашему предположению, нашей частной подсетью является 10.128.0.0/16 , добавьте зону обратного просмотра с помощью следующих строк (обратите внимание, что имя зоны обратного просмотра начинается с “128.10”, что представляет собой битное преобразование “10.128"):
Если ваши серверы охватывают несколько частных подсетей, но находятся в одном центре обработки данных, обязательно указывайте дополнительную зону и файл зоны для каждой отдельной подсети. После добавления всех необходимых зон сохраните и закройте файл named.conf.local .
Теперь, когда наши зоны указаны в BIND, нам нужно создать соответствующие файлы для зоны прямого и обратного просмотра.
Создание файла для зоны прямого просмотра
Давайте создадим директорию, в которой будут находиться наши файлы зоны. Согласно конфигурации named.conf.local, это должна быть директория /etc/bind/zones :
При создании нашего файла зоны для прямого просмотра мы будем опираться в качестве примера на файл зоны db.local . Скопируйте его в надлежащее место с помощью следующих команд:
Теперь необходимо отредактировать наш файл зоны для прямого просмотра:
Первоначально он будет выглядеть примерно следующим образом:
Далее удалите три записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.
В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.
Полученный нами в итоге пример файла зоны для прямого просмотра выглядит следующим образом:
Теперь пришло время перейти к файлу (файлам) зоны для обратного просмотра.
Создание файла (файлов) зоны для обратного просмотра
В ns1 для каждой зоны обратного просмотра, заданной в файле named.conf.local, необходимо создать файл зоны для обратного просмотра. При создании нашего файла (или файлов) зоны для обратного просмотра мы будем опираться в качестве примера на файл зоны db.local. Скопируйте его в надлежащее место с помощью следующих команд (замените имя файла назначения, чтобы оно соответствовало определению вашей зоны для обратного просмотра):
Отредактируйте файл зоны для обратного просмотра, который соответствует зоне(-ам), определенной(-ым) в named.conf.local:
Первоначально он будет выглядеть примерно следующим образом:
Как и в случае с файлом зоны для прямого просмотра, вам нужно изменить запись SOA и увеличить значение serial. Он должен выглядеть следующим образом:
Теперь удалите две записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.
В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.
Затем добавьте записи PTR для всех ваших серверов, чей IP-адрес соответствует подсети файла зоны, который вы редактируете. В нашем примере это будут все наши хосты, поскольку все они находятся в подсети 10.128.0.0/16 . Обратите внимание, что первый столбец включает два последних байта частных IP-адресов ваших серверов в обратном порядке. Обязательно замените имена и частные IP-адреса согласно данным ваших серверов:
Сохраните и закройте файл зоны для обратного просмотра (повторите описанные в данном разделе действия, если вам потребуется добавить дополнительные файлы зоны для обратного просмотра).
Полученный нами в итоге пример файла зоны для обратного просмотра выглядит следующим образом:
Мы завершили редактирование наших файлов, и теперь мы можем проверить наши файлы на ошибки.
Проверка синтаксиса конфигурации BIND
Запустите следующую команду для проверки синтаксиса файлов named.conf* :
Команда named-checkzone может использоваться для проверки корректности ваших файлов зоны. Первый аргумент команды указывает имя зоны, а второй аргумент определяет соответствующий файл зоны, оба из которых определены в named.conf.local .
А чтобы проверить конфигурацию зоны для обратного просмотра “ 128.10 .in-addr.arpa”, запустите следующую команду (замените на данные, соответствующие вашей зоне для обратного просмотра и файлу):
Когда все файлы конфигурации и зоны не будут иметь ошибок, вы должны будете перезапустить службу BIND.
Перезапуск BIND
Если у вас есть настроенный брандмауэр UFW, откройте доступ к BIND с помощью следующей команды:
Теперь ваш основной DNS-сервер настроен и может отвечать на запросы DNS. Давайте перейдем к созданию дополнительного DNS-сервера.
Настройка дополнительного DNS-сервера
В большинстве сред правильным решением будет создание дополнительного DNS-сервера, который будет отвечать на запросы, если основной сервер окажется недоступным. К счастью, настройка дополнительного DNS-сервера выполняется намного проще.
На сервере ns2 отредактируйте файл named.conf.options :
В верхней части файла добавьте ACL с частными IP-адресами всех ваших доверенных серверов:
Под директивой directory добавьте следующие строки:
Сохраните и закройте файл named.conf.options . Этот файл должен выглядеть так же, как файл named.conf.options сервера ns1, за исключением того, что его необходимо настроить на прослушивание частного IP-адреса ns2.
Теперь необходимо отредактировать файл named.conf.local :
Определите slave-зоны, соответствующие master-зонам основного DNS-сервера. Обратите внимание, что в качестве типа используется slave, в файле отсутствует путь, и существует директива masters , которая должна быть настроена на частный IP-адрес основного DNS-сервера. Если вы определили несколько зон для обратного просмотра на основном DNS-сервере, обязательно проверьте, что все они были добавлены на этом этапе:
Сохраните и закройте файл named.conf.local .
Запустите следующую команду для проверки валидности ваших файлов конфигурации:
После выполнения проверки перезапустите BIND:
Разрешите подключение DNS к серверу, внеся изменения в правила брандмауэра UFW:
Теперь у вас есть основной и дополнительный DNS-серверы для имени частной сети и преобразования IP-адреса. Теперь вам нужно настроить ваши клиентские серверы, чтобы они могли использовать ваши частные DNS-серверы.
Настройка DNS-клиентов
Прежде чем все ваши серверы в доверенном ACL смогут отправлять запросы на ваши DNS-серверы, вы должны настроить для каждого из них использование ns1 и ns2 в качестве сервера имен. Этот процесс варьируется в зависимости от операционной системы, но для большинства дистрибутивов Linux он подразумевает добавление ваших серверов доменных имен в файл /etc/resolv.conf .
Клиенты Ubuntu 18.04
На Ubuntu 18.04 настройка сетевого взаимодействия выполняется с помощью Netplan, абстракции, которая позволяет вам записывать стандартную конфигурацию сети и применять ее к несовместимому сетевому ПО, отвечающему за бекэнд. Для настройки DNS нам потребуется записать файл конфигурации Netplan.
Во-первых, найдите устройство, связанное с вашей частной сетью, отправив частной подсети команду ip address :
В этом примере используется частный интерфейс eth1 .
Далее необходимо создать новый файл в /etc/netplan с именем 00-private-nameservers.yaml :
Вставьте в файл следующее содержимое. Вам потребуется изменить интерфейс частной сети, адреса ваших DNS-серверов ns1 и ns2, а также зону DNS:
Примечание: Netplan использует формат сериализации данных YAML для своих файлов конфигурации. Поскольку YAML использует структурирование текста и пробелы для определения структуры данных, убедитесь, что ваше определение имеет равномерное структурирование текста во избежание ошибок.
Сохраните файл и закройте его после завершения.
Затем вы должны сообщить Netplan о необходимости использования нового файла конфигурации с помощью команды netplan try . При наличии проблем, которые приводят к потере подключения к сети, Netplan будет автоматически перезапускать изменения по истечении определенного периода времени:
Если счетчик в нижней части обновляется корректно, это значит, что новой конфигурации удалось по крайней мере не повредить ваше соединение SSH. Нажмите ENTER, чтобы принять изменения в конфигурации.
Теперь проверьте DNS-преобразователь системы, чтобы определить, применены ли изменения в конфигурацию DNS:
Прокрутите вниз, пока не увидите раздел для вашего интерфейса частной сети. Вы должны увидеть частные IP-адреса ваших DNS-серверов, которые будут перечислены в первую очередь, а за ними идут резервные значения. Ваш домен должен находиться в строке DNS Domain:
Ваш клиент должен быть настроен на использование ваших внутренних DNS-серверов.
Клиенты Ubuntu 16.04 и Debian
В серверах Ubuntu 16.04 и Debian вы можете изменить файл /etc/network/interfaces :
Сохраните файл и закройте его после завершения.
Перезапустите ваши сетевые службы, применив изменения с помощью следующих команд. Убедитесь, что вы заменили eth0 на имя вашего сетевого интерфейса:
В результате будет выполнен перезапуск вашей сети без отключения текущего подключения. Если все работает корректно, вы должны увидеть примерно следующее:
Еще раз проверьте, что ваши настройки были применены, введя следующую команду:
Вы должны увидеть ваши серверы доменных имен в файле /etc/resolv.conf , а также ваш домен поиска:
Ваш клиент настроен для использования ваших DNS-серверов.
Клиенты CentOS
В CentOS, RedHat и Fedora Linux отредактируйте файл /etc/sysconfig/network-scripts/ifcfg- eth0 . Возможно, вам придется заменить eth0 на имя вашего основного сетевого интерфейса:
Сохраните файл и закройте его после завершения.
Перезапустите сетевую службу с помощью следующей команды:
Команда может зависнуть на несколько секунд, но через короткое время вы должны вернуться в командную строку.
Убедитесь, что изменения вступили в силу, введя следующую команду:
Вы должны увидеть ваши серверы доменных имен и домена поиска в списке:
Ваш клиент теперь может подключиться и использовать ваши DNS-серверы.
Тестирование клиентов
Используйте nslookup для проверки того, могут ли ваши клиенты отправлять запросы вашим серверам доменных имен. У вас должна быть возможность сделать это для всех клиентов, которые были настроены и находятся в доверенном ACL.
Для клиентов CentOS вам может потребоваться установка утилиты с помощью следующей команды:
Мы можем начать выполнять прямой просмотр.
Прямой просмотр
Теперь мы можем проверить обратный просмотр.
Обратный просмотр
Чтобы протестировать обратный просмотр, отправьте DNS-серверу запрос на частный IP-адрес host1:
Результат будет выглядеть следующим образом:
Поздравляем! Ваши внутренние DNS-серверы настроены надлежащим образом! Теперь мы перейдем к сохранению записей зоны.
Сохранение DNS-записей
Теперь, когда у вас есть работающий внутренний DNS-сервер, вам нужно хранить ваши записи DNS, чтобы они точно отражали среду сервера.
Добавление хоста в DNS
При добавлении хоста в вашу среду (в одном центре обработки данных) вам нужно добавить его в DNS. Здесь представлен список шагов, которые вам нужно предпринять:
Основной сервер доменных имен
- Файл зоны для прямого просмотра: добавьте запись A для нового хоста, увеличив значение “Serial”
- Файл зоны для обратного просмотра: добавьте запись PTR для нового хоста, увеличив значение “Serial”
- Добавьте частный IP-адрес вашего нового хоста в доверенный ACL ( named.conf.options )
Протестируйте ваши файлы конфигурации:
Затем перезагрузите BIND:
Ваш основной сервер должен быть настроен для использования нового хоста.
Дополнительный сервер доменных имен
- Добавьте частный IP-адрес вашего нового хоста в доверенный ACL ( named.conf.options )
Проверьте синтаксис конфигурации:
Затем перезагрузите BIND:
Ваш вторичный сервер теперь будет принимать подключения с нового хоста.
Настройка нового хоста для использования вашей DNS
- Настройте /etc/resolv.conf для использования ваших DNS-серверов
- Выполните проверку с помощью nslookup
Удаление хоста из DNS
Если вы удалите хост из вашей среды или захотите просто убрать его из DNS, просто удалите все данные, которые были добавлены при добавлении сервера в DNS (т. е. выполните описанные выше шаги в обратно порядке).
Заключение
Теперь вы можете обращаться к интерфейсам серверов вашей частной сети по имени, а не по IP-адресу. Это упрощает настройку служб и приложений, поскольку вам больше не нужно запоминать частные IP-адреса, а файлы будет легче читать и понимать. Кроме того, теперь вы можете изменять свои конфигурации для работы с новыми серверами в одном месте, на вашем основном DNS-сервере, вместо того чтобы редактировать целых набор самых разных файлов.
Когда ваш внутренний DNS-сервер был настроен, а файлы конфигурации используют частные FQDN для указания сетевых подключений, *критически *важно, чтобы ваши DNS-сервера обслуживались надлежащим образом. Если оба сервера окажутся недоступны, ваши службы и приложения, которые опираются на них при работе, не смогут нормально функционировать. Именно поэтому рекомендуется настроить для вашей DNS минимум один дополнительный сервер и сохранять рабочиие резервные копии всех серверов.
DNS серверы (система доменных имен) позволяют нам получить определенный IP-адрес из доменного имени, таким образом, мы можем получить доступ к различным веб-сайтам, поместив ваше доменное имя непосредственно в адресную строку веб-браузера. У нас также есть возможность настроить DNS-сервер в домашней или профессиональной локальной сети, чтобы подключаться к различным компьютерам в локальной сети через определенное доменное имя, без необходимости всегда помнить частные IP-адреса. Сегодня в этой статье мы покажем вам, как настроить DNS-сервер на Linux сервер с использованием Bind9, самого популярного и используемого DNS-сервера.
Что такое привязка?
Bind, или также известный как Berkeley Internet Name Domain, представляет собой программное обеспечение, которое отвечает за выполнение задачи DNS-сервера. Bind в настоящее время является стандартом и широко используется в операционных системах Linux, а также в Unix, поэтому, если у вас есть сервер на базе Linux или Unix, и вам нужен DNS-сервер для обработки запросов из локальной сети, тогда Bind будет что вы должны использовать. Текущая версия Bind - это версия Bind9, и она обычно используется на всех серверах, предыдущие версии считаются небезопасными и «устаревшими», поэтому их не рекомендуется использовать.
Bind не заменяет DNS-серверы, подобные тем, которые мы можем использовать от Google (8.8.8.8), Cloudflare (1.1.1.1) или других, а скорее дополняет их. Клиенты локальной сети будут иметь в качестве DNS-сервера сервер привязки, который мы настраиваем на сервере Linux, позже в этой привязке мы сможем настроить различные правила для доступа к локальным компьютерам через их частные IP-адреса. Если клиент в локальной сети делает DNS-запрос на веб-сайт в Интернете, логически DNS-сервер не будет иметь все IP-адреса в Интернете в своей базе данных, в этом случае общедоступные DNS-серверы настроены для обработки этих запросов путем пересылки server с Bind запрос, и мы автоматически вернем его клиенту, который сделал запрос.
В настоящее время используется версия Bind 9, она была написана с нуля, чтобы избежать проблем с предыдущими версиями, кроме того, она включает очень важные функции, такие как DNSSEC для обеспечения безопасности доменов с использованием криптографии, а также улучшения параллельной обработки различных DNS-запросы, полная поддержка сетей IPv6 и многое другое. Конечно, эта последняя версия Bind имеет очень важные улучшения безопасности, таким образом, мы будем защищены от возможных атак, которые могли произойти в предыдущих версиях.
Предварительные требования перед установкой Bind
- Настройте статический DHCP в маршрутизаторе / брандмауэре, который у нас есть, указав наш MAC-адрес сетевой карты и IP-адрес, который мы хотим, чтобы он всегда получал.
- Статически настройте наш сервер Linux, в этом случае DHCP-сервер маршрутизатора / брандмауэра должен иметь диапазон DHCP, который находится за пределами нашего частного IP-адреса, который мы установили.
Чтобы статически настроить IP-адрес в Linux, мы должны отредактировать файл конфигурации «/ etc / network / interfaces» и поместить следующее:
auto lo
iface lo inet loopback
автомобиль Ens33
iface eth0 inet static
адрес 192.168.1.2
маска сети 255.255.255.0
192.168.1.1 шлюз
DNS-серверы 192.168.1.2
Затем мы должны перезапустить службу, чтобы изменения были корректно применены (если мы изменили текущий IP-адрес):
sudo service networking restart
Как только наш IP-адрес в локальной сети зафиксирован, мы можем установить Bind.
Привязать установку на Linux и автозагрузку
Первое, что нам нужно сделать для настройки DNS-сервера (привязки) в Linux, - это установить его из репозиториев, мы собираемся установить как DNS-сервер Bind9, так и пакеты, предлагаемые операционной системой Debian, поэтому мы необходимо поместить в консоль следующее:
sudo apt install bind9 bind9-doc resolvconf python-ply-doc
После того, как мы установили все предыдущие пакеты, нам нужно перейти в каталог программы, где нам нужно будет начать настройку необходимых файлов:
Целесообразно получить доступ к этому каталогу как root (sudo su) чтобы избежать проблем с разрешениями при копировании файлов или изменении существующих. Если мы введем «ls -l», чтобы перечислить все файлы, которые у нас есть, мы увидим следующее:
Как видите, у нас есть большое количество различных файлов конфигурации, каждый из которых специально ориентирован на конкретную задачу, в официальной документации Bind9 вы можете найти, для чего каждый из них предназначен. Предположим, что с этого момента вы всегда находитесь в режиме суперпользователя (root), чтобы редактировать или копировать файлы без ограничений.
Настройка серверов пересылки привязки с использованием общедоступных DNS-серверов
Первое, что мы собираемся сделать, это настроить переадресацию DNS-серверов, то есть общедоступных DNS-серверов для пересылки запросов в Интернет. Файл конфигурации, отвечающий за эту задачу, называется named.conf.options. Первое, что мы делаем, это делаем резервную копию файла на случай, если мы отредактируем его неправильно и все перестанет работать:
cp /etc/bind/named.conf.options /etc/bind/named.conf.options.copia
Теперь мы редактируем файл, добавляя DNS-серверы в раздел пересылки, как вы можете видеть здесь:
Это было бы так:
После того, как мы его изменили, мы перезапускаем службу Bind9, чтобы убедиться, что все работает правильно и не возвращает никаких ошибок:
sudo service bind9 restart
Теперь мы собираемся проверить, правильно ли они работают, для этого мы выполняем команду nslookup, и мы должны увидеть, что наш DNS-сервер правильно определил домен, в нашем случае IP-адрес сервера - 192.168.231.130:
После того, как мы настроили Bind для пересылки разрешений веб-сайтов в общедоступный DNS, мы увидим, как настроить его для разрешения внутренних доменов.
Настроить привязку для локальных разрешений
Файл конфигурации, который мы должны настроить сейчас, называется .conf.local, желательно сделать резервную копию на случай, если что-то пойдет не так при настройке, для этого мы выполняем:
cp /etc/bind/named.conf.local /etc/bind/named.conf.local.copia
После того, как мы сделали резервную копию, нам нужно будет отредактировать файл конфигурации named.conf.local, чтобы продолжить настройку. В этот файл конфигурации нам нужно будет поместить зону, о которой мы говорим, а также файл конфигурации привязки, в котором есть все конфигурации, поэтому мы можем оставить его так:
zone "redlocal.com" type master;
file "/etc/bind/db.redlocal";
>;
Важно, чтобы «файл» относился к файлу конфигурации, который мы импортируем и который мы собираемся настроить прямо сейчас.
Теперь нам нужно скопировать базу данных, которая есть в «db.local», присвоить ей имя » db.redlocal », Который мы определили в предыдущем файле.
cp /etc/bind/db.local /etc/bind/db.redlocal
Теперь мы редактируем этот файл конфигурации, который по умолчанию содержит много информации, и адаптируем его к нашим интересам.
После сохранения файла конфигурации мы проверяем синтаксис с помощью следующей команды:
Теперь перезапускаем процесс привязки следующей командой:
sudo service bind9 restart
У нас есть все готово, чтобы запустить серию тестов и проверить, все ли мы сделали правильно. Чтобы убедиться, что все работает, мы должны выполнить следующие команды:
Он покажет нам следующее, IP-адрес маршрутизатора:
То же самое можно сделать и с ПК1:
После того, как нам удалось правильно разрешить локальные домены, вернув соответствующий IP-адрес, мы можем без проблем пинговать через домен:
Теперь мы настроим обратное разрешение доменов.
Обратное разрешение домена
Теперь мы собираемся настроить DNS-сервер для разрешения доменов в обратном порядке, указав IP-адрес и сообщив, к какому домену принадлежит этот IP-адрес. Чтобы достичь нашей цели, мы должны добавить следующие строки в файл /etc/bind/ named.conf.local, который мы использовали ранее:
zone "192.in-addr.arpa" type master;
file "/etc/bind/db.192";
>;
Мы также должны скопировать файл конфигурации по умолчанию, чтобы отредактировать его. Из файла db.127 мы создаем db.192:
cp /etc/bind/db.127 /etc/bind/db.192
После того, как мы его создали, просто отредактируйте его, указав следующую информацию:
После сохранения файла конфигурации мы проверяем синтаксис с помощью следующей команды:
named-checkzone 192.168.231.130 /etc/bind/db.192
У нас должно получиться что-то вроде этого:
named-checkzone 168.192.in-addr.arpa db.192
zone 168.192.in-addr.arpa/IN: loaded serial 1
OK
Теперь перезапускаем процесс привязки следующей командой:
sudo service bind9 restart
И проверяем правильность работы:
Мы надеемся, что это полное руководство по привязке помогло вам настроить собственный 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, особенности других дистрибутивов тоже будут отмечены. Конфиг сети стенда следующий:
Установка 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 "имя_сети" ;
Раздел 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 секунд.
В конфигурационных файлах BIND могут применяться следующие директивы:
- $TTL - определяет TTL по-умолчанию для всех записей в текущей зоне.
- $ORIGIN - изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется "выше" (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
- $INCLUDE - включает указанный файл как часть файла зоны.
Для того чтобы локальный резолвер сервера тоже использовал локальный DNS, необходимо привести файл resolv.conf к следующему виду:
Если в имени ресурсной записи встречается символ "*", то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. Такую запись называют "wildcard запись". Однако, символ "*" не может быть использован где угодно. Это может быть только первый символ в поле Name текущего домена, отделенный от остальных символом "."
Настройка кэширующего DNS сервера
После установки bind, он полностью готов работать как кэширующий DNS сервер без дополнительной настройки. Единственный недостаток - он обрабатывает запросы на всех интерфейсах, что нам абсолютно не нужно, поэтому мы немного подредактируем настройки сервера.
Для того, чтобы BIND работал в качестве кэширующего сервера, необходимо иметь конфигурационные файлы заполненные необходимой информацией:
- named.conf;
- описание серверов корневой зоны (зона типа hint);
- описание зоны 127.in-addr.arpa.
В данном примере приведен кэширующий DNS сервер, обрабатывающий запросы из списка сетей lan, в которую входит только одна локальная сеть 192.168.1.1/24 и петлевой интерфейс. При необходимости можно включить туда и другие сети. После определения списка сетей в директиве acl, в любом месте конфига можно будет ссылаться на этот список по имени (в нашем примере имя - lan), что, собственно и сделано в разделе options. Большинство параметров я прокомментировал, но отдельного внимания требует раздел, описывающий зону корневых серверов. В параметре file задан относительный путь к файлу описания корневых серверов (путь, относительно рабочего каталога сервера). За обновлениями данного файла необходимо следить, хотя он обновляется довольно редко (откуда брать обновленный файл я писал в теории DNS). Как вы заметили, имеется так же две записи для зоны localhost и две записи обратных зон для бродкаст доменов. Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.
Чтобы не вносить неразбериху в куче конфигурационных файлов, в статье я привожу примеры на основе единого конфигурационного файла. На самом деле, в последних версиях Debian (и других дистрибутивах Linux), файл named.conf выглядит следующим образом:
То есть основной файл не содержит конфигураций, а включает в себя более узко специализированные файлы, которые отвечают за свои задачи, например named.conf.options - содержит глобальные параметры конфигурации, named.conf.default-zones - содержит описание localhost и broadcast зон, а named.conf.local содержит описания зон, за которые отвечает данный сервер.
Далее, хочу обратить внимание на наличие файлов зон в каталоге, указанном в разделе options в параметре directory с именами, соответствующими параметрам file в разделах, описывающих зоны:
Рассматривать файлы "петлевых" и бродкастовых зон не вижу смысла, т.к. после установки пакета bind настройки заданные по умолчанию в данных файлах вполне приемлемы. Далее, при организации мастер сервера мы рассмотрим пример описания файла зоны. Хочу обратить внимание, что мы настраиваем кэширующий сервер, а определяем мы его и как master для некоторых из зон. В нашем случае "кэширующий" говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.
Да, чуть не забыл, демон named должен быть разрешен для запуска на необходимых уровнях выполнения ОС (команда в RedHat - /sbin/chkconfig bind9 on, в Debian - /usr/sbin/update-rc.d bind9 defaults). После изменения конфигурационных файлов можно добавить сервис в автозагрузку и запустить демон:
Давайте рассмотрим другие варианты сервера.
Главный (master) сервер зоны
Основной конфиг содержит следующие настройки:
Отдельно хочется описать параметр allow-transfer < 10.0.0.191; >;. Данный параметр описывает серверы, которым разрешено скачивать копию зоны - т.н. slave серверА. В следующем примере мы разберем настройку slave DNS.
Для корректной работы логирования необходимо создать соответствующий каталог и присвоить необходимые права:
а так же в домене in-addr.arpa.
Вторичный (secondary, slave) авторитетный сервер зоны
Основная функция slave сервера - автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP, посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).
Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.
Прежде чем приступить к настройке slave DNS сервера, необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:
Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:
- Скопироватьконфигурационный файл named.conf с master сервера;
- Заменитьпараметр type master на type slave в тех зонах, для которых он будет вторичным;
- Параметр allow-transfer < 10.0.0.191; >;заменить на masters < 10.0.0.152;>; в тех зонах, для которых он будет вторичным;
- Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
- Создать каталоги для логов, как в предыдущем примере.
Итого, мы получаем конфиг slave сервера:
после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:
Настройка netfilter (iptables) для DNS BIND
Собственно, настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 53/udp порту. Почитав статью о том, что такое netfilter и правила iptables и ознакомившись с практическими примерами iptables, можно создать правила фильтрации сетевого трафика:
Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.
Устранение неполадок
Основным источником для выявления проблем с DNS является системный лог. Вот пример ошибок при запуске, когда я ошибся с путем к файлу зоны коревых серверов:
Отличным инструментом для диагностики являются команды диагностики DNS.
Резюме
В текущей статье я описал настройку основных конфигураций DNS сервера BIND. Целью статьи было - дать представление о работе сервера BIND в UNIX. Я практически не затронул вопросы безопасности ДНС и мало затронул такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения я предоставлю список дополнительных источников, в которых, я надеюсь, удастся получить нужную информацию. На этом ставлю точку. До новых встреч.
Читайте также: