Вопросы, связанные с работой DNS-маршрутизации (DNS routing)

[qmxocynjca]

В роутере (fw 5.0.0) прописан DNS от провайдера (обычный) и от Яндекса (DoT), в списке DNS маршрутизации прописан youtube.com.

Проблема: www.youtube.com не смог зароутиться куда надо. После неудачного роутинга несколько раз делал "nslookup www.youtube.com 192.168.1.1", но результата не дало - роутер упорно вёл по провайдеру.

Пробовал включить dns-proxy debug, после чего роутер почти завис секунд через 30, смог выключить эту настройку только через telnet. Кажется после этого роутинг таки заработал, но легче от этого не стало.

Наблюдения:

* провайдерные DNS возвращают 173.194.221.198 от primary и 64.233.162.198 от secondary на nslookup www.youtube.com.

* nslookup на www.youtube.com возвращает "Tracing route to wide-youtube.l.google.com", а на youtube.com возвращает "Tracing route to youtube.com".

* nslookup www.youtube.com 77.88.8.8 (обычный dns от яндекса) возвращает разные адреса на каждый запрос.

Вот как это примерно выглядит:

C:\Users\user>tracert -d -w 50 www.youtube.com

Tracing route to wide-youtube.l.google.com [173.194.220.198]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms     1 ms  <isp_gw>
^C
C:\Users\user>nslookup www.youtube.com 192.168.1.1
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    wide-youtube.l.google.com
Addresses:  2a00:1450:4010:c1e::c6
          142.251.1.198
Aliases:  www.youtube.com
          youtube-ui.l.google.com


C:\Users\user>tracert -d -w 50 www.youtube.com

Tracing route to wide-youtube.l.google.com [142.251.1.198]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms    <1 ms  <isp_gw>
^C
  
C:\Users\user>tracert -d -w 50 youtube.com

Tracing route to youtube.com [173.194.221.91]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.88.88
  2    91 ms    89 ms     *     <kvn_gw>
  

 

 

[avn]

51 минуту назад, kokzahvas сказал:

Кто-нибудь знает планируется ли добавить возможность добавлять в списки маршрутизации DNS IP-адреса не по одному, а с маской подсети, как в формате cidr?

Ещё со времён 5.1 так работает.

[Alex Izo]

Такую штуку заметил, разработчики DNS маршрутизации, как это прокомментируете?

Многие тут жалуются на DNS маршрутизацию, что она работает/криво/не работает вообще. Нашел 100% закономерность как словить неработоспособность: если не запускать в OPKG что либо, что работает с фильтрацией/маршрутизацией DNS, то штатная DNS маршрутизация кинетик работает. Но если в OPKG запустить например тот же Adguard, то кинетик сразу перестает наполнять ipset и DNS маршрутизация ломается.

Проблема элементарно воспроизводится:

opkg dns-override system configuration save - отдаем 53 порт от штатного резолвера кинетик в adguard

После (важна последовательность!) добавляем один список доменных имен (можно всего 1 домен) и делаем для него правило маршрутизации с перенаправлением в выбранный вами интерфейс, "добавлять автоматически" вкл и "эксклюзивный маршрут" не важно вкл или выкл, соответственно поднимаете интерфейс, политика клиента дефолт. Проведите трассировку и увидите, что маршрутизация не работает, запрос улетает напрямую в провайдера, минуя ранее выбранный интерфейс.

Далее стопаем adguard и возвращаем 53 обратно системному резолверу no opkg dns-override system configuration save.

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

 

Отсюда вытекает вопрос к остальным тут следящим за темой пользователям, как вы юзаете тот же adguard, если при его работе перестают работать системные dns маршруты, так как в отсутствии контроля 53 порта нечем наполнять ipset?

 

Изменено вчера в 18:31 пользователем Alex Izo

[Denis P]

5 минут назад, Alex Izo сказал:

Такую штуку заметил, разработчики DNS маршрутизации, как это прокомментируете?

Многие тут жалуются на DNS маршрутизацию, что она работает/криво/не работает вообще. Нашел 100% закономерность как словить неработоспособность: если не запускать в OPKG что либо, что работает с фильтрацией/маршрутизацией DNS, то штатная DNS маршрутизация кинетик работает. Но если в OPKG запустить например тот же Adguard, то кинетик сразу перестает наполнять ipset и DNS маршрутизация ломается.

Проблема элементарно воспроизводится:

opkg dns-override system configuration save - отдаем 53 порт от штатного резолвера кинетик в adguard

