Маршрутизация 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]

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

предположу, они допустили опечатку и имелся в виду x.com без точки в начале 

Почти уверен что нет. Потому что это был ответ на жалобу, что x.com без точки в начале отравляет в тоннель все окачивающееся на x.com.

[Racer X]

41 минуту назад, VVS сказал:

Как задать, чтобы маршрутизация распространялась на x.com, но не распространялась на *x.com (вопрос не к Вам)?

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

[VVS]

14 минут назад, Racer X сказал:

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

Надеюсь, что это не так, ибо, в противном случае, проще использовать стороннее решение.

[hlnw]

8 часов назад, Nkllganov53 сказал:

 

Это ожидаемое поведение.
Используйте .x.com в списке, либо добавьте yandex в исключения через CLI команды

На уточняющий вопрос будет ли это исправлено в 5.1 ответ:

Это поведение ожидаемое и меняться не будет.

Жалко, что с нами  нет @Le ecureuil

Лучше все-таки указывать exclude правило для нужных доменов, которые необходимо исключать для группы в CLI:

object-group fqdn domain-list0 exclude yandex.com
system configuration save

 

[Nkllganov53]

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

ага, и еще миллион подобных оканчиваюшихся на *x. супер логика

По поводу hlnw "Лучше все-таки указывать exclude правило для нужных доменов, которые необходимо исключать для группы в CLI"

Изменено 17 часов назад пользователем Nkllganov53

[Nkllganov53]

3 часа назад, Alex Izo сказал:

Что все так привязались к этому yandex.com?

Это символ проблемы. И дело не yandex.com, а в контроле что куда отправляется. И по-моему проще исправить, а не предлагать какие-то костыли

[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 доменов, сам запускает ресолв, чистку списков, ограничение их размера, и вообще вся реализация сложная (отсюда трудноуловимые баги).

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