Post navigation

Простая конфигурация DHCP

По-умолчанию конфигурация в файле dhcpd.conf не содержит никаких объявленных сетей, а так же в файле /etc/default/isc-dhcp-server нет указанных интерфейсов, по которым будет происходит слушание и раздача параметров. Поэтому при запуске службы вы получите ошибку.

Поэтому для запуска нам потребуется записать в конфигурационный файл простейшее описание сети(ей):

subnet 10.1.1.0 netmask 255.255.255.0 {
range 10.1.1.3 10.1.1.254;
}

subnet 192.168.0.0 netmask 255.255.0.0 {
}

А так же в файле /etc/default/isc-dhcp-server укажем наш интерфейс (или несколько):

INTERFACES="eth0"

Этот файл конфигурации указывает DHCP-серверу прослушивать запросы DHCP-клиента в подсети 10.1.1.0 с маской сети 255.255.255.0 на интерфейсе eth0. Кроме того, он назначит IP адреса в диапазоне 10.1.1.3-10.1.1.254. Он также определяет пустое описание для подсети 192.168.0.0.

Измените приведенный выше код с вашей подсетью и вставьте его в файл /etc/dhcp/dhcpd.conf. После перезагрузите DHCP-сервер с помощью команды:

Настройка DNS-клиентов

Прежде чем все ваши серверы в доверенном ACL смогут отправлять запросы на ваши DNS-серверы, вы должны настроить для каждого из них использование ns1 и ns2 в качестве сервера имен. Этот процесс варьируется в зависимости от операционной системы, но для большинства дистрибутивов Linux он подразумевает добавление ваших серверов доменных имен в файл .

Клиенты Ubuntu 18.04

На Ubuntu 18.04 настройка сетевого взаимодействия выполняется с помощью Netplan, абстракции, которая позволяет вам записывать стандартную конфигурацию сети и применять ее к несовместимому сетевому ПО, отвечающему за бекэнд. Для настройки DNS нам потребуется записать файл конфигурации Netplan.

Во-первых, найдите устройство, связанное с вашей частной сетью, отправив частной подсети команду :

В этом примере используется частный интерфейс .

Далее необходимо создать новый файл в с именем :

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

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

/etc/netplan 00-private-nameservers.yaml

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

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

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

Теперь проверьте DNS-преобразователь системы, чтобы определить, применены ли изменения в конфигурацию DNS:

Прокрутите вниз, пока не увидите раздел для вашего интерфейса частной сети. Вы должны увидеть частные IP-адреса ваших DNS-серверов, которые будут перечислены в первую очередь, а за ними идут резервные значения. Ваш домен должен находиться в строке DNS Domain:

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

Клиенты Ubuntu 16.04 и Debian

В серверах Ubuntu 16.04 и Debian вы можете изменить файл :

Внутри найдите строку и добавьте ваши серверы доменных имен в начало списка, который уже добавлен в файл. Под этой строкой добавьте опцию , указывающую на базовый домен вашей инфраструктуры. В нашем случае это будет “nyc3.example.com”:

/etc/network/interfaces

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

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

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

Еще раз проверьте, что ваши настройки были применены, введя следующую команду:

Вы должны увидеть ваши серверы доменных имен в файле , а также ваш домен поиска:

Ваш клиент настроен для использования ваших DNS-серверов.

Клиенты CentOS

В CentOS, RedHat и Fedora Linux отредактируйте файл . Возможно, вам придется заменить на имя вашего основного сетевого интерфейса:

Найдите опции и и задайте для них частные IP-адреса ваших основного и дополнительного серверов доменных имен. Добавьте параметр , используя базовый домен вашей инфраструктуры. В этом руководстве это будет “nyc3.example.com”:

/etc/sysconfig/network-scripts/ifcfg-eth0

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

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

Команда может зависнуть на несколько секунд, но через короткое время вы должны вернуться в командную строку.

Убедитесь, что изменения вступили в силу, введя следующую команду:

Вы должны увидеть ваши серверы доменных имен и домена поиска в списке:

