zubzer0

в логе 5.1 A6 есть улучшения FQDN, нужно тестить.

3 часовой тест ICMP пинга и TCP пинга, малыми пакетами, от роутера к клиенту шкала логарифмическая, чтобы не сливалось в ровную линию. нижние скачки в районе 0.3-1мс, пики на 10-15 мс левая часть - обычный веб серфинг. середина - простой. правая часть - торрент с 50 активными пирами. заметил забавность, что при использовании канала, пинги приобретают слегка сниженный характер (падают до 0.3мс) нежели при простое. (почти ровная 1мс) в тоже время, заметил, взлёт пиков НЕ является следствием загруженности канала от множества коннектов или трафика. Ибо левая часть и правая похожи, хотя слева просто веб, а справа торренты. ( помехи? ) какой-то четко выраженной последовательности повторений лагов - не наблюдаю. не в icmp, не в tcp ICMP: TCP: на графике взлёт пиков выглядит слегка пугающе. по факту: тех, что больше 2мс- около 300 (3%) тех, что больше 5мс - около 50 (0,5%) тех, что больше 10мс - около 5 (0,05%) 0 промахов. но, какие либо выводы делать не стоит, ибо тест всего 1 клиента и в определенной местности. здесь много влияющих факторов, сетевая карта и ос на клиенте, кабель и помехи ... нужно воспринимать, это только, как тест конкретного конфига. а для себя я делаю вывод, что в 0,05% пакетов, у меня почему-то случаются затупы (x10 lag)

надо писать на почту. https://keenetic.ru/ru/company/support прикладывая скрины из https://github.com/ameshkov/dnslookup и/или dig если linux. можно еще и с Wireshark по типу https://forum.keenetic.ru/topic/27262-медленный-dns/#findComment-231915 и вот сюда ткнуть

поскорее бы... хотя-бы для localhost как-то исключение сделать в ближайшем релизном 5.0.х (онже жестко прописан в системе, зачем ему dns-based routing) а остальное, пускай приложится в 5.1 в общем пакете оптимизаций (включая возврат кэширования)

притом поведение крайне странное. роутер буквально ничего не делает. 0 трафика, а задержка гуляет с 2х/3х кратным джиттером, на ровном месте, на localhost'e p.s. тут можно статью на хабре писать, о том как Кинетики локалхост уронили 😆

5.0.7 ситуация без изменений dns роутера продолжает неимоверно тормозить сам-себя и заставляет тормозить "самих-себя" - всех клиентов без статики.

обратите внимание на "Активные соединения" если их настолько много, что роутер буквально зависает от флуда. тогда проблема в PTR, их надо отключить. в конфиге это dns: use_private_ptr_resolvers: false clients: runtime_sources: rdns: false

кстати, еще немного оффтопика. в тестах "медленного DNS" я как-то поймал странный баг у винды. встроенная тулза nslookup игнорировала метрику интерфейса, и получалось, что через неё приходили одни ip с одного интерфейса, а всё остальное в ОС согласно метрики получало другие ip с правильного интерфейса. это странное поведение nslookup разрешилось только после перезагрузки ОС.

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

белые списки сложнее делать. нужно sing-box с фильтром региона . иначе всякий торрент трафик может бегать совсем не там где надо. или p2p игрушки тоже... а оборачивать 10тыс. строчек масок ip адресов ру-провайдеров, никакие роутеры не справиться. но при использовании sing-box вы попрощаетесь с TLS1.3 (SNI)

Helby, увы встроенный DNS сервер в Keenetic слабо годится для резольва отдельных доменов через конкретные сервера. решение, только такое, ставить добавочно сторонний днс (напр. adguardhome-go) куданибудь на 153 порт в котором будут прописаны необходимые правила. а в настройках роутера указать только 192.168.1.1:153 в правила маршрутизации жестко прописать ip через тунель. например 8.8.8.8 оставить штатно, а для 8.8.4.4 направлять в тунель. p.s. помните, что у сайтов, есть и доп.домены. узнать какие поможет расширение для браузера IPvFoo, и лучше использовать домены 2го уровня по типу - example.com

а еще, если у клиентов нет статики на localhost 127.0.0.1 (редко, но бывает) то они так-же получают его с 100-200мс, а то и под 300мс задержкой Я не верю, что пишу такое, добавил в конфиг unbound строчки статики для localhost local-zone: "localhost." static local-data: "localhost. 86400 IN A 127.0.0.1" local-data: "localhost. 86400 IN AAAA ::1" но, это не исправит внутренний localhost у роутера. внутри роутера все обращения к домену localhost , будут идти с 100-300 мс задержкой из-за резольва ip 127.0.0.1 Это даже звучит абсурдно, но это так.

я отправил в тех.поддержку свой и ваш скриншоты по localhost'у будет интересно получить очередной ответ, "так и должно быть" и "никаких изменений не ожидается". разрабы такой эпикфейл выкатили в релиз, и в упор не хотят видеть. (нормально, и так сойдет) p.s. если localhost резольвится больше 2мс, это уже проблемы.

