Dalex

Возможно кому-то пригодится и будет неприятным открытием, как для меня. Публичные DNS-резольверы, настраиваемые в веб - интерфейсе в разделе Интернет-фильтры, работают не в 100% случаев. Keenetic нужен не шифрованный plain-text dns, чтобы работать, а им обычно по умолчанию является DNS сервер провайдера (получается от провайдера и находится рядом - в Настройка DNS). И вот тут и начинается проблема - Keenetic использует и его для своих запросов и в результате "подмешивает" данные не только от выбранного публичного DNS-резольвера, но и от провайдерского. Это в том числе ломает и "Маршруты DNS" (в группу, отвечающую за маршрутизацию попадают совсем другие ip адреса, а не те, что получил клиент). Поэтому сейчас единственным решением, позволяющим в 100% случаев использовать публичный DNS-резольвер, является следующий ход (Публичный DNS-резольвер в разделе Интернет-фильтры конечно нужно выключить). 1. Добавить в "Настройка DNS" plain-text dns сервер для всех доменов от выбранного вами и не заблокированного публичного DNS-резольвера, например 8.8.8.8. Выбрать в настройках подключения к Интернет галку "Игнорировать DNSv4 интернет провайдера". 3. Добавить в "Настройка DNS" DoT\DoH\оба dns сервер для всех доменов от выбранного вами и не заблокированного публичного DNS-резольвера, например dns.google.com. 4. Отключить транзит запросов в "Настройка DNS" для вашего профиля.

"Маршруты DNS" работают со сбоями, так как в группу, которая маршрутизирует домен в конкретный интерфейс, часто попадают ip адреса, отличающиеся от тех, которые кинетик же в той же самой итерации отдает пользователю. Один запрос к одному домену от одного пользователя - > разные адреса в кеше DNS клиента пользователя и в соответствующей группе fqdn, отвечающей за маршрутизацию по маршрутам DNS -> кинетик отправляет пакеты в маршрут по умолчанию, ведь адрес то другой. А должен корректно разрезольвить и отправить их в выбранный в настройках маршрут. Засим все, возможно кто-то из "имеющих отношения к ООО Неткрейз" обратит внимание на этот топик.

Я проверяю с ноутбука обычного пользователя, подключенного по WIFI. Вы сами подтверждаете что есть проблема - "учитывая что провайдет отвечает быстрее чем quad - вполне ожидаемо". Это баг - и вы исправите со временем, или не баг и какая-то последовательность действий по настройке в 5.1.5 есть?

Я не хотел бы сейчас спрашивать - зачем я должен это делать, если включен публичный DNS. Давайте пока этот вопрос отложим, хотя спасибо, что подтвердили, что проблема существует. Самый важный вопрос - это то, что пользователям Кинетик отдает DNS ответ от публичного DNS, а сам внутри забирает совсем другие ip адреса из "plaintext dns" и добавляет уже их в "Маршруты DNS". Вы написали, что это не так. Вот вам подтверждение. "Включены" plaintext dns провайдера и публичный DNS quad9. На скриншотах - два DNS запроса - на кинетик и на 9.9.9.9 и вывод "show object-group fqdn". Как видите - в списке не появились ip адреса " 18.64.211", которые отдал Кинетик\quad9, но появились ip адреса 18.165.122, которые упорно отдает только провайдерский DNS.

Вот скриншот 2 запросов с моей ультры. Разница между первым и вторым, что перед вторым я сделал следующие действия: 1. Зашел в настройки L2TP соединения к провайдеру и выбрал "Игнорировать DNSv4 Интернет-провайдера". 2. Отключил и заново включил это соединение.

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

В KeeneticOS при включенном публичном DNS типа Cloudflare etc. есть две сущности, отрабатывающие DNS запросы: 1. ndnproxy, принимающий запросы на порт 53. 2. stubby, принимающий запросы на порт 40300. И они с собой явно не дружат. Ситуация первая - включаем "Игнорировать DNS провайдера". В этом случае ndnproxy (в Entware проверял) перестанет отвечать на DNS запросы и часть KeeneticOS перестанет корректно получать ответы на DNS запросы. Например, wireguard соединение к серверу по DNS имени не сможет подняться, несмотря на то, что публичный DNS то настроен и отвечает на 40300. Если изменить DNS имя в настройках соединения на ip адрес, поднимется. Ситуация вторая - "Маршруты DNS". Тут логика такая - 1. Пользователь делает DNS запрос и получает на него ответ от публичного DNS сервера (stubby?). 2. А вот KeeneticOS добавляет в группу fqdn ip (show object-group fqdn) адреса от ndnproxy и уже совсем другие адреса, потому что ndnproxy работает только с выключенной галкой "Игнорировать DNS провайдера" и отсылает запросы только на DNS сервер провайдера, публичный DNS он игнорирует от слова совсем. (есть кстати вопрос - а куда пойдет роутер, чтобы отресольвить dns.cloudflare.com, чтобы заработал публичный DNS - если провайдерские DNS игнорируются ?) В результате имеем две сущности: - ndnproxy, который всегда идет на DNS провайдера, игнорируя, что в KeeneticOS есть выбранный пользователем публичный DNS, - stubby, который может отдать с публичного DNS ответы пользвателям в локалке, но не может отвечать на внутренние запросы от процессов в KeeneticOS. Вот пример (ну да я их делал в Entware, но 1. с отключенным Entware ситуация не меняется, 2. проблема воспроизводится на другом устройстве без OPKG) - 4 запроса www.goodreads.com. К провайдеру, к ndnproxy (53 порт), к stubby (порт 40300) и к Яндекс DNS. И так со всеми запросами, которые имеют геораспределение\множественные записи DNS.

Похоже разобрался - DNS маршруты не работают с публичными DNS резольверами. Если отключить их в Интернет-фильтры, оставив системный\провайдерский, то поддомены попадают с правильными адресами. nslookup с 53 порта и 40300 выдают как раз те различные результаты, которые вносят путаницу. Keenetic ~ # nslookup www.goodreads.com 127.0.0.1:40301 Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: www.goodreads.com Address 1: 18.64.211.48 server-18-64-211-48.fra56.r.cloudfront.net Address 2: 18.64.211.47 server-18-64-211-47.fra56.r.cloudfront.net Address 3: 18.64.211.7 server-18-64-211-7.fra56.r.cloudfront.net Address 4: 18.64.211.111 server-18-64-211-111.fra56.r.cloudfront.net Keenetic ~ # nslookup www.goodreads.com 127.0.0.1:53 Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: www.goodreads.com Address 1: 3.174.230.53 server-3-174-230-53.waw51.r.cloudfront.net Address 2: 3.174.230.119 server-3-174-230-119.waw51.r.cloudfront.net Address 3: 3.174.230.28 server-3-174-230-28.waw51.r.cloudfront.net Address 4: 3.174.230.100 server-3-174-230-100.waw51.r.cloudfront.net

Воспользовался советами. Все DNS - кинетик, провайдерский, quad9, google показывают для www.dw.com ip 104.102.49.27. А вот в Keenetic в выводе "show object-group fqdn" запись при первой трассировке маршрута к нему появляется, но с совсем другим ip - 184.51.234.26. Аналогичная ситуация и по www.goodreads.com и по другим поддоменам из доменов в DNS маршрутах - адреса, которые отдают все DNS серверы - не совпадают с теми, что появяляются в show object-group fqdn Не понимаю - откуда они берутся и куда копать дальше :-(

Всем привет, прошу подсказать - как можно отдебажить маршруты DNS? Первая ситуация такая - создан отдельный список, содержащий одну запись - goodreads.com и правило маршрутизации. В результате (после ipconfig /flushdns) traceroute goodreads.com уходит по ожидаемому маршруту в туннель, но traceroute www.goodreads.com уходит в маршрут по умолчанию. Это несмотря на то, что в документации написано, что все поддомены в маршрутах DNS учитываются. Аналогичная ситуация с для примера - dw.com и www.dw.com. Как отдебажить это поведение, есть ли какая-то возможность увидеть внутрянку\логи движений по маршрутам DNS?Keenetic OS 5.0.12.

Вышел qBittorrent 5.2.2 Наткнулся на настройку, управляющую TTL для внутреннего кеша DNS - он 20 минут всего (1200 секунд). Возможно кому-то пригодится, чтобы снизить количество DNS запросов от qBT. В Веб интерфейсе в Настройки - Расширенные "Internal hostname resolver cache expiry interval" или "Время жизни кэша внутреннего разрешителя имён" [BitTorrent] Session\HostnameCacheTTL=1200 https://www.libtorrent.org/reference-Settings.html#resolver_cache_timeout

Вероятно перенаправление запросов к домену через специальный DNS сервер срабатывает раньше, чем срабатывают триггеры в "Маршруты DNS", поэтому хотелось бы обрптить на это внимание разработчиков KeeneticOS.

Именно. Такое ощущение, что создание отдельного DNS сервера выносит его из механики, которая создает DNS маршруты.

Выглядит так, что "Маршруты DNS" перестают работать, если для тех-же доменов добавить кастомный DNS сервер в Интернет-фильтры - Настройка DNS. Перестает работать маршрутизация по доменам, если добавить дополнительный днс сервер для определённого домена. При этом днс продолжает работать везде, кроме "Маршруты DNS".

Вышел qBittorrent 5.2.1 Бинарные файлы от уважаемого @TheBB здесь: https://bin.entware.net/aarch64-k3.10/test/qbittorrent-5.2.1_aarch64.tar.gz https://bin.entware.net/armv7sf-k3.2/test/qbittorrent-5.2.1_arm.tar.gz https://bin.entware.net/mipselsf-k3.4/test/qbittorrent-5.2.1_mipsel.tar.gz https://bin.entware.net/mipssf-k3.4/test/qbittorrent-5.2.1_mips.tar.gz Если кто-то хочет проголосовать за 3 issue, которые позволят разработчикам обратить внимание на то, что qbt генерирует дикое количество DNS запросов и может положить роутер, можно проголосовать за них на github: https://github.com/qbittorrent/qBittorrent/issues/9045 https://github.com/qbittorrent/qBittorrent/issues/22196 https://github.com/qbittorrent/qBittorrent/issues/24053