Как перенаправить dns запросы на другой сервер

Настройка Bind как кэширующего или перенаправляющего DNS-сервера в Ubuntu 14.04

DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.

В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.

Требования

• Понимание базовых типов DNS-серверов. Ознакомиться с подробностями можно в этой статье.
• Две машины, из которых хотя бы одна работает на Ubuntu 14.04. Первая машина будет настроена как клиент (IP-адрес 192.0.2.100), а вторая – как DNS-сервер (192.0.2.1).

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

Кэширующий DNS-сервер

Серверы этого типа также называются определителями, поскольку они обрабатывают рекурсивные запросы и, как правило, могут выполнить поиск данных DNS не других серверах.

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

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

Перенаправляющий DNS-сервер

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

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

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

1: Установка Bind на DNS-сервер

Пакет Bind можно найти в официальном репозитории Ubuntu. Обновите индекс пакетов и установите Bind с помощью менеджера apt. Также нужно установить пару зависимостей.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

После этого можно начать настройку сервера. Конфигурацию кэширующего сервера можно использовать в качестве шаблона для настройки перенаправляющего сервера, поэтому сначала нужно настроить кэширующий DNS-сервер.

2: Настройка кэширующего DNS-сервера

Сначала нужно настроить Bind в качестве кэширующего DNS-сервера. Такая конфигурация заставит сервер рекурсивно искать ответы на клиентские запросы на других DNS-серверах. Он будет последовательно опрашивать все соответствующие DNS-сервера, пока не найдет ответ.

Конфигурационные файлы Bind хранятся в каталоге /etc/bind.

Большую часть файлов редактировать не нужно. Главный конфигурационный файл называется named.conf (named и bind – два названия одного приложения). Этот файл ссылается на файлы named.conf.options, named.conf.local и named.conf.default-zones.

Для настройки кэширующего DNS-сервера нужно отредактировать только named.conf.options.

sudo nano named.conf.options

Этот файл выглядит так (комментарии опущены для простоты):

options <
directory «/var/cache/bind»;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;

Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.

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

Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.

Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.

Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).

В этом блоке перечислите IP-адреса или сети, у которых будет доступ к этому DNS-серверу. Поскольку сервер и клиент работают в подсети /24, можно ограничить доступ по этой подсети. Также нужно разблокировать localhost и localnets, которые подключаются автоматически.

acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
. . .

Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:

options <
directory «/var/cache/bind»;
recursion yes;

allow-query < goodclients; >;
. . .

Блок options явно включает рекурсию, а затем настраивает параметр allow-query для использования списка ACL. Для ссылки на группу ACL можно также использовать другой параметр, например allow-recursion. При включенной рекурсии allow-recursion определит список клиентов, которые могут использовать рекурсивные сервисы.

Однако если параметр allow-recursion не установлен, Bind возвращается к списку allow-query-cache, затем к списку allow-query и, наконец, к спискам по умолчанию localnets и localhost. Поскольку мы настраиваем только кэширующий сервер (он не имеет собственных зон и не пересылает запросы), список allow-query всегда будет применяться только к рекурсии. Это самый общий способ определения ACL.

Сохраните и закройте файл.

Это все настройки, которые нужно добавить в конфигурационный файл кэширующего DNS-сервера.

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

3: Настройка перенаправляющего DNS-сервера

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

На данный момент файл named.conf.options выглядит так:

acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
directory «/var/cache/bind»;
recursion yes;
allow-query < goodclients; >;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;

Можно использовать тот же список ACL, чтобы ограничивать DNS-сервер конкретным списком клиентов. Однако при этом необходимо немного изменить конфигурацию, чтобы сервер больше не пытался выполнять рекурсивные запросы.

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

Это делается в блоке options <>. Сначала нужно создать в нем новый блок forwarders, где будут храниться IP-адреса рекурсивных серверов имен, на которые нужно перенаправлять запросы. В данном случае это будут DNS-серверы Google (8.8.8.8 и 8.8.4.4):

Далее нужно в директиве forward установить значение only, поскольку сервер должен только перенаправлять все запросы и не пытаться разрешить их самостоятельно.

В результате конфигурация выглядит так:

acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
directory «/var/cache/bind»;
recursion yes;
allow-query < goodclients; >;
forwarders <
8.8.8.8;
8.8.4.4;
>;
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;

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

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving ‘in-addr.arpa/DS/IN’: 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving ‘111.111.111.111.in-addr.arpa/PTR/IN’: 8.8.4.4#53

Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.

. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .

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

4: Проверка настроек и перезапуск Bind

Теперь нужно убедиться, что настройки работают должным образом.

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

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

Если вы получили сообщение об ошибке, исправьте ее и повторите проверку.

После этого можно перезапустить демон Bind, чтобы обновить настройки.

sudo service bind9 restart

После нужно проверить логи сервера. Запустите на сервер команду:

sudo tail -f /var/log/syslog

Теперь откройте новый терминал и приступайте к настройке клиентской машины.

5: Настройка клиента

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

Отредактируйте файл /etc/resolv.conf, чтобы направить сервер на сервер имен.

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

Откройте файл с помощью sudo в текстовом редакторе:

sudo nano /etc/resolv.conf

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

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Сохраните и закройте файл.

Теперь можно отправить тестовый запрос, чтобы убедиться, что он разрешается правильно.

Для этого можно использовать ping:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
— google.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Это значит, что клиент может подключиться к google.com с помощью DNS-сервера.

Более подробную информацию предоставит инструмент dig. Попробуйте подключиться к другому домену:

dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org. IN A
;; ANSWER SECTION:
linuxfoundation.org. 6017 IN A 140.211.169.4
;; Query time: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE rcvd: 64

Как видите, обработка запроса заняла 36 миллисекунд. Повторите запрос. Сервер должен извлечь данные из кэша, что укорит обработку запроса:

dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org. IN A
;; ANSWER SECTION:
linuxfoundation.org. 6012 IN A 140.211.169.4
;; Query time: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE rcvd: 64

Теперь запрос обрабатывается гораздо быстрее.

Также можно протестировать обратное преобразование. Для этого используйте найденный IP (в данном случае 140.211.169.4) и dig с флагом –x:

dig -x 140.211.169.4
; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME 4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.
;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE rcvd: 117

Как видите, обратное преобразование выполнено успешно.

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

. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving ‘ns4.apnic.net/A/IN’: 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving ‘ns4.apnic.com/A/IN’: 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving ‘sns-pb.isc.org/AAAA/IN’: 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving ‘ns3.nic.fr/A/IN’: 2a00:d78:0:102:193:176:144:22#53

Это значит, что сервер пытается разрешить данные IPv6, но он не настроен для поддержки IPv6. Чтобы устранить ошибку, нужно настроить Bind для обслуживания только IPv4.

sudo nano /etc/default/bind9

Найдите параметр OPTIONS и добавьте в него флаг -4, чтобы настроить поддержку только IPv4.

OPTIONS color: #ff0000;»>-4 «

Сохраните и закройте файл.

sudo service bind9 restart

После этого в логах не должно быть ошибок.

Сохранение настроек клиента DNS

Параметры файла /etc/resolv.conf сбрасываются после перезапуска. Чтобы эти настройки использовались на постоянной основе, нужно отредактировать файлы, которые обращаются к этому файлу.

Откройте этот файл:

sudo nano /etc/network/interfaces

Найдите параметр dns-nameservers. Удалите текущую запись и замените ее данными о вашем DNS-сервере или просто добавьте новый DNS-сервер в качестве одного из значений.

. . .
iface eth0 inet static
address 111.111.111.111
netmask 255.255.255.0
gateway 111.111.0.1
dns-nameservers 192.0.2.1
. . .

Сохраните и закройте файл.

В системах CentOS и Fedora для этого нужно открыть файл /etc/sysconfig/network/network-scripts/ifcfg-eth0:

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

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

Сохраните и закройте файл.

Заключение

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

Условное разрешение DNS имен в Windows Server: DNS Conditional Forwarding, политики DNS

08.02.2021
itpro
Windows Server 2016, Windows Server 2019
комментариев 6

В этой статье мы рассмотрим два способа организации условного разрешения имен в DNS сервере на Windows Server 2016: DNS conditional forwarding и DNS policy. Эти технологии позволяют настроить условное разрешение DNS имен в зависимости от запрошенного имени, IP адреса и местоположения клиента, времени суток и т.д.

Условная пересылка DNS (Conditional Forwarding) позволяет перенаправить DNS запросы об определенном домене на определенные DNS-сервера. Обычно Conditional Forwarders используется, когда нужно настроить быстрое разрешение имен между несколькими внутренними приватными доменами, или вы не хотите, чтобы DNS запросы с вашего сервера пересылались через публичную сеть Интернет. В этом случае вы можете создать на DNS сервере правило DNS пересылки DNS запросов для определенной доменной зоны (только . ) на определенный DNS сервер.

