медленный DNS

[zubzer0]

Прошивка 5.0.4. Имеется wg туннель и "Списки доменных имен" для маршрутизации на wg.
днс сервер встроенный, прописан 8.8.8.8, без провайдерского.
при запросах напрямую к 8.8.8.8 ответ в районе 40-50мс.
при запросах через роутер, к времени ответов стабильно прибавляется 100+мс
так-же отсутствует какое-либо кэширование, последующие dnslookup-запросы были отправлены мгновенно после предыдущего.
указанный домен encode.su - вне списка доменых имен для маршрутизации. (аналогичная ситуация и с доменами из списка)
отключение списка доменных имен - не приводит к улучшению. 

используемая утилита - https://github.com/ameshkov/dnslookup

Изменено 1 февраля пользователем zubzer0

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

3 минуты назад, zubzer0 сказал:

Прошивка 5.0.4. Имеется wg туннель и "Списки доменных имен" для маршрутизации на wg.
днс сервер встроенный, прописан 8.8.8.8, без провайдерского.
при запросах напрямую к 8.8.8.8 ответ в районе 40-50мс.
при запросах через роутер, к времени ответов стабильно прибавляется 100мс
так-же отсутствует какое-либо кэширование, последующие запросы были отправлены мгновенно после предыдущего.
указанный домен encode.su - вне списка доменых имен для маршрутизации. (аналогичная ситуация и с доменами из списка)
отключение списка доменных имен - не приводит к улучшению. 

Это скорее всего блокировки. у меня 8-ки вообще не пингуются.

[zubzer0]

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

Это скорее всего блокировки. у меня 8-ки вообще не пингуются.

Маршрутизация к 8.8.8.8 без тунеля. 
напрямую с пк - ответ в районе 40мс, через промежуточный DNS роутера на тотже 8.8.8.8 +100мс задержки.
когда-как должны быть ну максимум +5мс,а не +100мс и то в лучших моментах.

к чему это приводит? если у сайта 10+ доменых имен на коннекте, это может приводить к более +1сек задержки перед началом загрузки страницы. к примеру vkvideo.ru подгружает аж 38(!) доменных имен userapi.com и okcdn.ru

Изменено 1 февраля пользователем zubzer0

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

Только что, zubzer0 сказал:

Маршрутизация к 8.8.8.8 без тунеля. 
напрямую с пк - ответ в районе 40мс, через промежуточный DNS роутера на тотже 8.8.8.8 +100мс задержки.

А у меня с компа не идет без тунеля 10, с тунелем не идет. f c hjenthf 5 -7 

[zubzer0]

аналогичная ситуация с vk.com и dns-yandex 77.88.8.8 (на роутере так-же прописан он, и только он)
роутер стабильно тормозит в DNS'ах

никаких фильтров по вычищению рекламы. только "Списки доменных имен" для маршрутизации на wg, но (повторюсь) их отключение не меняет ситуацию. Использование tcp вместо udp, так-же не меняет ситуацию с задержкой.  



150-200мс ожидания DNS-ответа это ужас! вспоминаются времена спутникового интернета из 00'ых

Изменено 1 февраля пользователем zubzer0

[zubzer0]

результаты пинга полным пакетом и tcp-пинг / http-ping 
используемая утилита https://github.com/pouriyajamshidi/tcping


роутер откликается быстро, но не по части работы встроенного DNS
даже страничка http://192.168.1.1/opkg - загружается через curl быстрее чем прилетают ответы от DNS

Что такого невообразимого пытается делать встроенный dns сервер, что он оказывается медленнее (доп. 100-150мс оверхед) чем встроенный http-сервер с 10-15мс О_о

Изменено 1 февраля пользователем zubzer0

[krass]

А если вернуться на стабильную keenetic os 4.x ? Это решает проблему?

P.S. Сам пока не рискнул переходить на keenetic os 5.x -- подожду год-другой...

Изменено 1 февраля пользователем krass

[zubzer0]

