Вопросы, связанные с работой 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>
  

 

 

[dimon27254]

В 20.03.2026 в 21:08, hlnw сказал:

В рамках кейса NDM-4305 будут внесены улучшения связанные со скоростью резолвинга доменных имен, которые указаны в объектных группах.

Просьба проверить работу с новой тестовой версией ПО.

К сожалению, в 5.1 Alpha 7 каких-либо положительных изменений не увидел.

Включил dns-proxy debug, и, кажется, NDMS решила новые IP домена просто пропустить, отдав только клиенту.

Спойлер

[I] Mar 22 18:56:16 ndnproxy: [597B] domain 'tr.rbxcdn.com.'. 
[I] Mar 22 18:56:16 ndnproxy: [597B] from 127.0.0.1 to 127.0.0.1 via (none), device 1, mac (none). 
[I] Mar 22 18:56:16 ndnproxy: [597B] noflt. 
[I] Mar 22 18:56:16 ndnproxy: [597B] set an expire timeout to 7000 msec. 
[I] Mar 22 18:56:16 ndnproxy: [597B] added an upstream request [3949] to 127.0.0.1:[40508]. 
[I] Mar 22 18:56:16 ndnproxy: [597B] trying a next server after 0 msec. 
[I] Mar 22 18:56:16 ndnproxy: [3949] sending a UDP request to 127.0.0.1:[40508] (slot 22, fd 18). 
[I] Mar 22 18:56:16 ndnproxy: [3949] sent. 
[I] Mar 22 18:56:16 ndnproxy: [597B] no more servers to try. 
[I] Mar 22 18:56:16 https-dns-proxy: Received request for id: 3949, len: 31 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: Requesting HTTP/2 
[I] Mar 22 18:56:16 ndm: Dns::Route::ResolveQueue: process fqdn event "tr.rbxcdn.com". 
[I] Mar 22 18:56:16 ndm: Dns::Route::ResolveQueue: "domain-list3": fqdn "tr.rbxcdn.com" already processed. 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: > POST /dns-query HTTP/1.1 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: > Host: dns.*.ru 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: > User-Agent: NDMS DoH proxy/0.1 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: > Accept: application/dns-message 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: > Content-Type: application/dns-message 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: > Content-Length: 31 
[I] Mar 22 18:56:16 https-dns-proxy: Reserved new io event: 0x7ff8b42f38 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < HTTP/1.1 200 OK 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Server: nginx 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Date: Sun, 22 Mar 2026 11:56:17 GMT 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Content-Type: application/dns-message 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Content-Length: 177 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Connection: keep-alive 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Access-Control-Allow-Origin: http://dns.*.ru 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: < Vary: Origin 
[I] Mar 22 18:56:16 https-dns-proxy: Released used io event: 0x7ff8b42f38 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: curl request succeeded 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: CURLINFO_NUM_CONNECTS: 0 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: CURLINFO_EFFECTIVE_URL: https://dns.*.ru/dns-query 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: CURLINFO_HTTP_VERSION: 1.1 
[I] Mar 22 18:56:16 https-dns-proxy: 3949: Times: 0.000000, 0.000000, 0.000000, 0.000386, 0.096629, 0.096770 
[I] Mar 22 18:56:16 https-dns-proxy: Received response for id: 3949, len: 177 
[I] Mar 22 18:56:16 ndnproxy: [3949] got a valid reply. 
[I] Mar 22 18:56:16 ndnproxy: [597B] send "normal" answer from [3949]. 
[I] Mar 22 18:56:16 ndnproxy: [597B] freed. 
[I] Mar 22 18:56:16 ndnproxy: out: capacity 64, used 0, collisions 0, max. buckets 0. 
[I] Mar 22 18:56:16 ndm: Dns::Route::ResolveQueue: syncing cache. 

Ниже self-test с включенным dns-proxy debug. Время запроса 18:56:16, на сервере 18:56:17.

 

