Если DNS-сервер ищет запись, и она отсутствует, он часто «отрицательно кеширует» тот факт, что эта запись отсутствует, и не пытается искать ее снова некоторое время. Я не вижу в RFC ничего о том, что TTL об отрицательном кешировании должен быть, поэтому я предполагаю, что это несколько произвольно. В реальном мире, как долго эти негативные записи держатся?

TTL для отрицательного кэширования не является произвольным. Он берется из записи SOA в верхней части зоны, к которой принадлежит запрошенная запись, если бы она существовала. Например:

example.org.    IN      SOA     master-ns1.example.org. Hostmaster.example.org. (
            2012091201 43200 1800 1209600 86400 )

Последнее значение в записи SOA («86400») - это время, в течение которого клиенты просят кешировать отрицательные результаты example.org..

Если клиент запрашивает doesnotexist.example.org., он кеширует результат в течение 86400 секунд.

Это зависит от вашего точного определения «отрицательного запроса», но в любом случае это описано в rfc2308 «Отрицательное кэширование DNS-запросов (DNS NCACHE)» :

NXDOMAIN

• Если разрешение выполнено успешно и в результате NXDOMAINполучен ответ с SOAзаписью, которая будет содержать NXDOMAINTTL (традиционно известный как MINIMUMполе). rfc2308#section-4

SERVFAIL

• Если разрешение не является успешным и приводит к тайм-ауту ( 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)

  Кроме того, ниже приведены некоторые заслуживающие внимания цитаты по этому вопросу:

  • https://kb.isc.org/article/AA-01178/ (2014 / 2016-01-07)

  Результат кэширования ответов SERVFAIL включал в себя некоторые ситуации, в которых он был признан вредным для клиента, особенно когда причины представления SERVFAIL клиенту были временными и из сценария, в котором немедленная повторная попытка запроса была бы более подходящее действие.

  • http://cr.yp.to/djbdns/third-party.html (2003-01-11)

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

Таким образом, NXDOMAINответ будет кэшироваться, как указано в SOAсоответствующей зоне, в то время SERVFAILкак маловероятно, что он будет кэширован, или, если он будет кэширован, он будет не более двухзначного числа секунд.

Существует RFC, посвященный этой теме: RFC 2308 - Отрицательное кэширование DNS-запросов (DNS NCACHE) .

Соответствующий раздел для чтения - 5 - Кэширование отрицательных ответов, в котором говорится:

Как и обычные ответы, отрицательные ответы имеют время жить (TTL). Поскольку в разделе ответов нет записи, к которой может быть применен этот TTL, TTL должен переноситься другим методом. Это делается путем включения записи SOA из зоны в раздел полномочий в ответе. Когда авторитетный сервер создает эту запись, его TTL берется из минимума поля SOA.MINIMUM и TTL SOA. Этот TTL уменьшается аналогично обычному кэшированному ответу и при достижении нуля (0) указывает, что кэшированный отрицательный ответ НЕ ДОЛЖЕН использоваться снова.

Во-первых, давайте определим SOA.MINIMUMTTL и SOA, описанные в RFC. TTL - это число перед типом записи IN( 900секунды в приведенном ниже примере). В то время как минимум является последним полем в записи ( 86400секунды в примере ниже).

$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com.    900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

Теперь давайте посмотрим на некоторые примеры, serverfault.comзона является иллюстративной, поскольку она имеет авторитетные серверы от двух разных провайдеров, которые настроены по-разному.

Давайте найдем авторитетные серверы имен для serverfault.comзоны:

$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.

Затем проверьте запись SOA с помощью сервера имен aws:

$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Отсюда видно, что TTL записи SOA составляет 900секунды, а отрицательное значение TTL - 86400секунды. Значение SOA TTL 900ниже, поэтому мы ожидаем, что это значение будет использовано.

Теперь, если мы запросим у авторитетного сервера несуществующий домен, мы должны получить ответ без ответа и с записью SOA в разделе полномочий:

$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE  rcvd: 135

Когда рекурсивный (кэширующий) распознаватель получает этот ответ, он анализирует запись SOA в AUTHORITY SECTIONи использует TTL этой записи, чтобы определить, как долго он должен кэшировать отрицательный результат (в этом случае, 900секунды).

Теперь давайте выполните ту же процедуру с сервером имен Google:

$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    21600   IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

Вы можете видеть, что серверы имен Google имеют разные значения как для SOA TTL, так и для отрицательных значений TTL. В этом случае отрицательный TTL of 300ниже, чем SOA TTL of 21600. Поэтому AUTHORITY SECTIONпри возврате NXDOMAINответа сервер Google должен использовать нижнее значение в записи SOA :

$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE  rcvd: 143

Как и ожидалось, TTL записи SOA в NXDOMAINответе составляет 300секунды.

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

В моем тестировании я также заметил, что некоторые рекурсивные (кэширующие) преобразователи не возвращают a AUTHORITY SECTIONс записью SOA с уменьшением TTL для последующих запросов, тогда как другие это делают.

Например, распознаватель облачных вспышек делает (обратите внимание на уменьшающееся значение TTL):

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

В то время как распознаватель по умолчанию в AWS VPC ответит разделом полномочий только на первый запрос:

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

Примечание. В этом ответе рассматривается поведение NXDOMAINответов.

Глоссарий:

• зона
• SOA
• TTL
• Рекурсивный NameServer
• Авторитетный Nameserver