Якщо сервер 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-рекурсив НЕ ВІДКЕШУВАТ кеш 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.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секунди.

Наведений вище приклад також демонструє, як легко отримати різні відповіді на один і той же запит. Відповідь, яку закінчує використання окремого розв'язувача кешування, - це відповідь на запит авторитетного намсервера.

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

Наприклад, використовується резолюція cloudflare (зверніть увагу на декрементирующее значення 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
• Авторитетний сервер імен