@admin может быть, все-таки рассмотрите вариант сделать обработку запросов, как это реализовано в dnsmasq? По сути, входной и выходной точкой всех запросов является ndnproxy, в том числе в политиках. Нельзя ли его "научить" извлекать IP-адреса из ответов upstream и загружать в object-group fqdn налету? Чтобы избавиться от всего того, что сделано сейчас и работает не совсем хорошо.

Я ранее пользовался dnsmasq, сейчас в основном MagiTrickle - там все работает идеально. Хотелось бы видеть, что также идеально все работало и "в стоке". Текущая реализация, к сожалению, очень далека от идеала.

Edited March 22 by dimon27254

[FLK]

При всем моем безграничном уважении к сотрудникам/разработчикам Keenetic/Netcraze им пора наверно признать, что этот функционал работает не так как хотелось бы очень многим пользователям, которые его просили и голосовали за него в одной из самых популярных тем на форуме)

Из версии в версию (начало положено аж в 5.0, а скоро уже 5.1 в стабильную выйдет) перетекают одни и те же проблемы. Функционал действительно очень нужный и полезный, хотелось бы чтоб он отрабатывал на 100%. Но пока увы и ах. Так может быть еще подумать, перетрясти то, что есть или пошевелить другие концепции?

Крик души, так сказать 😊

 

[Denis P]

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

1. Проблема "суффикса" когда по частичному совпадению под правила попадают и другие домены (x.com yandex.com)

2. Пропуск первых запросов, уходят мимо ipset'a -> приходится обновлять страницу

3. Когда у ответа маленький ttl, dns-proxy может выдать already processed и не добавлять адрес в ipset-> клиент получает новый адрес от dns-proxy (который не попал в набор) и пакетики идут по дефолтному маршруту

4. При резервировании приходится вешать ping-check на vpn интерфейс, но и это не всегда работает

з.ы. Поддержку dns маршрутов в других политиках обещают сделать в 5.2

[liliput-liliout]

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

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

Я думаю разработчикам стоит "погулять" до технической поддержки, где все неоднократно уже передавалось и селф-тесты и описание указанных багов.
Но, к сожалению, ответы от разработчиков предлагающих исключить yandex.com из правила x.com наводят на выводы, которые не очень вяжутся с их уровнем профессионализма.

[uhf]

Могу предположить, что фича давно готова в глазах менеджмента и в отчетах, остались лишь "мелкие баги". 
Обычные разработчики вряд ли захотят или смогут их переубедить, они лишь будут избегать задач, связанных с этим роутингом. Потому что знают, что быстро и легко починить его нельзя.
Руководитель разработки должен взять на себя ответственность и признать, что текущее решение неподходящее, требует рефакторинга и выделения ресурсов. А у него такого желания тоже, скорее всего, нет.
Поддержка держит оборону, очень сложно им доказать непостоянные ошибки, которые не воспроизводятся на стенде. Везде тупик.

Чтобы не быть голословным, я поковырял прошивку. Как и ожидалось, у фичи асинхронная архитектура, из-за которой все проблемы.
За DNS роутинг отвечает отдельный поток. Он читает из локального сокета сообщения от DNS-прокси, в которых тот передает события "получен от клиента запрос", и "получен ответ от DNS". Чтение идет с задержкой до 100 мс. (отсюда пропуск первых запросов), нет информации какой именно ответ ушел клиенту (отсюда путаница с IP). 
Также этот поток отслеживает TTL доменов, сам запускает ресолв, чистку списков, ограничение их размера, и вообще вся реализация сложная (отсюда трудноуловимые баги).

Сейчас хотелось бы понять, есть ли вообще вероятность, что возьмутся переделывать, или проще не тратить время на ожидание, и поискать другие решения.

[kisil-mike]

Существующее решение работает "корректно", похоже, только для самих разработчиков. Хотя этот функционал внедряли для конечных пользователей, и его логику стоило бы адаптировать под ожидания именно пользователей. Ответы поддержки в стиле "все работает как задумано" выглядят по меньшей мере странно.