11 минут назад, krass сказал:

А если вернуться на стабильную keenetic os 4.x ? Это решает проблему?

P.S. Сам пока не рискнул переходить на keenetic os 5.x -- подожду год-другой...

Да возможно, но потом. Думаю дождаться ответа по типу, "проблема принята и будет решаться как можно быстрее". 
Если не дождусь, то откачусь на 4 + dnsmasq ipset iptables 

Изменено 1 февраля пользователем zubzer0

[mrGhotius]

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

используемая утилита - https://github.com/ameshkov/dnslookup

А может все-таки с утилитой что-то не так?

Спойлер

А при захвате пакетов не видно таких задержек.

Спойлер

 

[zubzer0]

у меня и Wireshark показывает + 100-150мс
nslookup vk.com 77.88.8.8
nslookup vk.com 192.168.1.1

Изменено 1 февраля пользователем zubzer0

[mrGhotius]

А кто-то из форумчан, может проверить на версии 4.x?

[mrGhotius]

15 минут назад, zubzer0 сказал:

у меня и Wireshark показывает + 100-150мс

На роутере используете DoH/DoT?

[zubzer0]

3 минуты назад, mrGhotius сказал:

На роутере используете DoH/DoT?

при тестах использовался чистый 8.8.8.8 (в 1 посте) и чистый 77.88.8.8
в повседневе использую dot.

[mrGhotius]

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

при тестах использовался чистый 8.8.8.8 (в 1 посте) и чистый 77.88.8.8
в повседневе использую dot.

Это я понял, я имел ввиду в тесте при запросе к 192.168.1.1 DoT/DoH включены? Потому что у меня получается вот так:

Спойлер

 

[zubzer0]

при использовании DoT на роутере 77.88.8.8:853 задержка от днс-роутера скачет 200-300мс
тогда как задержка напрямую к tls://77.88.8.8:853 минуя днс-роутера, около 80-90мс

т.е. в случае использования DoT оверхед тайминг примерно тотже

upd. как и при использовании DOH https://77.88.8.8/dns-query 
роутер стабильно тормозит доп. 100-150мс сверху, вне зависимости от типа обычный/dot/doh

Изменено 1 февраля пользователем zubzer0

[mrGhotius]

5 минут назад, zubzer0 сказал:

при использовании DoT на роутере 77.88.8.8:853 задержка от днс-роутера скачет 200-300мс

тогда как задержка напрямую к tls://77.88.8.8:853 минуя днс-роутера, около 80-90мс

Ну да, забавно. Попробуйте в ТП написать, здесь меньше шансов получить разъяснения.

[zubzer0]

сделал на роутере dnsmasq на 192.168.1.1:153
в dnsmasq прописал address=/zer0.zub/8.8.8.8

в настройках прошивки KeeneticOS указал сервер 192.168.1.1:153
т.е. ссылающийся на dnsmasq внутри себя!

в итоге +100-120мс если обращаться через :53 который обращается к :153
нежели если обращаться к :153 напрямую к dnsmasq

в Wireshark результат тот-же. утилита работает правильно.

Роутер стабильно тормозит DNS на 100+ мс



проверил и в самом роутере
днс стабильно тормозит хоть то 192.168.1.1 хоть 127.0.0.1



170мс !
минимальный трафик, ЦП нагружен 1-3%

Изменено 1 февраля пользователем zubzer0

[dchusovitin]

5 часов назад, zubzer0 сказал:

отключение списка доменных имен - не приводит к улучшению. 

Не могу особо утверждать, но отключение немного странно работало (5.0.3). Убирались правила/маршруты, но наполнение ipset и/или опрос доменов продолжал крутиться в фоне (еще может от галочек зависеть, оба варианта). Надо было удалить правило полностью (список можно оставить), и лучше перезагрузиться.

dns-proxy debug  может помочь в определении, но вывода отладочной информации в журнал там будет много.

 

[zubzer0]

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

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