После (важна последовательность!) добавляем один список доменных имен (можно всего 1 домен) и делаем для него правило маршрутизации с перенаправлением в выбранный вами интерфейс, "добавлять автоматически" вкл и "эксклюзивный маршрут" не важно вкл или выкл, соответственно поднимаете интерфейс, политика клиента дефолт. Проведите трассировку и увидите, что маршрутизация не работает, запрос улетает напрямую в провайдера, минуя ранее выбранный интерфейс.

Далее стопаем adguard и возвращаем 53 обратно системному резолверу no opkg dns-override system configuration save.

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

 

Отсюда вытекает вопрос к остальным тут следящим за темой пользователям, как вы юзаете тот же adguard, если при его работе перестают работать системные dns маршруты, так как в отсутствии контроля 53 порта нечем наполнять ipset?

 

Это не проблема, а ожидаемое поведение. Как по вашему наборы должны заполняться если запросы уходят мимо штатного резолвера?

Изменено вчера в 18:33 пользователем Denis P

[Alex Izo]

2 минуты назад, Denis P сказал:

Это не проблема, а ожидаемое поведение. Как по вашему наборы должны заполняться если запросы уходят мимо штатного резолвера?

Сделать интеграцию с OPKG, хотя бы "звездочку" нарисовать в UI страницы DNS маршрутизации и расписать примечание для новичков...

ps как вы совмещаете dns маршрутизацию и правила фильтрации dns?

[Denis P]

11 минут назад, Alex Izo сказал:

Сделать интеграцию с OPKG, хотя бы "звездочку" нарисовать в UI страницы DNS маршрутизации и расписать примечание для новичков...

ps как вы совмещаете dns маршрутизацию и правила фильтрации dns?

у вас есть как минимум 2 варианта

1) использовать agh на другом порту отличном от 53 и направлять запросы с кинетика в него (в этом случае адреса конечных клиентов видны не будут)
2) наполнять ipset'ы через сам agh + скрипты для маркировки пакетов

Изменено вчера в 18:47 пользователем Denis P

[Alex Izo]

10 часов назад, Denis P сказал:

у вас есть как минимум 2 варианта

1) использовать agh на другом порту отличном от 53 и направлять запросы с кинетика в него (в этом случае адреса конечных клиентов видны не будут)
2) наполнять ipset'ы через сам agh + скрипты для маркировки пакетов

Второй вариант предпочтительнее, так как хочется видеть реальную по клиентам adguard статистику.

 

Видел форк adguard с наполнением ipset из web ui, но там не реализована сама маршрутизация, которую как я понял следует вручную прописать в cli. Однако с учетом того, что интерфейсы приходится часто менять (время такое, мрут мухи), придется постоянно корректировать в терминале маршруты, что неудобно.

 

Возможно имеется готовое ui решение по управлению маршрутами?

[Leshiyart]

4 минуты назад, Alex Izo сказал:

Однако с учетом того, что интерфейсы приходится часто менять (время такое, мрут мухи), придется постоянно корректировать в терминале маршруты, что неудобно.

можно привязаться к политике доступа(а для нее создается отдельная таблица маршрутизации), и уже там менять интерфейсы

[kokzahvas]

В 25.08.2026 в 12:40, avn сказал:

Ещё со времён 5.1 так работает.

Действительно работает. Спасибо. Не знал. Только в ходе тестирования обработки CIDR-адресации в списках маршрутов DNS я заметил очень странное поведение маршрутизации. Почему-то их обработка происходит в 100 раз медленнее, чем если бы я создал этот же маршрут в IPv4-маршрутах вместо списков в маршрутах DNS. Я ещё мог бы понять такую медленную обработку если бы использовал домен первого уровня, но я же использовал именно CIDR-запись. Я не прошу что-то изменить, мне просто интересно, чем можно объяснить такую медленную обработку. PS. Эффект замедления наиболее ярко выражен на больших IPv4-сетях, например 149.0.0.0/8, а также при большом количестве таких маршрутов в одном списке маршрутов DNS. 

[Alex Izo]

9 часов назад, Leshiyart сказал:

можно привязаться к политике доступа(а для нее создается отдельная таблица маршрутизации), и уже там менять интерфейсы

Интересная идея, реализовывали? Поделитесь командами?

[kda2495]

В 25.08.2026 в 07:40, avn сказал:

Ещё со времён 5.1 так работает.

То есть помимо доменных имён сайтов можно добавить и диапазоны IP типа 91.108.56.0/22 в список DNS для маршрутизации?

[Илья Картавенко]

8 минут назад, kda2495 сказал:

То есть помимо доменных имён сайтов можно добавить и диапазоны IP типа 91.108.56.0/22 в список DNS для маршрутизации?

Да