Мы выбираем Keenetic и готовы переплачивать за бренд именно ради качественной, гибкой прошивки и вниманию к деталям, что всегда находилось на высшем уровне. Очень хочется верить, что подобные отписки - это просто недопонимание на местах, а не новый курс компании.

Edited July 15 by kisil-mike

[spatiumstas]

В 20.06.2026 в 01:11, spatiumstas сказал:

5.1.0 без изменений 🥰

5.2 Alpha 3 Без изменений

 

@admin Можно услышать ответ касаемо будущего "Маршруты DNS", они будут работать или останутся в текущем состоянии? За полтора года ни в одной сборке не было нормального рабочего функционала, даже чуточки заинтересованности с вашей стороны. Хотелось бы понимать, стоит ли на неё рассчитывать в будущем, или оставаться на альтернативных решениях

[hoaxisr]

2 часа назад, Nokko сказал:

Какие сторонние решения можно использовать для маршрутизации такого рода

Magitrickle/HydraRoute/SingBox/Mihomo

[FLK]

1) провайдерские или любые plain-text dns работать не будут, пока есть хотя бы 1 doh/dot

2) если вы пытаетесь смотреть трубу, вбив только youtube.com скажу сразу - это так не работает...

Edited November 5, 2025 by FLK

[qmxocynjca]

1 час назад, FLK сказал:

1) провайдерские или любые plain-text dns работать не будут, пока есть хотя бы 1 doh/dot

Про это не знал, спасибо.

1 час назад, FLK сказал:

2) если вы пытаетесь смотреть трубу, вбив только youtube.com скажу сразу - это так не работает...

Да, это понятно, весь список нужных доменов заполнен. Проблема воспроизвелась конкретно с этим хостом, поэтому подробности опустил.

@Le ecureuil я бы рад держать dns-proxy debug включенным, чтобы отловить это, но это не реально - резолвер перестаёт отвечать через какое-то время (минута-две) и в логи начинает слать какое-то слишком низкоуровневое месиво. Сделайте чтобы dns-proxy debug был рабочим на постоянной основе?

[Le ecureuil]

Нет, debug он для отладки. Постоянно им пользоваться нельзя.

Если в целом, то все верно - нужно использовать нормальные, "неподмененные" DNS, иначе будет ерунда.

Насчет неработы - стоит проверить на грядущей версии, там есть некоторые улучшения.

[qmxocynjca]

7 часов назад, Le ecureuil сказал:

нужно использовать нормальные, "неподмененные" DNS, иначе будет ерунда.

DoT от Яндекса - это нормальный DNS в этом случае? Не очень понимаю что есть "неподменные". Если речь про "Интернет-фильтры", то ими не пользуюсь, всё руками прописано, никакого adguard и прочего нет в цепочке.

7 часов назад, Le ecureuil сказал:

Насчет неработы - стоит проверить на грядущей версии, там есть некоторые улучшения.

Это хорошо, будем посмотреть.

7 часов назад, Le ecureuil сказал:

Нет, debug он для отладки. Постоянно им пользоваться нельзя.

Тут вам видней, конечно, но это не первый раз когда я пробовал dns-proxy debug и все разы получалась какая-то жесть, когда было ощущение что девайс придётся ресетить, ибо всё вставало колом. 

[semipron]

Такая же фигня.

Заметил сразу по просмотру например твича, ttvnw.net добавлен в маршруты через влесс. Но показывает через раз, то в 1080р, то в 720р(1080р для России недоступен). Так же если трассировку запустить до рандомного юрла из моего списка в маршрутах, то где то идет через влесс, где то нет. Доты 8.8.8.8, 8.8.4.4, 9.9.9.9 прописаны.

[Oleg Nekrylov]