/etc/resolv.conf

Ваш клиент теперь может подключиться и использовать ваши DNS-серверы.

Настройка Bind9

Теперь перейдём к настройке Bind9. Откройте файл конфигурации, прописав в терминале:

и добавьте туда следующие строки:

forwaders — вышестоящий DNS, используемый в случаях, когда в базе не удаётся найти URL-запрос.

listen-on — адреса, через которые будет обслуживаться ваш DNS-сервер.

Перезапуск bind9

Далее необходимо перезапустить bind9. Для этого пропишите в терминале:

Теперь укажите зоны прямого и обратного просмотра, а также введите их в конфигурации bind9. Исходные данные следующие:

Доменное имя — dom IP-адрес сервера — 192.168.0.1 Имя сервера — ns.dom

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

далее отройте командой:

и отредактируйте следующим образом:

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

открываете его командой:

и также редактируете:

Чтобы настроить зоны в конфигурации bind9, нужно открыть файл конфигурации командой:

а дальше появляется снова два варианта развития событий. Если вы создавали secret key первым способом, пропишите:

// зона прямого просмотра

// зона обратного просмотра

key DHCP_UPDATER — информация о secret key, который вы записывали в самом начале (его необходимо прописывать в кавычках). IP-адреса, указанные здесь и далее, нужно вписывать именно так, как показано здесь.

Если ранее, вы воспользовались вторым способом, введите:

// зона прямого просмотра

// зона обратного просмотра

где key rndc-key — данные ключа, взятые из системы, а zone «dom» — данные о зоне применения системы доменных имён.

Проверить правильность настройки можно с помощью команды:

Если всё сделано правильно, то она ничего не напишет. Иначе вы увидите сообщение об ошибках, и их придётся исправить.

Остаётся сохранить всё это дело, затем закрыть и перезапустить bind9, введя:

Настройка firewall (iptables) в Debian

В качестве firewall в Debian по-умолчанию используется iptables, его и будем настраивать. Изначально фаервол полностью открыт и пропускает весь трафик. Проверить список правил iptables можно следующей командой:

# iptables -L -v -n

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Шанс ошибиться очень высок. Вы просто потеряете удаленный доступ к серверу.

Создадим файл с правилами iptables:

# mcedit /etc/iptables.sh

Очень подробно вопрос настройки iptables я рассмотрел отдельно, рекомендую ознакомиться. Хотя в примере другая ОС linux, принципиальной разницы нет, настройки iptables абсолютно одинаковые, так как правила одни и те же.

Добавляем набор простых правил для базовой настройки. Все необходимое вы потом сможете сами открыть или закрыть по аналогии с существующими правилами:

#!/bin/bash
#
# Объявление переменных
export IPT="iptables"

# Активный сетевой интерфейс
export WAN=ens18
export WAN_IP=10.20.1.16

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Установим политики по умолчанию для трафика, не соответствующего ни одному из правил
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# разрешаем пинги
$IPT -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Разрешаем исходящие соединения самого сервера
$IPT -A OUTPUT -o $WAN -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Разрешить форвардинг для уже инициированных и их дочерних соединений
$IPT -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из-за разных значений MTU
$IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы
# и поэтому не могут иметь определенного статуса.
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A FORWARD -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный
# обмен данными становится не возможным, обрубаем
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# Открываем порт для ssh (!!!не забудьте указать свой порт, который вы изменили ранее!!!)
$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT
# Открываем порт для web сервера
$IPT -A INPUT -i $WAN -p tcp --dport 80 -j ACCEPT
$IPT -A INPUT -i $WAN -p tcp --dport 443 -j ACCEPT

# Записываем правила в файл
/sbin/iptables-save > /etc/iptables_rules

Даем файлу права на запуск:

# chmod 0740 /etc/iptables.sh

Запускаем скрипт:

sh /etc/iptables.sh

Проверяем правила:

# iptables -L -v -n

Проверяем, что правила записались в файл /etc/iptables_rules. Если их там нет, то записываем их вручную.

# /sbin/iptables-save > /etc/iptables_rules

