Тобто з кешем в 10Gb в оперативці, маємо ще 10Gb кеша на жорсткому диску.
Потрібно це для того, щоб після рестарту можна було віддавати дані з кешу, а не знов їх отримувати з інших серверів.
Беручи до уваги, що рестарти доволі рідко бувають для резолвера (ще не було жодного за рік), то сенсу тримати дисковий кеш я не бачу.
Вимкнути дисковий кеш в knot-resolver я не зміг.
Довелось зменшити кеш в оперативній пам'яті й змонтувати дисковий кеш в оперативку.
~]# cat /etc/fstab |grep knot-resolver
tmpfs /var/cache/knot-resolver tmpfs rw,size=5G,uid=knot-resolver,gid=knot-resolver,nosuid,nodev,noexec,mode=0700 0 0
~]# cat /etc/knot-resolver/kresd.conf|grep cache.size
-- Refer to manual for optimal cache size
cache.size = 4990 * MB
~]# systemctl stop kresd@1
~]# mount /var/cache/knot-resolver
~]# systemctl start kresd@1
Кеш оперативки в конфіг файлі має бути меншим за змонтований розділ.
свой днс отдает зоны еще свои внутрь
пинг хоста дает
1.1.1.1 => 11ms
8.8.8.8 => 25ms
свой хост => 0.2ms
По идее с кеша будет отдавать очень быстро, поэтому локально будет быстрее, чем гнать пользователей на другие.
namebench выдает такое
Если есть провайдер - обязательно используем собственный резолвер для пользователей.
Да, решения от Google и Cloudflare популярны, но вот "отдебажить" проблему никак не получится в случае ее возникновения. Что "под капотом" - не узнать, поскольку это сторонний сервис. И вероятность срабатывания ограничений на количество запросов всегда будет "неизвестным".
и что ты там дебажижшь?
лимиты per ip
чаще приходится дебажить свой собственный резолвер которому сто лет в обед и никто его не обновляет
то dnssec отвалится, то udp size не тот
да и в целом по ртт смотреть не всегда хорошо, так как есть ещё скорость работы самого приложения и у тех же гуглов что-то самописное на реактивном топливе в этом плане
не грузить нат, не напарываться на лимит по ипу
Ви маєте увійти під своїм обліковим записом