Если списков fqdn несколько списков, то на 5.0.0 работает только первый и только по проводному сегменту, по WI-FI не работает (NC-1812/KN-1012/KN-2311) 😔

[Denis P]

44 минуты назад, Oleg Nekrylov сказал:

по WI-FI не работает (NC-1812/KN-1012/KN-2311) 😔

этим клиентам точно назначена политика по умолчанию?

[Oleg Nekrylov]

В 12.11.2025 в 17:50, Denis P сказал:

этим клиентам точно назначена политика по умолчанию?

Это не клиенты - это роутеры. А других политик и нет, только Политика по умолчанию.

Работает только eesti (wireguard), остальные идут через ISP, несмотря, что явно указан туннель. Флаг Эксклюзивный маршрут влияет  только на eesti. На 5.0b2/b3 всё работало, после обновления работает только первый список: выключаем eesti, начинает работать tmdb, выключаем tmdb, начинает работать intel...

Edited November 13, 2025 by Oleg Nekrylov

[Denis P]

39 минут назад, Oleg Nekrylov сказал:

Это не клиенты - это роутеры. А других политик и нет, только Политика по умолчанию.

Работает только eesti (wireguard), остальные идут через ISP, несмотря, что явно указан туннель. Флаг Эксклюзивный маршрут влияет  только на eesti. На 5.0b2/b3 всё работало, после обновления работает только первый список

Так это вы сейчас про статикроуты, а тема то про новую фичу из 5.0

[qmxocynjca]

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

Так это вы сейчас про статикроуты, а тема то про новую фичу из 5.0

Да не, видно же что что это списки доменов с вручную заданными именами.

Ждём новую версию прошивки, говорят там что-то должно быть поправлено.

[Denis P]

15 часов назад, Oleg Nekrylov сказал:

Это не клиенты - это роутеры

т.е. роутеры пиры должны следовать правилам dns маршрутизации и кинетик выступает в качестве dns сервера на них?
пока что к схеме вопросы возникают)

[Oleg Nekrylov]

3 часа назад, Denis P сказал:

т.е. роутеры пиры должны следовать правилам dns маршрутизации и кинетик выступает в качестве dns сервера на них?
пока что к схеме вопросы возникают)

К схеме вопросов нет, если вы конечно  сами себе чего-то не понапридумывали.

Клиенты здесь конечные устройства, сидящие за роутерами, а на роутерах несколько каналов и их задача коммутировать их в зависимости от поставленных задач.

 

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

Так это вы сейчас про статикроуты, а тема то про новую фичу из 5.0

Статически маршруты это тоже затрагивает. Через какое-то время они перестают работать:, в web, есть но не работают, сделаешь маршруту выкл/вкл и они на какое-то время опять начинают работать.

Edited November 13, 2025 by Oleg Nekrylov

[Denis P]

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

К схеме вопросов нет

Как же нет, если вы её не показываете? 

[qmxocynjca]

К теме топика - на 5.0.1 пока полет нормальный, но заметил странную особенность. Если устройство в политике и делает днс запрос на хост из списка (через резолвер, который используется во всех политиках!), то ipset не наполняется. Зачем это ограничение?

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

[Denis P]

6 минут назад, qmxocynjca сказал:

Если устройство в политике и делает днс запрос на хост из списка (через резолвер, который используется во всех политиках!), то ipset не наполняется. Зачем это ограничение?

Потому что в политиках обращение идет не к 53 порту, а заворот на другие, системные порты

[qmxocynjca]

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

Потому что в политиках обращение идет не к 53 порту, а заворот на другие, системные порты

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

Сейчас если устройство было в политике и походило по доменам из списка, то при смене политики на дефолтную возникает wtf, хотя устройство использует DNS от роутера с единственным апстримом.

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

[Denis P]

4 часа назад, qmxocynjca сказал:

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

технически - да, но о подобных ограничениях разработчики упоминали еще в 4.3, когда только часть функционала была реализована

[qmxocynjca]

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