Правила применились и произошла их запись в файл /etc/iptables_rules. Теперь нужно сделать так, чтобы они применялись при загрузке сервера. Для этого делаем следующее. Открываем файл /etc/network/interfaces и добавляем в него строку pre-up iptables-restore < /etc/iptables_rules Должно получиться вот так:

# cat /etc/network/interfaces

allow-hotplug eth0
iface eth0 inet dhcp
pre-up iptables-restore < /etc/iptables_rules

Для проверки перезагрузите сервер и посмотрите правила iptables. Должен загрузиться настроенный набор правил из файла /etc/iptables_rules.

Установка имени хоста на серверах имен

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

На первом DNS-сервере отредактируйте файл /etc/hosts, чтобы настроить FQDN этой машины:

В этом случае нужно связать IP-адрес 192.0.2.1 с полным именем сервера имен ns1.example.com. Мы можем сделать это, заменив строку, в которой указано имя хоста, внешним IP-адресом, FQDN и сокращенным псевдонимом хоста:

Сохраните и закройте файл, когда вы закончите.

Далее нужно еще раз проверить файл /etc/hostname:

Он должен содержать неполное имя хоста. Измените его, если это необходимо:

Сохраните и закройте файл, когда вы закончите.

Если вы изменили файл /etc/hostname, попросите систему перечитать его:

Итак, мы закончили с первым DNS-сервером на данный момент. Повторите эти же шаги на втором сервере.

Измените файл /etc/hosts, чтобы указать хост второго DNS-сервера:

Так же проверьте файл /etc/hosts. Он должен содержать только короткое неполное имя:

Снова заставьте систему перечитать файл, если вам нужно было что-то изменить в нем:

Теперь ваши серверы могут разрешать свои собственные имена без DNS. Вы готовы настроить NSD на своих серверах.

Проверка проблем с рекурсией

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

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

  • Сервер, используемый во время запроса, не отвечает.

  • Сервер, используемый во время запроса, предоставляет неверные данные.

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

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

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

Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:

  • Если сопоставитель возвращает IP-адрес корневого сервера, возможно, имеется разорванное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Следуйте инструкциям по , чтобы определить, где находится неработающее делегирование.

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

Тестирование неработающего делегирования

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

  1. В командной строке на тестируемом сервере введите следующее:

    Примечание

    Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).

  2. Если ответ содержит список записей ресурсов «NS» и «A» для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов «A» в качестве IP-адреса сервера.

    • Если ответ не содержит запись ресурса NS, делегирование будет разорвано.

    • Если ответ содержит записи ресурсов «NS», но нет записей ресурсов «A», введите » задать рекурсию» и выполните запрос по отдельности для записей ресурсов «a» серверов, перечисленных в записях NS. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса «A» для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.

  3. Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса «A» в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.

Просмотр текущих корневых ссылок

  1. Запустите консоль DNS.

  2. Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.

  3. Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.

  4. Щелкните корневые ссылки.

Проверьте наличие базовых подключений к корневым серверам.

  • Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу.

  • Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. Однако нередко можно увидеть перенастройку корневых серверов.

5: Тестирование клиентов

Используйте nslookup, чтобы проверить, могут ли ваши клиенты запрашивать серверы имен. Вы должны иметь возможность сделать это на всех клиентах, которые вы настроили и которые находятся в доверенном ACL.

На клиентах CentOS может потребоваться установить утилиту с помощью команды:

Начнем с прямого просмотра.

Прямой просмотр

Чтобы выполнить прямой просмотр и извлечь IP-адрес хоста host1.nyc3.example.com, введите:

Запрос host1 расширяется до host1.nyc3.example.com, поскольку параметр search содержит ваш частный субдомен, а запросы DNS будут пытаться просмотреть его, прежде чем искать хост в другом месте. Вывод команды выглядят следующим образом:

Теперь попробуем обратный просмотр.

Обратный просмотр

Чтобы протестировать обратный просмотр, запросите DNS-сервер:

Команда должна вернуть такой вывод:

