медленный 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 игнорирует.
 

Изменено Четверг в 22:32 пользователем zubzer0