Используя BIND9 в качестве сервера кэширования, есть ли способ установить срок действия кэшированных элементов / имен?

Время истечения известно как «TTL» или время жизни. Вы устанавливаете эту переменную в своем файле конфигурации, обычно /etc/bind/db.local или в любом другом файле конфигурации, который вы используете.

TTL указывается в секундах, поэтому установите его на более низкое значение, 60x60 = 3600 в течение часа, например

sudo -e /etc/bind/db.local

. Установите ttl:

$ TTL 3600

и перезапустите привязку.

Для получения дополнительной информации см .:

Как выполнить полную настройку DNS-сервера BIND9 с именем хоста?

и

https://help.ubuntu.com/10.04/serverguide/dns-configuration.html

Каждая запись DNS уже содержит значение Time To Live (TTL), которое указывает количество секунд, в течение которого она может быть кэширована, а запись SOA для зоны содержит TTL для отрицательных результатов.

Всякий раз, когда результат пересылается с DNS, который не является полномочным сервером для зоны, TTL уменьшается на время, когда результат уже был кэширован.

Например, когда я разрешаю google.de:

google.de.              300     IN      A       216.58.205.227

Если я сделаю это снова через десять секунд:

google.de.              290     IN      A       216.58.205.227

Первоначальный TTL записи был, скорее всего, 300 и DNS моего провайдера кэшировал его после того, как я впервые спросил, и вернул мне кэшированный результат на второй итерации.

Итак, время жизни отслеживается для каждой записи.

Когда вы запускаете свой собственный DNS-сервер, у него есть два способа разрешения имен: с помощью сервера пересылки или иерархического поиска.

Когда вы используете сервер пересылки, ваш сервер просто запрашивает другой сервер кэширования и получает кэшированный результат с укороченным TTL, если на другом сервере уже есть копия этой записи. Невозможно определить возраст этой кэшированной записи, только когда она должна истечь.

Когда вы выполняете рекурсивный поиск самостоятельно, вы в значительной степени гарантируете получение свежих результатов за счет необходимости выполнять поиск для каждого компонента пути на пути. Если ваша ссылка имеет большое время приема-передачи (GPRS или спутниковая связь), вполне вероятно, что исходный запрос от приложения истечет до того, как ваш сервер сможет получить результат.

В любом случае вы можете ограничить TTL для кэшированных записей на вашем сервере, используя настройки max-cache-ttl и max-ncache-ttl в BIND.

В настройке сервера пересылки это не сильно поможет, потому что все, что он будет делать, это снова заставит ваш сервер запросить сервер пересылки, который ответит кэшированным значением, если оно все еще допустимо.

В рекурсивной настройке это сократит время, в течение которого ваш сервер кеширует результаты - но все результаты на всех уровнях. Таким образом, по истечении этого времени он выполнит полный рекурсивный запрос.

Как правило, администраторы DNS очень стараются установить адекватные значения TTL для записей, например, я использую 60 секунд для записей, которые я использую, чтобы найти свою домашнюю сеть, в то время как у моих серверов TTL составляет один день. Когда я планирую переместить сервер, я уменьшу его TTL до часа накануне и до пяти минут перед отправкой в ​​центр обработки данных, чтобы вы могли получить разумные TTL из кэшей. Если вы меня угадываете, производительность будет только ухудшаться, поскольку ваш DNS обновляет записи без необходимости. Если некоторые записи часто устарели, это проблема конфигурации на стороне другого человека, а не на вашей стороне.

tl; dr: вы можете, но не должны.