Mikrotik split-dns: они это сделали

    Не прошло и 10 лет, как разработчики RoS (в stable 6.47) добавили функционал, который позволяет перенаправить DNS запросы в соответствии со специальными правилами. Если раньше надо было изворачиваться с Layer-7 правилами в firewall, то теперь это делается просто и изящно:

    /ip dns static
    add forward-to=192.168.88.3 regexp=".*\\.test1\\.localdomain" type=FWD
    add forward-to=192.168.88.56 regexp=".*\\.test2\\.localdomain" type=FWD
    

    Моему счастью нет предела!

    Чем это нам грозит?


    Как минимум, мы избавляемся от странных конструкций с NAT наподобие этой:
    
    /ip firewall layer7-protocol
    add comment="DNS Nat contoso.com" name=contoso.com regexp="\\x07contoso\\x03com"
    /ip firewall mangle
    add action=mark-packet chain=prerouting comment="mark dns contoso.com" dst-address-type=local dst-port=53 in-interface-list=DNSMASQ layer7-protocol=contoso.com new-packet-mark=dns-contoso.com passthrough=yes protocol=udp
    add action=mark-packet chain=prerouting comment="mark dns contoso.com" dst-address-type=local dst-port=53 in-interface-list=DNSMASQ layer7-protocol=contoso.com new-packet-mark=dns-contoso.com passthrough=yes protocol=tcp
    /ip firewall nat
    add action=dst-nat chain=dstnat comment="DST-NAT dns contoso.com" dst-port=53 in-interface-list=DNSMASQ packet-mark=dns-contoso.com protocol=udp to-addresses=192.0.2.15
    add action=dst-nat chain=dstnat comment="DST-NAT dns contoso.com" dst-port=53 in-interface-list=DNSMASQ packet-mark=dns-contoso.com protocol=tcp to-addresses=192.0.2.15
    add action=masquerade chain=srcnat comment="mask dns contoso.com" dst-port=53 packet-mark=dns-contoso.com protocol=udp
    add action=masquerade chain=srcnat comment="mask dns contoso.com" dst-port=53 packet-mark=dns-contoso.com protocol=tcp
    


    И это не все, теперь можно прописать несколько серверов пересылки, что поможет сделать dns failover.
    Интелектуальная обработка DNS даст возможность начать внедрение ipv6 в сеть компании. До этого я этого не делал, причина в том, что мне нужно было разрешать ряд dns имен в локальные адреса, а в ipv6 это было не сделать без довольно больших костылей.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 58

      +2
      А расскажите подробней — для чего это надо?
        +2
        Да все просто.
        Допустим, у вас есть домен, причем он имеет глобальное имя, к примеру в зоне .ru
        И вот вам нужно, что-бы некоторые ресурсы были доступны как из интернета так и во внутренней сети за NAT. Реализуется это тем, что-бы внутри NAT отвечать на DNS запрос IP адресом из серой сети, а не публичны. Или надо выносить все подобные сервера в DMZ.
          0
          Это зонами делается в BIND
            0
            Это совсем грустный вариант для нано филиальчиков. Куда водружать BIND, если в филиале кроме двух ПК и mikrotik ничего нет?
            Заруливать DNS в туннель до головного офиса — совсем не лучшая затея.
              0
              Это был грустный вариант раньше, а теперь ставишь малину и на нее — все, что душе угодно: прокси, тор, днс, впн-сервер, веб-сервер, баннерорезку и т.п.
                +8
                Зачем тогда Mikrotik? Это создает дополнительные точки отказа и усложняет поддержку.
                  0
                  Я в целом положительно отношусь к микротикам, просто хотел отметить, что это не единственное решение описанной проблемы, можно было и раньше, и при сравнимом бюджете. И вообще хорошо, когда вариантов больше одного.

                  А вообще, когда у вас есть внутренние ресурсы в филиале, но нет ни одного сервера — тут что-то не сходится, вспоминаю про трусы и крестик. Разве что камера какая-нибудь или принтер, но это на большинстве роутеров прикручивается через LAN DNS функцию, даже с динамическим внутренним IP.
                    +3
                    У меня в практике вполне типичная ситуация: точка продаж.
                    На точке есть пара ПК и принтер, иногда камера. Mikrotik обеспечивает туннель до общей сети. И тут как раз split dns мне сильно помогает, если падает туннель, то пропадают внутренние ресурсы, но остаётся интернет. И если туда приезжает менеджер с ноутом, то ему не надо ничего специально настраивать, все работает как из головного офиса или дома.
                0
                Прокси, впн? И получаешь скорость в пол байта в секунду?
                  0
                  А вам сколько надо? Если гигабит/с — то узнайте сначала сколько такой канал стоит для юрлиц.
                    0
                    10-100 мбит/с в регионах могут быть не так уж и дороги.
                    На прошлой работе вообще, насколько помню, услугу создания сети между точками продаж и головной фирмой провайдер предлагал на неплохих скоростях.
                      0
                      Pine A64 (Cortex-A53) легко справляется с 300 мбит каналом как некэширующий прокси-сервер, RPi4(Cortex-A72) еще быстрее. Для каналов быстрее 500 мбит/с я бы уже задумался о чем-нибудь более серьезном, но это не точка продаж ни разу, там такие скорости не нужны.
                0
                Заруливать DNS в туннель до головного офиса — совсем не лучшая затея.


                А вы считаете, что нагружать софтроутер разборами ДНС запросов затея получше? Кроме того, если у меня 500 таких филиалов, то каждый филиал- это отдельная точка для настройки?
                  0
                  А как вы настраиваете такие филиалы? Прямо из коробки в бой?
                    0
                    Я про эксплуатацию. Вот поступила вам команда зарезать хабр на все 500 филиалов. Вы предлагаете зайти на каждый и править фильтр вместо централизованного управления?
                      –1
                      Тут уже можно делать по разному, но я в компании смог объяснить, что технические запреты ресурсов (типа сайтов), ничего не решат, поэтому такой команды мне не дадут.
                      Если надо массового настроить 500 роутеров, то тут прямая дорога к изучению ros api, что поможет делать не только это.
              0
              ааа… я это делал путём дополнительного правила в NAT
                0
                Ага, Layer-7, mangle, NAT. И скажи нет dns failover для таких доменов, проблема с большими пакетами и т.п.
                  0
                  Да у меня там один сайтик был :) Так что не сильно парился.
                +1
                Если я не ошибаюсь, то ситуация с сервером за NAT'ом и пробросом портов решается NAT-loopbak правилом без всяких layer 7 и DNS вообще. Например, для внктренней сети 192.168.0.0/24 вот так:
                chain=srcnat action=masquerade protocol=tcp src-address=192.168.0.0/24 dst-address=192.168.0.0/24 out-interface=<Your_LAN_bridge> dst-port=0-65535
                  0
                  Это близкий случай, но не тот.
                    0
                    Странно. У меня вроде работает. Расскажите, пожалуйста, когда это не работает для сервера за NAT'ом. Я бы тоже у себя пофиксил.
                      +3
                      Первое, чем мне не нравится hairpin nat это то, что мы нагружаем роутер лишним трафиком.
                      Плюсы split-dns в том, что можно держать в глобальной доступности всего пару сервисов, а остальные в привате. И тут для пользователя самое удобное, он не встречает никаких различий между подключением к сервисам внутренним и внешним, для него это выглядит прозрачно и в голове он держит только один домен. В случае без split dns, очень часто имеется ситуация с существованием как глобального домена так и локального.
                +1
                Например, можно сделать так, чтобы запросы на внутренние ресурсы локальной сети/интранет сети не уходили в «дикий интернет».
                У некоторых провайдеров довольно паршиво настроенные сервера DNS, можно отправить все запросы на широко известные публичные сервера, а запросы на ресурсы провайдера — на его сервер/сервера.
                Некоторые носят компактные модели MikroTik с собой и подключают в разных местах (заранее известных) можно учесть специфику сразу всех этих сетей, до этого в особо специфичных случаях приходилось что-нибудь перенастраивать
                  0
                  Например есть у вас в облаке домен ourcloud.internal и VPN туда из офиса, и надо что бы из офиса резолвились server1.ourcloud.internal, redis23.ourcloud.internal и т.п. Направляете запросы *.ourcloud.internal на облачный ресолвер, а остальные как обычно.
                    0
                    А расскажите подробней — для чего это надо?

                    Вот мой случай: два провайдера, у каждого есть внутренние сервисы (сайт, личный кабинет), не доступные из интернета. Один из провайдеров часто меняет IP этих сервисов. Таким образом, мне необходимы ДНС обоих провайдеров, причем имена сайтов должны резолвиться именно своим ДНС-сервером. Я вот до этой статьи и не обратил внимания на изменения, в основном потому что на long term сидел. Перешел на stable.
                    0
                    С какой версии RouterOS?
                      +1
                      С текущей стабильной, хотя эту функцию можно было попробовать и в testing.
                        +2
                        С текущей стабильной, хотя эту функцию можно было попробовать и в testing.
                        Вы сознательно заставляете того, кто наткнётся на эту статью (а это именно статья, а не заметка в блоге, хотя и выглядит так) через какое-то время, выяснять, а какая же версия RouterOS была текущей стабильной в июне 2020-го?
                          +1
                          Нет, просто вы не прочитали эту информацию в заметке.
                            +1
                            Похоже на то.
                            Прошу прощения!
                      0
                      Если б у них ещё regexp отрабатывался после обычной статики, а не до, было б совсем хорошо
                        0
                        А с настроенным DoH работает?
                          0
                          Сам не использовал, ответить не могу.
                            0
                            Да
                            !) dns — added client side support for DNS over HTTPS (DoH) (RFC8484);
                              0

                              Что-то у меня с настроенным DoH пересылка запросов не пошла. А то что вы привели в качестве пруфа, говорит о том, что DoH в принципе теперь поддерживается.

                                0
                                My bad
                                  0
                                  в документации указано:
                                  Currently DoH is not compatible with FWD type static entries, in order to utilize FWD entries, DoH must not be configured.
                              +2
                              Извините, но Twitter в соседней вкладке.
                              Могли бы и поподробнее расписать: суть изменения, примеры использования, сравнение с предыдущими версиями и т.д.
                                +3
                                Это тот самый случай, когда имеет смысл читать комментарии :)
                                  +1
                                  Этот тот случай, когда большая и подробная статья лежит и тухнет, а невнятный хайп — нет.
                                  Я сам не люблю такие статьи, однако и сам создал такую. Зато я сразу вижу интерес сообщества, за что спасибо. Торжественно обещаю, мельчить больше не буду.
                                0
                                Кроме того, приехал Split DNS для IPsec
                                *) ike2 — added support for RFC8598;
                                  +1

                                  Маленький вопрос по переопределению определённых имён в рамках перенаправляемых доменов.
                                  Допустим, у нас есть домен "*.test1.localdomain", который мы перенаправляем на forward-to=192.168.88.3. Но есть одно имя из этого домена exception.test1.localdomain, IP-адрес которого необходимо переопределить на 127.0.0.1, к примеру, используя static dns на MikroTik'е.


                                  Вопрос 1. Какая очерёдность резолвинга? Перебьёт ли static этот forward-to? В случае с layer7 не перебивало, т.к. запрос на 53-й порт (подходящий под условия) форвардился на другой DNS и до DNS-сервера MikroTik'а запрос не долетал.
                                  Вопрос 2. Кто хорошо умеет в регекспы, подскажите, как можно добавить исключение в regexp=".*\.test1\.localdomain", чтобы под этот regexp попадал весь домен включая поддомены, за исключением имени exception.test1.localdomain?

                                    0
                                    Попытался поэкспериментировать, но у меня не вышло сделать подобное, увы.

                                    1. По моим ощущениям, сначала разрешаются правила с регулярками, а затем – чисто статические. Документация, кстати, говорит, что это так:
                                    The server is capable of resolving DNS requests based on POSIX basic regular expressions so that multiple requests can be matched with the same entry. In case an entry does not conform with DNS naming standards, it is considered a regular expression and marked with an ‘R’ flag. The list is ordered and is checked from top to bottom. Regular expressions are checked first, then the plain records.

                                    2. Я попытался вывести из-под правила домен test.example.com. В цитате выше упомянуто, что используются POSIX basic regular expressions, то есть никаких negative lookahead не получится, (?!test).*\.example.com не сработал. Попытался запустить ([^t]+|t[^e]+|te[^s]+|tes[^t]+)\.example.com по образу и подобию этого ответа со stackoverflow, но результат оказался прямо противоположный: только test.example.com стал попадать под правило. Хотя на сайтах типа regexr.com поведение совпадает с ожидаемым мной. :/
                                      0
                                      Как оказалось, ещё вчера 6.47 вышла в stable, поэтому я обновил один из домашних роутеров и проверил.
                                      Опытным путём выяснилось, что статичная запись типа A имеет приоритет над записью типа FWD. При чём даже не влияет где эта запись находится выше FWD, или ниже.
                                      Так что вопрос с исключающимися регулярками с повестки снят. Если нужно исключить какие-то хосты из форвардинга – добавляем их статиком и всё нормально работает.
                                        0
                                        А, понятно. У меня просто надо всем, кроме одного домена, назначить A-запись. Наверное, я использую не тот инструмент, но он работает. :)

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

                                          мне кажется проще всего в две записи:


                                          ^exception\.test1\.localdomain$ - Type A (не перенаправлять)
                                          .*\.test1\.localdomain$ - Type FWD (перенаправлять)

                                          первая отработает — вторая уже не будет.
                                          под первую не попадёт — отфорвардит

                                        0
                                        Не уложился в 30-минутный лимит редактирования коммента. :/

                                        UPD: Документация немного устарела, похоже. По крайней мере, работают не только POSIX BRE, но и ERE. Хотя я сначала так и думал. :D

                                        И проблема с регекспами решилась достаточно просто: надо было добавить ^ в начало. Почему-то регулярка срабатывает, даже если часть домена попадает под неё. Мне сложно придумать подобную ситуацию без натягивания совы, но лучше иметь гибкость, чем не иметь её, когда она нужна.

                                        В абстрактном случае работает ^([^t]+|t[^e]+|te[^s]+|tes[^t]+|test.+)\.example\.com$,
                                        а в вашем – что-то вроде ^([^e]+|e[^x]+|ex[^c]+|exc[^e]+|exce[^p]+|excep[^t]+|except[^i]+|excepti[^o]+|exceptio[^n]+|exception.+)\.test1\.localdomain$, хотя это и нечитаемо.
                                      0
                                      Подскажите пожалуйста, я ранее пользовался связкой Layer7+mangle(mark connections)+NAT
                                      У меня все работало (условная пересылка DNS запросов).
                                      Попробовал реализовать через DNS static — не получается

                                      Домен: home.local
                                      Прописываю следующее
                                      /ip dns static
                                      add forward-to=192.168.2.2 regexp=".*\\.home\\.local" type=FWD

                                      но DNS сервер микротика не разрешает данный префикс FQDN серверов
                                      Что я делаю не так, подскажите пожалуйста.
                                        0
                                        А ваши клиенты точно спрашивают dns у роутера? Есть вероятность работы кэша на клиентах, какой dns суффикс вы отдали\установили у клиента?
                                          0
                                          решил таким образом, как был реализован regexp в layer7

                                          /ip dns static
                                          add forward-to=192.168.2.2 regexp="(home.local)" type=FWD
                                          0
                                          в контексте split-dns у меня родился юзкейс — организовать прозрачный доступ из локальной сети к .onion. Tor ноду держим на raspberry pi к примеру рядом в локальной сети.

                                          но возникает вопрос реализации, web-proxy в данном случае все равно нужен на микроте?
                                          я пробовал реализовать по сценарию web-proxy (Mikrotik) — 3proxy (raspberry pi) — tor-socks5 (raspberry pi) — но выглядит это как большой костыль.
                                          наводку брал тут

                                          возможно можно как-то проще?
                                            0
                                            теперь можно прописать несколько серверов пересылки

                                            Не работает фэйловер.
                                            1. Прописать можно в gui хоть как (через пробел, запятую и т.д) но в терминале
                                            ip dns static export 
                                            будет только первая запись.

                                            2. В терминале можно прописать через запятую слитно
                                            /ip dns static> add forward-to=10.110.10.100,10.110.0.118 regexp=".*\\win\\.some\\.ru" type=FWD
                                            но оно не будет работать. И в кэше будет эта слитная запись с запятой

                                            3. Если дублировать правило FWD и указать для форвардинга резервный dns, то все равно не сработает при падении основного, т.к. тупо обрабатываются вхождения по списку.

                                            Так что, пока фича сыровата для боевого применения. Буду дальше пользовать для dns форвардинга NAT с балансировкой через PCC, пока не допилят до ума
                                              0
                                              Вот с обновлением 6.47.1 проверил, если есть две записи форварда, то работает failover, хотя это поведение в relase notes не отражено.
                                                0
                                                А как проверял?
                                                Я на этой же прошивке делал. Обрабатывается первая запись по списку. Никакой проверки жив ли хост и жив ли на нем днс.
                                                  0

                                                  Блокировал в фаерволе филиалов dns запросы с тестового роутера.
                                                  Но вот засада, на днях реально отключал я dns который был основным и failover работал как-то рандомно. Первые 5-10 запросов отрабатывал (с большой задержкой), а потом переставал. Что-то разрабы в Mikrotik сделали не то…
                                                  Кто-то интересно тикет уже им писал?

                                                    0

                                                    Тикет на что? Оно же форвадит как заявлено. Просто без фэйловера, который и не заявлен.
                                                    Подходит для сценария временного перенаправления запросов.
                                                    Можешь без блокировки тупо попробовать разрешить подходящее под правило имя с dig или nslookup через сервер ниже по списку.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое