Назад | Перейти на главную страницу

BIND (сервер пересылки + кэширование) - обслуживать кэширование в случае сбоя пересылки

Я хочу настроить BIND в качестве сервера пересылки DNS, а также использовать кеширование.

Как я могу настроить его для обслуживания кешированных результатов (даже если они превышают TTL) в случае сбоя пересылки?

Этот вопрос уже задавался здесь, но ответа не было - Как заставить BIND возвращать старые кешированные файлы, если все серверы пересылки вышли из строя?

Причина, по которой мне нужно это сделать, - у меня очень плохой интернет-провайдер (и нет лучшей альтернативы в моем районе). Часто все запросы поиска DNS терпят неудачу, я пробовал много бесплатных провайдеров DNS, все они терпят неудачу в течение этого периода. Подключение к Интернету не отключено, только запросы DNS не работают.

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

Использование просроченных данных является действительно сильным запретом в стандартах, поэтому меня бы сильно удивило, возможно ли вообще заставить BIND это делать. Возможно, вы захотите изучить альтернативные преобразователи, более ориентированные на личное использование, или (поскольку это звучит так, как будто ваш интернет-провайдер периодически блокирует трафик на порт 53) попробуйте получить VPN-туннель, и ваш BIND использует его.

Calle правильный, вы не собираетесь заставить BIND нарушить TTL (кроме снижения максимума, который здесь не помогает). Тем не менее, если ваш интернет-провайдер настолько плох, что вы не можете надежно подключиться к серверам пересылки, я не совсем уверен, какой смысл использовать пересылки. быть.

Многие домены предлагают более авторитетные серверы имен, чем количество серверов пересылки, которые обычно в конечном итоге настраиваются (2). Это, в свою очередь, означает больше возможностей для запроса получить ответ в сценарии, когда вы наблюдаете потерю пакетов. Мне кажется, что вы получите больше пользы от выполнения рекурсии самостоятельно, чем от использования конфигурации пересылки.

Вы также можете попробовать более новую версию BIND, которая поддерживает функцию предварительной выборки. В сочетании с выполнением вашей собственной рекурсии сервер автоматически попытается выполнить обновление на всех серверах имен для записи непосредственно перед истечением срока действия записи из кеша. Это происходит только в том случае, если запрос поступает незадолго до истечения срока действия записи, но здесь он все равно может помочь.

предварительная выборка

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

Предварительная выборка определяет "триггерное" значение TTL, при котором будет происходить предварительная выборка текущего запроса: когда во время обработки запроса встречается запись кэша с более низким значением TTL, она будет обновлена. Допустимые значения TTL триггера: от 1 до 10 секунд. Значения больше 10 секунд будут автоматически уменьшены до 10. Установка триггера TTL на ноль (0) приводит к отключению предварительной выборки. По умолчанию TTL триггера равен 2.

Необязательный второй аргумент определяет TTL «приемлемости»: наименьшее исходное значение TTL, которое будет принято для записи, чтобы иметь право на предварительную выборку. TTL соответствия требованиям должен быть как минимум на шесть секунд длиннее TTL триггера; в противном случае named беззвучно отрегулирует его вверх. По умолчанию TTL соответствия равен 9.

ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html

BIND - это DNS-сервер, он соответствует стандартам и правилам TTL. Что вам нужно, так это кеширующий прокси с поддержкой DNS-кеша. Например, Squid с положительным_dns_ttl, установленным на какое-то большое значение, может сработать, или любой другой прокси, который вы предпочитаете.