arhead Опубликовано 18 декабря, 2018 · Жалоба И резолвер и для обратной зоны. Или просто поставить Bind поновее? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
guеst Опубликовано 19 декабря, 2018 · Жалоба как вам выше правильно советовали уже, пора разделять. Резольвер отдельно, авторитативные функции отдельно. Например для резольвера unbound, для зон оставить bind если он вам роднее, или (как выше же советовали nsd).... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 19 декабря, 2018 · Жалоба On 12/18/2018 at 5:47 AM, guеst said: forward-zone: name: "." forward-addr: xxx.19.128.2 forward-addr: xxx.1.172.2 forward-addr: xxx.10.128.1 forward-first: yes Это то зачем???? Unbound может все делать сам без помощников. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
guеst Опубликовано 20 декабря, 2018 · Жалоба 8 часов назад, Telesis сказал: Это то зачем???? Unbound может все делать сам без помощников. это у меня за тем, что я не провайдер, а из кровавого энтерпрайза... и мне надо использовать вышестоящие (провайдерские) резольверы, т.к. там они фильтруют по блокировкам РКН Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 25 декабря, 2018 (изменено) · Жалоба On 12/20/2018 at 3:48 AM, guеst said: это у меня за тем, что я не провайдер, а из кровавого энтерпрайза... и мне надо использовать вышестоящие (провайдерские) резольверы, т.к. там они фильтруют по блокировкам РКН это должны делать для тебя и без ДНС. Изменено 25 декабря, 2018 пользователем Telesis Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 27 декабря, 2018 · Жалоба Есть проблема в связке bind+unbound, при обновлении своих зон (например, PTR) на bind и выполнения rndc reload, до unbound это долетает как бы мягко говоря "не быстро", попробовал выставить cache-min-ttl: 0 но не особо помогло. Очень долго unbound отвечает NXDOMAIN об обновлённой записи. И ещё заметил что unbound на Debian (Version 1.4.22) и FreeBSD (unbound Version 1.8.0) отвечает по разному в Query time при первом запросе не из кеша, у последнего Query time: ~ 100-200 msec, конфиги и ресурсы примерно одинаковые. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boco Опубликовано 28 декабря, 2018 · Жалоба 11 часов назад, hsvt сказал: при обновлении своих зон (например, PTR) на bind и выполнения rndc reload, до unbound это долетает как бы мягко говоря "не быстро", попробовал выставить cache-min-ttl: 0 но не особо помогло. Очень долго unbound отвечает NXDOMAIN об обновлённой записи. cache-max-ttl, cache-max-negative-ttl Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 28 декабря, 2018 · Жалоба 9 часов назад, boco сказал: cache-max-ttl, cache-max-negative-ttl # the time to live (TTL) value lower bound, in seconds. Default 0. # If more than an hour could easily give trouble due to stale data. cache-min-ttl: 0 # the time to live (TTL) value cap for RRsets and messages in the # cache. Items are not cached for longer. In seconds. cache-max-ttl: 86400 # the time to live (TTL) value cap for negative responses in the cache # cache-max-negative-ttl: 3600 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 29 декабря, 2018 · Жалоба On 12/27/2018 at 4:42 PM, hsvt said: И ещё заметил что unbound на Debian (Version 1.4.22) и FreeBSD (unbound Version 1.8.0) отвечает по разному в Query time при первом запросе не из кеша, у последнего Query time: ~ 100-200 msec, конфиги и ресурсы примерно одинаковые. С каждой новой версией стало немного тупить. Вроде как с ветки 1.5, стал это замечать. Попробуйте вот с такими настройками. module-config: "iterator" minimal-responses: yes On 12/27/2018 at 4:42 PM, hsvt said: на bind и выполнения rndc reload На Unbound просто очистите кеш для этой зоны. unbound-control flush_zone ИМЯ_ЗОНЫ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 29 декабря, 2018 · Жалоба Для ускорения создайте в unbound.conf forward-zone: name: "company.example.ru." forward-addr: IP-АДРЕС-BIND Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 2 января, 2019 (изменено) · Жалоба В 29.12.2018 в 12:33, Telesis сказал: С каждой новой версией стало немного тупить. Вроде как с ветки 1.5, стал это замечать. Попробуйте вот с такими настройками. module-config: "iterator" minimal-responses: yes На Unbound просто очистите кеш для этой зоны. unbound-control flush_zone ИМЯ_ЗОНЫ Спасибо вам, попробую. В 29.12.2018 в 12:47, Telesis сказал: Для ускорения создайте в unbound.conf forward-zone: name: "company.example.ru." forward-addr: IP-АДРЕС-BIND Ну оно примерно так и сделано, только не forward, а stub и по tcpdump видно, как при запросах на эти зоны unbound лезет спрашивать у бинд. Видимо всё таки ещё большой TTL у зоны. stub-zone: name: "1.1.1.in-addr.arpa." stub-addr: IP-АДРЕС-BIND_MASTER stub-addr: IP-АДРЕС-BIND_SLAVE stub-zone: name: "company.example.ru." stub-addr: IP-АДРЕС-BIND_MASTER stub-addr: IP-АДРЕС-BIND_SLAVE Изменено 2 января, 2019 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...