Настройка DNS Conditional Forwarder в Windows Server

Попробуем настроить условное перенаправление DNS запросов для определенной доменной зоны на Windows Server 2016. Например, я хочу, чтобы все DNS запросы к зоне corp.winitpro.ru пересылались на DNS сервер 10.1.10.11.

1. Запустите консоль управления DNS ( dnsmgmt.msc );
2. Разверните ваш DNS сервер, щелкните правой кнопкой по разделу Conditional Forwarders и выберите New Conditional Forwarder;
3. В поле DNS domain укажите FQDN имя домена, для которого нужно включить условную пересылку;
4. В поле IP addresses of the master servers укажите IP адрес DNS сервера, на который нужно пересылать все запросы для указанного пространства имен;
5. Если вы хотите хранить правило условной переадресации не только на этом DNS сервере, вы можете интегрировать его в AD. Выберите опцию “Store this conditional forwarder in Active Directory”;
6. Выберите правило репликации записи conditional forwarding (All DNS servers in this forest, All DNS servers in this domain или All domain controllers in this domain).

Настройка DNS Conditional Forwarding с помощью PowerShell

Вы можете создать правило Conditional Forward для определенной DNS зоны с помощью PowerShell. Воспользуйтесь командлетом Add-DnsServerConditionalForwarderZone:

Add-DnsServerConditionalForwarderZone -Name dmz.winitpro.ru -MasterServers 192.168.1.11,192.168.101.11 -ReplicationScope Forest

Чтобы вывести список DNS Conditional Forwarders на определенном сервере, выполните следующий PowerShell скрипт:

$DNSServer = «DC01»
$Zones = Get-WMIObject -Computer $DNSServer -Namespace «root\MicrosoftDNS» -Class «MicrosoftDNS_Zone»
$Zones | Select-Object Name,MasterServers,DsIntegrated,ZoneType | where <$_.ZoneType -eq "4">| ft -AutoSize

Фильтрация запросов DNS, политики разрешения имен в Windows Server 2016

В Windows Server 2016 появилась новая фича в службе DNS сервера – DNS политики. DNS политики позволяют настроить DNS сервер так, чтобы он возвращал различные ответы на DNS запросы в зависимости от местоположения клиента (с какого IP адреса или подсети пришел запрос), интерфейса DNS сервера, времени суток, типа запрошенной записи (A, CNAME, PTR, MX) и т.д. DNS политики в Windows Server 2016 позволяют реализовать сценарии балансировки нагрузки, фильтрации DNS трафика, возврата DNS записей в зависимости от геолокации (IP адреса клиента) и многие другие сложные сценарии.

Вы можете создать политику как на уровне DNS сервера, так и на уровне всей зоны. Настройка DNS политик в Windows Server 2016 возможна только из командной строки PowerShell.

Попробуем создать простую политику, которая позволяет вернуть разный ответ на DNS запрос в зависимости от геолокации клиента. Допустим, вы хотите, чтобы клиенты в каждом офисе использовали собственный прокси на площадке. Вы создали политику назначения прокси в домене (на всех клиентах будет указано proxy.winitpro.ru). Но клиент из каждого офиса должен резолвить этот адрес по-разному, чтобы использовать для доступа свой локальный прокси-сервер.

Я создал 3 подсети для разных офисов компании:

Add-DnsServerClientSubnet -Name «MSK_DNS_Subnet» -IPv4Subnet «192.168.1.0/24»
Add-DnsServerClientSubnet -Name «EKB_DNS_Subnet» -IPv4Subnet «192.168.11.0/24»
Add-DnsServerClientSubnet -Name «SPB_DNS_Subnet» -IPv4Subnet «192.168.21.0/24»

Чтобы вывести список всех IP подсетей клиентов, выполните:

Теперь нужно для каждого офиса создать отдельную DNS область:

Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “MSKZoneScope”
Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “EKBZoneScope”
Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “SPBZoneScope”

Следующие команды добавят 3 DNS записи с одним именем, но указывающие на разные IP адреса в разных областях DNS:

Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.1.10” -ZoneScope “MSKZoneScope”
Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.11.10” -ZoneScope “EKBZoneScope”
Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.21.10” -ZoneScope “SPBZoneScope”

Get-DnsServerResourceRecord -ZoneName “winitpro.ru” -ZoneScope SPBZoneScope

Теперь нужно создать DNS политики, которые свяжут IP подсети, DNS области и A записи.

Add-DnsServerQueryResolutionPolicy -Name “MSKResolutionPolicy” -Action ALLOW -ClientSubnet “eq,MSK_DNS_Subnet” -ZoneScope “MSKZoneScope,1” -ZoneName “winitpro.ru” –PassThru
Add-DnsServerQueryResolutionPolicy -Name “EKBResolutionPolicy” -Action ALLOW -ClientSubnet “eq,EKB_DNS_Subnet” -ZoneScope “EKBZoneScope,1” -ZoneName “winitpro.ru” -PassThru
Add-DnsServerQueryResolutionPolicy -Name “SPBResolutionPolicy” -Action ALLOW -ClientSubnet “eq,SPB_DNS_Subnet” -ZoneScope “SPBZoneScope,1” -ZoneName “winitpro.ru” –PassThru

• -Action ALLOW
• -Action DENY
• -Action IGNORE

Можно использовать следующие параметры в фильтре DNS:

-InternetProtocol «EQ,IPv4,NE,IPv6»
-TransportProtocol «EQ,UDP,TCP»
-ServerInterfaceIP «EQ,192.168.1.21»
-QType «EQ,A,AAAA,NE,PTR»
-TimeOfDay «EQ,9:00-18:00»

Вывести список всех DNS политик для DNS зоны на сервере можно так:

Get-DnsServerQueryResolutionPolicy -ZoneName winitpro.ru

Теперь с устройств из различных офисов проверьте, что DNS сервер на один и тот же запрос возвращает различные IP адреса прокси:

Можно запретить DNS серверу возвращать DNS адреса для определенного пространства имен (домена):

Add-DnsServerQueryResolutionPolicy -Name ‘BlockFidhingPolicy’ -Action IGNORE -FQDN «EQ,*.cberbank.ru»

Предыдущая статья Следующая статья

Настройка DNS-сервера для использования серверов пересылки

Сервер пересылки — это DNS-сервер в сети, который пересылает DNS-запросы внешних DNS-имен на DNS-серверы за пределами этой сети. Сервер также можно настроить на пересылку запросов в соответствии с определенными именами домена, используя условную пересылку.

DNS-сервер используется как сервер пересылки, когда другие DNS-серверы в сети настроены на переадресацию запросов, которые не могут быть разрешены локально, на этот DNS-сервер. С помощью сервера пересылки можно управлять разрешением имен для имен, находящихся за пределами организации, например в сети Интернет, что может способствовать увеличению эффективности разрешения имен для компьютеров в сети. Дополнительные сведения об использовании серверов пересылки и условной пересылки см. в разделе Общее представление о серверах пересылки.

Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы или наличие эквивалентных прав. Подробные сведения об использовании соответствующих учетных записей и членства в группах см. на странице https://go.microsoft.com/fwlink/?LinkId=83477 .

Настройка DNS-сервера для использования пересылки

Откройте диспетчер DNS.

В дереве консоли щелкните необходимый DNS-сервер.

DNS/необходимый DNS-сервер

В меню Действие выберите команду Свойства.

На вкладке Серверы пересылки в разделе Домен DNS щелкните имя домена.

В поле Список IP-адресов серверов пересылки для выбранного домена введите IP-адрес сервера пересылки, а затем нажмите кнопку Добавить.

Дополнительные сведения

• Чтобы открыть диспетчер DNS, нажмите кнопку Пуск, выберите Администрирование, затем щелкнете DNS.

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

Откройте окно командной строки.

Введите указанную ниже команду и нажмите клавишу ВВОД.

Имя средства командной строки, предназначенного для управления DNS-серверами.

Обязательный компонент. DNS-имя узла, на котором содержится DNS-сервер. Также можно ввести IP-адрес DNS-сервера. Чтобы указать DNS-сервер на локальном компьютере, можно ввести точку (.).

Обязательный компонент. Настройка сервера пересылки.

Обязательный компонент. Разделенный пробелами список, состоящий из одного или нескольких IP-адресов DNS-серверов, на которые пересылаются запросы. Можно указать список IP-адресов, разделенных запятыми.

Параметр времени ожидания. Параметр времени ожидания — это количество секунд перед истечением срока действия пересланных запросов.

Указывает значение для параметра /TimeOut. Значение указывается в секундах. По умолчанию это время составляет 5 секунд.

Определяет, использует ли DNS-сервер рекурсию при запросе имени домена, указанного в параметре имя_зоны.