ужз. как можно было пропустить в релиз, и не фиксить вот уже с месяц. и откладывать это на 5.1 версию, которая выйдет (если повезет) через полгода. мужики, тут-какбы localhost под 200мс 😲 чесслово, такого я еще не видывал.

вы же понимаете, что много-много где в конфигах как самого роутера, так и entware, прописан адрес localhost и вот каждое обращение к localhost это 100-200мс задержки ...

это какой-то сюр, господа ...

вот в вашем случае, задержки и отключения кэша, от включения DNS правил маршрутизации - похоже нет (ошибка с зависимостью от архитектуры? хмм) А вот так на KN-1012 (ARM64) https://images4.imagebam.com/b8/86/62/ME1AVT1F_o.png https://images4.imagebam.com/51/fb/9e/ME1AVT1K_o.png DNS через "спутниковый интернет" цитирую ответ тех.поддержки на почте: то, что DNS в космос улетает, "это нормально, так и было задумано"

а если сделать это внутри роутера через dig ? возможно у вас так-же стоит неведомый dns кэш-перехват ... dig @127.0.0.1 example.com dig @192.168.97.97 example.com

target-fetch-policy: "3 2 1 0 0" делает проникание не в *.example.com , а в NS записи описание: https://www.reddit.com/r/dns/comments/fkof57/unbound_dns_unclear_setting/ unbound очень хорошая палочка-выручалочка для любых видов DNS-маршрутизации, не только встроенный FQDN. prefetch + serve-expired + target-fetch-policy

а вот тут интересный момент, но без точного анализа. в unbound есть target-fetch-policy: "3 2 1 0 0", и вроде с этой опцией ю... стал маршрутизироваться лучше, без проскакиваний. с этой опцией в FQDN записывается больше субдоменов. можно еще чуть глубже target-fetch-policy: "4 3 2 1 0" (но это только если ARM64)

проблема подтверждается. её можно не видеть, если есть кэш перехват, либо на уровне ОС, либо как я описывал ранее - через unbound

сделал маршрутизацию на 1.0.0.1 через WG, проверил 1.0.0.1 в роутере - оверхед и без кэша 1.0.0.1 на клиенте - значительно меньше чем с роутера, но больше чем с 1.1.1.1 трассировка маршрута от клиента к 1.1.1.1 идёт через провайдера. трассировка маршрута от клиента к 1.0.0.1 идет через WG, как и полагается. FQDN работает, он правильно распределяет трафик. Мне кажется, у вас всеже есть кэш перехват. jinndi попробуйте сделать тест внутри роутера, можно и через dig (он тоже пишет время ответа) dig @127.0.0.1 example.com dig @192.168.1.1 example.com

в настройках (GUI) днс у роутера пробывались варианты: - dot/doh на 1.1.1.1 8.8.8.8 - обычный dns (53) на 1.1.1.1 8.8.8.8 - обычный dns на встроенный 192.168.1.1:153 (с обычным dns 53 на 1.1.1.1 8.8.8.8, с кэшем) - обычный dns на встроенный 192.168.1.1:153 (с обычным dns 53 на 1.1.1.1 8.8.8.8, без кэша) - обычный dns на встроенный 192.168.1.1:153 (с dot/doh на 1.1.1.1 8.8.8.8, с кэшем) - обычный dns на встроенный 192.168.1.1:153 (с dot/doh на 1.1.1.1 8.8.8.8, без кэша) - обычный dns на встроенный 192.168.1.1:153 с записью фейк домена zer0.zub во всех сценариях 1.1.1.1 и 8.8.8.8 маршрутизируются напрямую. без впн, и без внесения их в правила маршрутизации. даже когда KeeneticDNS получал запись от встроенного dnsmasq с фейк записью zer0.zub - не было кэширования - была оверхед задержка - в тоже время, если с клиента обращаться напрямую к 192.168.1.1:153 - все отлично.

кхмм.. решил перепроверится еще раз. ситуация та-же, при наличии правил (даже если они выключены), кэш не работает + оверхед задержка. правила удаляю, оставляя списки - кэш начинает работать, оверхед задержка пропадает. - каких либо настроек KeeneticDNS через CLI - вообще не делались, ни разу. Маршруты DNS - Правила маршрутизации (есть) https://images4.imagebam.com/7f/3f/ba/ME1AVGUT_o.png Маршруты DNS - Правила маршрутизации (отсутствуют) https://images4.imagebam.com/a0/3f/d9/ME1AVGUU_o.png

- если ответы приходят быстро, то кэширование работает. - вы делали "Маршрутизация - Маршруты DNS - Правила маршрутизации" ? (основа проблемы) - вы делали какой либо кэш-перехват, как из моего примера с unbound ?