Если 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)»:
NXDOMAINNXDOMAIN, в ответ будет SOA запись, которая будет содержать NXDOMAIN TTL (традиционно известный как 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 НЕ Кэшировал SERVFAIL вообще, если вышеуказанный коммит и документация о первом введении в 9.9.6-S1 следует верить.
В последней версии BIND по умолчанию servfail-ttl является 1s, и настройка жестко запрограммирована до потолка 30s (вместо установленного RFC потолка 300s). 90174e6 (2015-10-17)
Кроме того, следующие цитаты заслуживают внимания:
Результат кэширования ответов SERVFAIL включал некоторые ситуации, когда было замечено, что это вредно для взаимодействия с клиентом, особенно когда причины представления SERVFAIL клиенту были временными и из-за сценария, в котором немедленная повторная попытка запроса будет более подходящее действие.
Вторая тактика состоит в том, чтобы утверждать, что широко распространенные DNS-клиенты будут делать что-то особенно опасное, когда не смогут связаться со всеми DNS-серверами. Проблема с этим аргументом в том, что это утверждение ложно. Любой такой клиент явно глючит и не сможет выжить на рынке: подумайте, что произойдет, если маршрутизаторы клиента ненадолго выйдут из строя или если сеть клиента временно затоплена.
Таким образом, NXDOMAIN ответ будет кэшироваться, как указано в SOA соответствующей зоны, тогда как SERVFAIL вряд ли будет кэшироваться, или, в случае кеширования, это будет самое большее двузначное число секунд.
Этой теме посвящен RFC: RFC 2308 - отрицательное кэширование DNS-запросов (DNS NCACHE).
Соответствующий раздел для чтения: 5 - Кеширование отрицательных ответов в котором говорится:
Как и обычные ответы, отрицательные ответы имеют время жить (TTL). Поскольку в разделе ответов нет записи, к которой можно применить этот TTL, TTL должен передаваться другим методом. Это делается путем включения записи SOA из зоны в раздел полномочий ответа. Когда авторитетный сервер создает эту запись, его TTL берется из минимального значения поля SOA.MINIMUM и TTL SOA. Этот TTL уменьшается аналогично нормальному кэшированному ответу и по достижении нуля (0) указывает, что кешированный отрицательный ответ НЕ ДОЛЖЕН использоваться снова.
Во-первых, давайте определим SOA.MINIMUM и SOA TTL, описанный в 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 секунд. Значение TTL SOA 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 300 ниже, чем SOA TTL 21600. Поэтому сервер Google должен использовать меньшее значение в AUTHORITY SECTION Запись SOA при возврате NXDOMAIN ответ:
$ 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 был запрошен.
В своем тестировании я также заметил, что некоторые рекурсивные (кеширующие) преобразователи не возвращают 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 ответы.
Глоссарий: