Mikrotik выступает как DNS-слейв.

Ну, я бы считал случайные ответы NXDOMAIN по локальным именам довольно серьёзной проблемой (ведь это происходит постоянно, а не только когда что-то не работает!), но, конечно, решать вам самим. Всё зависит от того, для чего нужны эти локальные имена.

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

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

Вот в чём ваша проблема: таймауты в DNS — дело довольно частое. Это не из-за вашей инфраструктуры или провайдера, просто на некоторые запросы приходит никаких ответов. DNS-серверы домена могут быть мертвы, могут вообще исчезнуть — что угодно. Каждый раз, когда вы попадаете на такой плохо настроенный домен (а при обратных DNS-запросах это случается ещё чаще), резолвер переключается на следующий сервер. Обычно это не проблема, а даже плюс: нагрузка равномерно распределяется между серверами. Когда все ставят 8.8.8.8 первым сервером, а 8.8.4.4 — вторым (или 1.1.1.1 и 1.0.0.1), первый адрес получает гораздо больше нагрузки, чем второй. На самом деле же используются оба.

А теперь проблема: если вы обращаетесь к своему локальному домену через 1.1.1.1 вместо локального DNS, резолвер вернёт NXDOMAIN (домен не найден), и MikroTik просто пересылает это пользователю. NXDOMAIN — это код ошибки, который НЕ заставит резолвер попробовать другой сервер. Таймауты — да, заставляют, а такой ответ — нет.

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

Итак, условные форвардеры, которые отправляют всё для домена X на IP X, а всё остальное — на публичный DNS, на Mikrotik сделать не получится. Но можно использовать ваш основной DNS как DNS-сервер в Mikrotik и в Bind разрешить Mikrotik запрашивать внутренние зоны, рекурсию и доступ к кешу. Тогда, если Bind уже знает A-запись для хоста, он не будет запрашивать её снова. Предполагаю, у вас есть внутренняя зона и внешняя с использованием views, так что увеличьте глобальный $ttl до нескольких дней — тогда, даже если Bind упадёт, Mikrotik дольше будет кешировать локальные DNS-записи. Но при этом вы не сможете запрашивать внешние хосты, если основной DNS выйдет из строя. #Bind named.conf.local — только для приватных зон, если у вас есть views:

allow-query {mikrotik;};  
allow-query-cache {mikrotik;};  
allow-recursion {mikrotik;};

Можно сделать и не очень аккуратно, но работающий способ: то, что выше, плюс добавить публичный DNS в Mikrotik. Если клиенты запросят внутренний IP, которого нет в кеше Mikrotik, он может пойти либо на внутренний DNS, либо на публичный — в зависимости от того, какой DNS выберется (round robin). Очевидно, что внутренние запросы к публичному DNS провалятся, но если запрос попадёт на внутренний, будет ответ и запись попадёт в кеш. В этом варианте, если основной сайт упадёт, разрешение имён всё равно будет работать, но некоторые запросы могут не пройти, и пользователям придётся, например, обновлять страницу, потому что произошёл сбой при получении внутренней DNS-записи с публичного DNS.

@RoadkillX: Проблема в том, что всё неправильно (ничего личного). Если сделать DNS-сервер в Локации А (который разрешает и приватные, и публичные имена) главным резолвером, то Локация B становится зависимой от Локации А. И дело не только в локальных именах, это всего лишь маленькая, второстепенная часть. Туннель ни в коем случае не должен падать, потому что если это случится, Локация B фактически останется без интернета, разве что с парой уже кэшированных записей, но многие сайты используют очень короткие TTL, так что этого надолго не хватит (естественно, у Локации B будет полноценный интернет, но без DNS толку мало). “Удачная лотерея DNS” с комбинированием внутренних и внешних резолверов почти неработоспособна. Выделенный DNS-резолвер в Локации B, хоть и более правильное решение, тоже имеет серьёзные недостатки. Во-первых, это перебор, нужна дополнительная машина. Любая подойдёт, даже старый RasPi или что-то подобное — с этим проблем нет. Но её нужно поддерживать в рабочем состоянии, потому что она становится единственной точкой отказа. Если уж ставить не один, а больше, то это уже двойной перебор, учитывая, что доступ только к локальным именам должен был быть всего лишь небольшим дополнением. Тут лучше использовать условные переадресации.