Чтобы просмотреть полный синтаксис этой команды, введите следующий текст в командной строке, а затем нажмите клавишу ВВОД:

Дополнительная информация

• Чтобы открыть окно командной строки с более высоким уровнем прав, нажмите кнопку Пуск, выберите Все программы, Стандартные, щелкните правой кнопкой мыши пункт Командная строка, а затем выберите пункт Выполнить от имени администратора.

Команда /ZoneAdd служит для добавления зоны, указанной в параметре имя_зоны. Параметр IP-адрес — это IP-адрес, на который DNS-сервер будет пересылать неразрешенные DNS-запросы. С помощью параметра /Slave DNS-сервер обозначается как подчиненный сервер. При указанном параметре /NoSlave (параметр по умолчанию) DNS-сервер не является подчиненным сервером, а это означает, что он может выполнять рекурсию. Параметры /Timeout и Время были рассмотрены в предыдущей таблице.

С помощью параметра /Local можно задать локальный список главных серверов для серверов пересылки, интегрированных в Active Directory. Параметр IP-адреса_серверов является списком, состоящим из одного или нескольких IP-адресов главных серверов для зоны. Главными серверами могут быть DNS-серверы, содержащие основные или дополнительные копии зоны, однако в главные серверы не могут быть записаны IP-адреса DNS-серверов таким образом, чтобы два DNS-сервера, содержащие копии зоны, использовали друг друга в качестве главных серверов. Такая настройка приведет к созданию циклической пересылки.

Условная переадресация DNS-запросов на MikroTik

MikroTik

Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.

Вводная информация DNS forwarding

Если используете маршрутизатор MikroTik с настроенным VPN между офисами, вероятно приходилось сталкиваться с проблемой переадресации DNS-запросов на внутренний сервер имён. Существует DNS-сервер, который автоматически разрешает имена сайтов на другом конце туннеля. Однако, если вы запрашиваете DNS-запись для внутреннего домена, например, company.ru, на другом конце, маршрутизатор MikroTik попытается преобразовать запрос через собственный DNS-сервер, который, очевидно, не имеет необходимой информации. Разберемся с проблемой DNS forwarding более детально.

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

Как ни странно, у Микротика нет простого решения для условной пересылки DNS или пересылки DNS-запросов для определенного домена на конкретный сервер, однако мы сможем решить данную задачу с помощью командной строки.

Буду считать, что читатель знаком с командной строкой Mikrotik и нет необходимости расписывать используемый функционал, – это выходит за рамки этой публикации. В решении мы будем работать на 7 уровне сетевой модели OSI или прикладном уровне.

Прежде чем начать, вам понадобится следующая информация:

• Внутренний IP адрес вашего маршрутизатора MikroTik (172.16.100.1 в моем случае)
• IP адрес внутреннего DNS сервера (10.100.100.2 в моем случае)
• Имя внутреннего домена (mycompany.ru в моем случае)
• Доступ к маршрутизатору Микротик по протоколу ssh

Приступим к решению

1. Откройте текстовый редактор, например, notepad и вставьте следующие команды:

2. В списке команд выше необходимо изменить внутренний IP-адрес вашего маршрутизатора (зеленый цвет), имя внутреннего домена (оранжевый цвет) и адрес внутреннего DNS сервера (синий цвет) в соответствии с вашими настройками в текстовом редакторе.

3. Откройте ssh-сеанс на маршрутизаторе MikroTik и вставьте отредактированное содержимое текстового редактора в командную строку.

4. Перезагрузите маршрутизатор, чтобы изменения вступили в силу

Поиск неисправностей

Нам необходимо проверить, сможем ли попасть на сайты интрасети с другой стороны VPN. Если вы не можете, убедитесь, что туннель vpn запущен и работает, и что сайты действительно доступны через их внутренние IP-адреса, например, проверка по ping-протоколу нашего DNS-сервера 10.100.100.2. Следующим шагом является устранение проблемы с разрешением DNS при помощи таких команд, как nslookup. Сначала убедитесь, что DNS-сервер с другой стороны туннеля отвечает на запросы NS, выдавая команду:

где 10.100.100.2 DNS-сервер Интранета.

После приглашения > введите имя одного из ваших сайтов интрасети, и сервер имен должен сообщить его IP-адрес:

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

где 172.16.100.1 — внутренний IP-адрес нашего маршрутизатора MikroTik.

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

MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс « Настройка оборудования MikroTik ». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.