Модульні уроки (2/3)
Serve-stale and data freshness
Застаріле обслуговування та свіжість даних
Зазвичай розпізнавач оновлює або відхиляє відповідь після закінчення терміну TTL. Serve-stale дозволяє розв’язувачу, якщо він не може оновити дані, тимчасово повертати прострочену відповідь замість негайної помилки. Це як використання резервної копії каталогу, коли центральний офіс недоступний.
Це може покращити доступність, але зменшить актуальність: стара адреса може більше не бути дійсною або безпечною. Резолвер повинен спробувати оновити, обмежити тривалість обслуговування застарілих даних і ретельно обробляти прострочені підписи DNSSEC і чутливі до безпеки записи, такі як DS або TLSA.
Наприклад, якщо орган доступу недоступний, а резолвер має api.example.test → 192.0.2.10, обслуговування цієї застарілої відповіді може підтримувати доступність служби, якщо адреса все ще правильна. Якщо адреса була перепризначена, та сама поведінка може бути небезпечною. Serve-stale — це політика розв’язувача, а не універсальне скасування TTL. Визначте обмеження та стежте за їх використанням.
Посилання: [RFC 8767 — Обслуговування застарілих даних для підвищення стійкості DNS] (https://www.rfc-editor.org/rfc/rfc8767.html)
Перевірте своє розуміння
Виберіть найкращу відповідь. У прикладах використовуються навчальні імена та не надсилаються справжні DNS-запити.
Який компроміс із serve-stale?