Що таке DNS-кеш і скільки в ньому живуть записи?

Де насправді кешується DNS-відповідь?

Один пошук проходить через кілька кешів, перш ніж ви щось помітите, і кожен тримає власну копію протягом власного часу:

• Браузер. Chrome, Edge і Firefox кожен тримає невеликий власний DNS-кеш, окремий від системного. Кеш Chrome видно на chrome://net-internals/#dns, і його очищення стосується лише цього браузера, а не решти машини.
• Стаб-резолвер ОС. Windows виконує службу DNS Client і кешує відповіді, які можна переглянути командою ipconfig /displaydns; macOS кешує через mDNSResponder; більшість Linux-стільниць запускають systemd-resolved, локальний кешувальний стаб-резолвер, до якого звертаються через resolvectl. Це справжній кеш із власним відліком TTL, а не просто копія того, що є в браузері.
• Роутер. Більшість домашніх роутерів запускають невеликий DNS-форвардер, який відповідає з власного кеша, перш ніж передати запит далі, тому перезавантаження роутера іноді вирішує проблему з DNS, що насправді була десь-інде.
• Рекурсивний резолвер. Резолвер вашого провайдера, або публічний резолвер, обробляє більшість пошуків в інтернеті й тримає найбільший і найбільш спільний кеш. Щойно він отримав відповідь, кожен пристрій, що його питає, отримує кешовану копію, поки вона не спливе.

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

Що таке TTL, і хто насправді його дотримується?

Кожен DNS-запис несе час життя: число в секундах, задане тим, хто керує зоною, яке каже резолверу, як довго він може повторно використовувати відповідь, перш ніж спитати знову. RFC 1035 визначає це як інтервал, протягом якого запис «може кешуватися, перш ніж знову слід звернутися до джерела інформації», а TTL, рівний нулю, означає, що відповідь узагалі не можна кешувати.

Кожен кеш у цьому ланцюжку, браузер, стаб-резолвер, роутер, рекурсивний резолвер, має дотримуватися цього числа, відраховуючи від моменту, коли вперше отримав запис. На практиці деякі резолвери провайдерів застосовують власну нижню межу поверх нього, зазвичай годину чи більше, незалежно від того, який TTL заявляє зона. Саме тому зниження TTL, щоб пришвидшити майбутню зміну, допомагає з більшістю резолверів, але не є гарантією для кожного з них.

Що таке негативне кешування, і чому щойно створений запис може лишатися недоступним?

Резолвер кешує не лише записи, що існують. Якщо запит повертається без такого імені (NXDOMAIN) або без запису потрібного типу, ця невдача теж кешується, і це називається негативним кешуванням. RFC 2308 визначає тривалість життя негативного кеша з поля minimum SOA-запису, а RFC 9520 тепер робить кешування такої відмови обов’язковим, а не опційним для сумісного резолвера.

Це і є механізм за знайомою проблемою: ви створюєте новий піддомен, опитуєте його на секунду зарано, отримуєте NXDOMAIN, і резолвер пам’ятає «не існує» протягом усього негативного TTL зони, навіть попри те, що запис уже існує. Windows показує ці два типи записів окремо: ipconfig /displaydns виводить і позитивні, і негативні відповіді, а ipconfig /flushdns явно відкидає негативні записи кеша як частину очищення.

Чому сайт визначається у вас, а в когось іншого ні?

Бо єдиного спільного кеша не існує. Дві людини, що звертаються до двох різних резолверів, або до того самого резолвера в два різні моменти, можуть отримати дві різні відповіді на те саме ім’я. Копія одного резолвера може бути ще свіжою з пошуку годину тому; інший міг узагалі ніколи не бачити це ім’я і піти по актуальне значення. Жоден із них не помиляється, вони просто на різних годинниках. Якщо це відбувається одразу після того, як ви змінили запис, як перевірити поширення DNS розповідає, як порівняти кілька резолверів поряд і прочитати, скільки часу лишилося в кожного.

Як прочитати TTL запису, що досі в кеші?

Опитайте ім’я напряму й залиште повний вивід, а не коротку форму:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Число перед типом запису, у цьому прикладі 847, - це секунди, що лишилися до спливання саме цієї копії резолвера; це не оригінальний TTL запису, який зі стовідсотковою точністю знає лише авторитетний сервер. Запустіть той самий запит ще раз через кілька секунд, і число зменшиться приблизно на стільки ж, підтверджуючи, що ви читаєте живий відлік, а не статичне налаштування. Якщо ім’я взагалі не визначається, а не визначається з низьким числом, це вже інша несправність: як очистити DNS розповідає, як спершу очистити власний кеш, а що насправді робить DNS-резолвер описує, що відбувається далі в ланцюжку, коли проблема не у вашому власному кеші.

Кеш пояснює, чому один відвідувач бачить зміну одразу, а інший ні; він не пояснює запис, що ніде й ніколи не оновлюється. Запустіть живий пошук через інструмент DNS-запиту, щоб побачити поточну відповідь з-за меж власної мережі, а якщо сайт має лишатися доступним за розкладом, а не перевірятися одноразово, саме для цього існує розподілений моніторинг із багатьох контрольних точок. HostTracker моніторить вебсайти з 2004 року, зараз стежить за понад 500 000 сайтів із понад 300 контрольних точок у 158 містах і сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та інших каналах, коли перевірка провалюється, зокрема перевірка, що очікує конкретну IP-адресу і позначає її, щойно відповідь змінюється.

Часті запитання

Чи сповільнює повний DNS-кеш мій комп’ютер?

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

Чи виправляє очищення мого кеша щось для інших людей?

Ні. ipconfig /flushdns, dscacheutil -flushcache і resolvectl flush-caches очищують кеш лише на машині, де ви їх виконуєте. Усі інші й далі читають зі свого браузера, свого роутера й свого резолвера, кожен за власним таймером.

Чи є DNS-кеш тим самим, що й кеш CDN?

Ні, хоча ці два поняття плутають. DNS-кеш зберігає відповідь на питання «яка IP-адреса відповідає цьому імені». Кеш CDN зберігає сам вміст сторінки чи файлу на сервері, ближчому до відвідувача. Очищення одного не впливає на інше.

Чи можу я встановити власний TTL, якщо не керую доменом?

Ні. TTL - це властивість запису, яку задає в авторитетній зоні той, хто керує DNS домену. Як відвідувач, єдиний ваш важіль - обрати резолвер, що поважає короткий TTL, а не той, що застосовує власну нижню межу.

Чому TTL, який я бачу, змінюється щоразу під час запиту?

Тому що ви звертаєтеся до іншого резолвера або до того самого в інший момент його відліку. Опитайте авторитетний nameserver напряму командою dig example.com @ns1.yourdns.example, щоб побачити TTL таким, яким його задали спочатку, без жодного відліку.