Маршрутизация DNS иногда не работает

[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>
  

 

 

Изменено 4 ноября, 2025 пользователем qmxocynjca

[Racer X]

Под "раньше" я имел в виду предыдущие альфы и беты 5.1.

[zingarini]

В 29.04.2026 в 17:09, Илья Картавенко сказал:

На клиентах и в браузерах выключили использование частных серверов? 

проверяю средствами роутера. 

[Racer X]

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

проверяю средствами роутера

Ну тогда понятно почему у вас СОВСЕМ ничего не работает.
Вы с реальных клиентов проверяйте. Запросы средств роутера не попадают в DNS роутинг.

[Jon De]

после обнлвления с 5.0.8 до 5.0.10 тоже перестал работать PBR.

при чем если в списки добавить список IP адресов начинает заворачивать как нужно. 

Куда копать?

Еще пожелание убрать или увеличить ограничении на 300 строк в списках.

[Racer X]

32 минуты назад, Jon De сказал:

Еще пожелание убрать или увеличить ограничении на 300 строк в списках.

Есть устойчивое ощущение что с короткими списками работает лучше. 
У меня несколько списков в пределах 10-15 строк и два по 60-80. Так вот проблемы чаще всего возникают в длинных списках. Не могу полностью исключать банальное совпадение, но такое вот наблюдение имеется.

[Jon De]

47 minutes ago, Racer X said:

Есть устойчивое ощущение что с короткими списками работает лучше. 
У меня несколько списков в пределах 10-15 строк и два по 60-80. Так вот проблемы чаще всего возникают в длинных списках. Не могу полностью исключать банальное совпадение, но такое вот наблюдение имеется.

До и с короткими не работает если говорить про fqdn. а так туда хоть список iP адресов можно загнать.

[Racer X]

2 часа назад, Jon De сказал:

До и с короткими не работает если говорить про fqdn

Да работает если все правильно настроено. Не идеально, но работает. На двух моих и еще 3 других роутерах за которыми присматриваю.
Если не работает, то где-то что-то не то делаете. Как вариант dns запросы клиентов идут мимо dns-proxy роутера. Плюс dsn роутинг работает только в рамках политики по умолчанию. В других политиках не работает.

Изменено 5 мая пользователем Racer X

[Простолюдин]

Кажется я тоже столкнулся с подобной проблемой, но в моем случае вместо DNS-имен используются ip-адреса для ресурса, который доступен только с иностранного IP.
Проблема появилась после добавления второго VPN-подключения и создания правила маршрутизации для нового (второго) интерфейса - сайт перестал меня пускать сообщая что "сервис не доступен в вашем регионе".

Запуск трассировки на ПК так же показывает, что трафик перестал идти по маршруту через vpn-интерфейс.

Раньше, когда в маршрутизации использовался один интерфейс, таких проблем не возникало.

5.1 beta 1

Изменено 5 мая пользователем Простолюдин

[Jon De]

On 5/5/2026 at 4:52 PM, Racer X said:

Да работает если все правильно настроено. Не идеально, но работает. На двух моих и еще 3 других роутерах за которыми присматриваю.
Если не работает, то где-то что-то не то делаете. Как вариант dns запросы клиентов идут мимо dns-proxy роутера. Плюс dsn роутинг работает только в рамках политики по умолчанию. В других политиках не работает.

есть пошаговая инструкция?

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

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

есть пошаговая инструкция?

https://support.keenetic.ru/skipper/kn-1910/ru/51150.html#51150-маршруты-dns

[zingarini]

В 05.05.2026 в 16:52, Racer X сказал:

dsn роутинг работает только в рамках политики по умолчанию

АА! Спасибо! Теперь работает.

Но, нужно чтобы работало и на пользовательских политиках!

Изменено Четверг в 15:20 пользователем zingarini

[Jon De]

On 5/7/2026 at 9:17 AM, Илья Картавенко said:

https://support.keenetic.ru/skipper/kn-1910/ru/51150.html#51150-маршруты-dns

все как в инструкции, работает выборочно. 

[VVS]

2 часа назад, Jon De сказал:

все как в инструкции, работает выборочно. 

Значит не всё, как в инструкции.

[Luci4]

17 часов назад, VVS сказал:

Значит не всё, как в инструкции.

либо баг

[kpukjkee]

В последнее время плохо работает маршрутизация через WG вшитую в кенетик. Иногда работает иногда нет. Проблема настигла после обновления на 5.0.11 (KN1011)

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

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

В последнее время плохо работает маршрутизация через WG вшитую в кенетик. Иногда работает иногда нет. Проблема настигла после обновления на 5.0.11 (KN1011)

Обновляйтесь на 5.1, все работает

[hoaxisr]

39 минут назад, Илья Картавенко сказал:

все работает

Не все. Заявленный функционал fallback для fqdn как не работал, так и не работает. 

Как были пропуски наполнения ipset, так и остались.

Функция как была нестабильной, так и осталась. 

[Denis P]

17 минут назад, hoaxisr сказал:

Заявленный функционал fallback для fqdn как не работал, так и не работает. 

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

Изменено Воскресенье в 11:54 пользователем Denis P

[hoaxisr]

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

чтобы интерфейс однозначно отключался при недоступности пира

Он "однозначно" выключается через невообразимо долгое время. Т.е. до статуса "административно" down проходит куча времени. А вот статус "failed" от pingcheck вообще не влияет на работу этой функции, даже когда failedcount>установленного в профиле pingcheck.  Можете проверить самостоятельно, в ТП об этом писал, но обратного гудка не слышно и вера потеряна. 

Рекомендовать использовать этот функционал я бы точно не стал. Особенно в свете наличия сторонних решений, умеющих делать не тупое наполнение ipset от резолва, а сравнивать SNI и IP и маршрутизировать избирательно даже сервисы за CDN.

 

[Denis P]

22 минуты назад, hoaxisr сказал:

Он "однозначно" выключается через невообразимо долгое время. Т.е. до статуса "административно" down проходит куча времени. А вот статус "failed" от pingcheck вообще не влияет на работу этой функции, даже когда failedcount>установленного в профиле pingcheck.  Можете проверить самостоятельно, в ТП об этом писал, но обратного гудка не слышно и вера потеряна. 

Рекомендовать использовать этот функционал я бы точно не стал. Особенно в свете наличия сторонних решений, умеющих делать не тупое наполнение ipset от резолва, а сравнивать SNI и IP и маршрутизировать избирательно даже сервисы за CDN.

 

Вы проверяли с

 interface X ping-check restart

?

Фокус то именно в этом...

Изменено Воскресенье в 13:30 пользователем Denis P

[hoaxisr]

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

Вы проверяли с

 interface X ping-check restart

?

Фокус то именно в этом...

Именно с этим параметром.

Не влияет pingcheck на работу fallback. Да и сам pingcheck работает странно - делая две проверки вместо одной за интервал.

Изменено Воскресенье в 14:13 пользователем hoaxisr

[uhf]

Так что в итоге делать-то по проблеме, описанной ТС? 
5.0.11, 5.1 Beta 1 - все так же присутствует.

Создан один список с одним доменом youtube.com
Для этого списка создано одно правило маршрутизации в впн.
В итоге, при трассировке с клиента:
youtube.com - маршрутизация работает
m.youtube.com - маршрутизация работает
www.youtube.com - маршрутизация НЕ работает

Ощущение что криво парсится DNS ответ и игнорируются CNAME. Вот что внутрях

        <entry>
            <fqdn>www.youtube.com</fqdn>
            <type>runtime</type>
            <deadline4>1749</deadline4>
            <deadline6>1822</deadline6>
            <fail-counter4>0</fail-counter4>
            <fail-counter6>0</fail-counter6>
            <last-external>103</last-external>
            <last-list-changed>103</last-list-changed>
            <parent>youtube.com</parent>
            <ipv4/>
            <ipv6/>
        </entry>

DNS ставил гугловский - не помогает.

[Jon De]

On 5/8/2026 at 5:38 PM, VVS said:

Значит не всё, как в инструкции.

Сегодня включил Check the Availability of the Internet (Ping Check), до этого он был выключен.

Вроде стало все работать, в инструкции про это ничего нет... Понаблюдаю, возможно просто совпадение.

PS: туннели openconnect и openvpn, на всякий случай.