Если все имена и IP-адреса разрешены с правильным значением, это означает, что ваши файлы зон настроены правильно. Если вы получили другие значения, обязательно просмотрите файлы зон на первичном DNS-сервере (например, db.nyc3.example.com и db.10.128).

Теперь рассмотрим сохранение записей в зоне.

Создание зон

В нашей конфигурации мы описали зону dmosk.ru в трех view. Соответственно, нам нужно создать 3 файла. В зависимости от типа операционной системы, их местоположение будет различаться.

а) CentOS / Red Hat:

mkdir /var/named/master

б) Ubuntu / Debian:

mkdir /var/cache/bind/master

* если мы еще не создавали зоны, то создаем данные каталоги.

Теперь можно создавать сами файлы для зон.

а) CentOS / Red Hat:

vi /var/named/master/dmosk.ru.in01

б) Ubuntu / Debian:

vi /var/cache/bind/master/dmosk.ru.in01

Пример файла с минимально необходимым набором записей:

$TTL 14400
dmosk.ru.     IN      SOA     ns1.dmosk.ru. admin.dmosk.ru. (
        2020120401      ; Serial
        10800           ; Refresh
        3600            ; Retry
        604800          ; Expire
        604800          ; Negative Cache TTL
)
                IN      NS      ns1.dmosk.ru.
@               IN      A       192.168.0.20
ns1             IN      A       192.168.0.2

* это файл для зоны dmosk.ru во view «internal-01». Он будет возвращать IP для записи 192.168.0.20. Предполагается, что адрес DNS-сервера в данном сетевом сегменте 192.168.0.2.

Создаем описание для зоны в следующем view.

а) CentOS / Red Hat:

vi /var/named/master/dmosk.ru.in02

б) Ubuntu / Debian:

vi /var/cache/bind/master/dmosk.ru.in02

Содержимое:

$TTL 14400
dmosk.ru.     IN      SOA     ns1.dmosk.ru. admin.dmosk.ru. (
        2020120401      ; Serial
        10800           ; Refresh
        3600            ; Retry
        604800          ; Expire
        604800          ; Negative Cache TTL
)
                IN      NS      ns1.dmosk.ru.
@               IN      A       192.168.1.20
ns1             IN      A       192.168.1.2

* файл для зоны во view «internal-02». Он будет возвращать IP для записи 192.168.1.20. Предполагается, что адрес DNS-сервера в данном сетевом сегменте 192.168.1.2.

Наконец, создаем последний файл.

а) CentOS / Red Hat:

vi /var/named/master/dmosk.ru.any

б) Ubuntu / Debian:

vi /var/cache/bind/master/dmosk.ru.any

Его содержимое:

$TTL 14400
dmosk.ru.     IN      SOA     ns1.dmosk.ru. admin.dmosk.ru. (
        2020120401      ; Serial
        10800           ; Refresh
        3600            ; Retry
        604800          ; Expire
        604800          ; Negative Cache TTL
)
                IN      NS      ns1.dmosk.ru.
@               IN      A       92.53.123.166
ns1             IN      A       92.53.123.165

* файл для зоны во view «external». Он будет возвращать IP для записи 92.53.123.166. Предполагается, что адрес DNS-сервера в данном сетевом сегменте 92.53.123.165.

Настройка DNS в Debian

Сперва мы ознакомимся с файлом /etc/resolv.conf. Это — это основной файл настройки библиотеки распознавателя имен DNS. Распознаватель — это библиотека на языке Cи, именно она обеспечивает доступ к DNS для программ в системе.

Его функции настроены на следующее:

  • На проверку записей в файле /etc/hosts или на нескольких серверах DNS;
  • На использование базы данных хостов NIS (Информационная служба сети);

В современных Linux-системах, которые используют systemd, локальные приложения получают доступ к DNS через демон system-resolved. По умолчанию эта служба имеет четыре различных режима и использует по умолчанию файл-заглушку. Его путь: /run/systemd/resolve/stub-resolv.conf.

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