Тут вопрос - как работает кэширование dns в принципе у Кинетика? Шарится ли кэш между политиками в ситуации с одним dns апстримом? Если шарится, то логично и ipset-ы наполнять по этой же логике.

[avn]

33 минуты назад, qmxocynjca сказал:

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

Тут вопрос - как работает кэширование dns в принципе у Кинетика? Шарится ли кэш между политиками в ситуации с одним dns апстримом? Если шарится, то логично и ipset-ы наполнять по этой же логике.

 

Если хотите, что бы DNS-Маршрутизация работала и в политиках, то попробуйте для нее изменить приоритет, путем добавление копии rule. Мне такой тест проводить лениво, но если заработает, можно написать разработчикам.

$ ip rule add from all fwmark 0xffffaaf lookup 4102 pref  8

$ ip rule
0:      from all lookup local
8:      from all fwmark 0xffffaaf lookup 4102
10:     from all fwmark 0xffffa00 lookup main
100:    from all fwmark 0xffffaaa lookup 4096
101:    from all fwmark 0xffffaaa blackhole
102:    from all fwmark 0xffffaab lookup 4098
103:    from all fwmark 0xffffaab blackhole
106:    from all fwmark 0xffffaae lookup 4100
107:    from all fwmark 0xffffaae blackhole
108:    from all fwmark 0xffffaac lookup 4101
109:    from all fwmark 0xffffaac blackhole
110:    from all fwmark 0xffffaaf lookup 4102
111:    from all fwmark 0xffffaaf blackhole
233:    from all fwmark 0x20000000 lookup 233
1152:   from x.x.x.x lookup 16385
2000:   from all lookup 248
32766:  from all lookup main
32767:  from all lookup default

 

[Denis P]

12 минут назад, avn сказал:

 

Если хотите, что бы DNS-Маршрутизация работала и в политиках, то попробуйте для нее изменить приоритет, путем добавление копии rule. Мне такой тест проводить лениво, но если заработает, можно написать разработчикам.

$ ip rule add from all fwmark 0xffffaaf lookup 4102 pref  8

$ ip rule
0:      from all lookup local
8:      from all fwmark 0xffffaaf lookup 4102
10:     from all fwmark 0xffffa00 lookup main
100:    from all fwmark 0xffffaaa lookup 4096
101:    from all fwmark 0xffffaaa blackhole
102:    from all fwmark 0xffffaab lookup 4098
103:    from all fwmark 0xffffaab blackhole
106:    from all fwmark 0xffffaae lookup 4100
107:    from all fwmark 0xffffaae blackhole
108:    from all fwmark 0xffffaac lookup 4101
109:    from all fwmark 0xffffaac blackhole
110:    from all fwmark 0xffffaaf lookup 4102
111:    from all fwmark 0xffffaaf blackhole
233:    from all fwmark 0x20000000 lookup 233
1152:   from x.x.x.x lookup 16385
2000:   from all lookup 248
32766:  from all lookup main
32767:  from all lookup default

 

не поможет, потому что
 -A PREROUTING -m mark --mark 0x0 -j _NDM_DNSRT_PREROUTING_MANGLE
да и метки там динамические с таблицами

Edited November 16, 2025 by Denis P

[qmxocynjca]

12 минут назад, avn сказал:

Если хотите, что бы DNS-Маршрутизация работала и в политиках

Спасибо, но как раз не хочу. Я лишь хочу чтобы dns запросы из политик наполняли ipset, который используется в маршрутизации dns в основной политике.

[Alf_massol]

У меня вообще не маршутизируется по DNS. Записан и по имени и по IP

traceroute -n api.themoviedb.org
traceroute to api.themoviedb.org (65.9.175.91), 30 hops max, 60 byte packets
 1  192.168.1.1  1.630 ms * *
 2  192.168.1.1  3054.966 ms !H  3055.176 ms !H  3055.171 ms !H

А вот если добавить IP-v4 маршрутизацию, то все отлично