MikroTik Split or Forwarding DNS
Форвард зоны на другой сервер, ждали, ждали и дождались
В логах беты версии 6.47 увидел что есть изменения в работе DNS сервера на MikroTik.
Ну что-же интересно, необходимо проверить, работу и посмотреть что к чему.
Решил не использовать GNS, а взял с полки специально для тестов HAP ac2 и естественно обновил на последнюю beta версию.
IP адрес маршрутизатора с бета версией 172.20.17.100
Естественно по наитию пошли смотреть в /ip dns static
И видим нововведения, ну что же надо разобраться и проверить.
Не только A но и другие типы записей.
Раньше нем было доступно только A и AAAA записи для IPv4 и соответственно IPv6, как видим сейчас стало значительно больше.
Ну что-же давайте проверим все эти записи.
CNAME
Тип ссылки, когда мы говорим, что для данной записи ищи значение в другой записи.
Записи MX необходимы для корректной работы, а точнее поиска сервера для получения почты по протоколу SMTP.
Создадим две записи для вымышленного домена, с разными весами.
Когда вам надо сообщить, что за конкретное доменное имя отвечает другой сервер, вы должны использовать запись типа NS.
Вы можете сохранять произвольное значение, частно используется для того чтобы проходить валидация SPF для перечисления записей разрешённых хостов для отправки почты. Также при использовании DKIM подписи.
И ещё мы написали программку knockme которая также может использовать TXT для получения параметров knock-a.
Многие сервисы могут использовать для автоматического получения списка серверов например SIP, XMPP, LDAP и прочее.
Ну что же вроде всё работает.
И самая долгожданная штука это так называемый SPLIT DNS.
MikroTik Split DNS
Для начало, для чего он нужен.
Данный режим ещё называется forward zone
Представим себе ваш MikroTik выступает в роли маршрутизатора удалённого филиала. На нём поднимается VPN до центрального филиала прописываются маршруты и прочее. У вас доменная авторизация все компьютеры в домене, естественно хорошей практикой на компьютерах прописать DNS сервера который обслуживают Active Directory службы. Но в таком случае если туннель по какой-то причине упадёт ваш филиал останется без интернета, а ведь интернета может не быть в центральном филиале. Да перестанут работать различные шары и прочее, конечно для этих целей существует как минимум RODC, но навсегда есть возможность установить подобный сервис в филиале ввиду множества различных проблем.
Представим что наш dns suffix равен mycom.loc
Соответственно, а что если мы на компьютерах припишем DNS сервер адрес MikroTik, а на MikroTik укажем, что если запрос содержит mycom.loc то перенаправлять такие запросы на сервера DNS AD, а все остальные запросы перенаправлять допустим на 8.8.8.8.
Установим на MikroTik сервер DNS 8.8.8.8
и настроим forwarding зоны
Обратите внимания что мы используем регулярное вырожение.
Давайте проверим. Я решил взять реальный прод, поэтому DNS суффикс скрыл, не переживайте всё по подобию.
И так в скриншотах, с замазанным суффиксом.
Настоятельно рекомендую пока данный функционал не использовать в проде, так как это всё ещё бета версия.
Split DNS
Contents
Overview
Installations of Zimbra behind a firewall (or NAT Router) often require the creation of some form of split DNS, also called split-horizon or dual-horizon DNS. This is a DNS installation where machines receive different IP address answers to queries depending on whether they are (commonly) inside or outside a firewall and an IP address reply from the DNS server gives a Private Network IP address that is different than the Public IP of your internet connection. For further information on Private Network IP addresses see the following article: http://en.wikipedia.org/wiki/Private_network
This is because the Postfix mail system used by Zimbra performs a DNS MX lookup for the Zimbra server followed by a DNS A lookup when attempting to route email to the back-end message store. Frequently, this is the same physical host as Postfix. The DNS server frequently returns the external address of the mail host, not the internal address. Depending on how the firewall and network are configured, the external address may not even be reachable from the mail host, and mail will not be delivered.
Split DNS avoids this problem by providing an internal DNS server (this example uses bind or dnsmasq) that can be used to resolve the internal address of the server. This guide will detail how to set up a very specific, single-host DNS server (i.e. bind or dnsmasq) that can be installed on the Zimbra host itself so that it can resolve its own address. This should not be used for a multi-node Zimbra installation, and should not be used as the DNS server for any other hosts on your network.
It is possible to use a generalized split-horizon DNS server to perform this function, but it will need to be set up differently, and many people recommend against it because even a couple ms of delay can be too much on a heavily loaded system. If you decide to use another DNS server on your LAN then any functioning DNS server that provides a LAN IP response for the DNS MX lookup of the Zimbra server will do (BIND, Active Directory, PowerDNS etc.), check the ‘Verify. ‘ section in this article for details on how to check that your DNS server is configured correctly.
Attention! the use of Bind or dnsmasq are mutually exclusive, you have to setup one OR the other!
Configuring Bind on the Zimbra Server
Install Bind on Red Hat Enterprise Linux
Use up2date to download bind from Red Hat Network.
Install bind9 on Ubuntu/Kubuntu Hardy Heron
You could also make sure it is installed from Synpatic Package Manager or Adept.
Edit the named.conf file
/etc/named/chroot/etc/named.conf and you should create a symbolic link to /etc/named.conf,
Make sure to set the forwarders to match the DNS servers currently in use on your system. The forwarders setting allows the server to query those DNS servers for any addresses for which it is not authoritative.
Create a /var/named/db.server.example.com zone file
Change /etc/resolv.conf
Start named on the zimbra server
Enable autostart of named on boot
Configuring dnsmasq on the Zimbra Server
dnsmasq is a very powerful tool that can provide basic dns services/caching, act as dhcp server and also as tftp server. It’s also easy to setup. So you can use dnsmasq INSTEAD of bind following these instructions.
Install dnsmasq on Debian GNU/Linux
Edit the /etc/dnsmasq.conf file
Let’s say that upstream dns are 8.8.8.8 and 208.67.222.222. Put only these lines in the config file:
Edit the /etc/hosts file
The loopback line should look like this:
You need a line to resolve the IP of mail.yourdomain.com to the private IP of the zimbra server, so make sure you have:
Edit the /etc/resolv.conf file
To have the host resolv through dnsmasq, you have to set your localhost (127.0.0.1) as nameserver
Restart dnsmasq
To have the settings take effect, you have to restart dnsmasq
Verify that everything is working
To verify that your configuration of DNS is correct you should run the following commands on the Zimbra server itself (the expected output is in the boxes below the commands).: This is true whatever DNS program you use for this kind of configuration (i.e. dnsmasq instead of bind9).
dig yourdomain.com mx
dig yourdomain.com any
You should also make sure that the DNS server that is responding to your dig commands is the one you have configured on your LAN and it’s the one that has your Zimbra server DNS records. If you see any IP that is not the correct LAN IP or the correct DNS server then you have entered the wrong information in your DNS configuration files.
If you’re asked in the forums to provide the information to confirm your DNS is correct then, in addition to the above information, you should also supply the output of the following commands (run on your Zimbra server):
In this article it’s assumed that you’re installing the DNS server on your Zimbra server so your resolv.conf should look like this:
Although it’s mentioned in other articles it bears repeating that your hosts file should look like this:
The line for the loopback adapter (127.0.0.1) should be formatted as shown. The hosts file should also be formatted as shown and have the LAN IP of your Zimbra server (as shown in the DNS records) and contain the hostname (mail) and your domain name (yourdomain.com) which gives you the Fully Qualified Domain Name (FQDN) of your server ‘mail.yourdomain.com’.
If you have a number of servers inside the firewall that need to use internal addresses to communicate to each other, you should consider setting up a full internal DNS server that can be authoritative for the whole domain. This example is not suitable for this task.
Устраняем проблемы DNS
Работа с DNS — важнейшая часть планирования Active Directory (AD). Прежде чем организовать домен AD, необходимо установить DNS. Служба AD и создающая для нее основу служба DNS требуют более тщательного планирования, чем любой другой инструмент Microsoft. Действовать по принципу «сначала щелкни, а там видно будет» — верный способ навлечь на себя неприятности. Однако из-за ряда особенностей AD настроить DNS для работы с AD нелегко даже опытным администраторам, хорошо знакомым с DNS. В данной статье рассматриваются принципиальные условия, которые необходимо соблюдать при настройке DNS для работы с AD, а также полезные новые функции DNS, реализованные в Windows Server 2003.
Прежде чем создавать домен AD, требуется установить один или несколько DNS-серверов для размещения DNS-зоны с тем же именем. Следует обратить внимание на термины «домен» и «зона». Термин «домен» может иметь два значения. Можно говорить о DNS-домене с именем bigfirm.biz в смысле, не имеющем ничего общего с AD и любыми программами Microsoft. Но можно говорить об AD-домене с именем bigfirm.biz — такой домен не имеет большого отношения к DNS, зато тесно связан с безопасностью в программных системах Microsoft. Чтобы не путать DNS-домены с AD-доменами, я буду называть DNS-домен «зоной».
Предположим, что на DNS-сервере компании Bigfirm размещена зона bigfirm.biz. В зону входят Web-сервер и несколько почтовых серверов, и необходимо, чтобы заказчики могли иметь доступ к этим серверам. Но администраторы Bigfirm не хотят использовать данный DNS-сервер и размещенную на внешних машинах зону bigfirm.biz для реализации AD, так как в AD хранится конфиденциальная информация, которую опасно публиковать в Internet. Поэтому, как и большинство проектировщиков AD, администраторы Bigfirm формируют группу DNS-серверов, невидимых из общедоступной сети Internet, на которых размещается зона bigfirm.biz, отделенная от общедоступной зоны bigfirm.biz. Такой подход называется разделением (split-brain или split-horizon) DNS.
Основные сведения о разделенных зонах DNS
Организовать разделенную DNS довольно просто, и я рассказывал об этом в других статьях. Напомню коротко, что для организации разделенной DNS сначала нужно установить серверную службу DNS на нескольких серверах. Затем компании Bigfirm следует настроить конфигурацию каждой системы во внутренней сети (то есть сети, в которой необходимо отыскивать контроллеры домена AD), чтобы они могли получать информацию DNS от одного или нескольких внутренних серверов. Клиенты DNS внутри корпоративной сети никогда не должны запрашивать DNS-серверы в общедоступной Internet; в противном случае они никогда не смогут обнаружить контроллеров домена (DC). То же справедливо и для внутренних DNS-серверов: их следует настроить на преобразование имен только с использованием внутренних DNS-серверов. Хотя внутренние DNS-серверы обращаются друг к другу для преобразования имен, они могут преобразовывать имена Internet.
Bigfirm может назначить один из внутренних DNS-серверов первичным DNS-сервером для внутренней зоны bigfirm.biz и разрешить динамическое обновление этой зоны. Затем можно настроить все остальные DNS-серверы сети для работы в качестве вторичных DNS-серверов зоны bigfirm.biz; каждый из них получает экземпляры зоны bigfirm.biz с первичного сервера bigfirm.biz. Такой простой подход позволяет разместить разделенную DNS для одного домена AD.
Добавление зон, интегрированных с AD
Приведенное описание — недостаточно полное для многих администраторов, так как оно не охватывает зоны, интегрированные с AD. Использование первичных и вторичных DNS-серверов для данной зоны — стандартный способ применения DNS-серверов. Впервые этот метод был использован в широко распространенной серверной программе BIND DNS; аналогичный способ применяется и во встроенных DNS-серверах Windows 2000 Server и Windows 2003. Эта модель предусматривает наличие в зоне одного первичного сервера DNS и неограниченного числа вторичных. Любые изменения в зоне должны производиться на первичном DNS-сервере, который затем копирует измененные параметры на вторичные серверы. В терминах Windows 2000 этот подход можно назвать моделью с одним мастером, так как принимать изменения может только один ответственный за зону DNS сервер.
Модель с одним мастером — слабое звено архитектуры с первичным и вторичными DNS-серверами. В Windows 2003, Windows XP и 2000 используется динамическая служба DNS (DDNS), поэтому каждая рабочая станция и сервер должны перерегистрировать свои имя и адрес в зоне DNS каждый день в процессе начальной загрузки (это упрощенное представление: на самом деле процедуру перерегистрации запускают пять различных событий). В модели первичный/вторичный только первичный DNS-сервер зоны может принимать изменения для этой зоны. Если компания располагает несколькими тысячами машин, то в течение считанных минут после начала рабочего дня на первичный DNS-сервер могут обрушиться тысячи запросов на DNS-регистрацию.
В зонах DNS, интегрированных с AD, может быть не один, а несколько первичных DNS-серверов — информация о DNS-зоне хранится не в файле на DNS-сервере, а становится частью базы данных AD. Windows 2000 тиражирует базу данных AD на все DC домена, и каждый DC видит и даже может изменить информацию в DNS.
Кроме того, интеграция зоны DNS с AD повышает безопасность сети, так как регистрацию DDNS могут выполнить только члены домена. В простой первичной зоне DNS, принимающей динамическую регистрацию, любая машина может регистрировать DNS-записи. Поэтому теоретически любая посторонняя машина может регистрировать записи, выдавая себя за DC. Сам факт появления системы, выдающей себя за DC, не приведет к нарушению информационной безопасности сети, но такое положение нельзя считать нормальным — за этим может скрываться попытка кражи паролей. Однако в зоне, интегрированной с AD, посторонней машине гораздо труднее присвоить чужую роль. Прежде чем принять регистрацию DNS, интегрированные с AD серверы DNS проверяют, является ли регистрируемая машина членом домена.
Островная DNS
Зоны, интегрированные с AD, и разделенная DNS могут породить конфликт, известный под названием «островная DNS» (island DNS). В случае с островной DNS два или несколько DC выполняют роль DNS-серверов домена, и на них, как обычно, размещается зона, интегрированная с AD. Но каждый DC располагает своей информацией. Каждый DC регистрирует идентификационную информацию о своем экземпляре зоны DNS, но никогда не реплицирует эту информацию на другие DC/DNS-серверы (то есть серверы, которые играют двойную роль DC и DNS-серверов). Поэтому каждый DC/DNS-сервер считает себя единственным на планете.
Островная DNS возникает только в корневом домене леса, только если используются зоны, интегрированные с AD, применяется разделенная DNS (каждый DNS-сервер настроен на разрешение запросов DNS лишь у себя) и только если в корневом домене имеется более одного DC/DNS-сервера. Насколько мне известно, возникновение островной DNS возможно в DNS-серверах на базе Windows 2003 и Windows 2000.
Чтобы избежать появления островной DNS, следует изменить конфигурацию DC/DNS-сервера. Во-первых, нужно назначить одну систему DC/DNS «ведущим» DNS-сервером зоны. Этот сервер не будет настоящим мастером. Регистрацию DNS по-прежнему станут выполнять несколько мастеров, но я пользуюсь этим термином для простоты изложения. Ведущий DNS-сервер должен по-прежнему указывать на себя (поле Preferred DNS server в окне TCP/IP Properties этой системы должно содержать только собственный IP-адрес данного сервера). Поле Alternate DNS server остается пустым. Затем нужно настроить другие DNS-серверы таким образом, чтобы они использовали IP-адрес мастера в качестве основного DNS-сервера, а какой-нибудь другой DNS-сервер — в качестве альтернативного. За исключением мастер-сервера, никогда не следует настраивать систему на обращение к самой себе как основной или альтернативной.
Предположим, у нас имеется три контроллера с именами DC1, DC2 и DC3. Все три DC являются DNS-серверами, расположены в корневом домене леса и хранят информацию о зоне DNS данного домена в интегрированной с AD зоне. Произвольно назначив DC1 ведущим, я настроил DC1 таким образом, чтобы в его поле Preferred DNS server содержался IP-адрес DC1, и оставил поле Alternate DNS server пустым. Я вставил IP-адрес DC1 в поле Preferred DNS server контроллера DC2, а в поле Alternate DNS server контроллера DC2 указал IP-адрес DC3. В поле Preferred DNS server контроллера DC3 я ввел IP-адрес DC1, а в поле Alternate DNS server контроллера DC3 — IP-адрес DC2.
Рассмотрим еще два DC (MYDC1 и MYDC2), связи между которыми организованы по тому же принципу. Если произвольно выбрать MYDC1 в качестве мастера, то в поле Preferred DNS server контроллера MYDC1 следует указать IP-адрес MYDC1 и оставить поле Alternate DNS server пустым. В контроллере MYDC2 требуется указать IP-адрес MYDC1 в поле Preferred DNS server. Но что делать с полем Alternate DNS server контроллера MYDC2? Это поле нужно оставить пустым.
Добавление доменов
Предположим, что в bigfirm.biz необходимо иметь два AD-домена — исходный домен bigfirm.biz и домен с именем bigfirm.com. Как в этом случае организовать разделенную DNS? Компании Bigfirm достаточно создать первичную зону с именем bigfirm.com на одном из внутренних DNS-серверов. Все остальные внутренние DNS-серверы компании следует сделать вторичными DNS-серверами зоны bigfirm.com. Таким образом, в распоряжении компании будет вся инфраструктура, необходимая для двухдоменного леса AD.
Если Bigfirm использует зоны, интегрированные с AD, то очевидный следующий шаг — интегрировать с AD как зону bigfirm.biz, так и bigfirm.com и установить DNS на некоторых DC. В результате DNS-серверы каждого домена должны видеть зоны друг друга. Однако данный метод не срабатывает из-за странной особенности зон, интегрированных с AD. Данные о зоне, интегрированной с AD, направляются только на контроллеры домена этой зоны — DC/DNS-серверам bigfirm.com будут видны только данные bigfirm.com. Это ограничение в Windows 2003 можно обойти, но в многодоменные леса на базе Windows 2000 придется внести некоторые изменения, чтобы обеспечить работу DNS, интегрированной с AD. Все DNS-серверы bigfirm.biz необходимо настроить в качестве вторичных DNS-серверов для bigfirm.com, а все DNS-серверы bigfirm.com — в качестве вторичных DNS-серверов для bigfirm.biz. Внутри доменов можно по-прежнему использовать зоны, интегрированные с AD, но в каждом домене должна содержаться вся необходимая информация для обнаружения контроллеров bigfirm.com, и наоборот.
При использовании DNS-серверов на базе Windows 2003 у администраторов Bigfirm будет более широкий выбор. Эти возможности мы рассмотрим в следующей статье.
Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com
Поделитесь материалом с коллегами и друзьями
Настройка Split DNS в BIND
Представьте себе следующую распространенную ситуацию. Есть сеть, положим 10.0.0.0/24, в ней — веб-сервер 10.0.0.100 и рабочая станция 10.0.0.200. Есть маршрутизатор с внешним адресом 203.0.113.1. Порты 80/443 проброшены внутрь на 10.0.0.100.
Чаще всего эту проблему решают с помощью так называемого hairpin NAT. Об этом я уже когда-то писал. Решение с hairpin — приемлемое, но не идеальное. Трафик с этом случае идет через маршрутизатор, даже если оба хоста находятся в одном сегменте канального уровня и могли бы общаться напрямую.
Популярность решения с hairpin объяснима. Многие сети вообще не имеют своих серверов DNS, в этом случае других решений и нет. Даже если свои сервера есть, правило для hairpin сетевой администратор может настроить без взаимодействия с администратором сервера DNS. Тем не менее правильное решение этой задачи — использовать split DNS, то есть выдавать разный ответ в зависимости от того, кто спрашивает.
Split DNS в BIND
Рассмотрим пример настройки. Для простоты тестирования в пределах одной машины мы используем адрес 127.0.0.10 в качестве условной «внутренней сети» — под localhost отведена вся сеть 127.0.0.0/8, а не только общеизвестный 127.0.0.1.
Важный момент: если вы используете split DNS, то все зоны нужно поместить в какое-то представление, даже если они используются только в одном представлении. Иначе демон откажется загружать настройки.
Split-Brain DNS
| Executive Summary: Split-brain DNS is a Domain Name System (DNS) configuration method that enables proper name resolution of local resources from both inside and outside of your local network. Use split-brain DNS when your edge router or firewall is configured to drop packets when it sees one of its connected networks trying to send information to itself. You configure a new primary DNS zone with the New Zone Wizard to set up split-brain DNS. |
The Domain Name System (DNS) is one of the most critical aspects of any IT environment. All Internet users, whether they know it or not, are dependent on DNS. If, like most Windows IT Pro readers, you’re running Active Directory (AD) in your environment, you know that your users are also heavily dependent on DNS to locate resources on your network, such as domain controllers (DCs). Without using DNS to locate a DC, your users wouldn’t even be able to log on!
Split-brain DNS is a configuration method that enables proper resolution of names (e.g., example.com) from both inside and outside of your local network. Although “split-brain DNS” sounds like something that would require an Ace bandage and a boatload of aspirin, it’s actually something that almost every organization uses. Despite how common it is, I still regularly hear from administrators who aren’t familiar with it for one reason or another, and who have problems that can be solved easily by setting up split-brain DNS. Let’s take a look at a situation where split-brain DNS is called for, then I’ll demonstrate how you can set up split-brain DNS in your organization.
A Splitting Headache
Imagine this frustrating scenario: You’re an administrator for a small organization, and you’ve just finished setting up a new web server. This new server is joined to your AD domain, mydomain.local, and you’ve securely published it to the Internet through your firewall. The machine name of this server is WEB01, making its Fully Qualified Domain Name (FQDN) web01.mydomain.local. You’ve assigned it a static IP address of 192.168.123.10.
Your ISP hosts your external DNS records, so you select an unused public IP address from the pool they’ve assigned to you, then ask the ISP to configure an A record for www.mydomain.com that resolves to your chosen public IP address. Later, sitting at your office desk, you type www.mydomain.com into the address bar of your browser, but your site doesn’t load. You confirm with your ISP that they’ve set up the A record correctly. You then call your neighbor, who’s home on vacation, and have her try to load your site. It works perfectly for her. What gives?
“So?” you might be saying to yourself. “That should work: My computer should then connect to that IP address, and everything should be lovely!” But it isn’t. The problem is that your edge router or firewall is configured such that when it sees one of its connected networks trying to send information to itself, it drops the packets and you’re dead in the water because your site doesn’t load.
The solution is clear: You need to make your internal DNS servers answer queries for www.mydomain.com with the static IP address 192.168.123.10.
Split-brain DNS ensures that when users at the office on the local network type in www.mydomain.com, the DNS record returned contains the internal private IP address of the website you’ve set up, but when users away from the office’s local network try to access www.mydomain.com, the DNS record returned contains the external public IP address of the website. Figure 1 shows a highlevel overview of the query paths after this setup is complete.
Double-Duty DNS
Contrary to what you might believe, your AD DNS servers are capable of hosting DNS zones that aren’t also AD domains. In fact, these zones can be AD-integrated without being AD domains!
For this example, though, we’ll configure a new primary DNS zone on a Windows Server 2003 Standard Edition AD DNS server. Start by opening the Microsoft Management Console (MMC) DNS Management snap-in and expanding the server node. Right-click Forward Lookup Zones, then click New Zone to launch the New Zone Wizard. Click Next on the Welcome page to proceed to the second page of the wizard. As Figure 2 shows, you’ll see choices for creating a Primary zone, Secondary zone, or Stub zone, as well as a checkbox, selected by default, that lets you store your new zone in AD. Select Primary zone and clear the checkbox for storing the zone in AD; for this example, we want to store our zone in a flat file.
On the wizard’s next page, enter the zone name mydomain.com. When you click Next, you’ll be given the option to change the filename that the DNS server uses to store the zone records; for this example you can use the default that the wizard suggests. Figure 3 shows the wizard’s Dynamic Update page, where you’ll have two options: to let the zone accept both nonsecure and secure dynamic updates or to not allow the zone to accept any dynamic updates. We aren’t setting up any records that should be updated dynamically, so select Do not allow dynamic updates. The last page of the wizard presents a summary of what will occur after you click Finish.
Continue on Page 2
You can now test your split-brain configuration from your workstation. But before you do, make sure to flush your DNS cache by entering the following from a command prompt: ipconfig /flushdns Type www.mydomain.com into your browser, and your site should load. Neat, isn’t it?
You can add additional hosts to your newly created zone for any other resources, such as a mail server or a terminal server, that you want to access by the same name both internally and externally.
An alternative to split-brain DNS would be to use a third-party solution at the edge of your network that can rewrite the IP addresses returned in packets containing DNS data. For example, Cisco’s PIX and ASA appliances have a feature called DNS Doctoring that performs such rewrites. All of these methods are fairly easy to execute, but you should still try them in a test environment before making changes to your production environment. Happy querying!