Да! именно так. Удалил правила, но списки оставил, презагрузился. и только тогда встроенный dns стал работать адекватно! 
После добавления правил к спискам - проблема роста задержки вновь вернулась.
Последующая перезагрузка роутера - не помогает.

Проблема именно там - в наличии правил маршрутизации DNS. 

у меня 7 списков/правил по 30-50 доменов в каждом. дублей нет.
всего 233, все домены второго уровня - example.com
объединение всех доменов в один бОльшой список и одно правило - проблему не решает.

FQDN требует оптимизаций производительности !

Изменено 2 февраля пользователем zubzer0

[zubzer0]

после небольших экспериментов(с перезагрузками), как оказалось в падении производительности - количество не влияет.
хоть 10 доменов, хоть 800 доменов по типу example.com
и так и так будет дополнительные 100+мс оверхеда, вне зависимости состоит ли запрашиваемый домен в списке или нет 

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

Изменено 2 февраля пользователем zubzer0

[zubzer0]

придумал такой костыль-решение:

1. запускаем dnsmasq на 153 порту, который слушает локалку (br0) и loopback (lo)
dns сервер указываем 127.0.0.1 на 53 порту
включаем кэширование на 100 адресов. (не ставьте много, это может привести к потере актуальности записей маршрутизации в FQDN)
отключаем подгрузки каких либо других настроек, кроме этого конфига
вписываем выдуманный домен - для проверки

/opt/etc/dnsmasq.conf

port=153
user=root
group=root
interface=br0
interface=lo
server=127.0.0.1#53
cache-size=100
no-resolv
address=/keen.etic/1.2.3.4

/opt/etc/init.d/S56dnsmasq restart

2. проверяем что dnsmasq работает, напр. через тулзу https://github.com/ameshkov/dnslookup
> dnslookup keen.etic 192.168.1.1:153
вы должны получить 1.2.3.4

3. создаем правило переадресации портов как на картинке:
тем самым переадресуем все входящие 192.168.1.х на 53 порту, в 153 порт внутри роутера, который в свою очередь обращается к 53 порту своего 127.0.0.1
Зачем? Это даст возможность кешировать днс записи, чтобы второе и последующие обращения происходили без этого 100-200мс тормоза.

При этом мы оставляем рабочим и родной DNS и логику FQDN.
Просто слегка бустим/исправляем кэш-перехватом. 



костыль, кэширование должно быть непосредственно в KeenDNS, желательно с доп. настройкой времени хранения (1-1440 мин.)

Изменено 2 февраля пользователем zubzer0

[zubzer0]

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

Ну да, забавно. Попробуйте в ТП написать, здесь меньше шансов получить разъяснения.

Ответ ТП: Да, это нормально, так и было задумано при реализации, что будет работать с некоторой задержкой.

"некоторой" - в районе доп. +100-200мс, где даже http-сервер(KeeneticOS) быстрее  : |

[dchusovitin]

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

Ответ ТП: Да, это нормально, так и было задумано при реализации, что будет работать с некоторой задержкой.

"некоторой" - в районе доп. +100-200мс, где даже http-сервер(KeeneticOS) быстрее  : |

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

Я наблюдал схожее, хоть сразу и не написал. На меньшем кол-ве доменов, и на ultra 1811/1812. Т.е. (возможно) производительность cpu не особо имеет значение. Как будто, где-то очередь, которая разбирается последовательно.
Adguard тоже помогал (за встроенным dns), с включенным optimistic caching (отвечать всегда из кэша) и увеличинным ttl.

[zubzer0]

@dchusovitin  сначала тут был пост-сообщение, где я посоветовал использовать AdGuardHome до KeenDNS.
но спустя некоторое время до меня дошла мысль: что актуальность записи в FQDN может быть утрачена, и при этом AdGuardHome будет отсылать сразу к IP, т.е. с утраченной актуальностью маршрутизации. 

