Если DNS-сервер ищет запись, и она отсутствует, он часто «отрицательно кеширует» тот факт, что эта запись отсутствует, и не пытается искать ее снова некоторое время. Я не вижу в RFC ничего о том, что TTL об отрицательном кешировании должен быть, поэтому я предполагаю, что это несколько произвольно. В реальном мире, как долго эти негативные записи держатся?
domain-name-system
Leopd
источник
источник
Ответы:
TTL для отрицательного кэширования не является произвольным. Он берется из записи SOA в верхней части зоны, к которой принадлежит запрошенная запись, если бы она существовала. Например:
Последнее значение в записи SOA («86400») - это время, в течение которого клиенты просят кешировать отрицательные результаты
example.org..Если клиент запрашивает
doesnotexist.example.org., он кеширует результат в течение 86400 секунд.источник
MIN(SOA TTL, SOA.MINIMUM), а не простоSOA.MINIMUM. (См. Tools.ietf.org/html/rfc2308#section-5 )Это зависит от вашего точного определения «отрицательного запроса», но в любом случае это описано в rfc2308 «Отрицательное кэширование DNS-запросов (DNS NCACHE)» :
NXDOMAINNXDOMAINполучен ответ сSOAзаписью, которая будет содержатьNXDOMAINTTL (традиционно известный какMINIMUMполе).rfc2308#section-4SERVFAILЕсли разрешение не является успешным и приводит к тайм-ауту (
SERVFAIL) , то оно также может вообще не кэшироваться и при любых обстоятельствах НЕ ДОЛЖНО кэшироваться дольше 5 минут.rfc2308#section-7.1Обратите внимание, что на практике кэширование таких результатов в течение полных допустимых 5 минут является отличным способом уменьшить возможности клиента, если его сервер кэширования иногда испытывает кратковременные проблемы с подключением (и эффективно делает его легко уязвимым для усиления отказа в обслуживании, где несколько секунд простоя приведут к отключению определенных частей DNS в течение пяти полных минут).
До BIND 9.9.6-S1 (выпущенного в 2014 году), по-видимому,
SERVFAILвообще не кэшировался.a878301(2014-09-04)Например, во время Вашего вопроса и во всех версиях BIND выпущен до 2014 года BIND распознаватель DID NOT кэш
SERVFAILвообще, если выше фиксации и документации о первом введении в 9.9.6-S1 можно верить ,В последнем BIND, по умолчанию
servfail-ttlэто1s, и установка зашита на потолок30s(вместо RFC санкционированного потолка300s).90174e6(2015-10-17)Кроме того, ниже приведены некоторые заслуживающие внимания цитаты по этому вопросу:
Таким образом,
NXDOMAINответ будет кэшироваться, как указано вSOAсоответствующей зоне, в то времяSERVFAILкак маловероятно, что он будет кэширован, или, если он будет кэширован, он будет не более двухзначного числа секунд.источник
Существует RFC, посвященный этой теме: RFC 2308 - Отрицательное кэширование DNS-запросов (DNS NCACHE) .
Соответствующий раздел для чтения - 5 - Кэширование отрицательных ответов, в котором говорится:
Во-первых, давайте определим
SOA.MINIMUMTTL и SOA, описанные в RFC. TTL - это число перед типом записиIN(900секунды в приведенном ниже примере). В то время как минимум является последним полем в записи (86400секунды в примере ниже).Теперь давайте посмотрим на некоторые примеры,
serverfault.comзона является иллюстративной, поскольку она имеет авторитетные серверы от двух разных провайдеров, которые настроены по-разному.Давайте найдем авторитетные серверы имен для
serverfault.comзоны:Затем проверьте запись SOA с помощью сервера имен aws:
Отсюда видно, что TTL записи SOA составляет
900секунды, а отрицательное значение TTL -86400секунды. Значение SOA TTL900ниже, поэтому мы ожидаем, что это значение будет использовано.Теперь, если мы запросим у авторитетного сервера несуществующий домен, мы должны получить ответ без ответа и с записью SOA в разделе полномочий:
Когда рекурсивный (кэширующий) распознаватель получает этот ответ, он анализирует запись SOA в
AUTHORITY SECTIONи использует TTL этой записи, чтобы определить, как долго он должен кэшировать отрицательный результат (в этом случае,900секунды).Теперь давайте выполните ту же процедуру с сервером имен Google:
Вы можете видеть, что серверы имен Google имеют разные значения как для SOA TTL, так и для отрицательных значений TTL. В этом случае отрицательный TTL of
300ниже, чем SOA TTL of21600. ПоэтомуAUTHORITY SECTIONпри возвратеNXDOMAINответа сервер Google должен использовать нижнее значение в записи SOA :Как и ожидалось, TTL записи SOA в
NXDOMAINответе составляет300секунды.Приведенный выше пример также демонстрирует, как легко получить разные ответы на один и тот же запрос. Ответ, который в конечном итоге использует отдельный распознаватель кэширования, заключается в том, какой авторитетный namserver был запрошен.
В моем тестировании я также заметил, что некоторые рекурсивные (кэширующие) преобразователи не возвращают a
AUTHORITY SECTIONс записью SOA с уменьшением TTL для последующих запросов, тогда как другие это делают.Например, распознаватель облачных вспышек делает (обратите внимание на уменьшающееся значение TTL):
В то время как распознаватель по умолчанию в AWS VPC ответит разделом полномочий только на первый запрос:
Примечание. В этом ответе рассматривается поведение
NXDOMAINответов.Глоссарий:
источник