К сожалению, из-за того, что /etc/resolv.conf не прямо управляется службой systemd-resolved, а иногда с помощью использования initscripts или NetworkManager, любые пользовательские изменения НЕ будут сохранены. С учетом всех сложностей, описанных выше, я хочу поделиться с вами информацией о том, как настроить DNS на Debian в этом злополучном файле /etc/resolv.conf.

Шаг 1. Содержимое /etc/resolv.conf

Чтобы это сделать мы откроем терминал и напишем команду:

В нем мы видим имя сервера nameserver 192.168.1.1 и больше ничего. Это пока что, но мы к нему вернемся.

Шаг 2. Установка resolvconf

Обязательно обновим систему с помощью команды:

После обновления устанавливаем resolvconf. Для этого пишем команду:

После установки система должна автоматически запустить службу resolvconf.service. Чтобы проверить так ли это вам надо будет использовать команду:

Здесь мы видим, что служба не запущена, но бывает, что триггер срабатывает автоматически. Так или иначе, нам надо запустить эту службу. Используем следующие команды:

Как вы поняли, с помощью sudo systemctl start resolvconf.service и sudo systemctl enable resolvconf.service мы запускаем службу, а sudo systemctl status resolvconf.service отобразит состояние активности этой службы.

Шаг 3. Настройка DNS

Теперь откройте файл /etc/resolvconf/resolv.conf.d/head. Делается это с помощью команды:

Прекрасно, следующим шагом будет внесение данных в этот файл. Вписываем в него следующие строки так, как это показано на скриншоте:

Сохраняем изменения с помощью ctrl+o -> Enter -> ctrl+x. Теперь надо перезагрузить систему, чтобы изменения пришли в действие.

Шаг 4. Проверяем файл /etc/resolv.conf

После перезагрузки снова открываем терминал и пишем команду для запуска службы (это вторичная мера, у меня, например, триггер сработал автоматически):

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

На скриншоте отображены те самые данные, которые мы внесли в файл — nameserver 8.8.8.8 и nameserver 8.8.4.4 На этом все! Настройка DNS Debian завершена. Достаточно легко и просто, а главное, что все работает.

Тестирование клиентов

Используйте для проверки того, могут ли ваши клиенты отправлять запросы вашим серверам доменных имен. У вас должна быть возможность сделать это для всех клиентов, которые были настроены и находятся в доверенном ACL.

Для клиентов CentOS вам может потребоваться установка утилиты с помощью следующей команды:

Мы можем начать выполнять прямой просмотр.

Прямой просмотр

Например, мы можем выполнить прямой просмотр для получения IP-адреса host1.nyc3.example.com с помощью следующей команды:

Запрос “host1” расширяется до “host1.nyc3.example.com”, потому что опция задана для вашего частного субдомена, а запросы DNS будут пытаться просмотреть этот субдомен перед поиском по всему хосту. Результат описанной выше команды будет выглядеть следующим образом:

Теперь мы можем проверить обратный просмотр.

Обратный просмотр

Чтобы протестировать обратный просмотр, отправьте DNS-серверу запрос на частный IP-адрес host1:

Результат будет выглядеть следующим образом:

Если все имена и IP-адреса будут передавать правильные значения, это означает, что ваши файлы зоны настроены надлежащим образом. Если вы получите неожиданные значения, обязательно проверьте файлы зоны на вашем основном DNS-сервере (например, и ).

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

Resolver DNS в Ubuntu 20.04 LTS

Какой у вас в системе установлен резолвер можно посмотреть вот такой командой:

Чтобы установить ваш DNS в качестве резолвера по умолчанию, откройте файл конфигурации systemd-resolved.

И пропишите в файле в секции ваш DNS-сервер

Закрываем файл и перезагружаем systemd-resolver

Если теперь посмотреть статус то DNS должен измениться на IP вашего сервера.

Также теперь проверьте содержание .

Если привязки не произошло, то можно установить утилиту

Запускаем сервис

На этом Настройка локального DNS-сервера BIND9 на Ubuntu 20.04 LTS окончена.

Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы. Заранее всем спасибо!!!

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Мой редактор ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: