Т.е. при 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 не тот
да и в целом по ртт смотреть не всегда хорошо, так как есть ещё скорость работы самого приложения и у тех же гуглов что-то самописное на реактивном топливе в этом плане
не грузить нат, не напарываться на лимит по ипу
Вы должны войти