Увы, но кэширование ДО KeenDNS должно быть совсем небольшим (по типу L1 кэша процессора )
Возможно даже 300 записей будет много, хватит и 100 (сообщение поправил).

Если вы используете AdGuardHome с бОльшим кэшированием, то он должен быть исключительно после KeenDNS.
Перед KeenDNS - dnsmasq с маленьким кэшем. И даже в этом случаее может возникнуть момент с потерей актуальности. 

ПК <-> miniCache/dnsmasq <-> KeenDNS/FQDN <-> bigCache/AdGuardHome <-> Интернет

ВАЖНО: Кэширование(miniCache) должно быть встроено в логику FQDN, а так-же проведено улучшение скорости работы.

Изменено 2 февраля пользователем zubzer0

[zubzer0]

Очень важный момент по поводу доменной-маршрутизации:

Если вы используете "Списки доменных имен" (не важно в какой именно её реализации),
то, идеально, чтобы какое либо кэширование ДО механизма распределения маршрутов - должно отсутствовать в принципе.
Иначе возможен момент с потерей актуальности маршрутов. Когда вы используете IP из кэша, который отсутствует в актуальном списке на маршрутизацию, и вы не получаете ту самую маршрутизацию, хотя имеете IP и коннект, но в "маршруте по умолчанию".

1. Кэширование должно быть встроенным в сам "DNS-based routes" . Важный момент, клиенты должны получать max-ttl <=10 минут, но кэш держатся значительно дольше (60мин), и фоново актуализировался при новых запросах. Как вариант вместо 10-60, применить 3-10.

2. Также необходимо реализовать сохранение предыдущего состояния ip-маршрутов в течении времени как минимум равное max-ttl, чтобы клиенты с устаревшими записями DNS - не стучались по "маршруту по умолчанию"

А вот кэширование, реализованное что-до и что-после механизма "DNS-based routes" = это два костыля, один левый и другой правый 😁

Изменено 3 февраля пользователем zubzer0

[zubzer0]

по поводу второго пункта:

почему нужно сохранять старые записи DNS на маршрутизации, пример.
 
- в роутере прописаны 2 и более сервера днс. 8.8.8.8 и 1.1.1.1
- к роутеру подключены 2 и более клиента.

1. первый клиент делает днс-запрос для ютуба
1.1 роутер получает IP от 8.8.8.8 
1.2 первый клиент получает ip и маршрутизацию, время ttl допустим 10минут.

2. спустя минуту второй клиент делает запрос на тот-же ютуб
2.1 роутер получает уже другие IP от 1.1.1.1 
2.2 второй клиент получает другие IP и обновленную маршрутизацию

3.1 первый клиент теряет правильную маршрутизацию.
3.2 первый клиент не видя коннекта, делает запрос к роутеру.
3.3 роутер снова получает IP от 8.8.8.8 и обновляет маршрутизацию

4.1 второй клиент теряет маршрутизацию.
4.2 ...

и так по кругу...

ситуацию изменило бы
1. кэширование: второй клиент получил бы те-же IP, что и первый
2. сохранение записи: если возникает расхождение, первый клиент остается на своей "старой" маршрутизации.

p.s. я крайне надеюсь, что разработчики "FQDN / DNS-based routes" прочитают это.
в этом и кроется проблема с периодическим хождением трафика не в ту дверь интерфейс.
(особенно часто, это случается с ютубом и пр. крупными cdn-порталами)

 

Спойлер

как я вижу временное/костыльное решение:

пк - dnsmasq - KeenDNS - AdGuardHome - Internet
или
пк - dnsmasq - KeenDNS - Internet

dnsmasq:
cache-size=1000
min-cache-ttl=600
max-cache-ttl=600
max-ttl=60

AdGuardHome:
оптимистическое кеширование обязательно откл.
cache_ttl_min: 600
cache_ttl_max: 3600

в итоге, каждые 60сек происходит запрос от клиентов к dnsmasq для обновления dns записей.
dnsmaq обновляет свои кэши с периодом 10мин от KeenDNS
KeenDNS берет из Интернета или кэша AdGuardHome (с оверхедом +100-150мс)
AdGuardHome обновляет свои кэши с периодом 10-60мин.

когда второй клиент сделает запрос, он либо получит из кэша dnsmasq, либо чуть дольше (+150-200мс) из кэша AdGuardHome (или внешнего днс). И в обоих вариантах IP уже будет в записи маршрутизации.

в случае если от AdGuardHome (или внешнего днс) придут новые IP после запроса второго клиента, то у первого клиента будет 60сек(или менее) чтобы обновить свои записи и продолжить новую "DNS-based routes" маршрутизацию.

Эти 60сек неправильной маршрутизации можно избежать если-бы KeenDNS умел временно сохранять старый маршрут.
Если убрать dnsmasq с подменой TTL, то клиенты могут дОлго просидеть на уже не маршрутизируемых IP, до тех пор пока не обновят свои записи. dnsmaq в данном случае "решает" две задачи - держит клиентов в актуальности и дает быстрый ответ(из 10мин кэша)

за счет кэша AdGuardHome - минимизируется вариант события частой смены IP на FQDN

 

Изменено 3 февраля пользователем zubzer0

[avn]

5 часов назад, zubzer0 сказал:

по поводу второго пункта:

почему нужно сохранять старые записи DNS на маршрутизации, пример.
 
- в роутере прописаны 2 и более сервера днс. 8.8.8.8 и 1.1.1.1
- к роутеру подключены 2 и более клиента.

1. первый клиент делает днс-запрос для ютуба
1.1 роутер получает IP от 8.8.8.8 
1.2 первый клиент получает ip и маршрутизацию, время ttl допустим 10минут.

2. спустя минуту второй клиент делает запрос на тот-же ютуб
2.1 роутер получает уже другие IP от 1.1.1.1 
2.2 второй клиент получает другие IP и обновленную маршрутизацию

3.1 первый клиент теряет правильную маршрутизацию.
3.2 первый клиент не видя коннекта, делает запрос к роутеру.
3.3 роутер снова получает IP от 8.8.8.8 и обновляет маршрутизацию

4.1 второй клиент теряет маршрутизацию.
4.2 ...

и так по кругу...

ситуацию изменило бы
1. кэширование: второй клиент получил бы те-же IP, что и первый
2. сохранение записи: если возникает расхождение, первый клиент остается на своей "старой" маршрутизации.

p.s. я крайне надеюсь, что разработчики "FQDN / DNS-based routes" прочитают это.
в этом и кроется проблема с периодическим хождением трафика не в ту дверь интерфейс.
(особенно часто, это случается с ютубом и пр. крупными cdn-порталами)

 

  Показать контент

как я вижу временное/костыльное решение:

пк - dnsmasq - KeenDNS - AdGuardHome - Internet
или
пк - dnsmasq - KeenDNS - Internet

dnsmasq:
cache-size=1000
min-cache-ttl=600
max-cache-ttl=600
max-ttl=60

AdGuardHome:
оптимистическое кеширование обязательно откл.
cache_ttl_min: 600
cache_ttl_max: 3600

в итоге, каждые 60сек происходит запрос от клиентов к dnsmasq для обновления dns записей.
dnsmaq обновляет свои кэши с периодом 10мин от KeenDNS
KeenDNS берет из Интернета или кэша AdGuardHome (с оверхедом +100-150мс)
AdGuardHome обновляет свои кэши с периодом 10-60мин.

когда второй клиент сделает запрос, он либо получит из кэша dnsmasq, либо чуть дольше (+150-200мс) из кэша AdGuardHome (или внешнего днс). И в обоих вариантах IP уже будет в записи маршрутизации.

в случае если от AdGuardHome (или внешнего днс) придут новые IP после запроса второго клиента, то у первого клиента будет 60сек(или менее) чтобы обновить свои записи и продолжить новую "DNS-based routes" маршрутизацию.

Эти 60сек неправильной маршрутизации можно избежать если-бы KeenDNS умел временно сохранять старый маршрут.
Если убрать dnsmasq с подменой TTL, то клиенты могут дОлго просидеть на уже не маршрутизируемых IP, до тех пор пока не обновят свои записи. dnsmaq в данном случае "решает" две задачи - держит клиентов в актуальности и дает быстрый ответ(из 10мин кэша)

за счет кэша AdGuardHome - минимизируется вариант события частой смены IP на FQDN

 

Открою секрет, старые записи на маршрутизацию никуда не исчезают, они хранятся в ipset.

[zubzer0]

погонял я методику быстрого кэша dnsmasq спереди
и длинного кэша у AdGuardHome позади (оптимистик офф)
с параметрами из пред.поста.

увы, но именно youtube всеравно периодически слетает/не прописывается у "DNS-based routes"
какие-то там видимо "особенные" днс-записи которые keenetic игнорирует.
 

Изменено 5 февраля пользователем zubzer0

[zubzer0]

удалось снизить влияние оверхед задержки FQDN 150-200мс только таким способом:

клиенты - unbound - KeneeticDNS(FQDN) - adguardhome-go - интернет

1. Настройка AGH-go
- указываем bind_hosts 192.168.1.1 и port 253
- Быстрый IP - off (т.к. AGH находится после FQDN)
- кэш и оптимистический - строго off 
- размер кэша - 0
- TTL min / max = 900 / 86400
- TTL заблокированного = 900

2. Настройка KeneeticDNS:
- прописываем днс сервер - 192.168.1.1:253 (AGH)
- делаем правило перенаправления (перехвата) 53->153 (для unbound)
https://images4.imagebam.com/6f/ba/ab/ME1AT36A_o.png
(плюсом: данным правилом клиенты не смогут обратится к любым другим DNS на 53 порту, заставляя клиентов использовать только 192.168.1.1, и пресекая утечки мимо FQDN, [исключение: doh/dot] )


3. Настройка unbound (для ARM64 2ядра):
- включен обычный кэш
- включен prefetch кэш, который фоново обновляет записи за 10% перед истечением TTL
- включен "оптимистический кэш" на 3ч, который отдает ответы с TTL 10сек, в это время фоново обновляя просроченные записи.

- в случае если у AGH будет включено кэширование, то фоновые записи из 10%-prefetch будут обновляться из старого кэша AGH (это плохо)

- opkg install unbound-daemon unbound-checkconf
- /opt/etc/unbound/unbound.conf

Спойлер

server:
    # --- Сетевые настройки ---
    interface: 127.0.0.1
    interface: 192.168.1.1
    port: 153

    do-ip6: no
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.1/32 allow
    access-control: 192.168.1.0/24 allow

    # --- Кэширование ---
    prefetch: yes
    cache-min-ttl: 900
    cache-max-ttl: 86400
    msg-cache-size: 16m
    rrset-cache-size: 32m
    neg-cache-size: 8m
    # --- Оптимистическое 3ч по 10сек
    serve-expired: yes
    serve-expired-ttl: 10800
    serve-expired-reply-ttl: 10
    serve-expired-client-timeout: 0
    serve-expired-ttl-reset: no

    # --- Тюнинг ARM64 ---
    num-threads: 2
    msg-cache-slabs: 2
    rrset-cache-slabs: 2
    infra-cache-slabs: 2
    so-rcvbuf: 2m
    so-sndbuf: 2m
    so-reuseport: yes
    edns-buffer-size: 1232

    # --- Емкость, балансировка, глубина --- 
    qname-minimisation: no
    minimal-responses: no
    rrset-roundrobin: no
    target-fetch-policy: "3 2 1 0 0"

    # --- DNSSEC отключён ---
    module-config: "iterator"
    do-not-query-localhost: no

    # --- Логирование (тишина) ---
    chroot: ""
    directory: "/opt/etc/unbound"
    username: ""
    verbosity: 0
    val-log-level: 0
    log-queries: no
    log-replies: no
    use-syslog: no

    # --- Локальная запись для localhost ---
    local-zone: "localhost." static
    local-data: "localhost. 86400 IN A 127.0.0.1"
    local-data: "localhost. 86400 IN AAAA ::1"

