Короткий ответ

Кэш RouterOS отвечает клиентам только при allow-remote-requests=yes. Без этого флага сам роутер резолвит (/ping mikrotik.com с CLI работает), а ПК с DNS 192.168.88.1 получает timeout. Второй столб — пустой или мёртвый servers= (upstream). Третий — filter input drop UDP/TCP 53 с LAN.

Не включайте remote-requests и одновременно accept 53 с ether1: получите открытый резолвер на 203.0.113.10. LAN-only accept, WAN drop.

Симптомы и как отличить

ТестЗначение
С ПК ping 1.1.1.1 ок, one.one.one.one нетDNS, не NAT
С роутера оба ок, с ПК имя нетallow-remote-requests / input 53
И роутер, и ПК не резолвятupstream, UDP 53 наружу, DoH
DHCP раздал 8.8.8.8, проблем неткэш роутера просто не используется

Похоже на нет интернета, но ping по IP с LAN жив — не начинайте с masquerade.

Возможные причины

  1. allow-remote-requests=no (дефолт на части ручных конфигов).
  2. servers пустой и нет use-peer-dns с DHCP-клиента WAN.
  3. Upstream недоступен (filter output, маршрутизация, провайдер режет 53).
  4. Input drop 53 с bridge.
  5. DHCP network раздаёт 192.168.88.1, кэш выключен.
  6. DoH настроен криво (use-doh-server без работающего TCP/443).
  7. static FWD/regexp сломали зону.

Диагностика

/ip dns print
/ip dns cache print
/ip dhcp-server network print
/ip firewall filter print stats where chain=input

С роутера:

/ping one.one.one.one count=3

С ПК: nslookup example.com 192.168.88.1 и nslookup example.com 1.1.1.1. Второй успех, первый нет — проблема кэша/ACL, не «интернет».

DoH (ROS 7):

/ip dns print

Поля use-doh-server, verify-doh-cert. Если DoH включён и 443 к провайдеру DoH мёртв — весь резолв ляжет, даже при живых servers.

Решение

Сценарий A. Включить кэш для LAN

/ip dns
set allow-remote-requests=yes servers=1.1.1.1,9.9.9.9

Filter выше drop all:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=53 in-interface-list=LAN comment=dns-lan
add chain=input action=accept protocol=tcp dst-port=53 in-interface-list=LAN comment=dns-lan-tcp

Не ставьте эти правила с in-interface-list=WAN.

Сценарий B. Клиентам сразу публичный DNS

Если кэш не нужен:

/ip dhcp-server network
set [find address="192.168.88.0/24"] dns-server=1.1.1.1,9.9.9.9

Тогда allow-remote-requests можно оставить no. Роутер сам пусть имеет servers для NTP/upgrade.

Сценарий C. Upstream через провайдера

Верните use-peer-dns=yes на DHCP-клиенте WAN или пропишите DNS из карточки ISP. Смешивать DoH и мёртвый ISP DNS без проверки — путь к SERVFAIL.

Сценарий D. Открытый резолвер уже случился

/ip firewall filter
add chain=input action=drop protocol=udp dst-port=53 in-interface-list=WAN
add chain=input action=drop protocol=tcp dst-port=53 in-interface-list=WAN

Проверьте, что WAN list содержит ether1. Счётчики drop с WAN на 53 — ожидаемый шум сканеров.

Как проверить, что проблема устранена

/ip dns cache print

Кэш растёт при запросах с ПК. nslookup на 192.168.88.1 отвечает. С WAN UDP 53 закрыт. Сайты открываются на клиенте без браузерного DoH.

Проверка с самого роутера не достаточна — обязателен клиент в 192.168.88.0/24.

Если не помогло

  • Split DNS / static /ip dns static перекрывает имя — ищите regexp.
  • NTP и upgrade работают (они могут ходить иначе) — всё равно чините DNS клиентов отдельно.
  • Резолв есть, HTTPS нет — сертификат/время/фильтр 443, не DNS.
  • Adlist в ROS 7 (если пользуетесь) ломает нужные имена — смотрите /ip dns adlist в вашей версии, отключайте для теста.

Профилактика

  • Явная политика: либо кэш LAN-only, либо публичный DNS в DHCP.
  • Мониторинг: резолв с клиента, не только ping IP.
  • Документировать DoH.
  • Harden input DNS вместе с управлением.

DoH, peer DNS и почему резолв «иногда» живой

В RouterOS 7 поле use-doh-server переключает резолвер на HTTPS. Если DoH-узел недоступен (filter output, DPI, мёртвый маршрут), падает и кэш для LAN, даже при заполненном servers=1.1.1.1. Для теста отключите DoH и снова /ip dns cache flush, затем nslookup с ПК на 192.168.88.1.

use-peer-dns=yes на DHCP-клиенте WAN дописывает DNS провайдера в /ip dns. После смены ISP вы можете резолвить только через мёртвые адреса старого peer. Проверьте:

/ip dns print
/ip dhcp-client print detail

Статические /ip dns static с regexp перекрывают имена молча: клиент получает «не тот» A-запись, браузер «не открывается», ping по IP жив. Перед чисткой cache выгрузите static в export.

Открытый резолвер проверяйте с WAN: UDP 53 на 203.0.113.10 должен дропаться. Counters на drop 53 с WAN — нормальный шум. Accept 53 только in-interface-list=LAN. Не ставьте servers=192.168.88.1 — петля на собственный listener.

FAQ

max-udp-packet-size и TCP fallback?

Большие ответы DNS могут резаться. Симптом — отдельные зоны SERVFAIL. Не первая причина «весь DNS мёртв».

Можно ли servers=192.168.88.1?

Петля на себя. Upstream должен быть внешним или DC в LAN (10.0.10.10), не сам listener.

cache flush обязателен после смены servers?

Желателен:

/ip dns cache flush

Иначе клиент получит старый TTL.

Почему Windows показывает DNS 192.168.88.1, а запросы идут на 8.8.8.8?

NRPT, DoH, split tunnel VPN на ПК. Смотрите клиент, не только MikroTik.

IPv6 DNS?

/ipv6 dhcp-server и RA advertise-dns. Сломанный IPv6 DNS при живом v4 даёт «иногда не открывается». Проверяйте оба стека.

Как отличить мёртвый upstream от filter на input 53?

С роутера /ping one.one.one.one проверяет, что сам RouterOS умеет резолвить через servers или DoH. Если это работает, а nslookup example.com 192.168.88.1 с ПК таймаутит — allow-remote-requests=no или drop UDP/53 в input с bridge. Если не резолвит и роутер — чините WAN, DNS провайдера, DoH и output. Счётчики input на правиле dns-lan должны расти во время nslookup. Счётчики drop 53 с WAN при этом могут расти от сканеров — это не ваши клиенты. Не открывайте 53 на ether1 ради «проверки». После смены servers делайте /ip dns cache flush, иначе TTL прячет старый ответ. DHCP network, который раздаёт 192.168.88.1, обязан совпадать с включённым кэшем; иначе раздайте 1.1.1.1 напрямую и не держите half-on кэш.