# Основной forward 
forward-zone:
    name: "."
    forward-addr: 127.0.0.1@53

Сделайте проверку !!
unbound-checkconf /opt/etc/unbound/unbound.conf

/opt/etc/init.d/S61unbound start
 

На клиенте, был сделан фоновый скрипт с dnsproxy, который логирует скорость ответа от сервера 192.168.1.1
и в течении 3 дней сбора статистики, на прямом KeeneticDNS, было установлено, что средняя задержка ответов около 180мс !!
Тогда-как на вышестоящем AGH, который отдавал ответы встроенному KeeneticDNS, "среднее время обработки запроса" была всего 20мс.
После применения этого "днс-бутерброда", удалось снизить среднюю задержку, на клиенте, на минус 150мс. Сделав её равной около ~30мс. 
 

Изменено Вторник в 21:40 пользователем zubzer0

[Buba]

Столкнулся с тем же самым! Прошивка 5.0.4
Решил попробовать работу "Маршруты DNS", но всегда использую свой Adguard Home с DoT (они быстрее DoH), прикладываю скрин времени ответа, всегда до 20 мс.

Спойлер

Переключился на DNS в Keenetic, чтобы заработали "Маршруты DNS" и уронил челюсть, время ответа стало 200-300 мс, что?!
При этом в Keenetic использую такие же DoT адреса.

В 20.02.2026 в 20:18, zubzer0 сказал:

удалось снизить влияние оверхед задержки FQDN 150-200мс только таким способом:

клиенты - unbound - KeneeticDNS(FQDN) - adguardhome-go - интернет

Правильно понимаю, что это со включенной работой "Маршруты DNS"?
Если да, то аргумент техподдержки, что "так задумано для маршрутов" выглядит так себе, тоже написал им, а потом нашёл тут тему.
Сначала подумал, что не уж то из-за "Маршруты DNS" столько набегает, ну не может же поиск домена в списках и маркировка пакетов так много занимать, ну максимум 10 мс, но не 200 мс же.

Вы проделали колоссальную работу, хоть не мне одному это показалось странным, а то сайты грузить начало секундами...это явно баг.
Рано автор KVAS-а отправил на пенсию, в строю ещё побудет.

Изменено Понедельник в 01:21 пользователем Buba

[avn]

6 часов назад, Buba сказал:

Столкнулся с тем же самым! Прошивка 5.0.4
Решил попробовать работу "Маршруты DNS", но всегда использую свой Adguard Home с DoT (они быстрее DoH), прикладываю скрин времени ответа, всегда до 20 мс.

  Скрыть контент

Переключился на DNS в Keenetic, чтобы заработали "Маршруты DNS" и уронил челюсть, время ответа стало 200-300 мс, что?!
При этом в Keenetic использую такие же DoT адреса.

Правильно понимаю, что это со включенной работой "Маршруты DNS"?
Если да, то аргумент техподдержки, что "так задумано для маршрутов" выглядит так себе, тоже написал им, а потом нашёл тут тему.
Сначала подумал, что не уж то из-за "Маршруты DNS" столько набегает, ну не может же поиск домена в списках и маркировка пакетов так много занимать, ну максимум 10 мс, но не 200 мс же.

Вы проделали колоссальную работу, хоть не мне одному это показалось странным, а то сайты грузить начало секундами...это явно баг.
Рано автор KVAS-а отправил на пенсию, в строю ещё побудет.

Ну так в чем проблема, используйте adh, и маршрутизация keenetic, Но не используйте dns- кеенетик.  В поиск, adh+ioset.

Изменено Понедельник в 07:51 пользователем avn