Журнали DNS-резолвера та журнали VPN-з'єднань: що зберігає кожен
Резолвер записує імена, на які його просили відповісти; VPN записує події тунелю з власної реалізації. Одна політика зберігання не покриває іншу.
Журнал DNS-резолвера і журнал VPN-з'єднань — обидва мережеві записи, обидва корисні й не замінюють один одного. Резолвер отримує імена, на які його просили відповісти. Кінцева точка VPN обробляє тунельні з'єднання і записує те, що її реалізація вирішила про них записати. Вони можуть бути в одній будівлі, обслуговуватися однією командою і підпадати під одне повідомлення про конфіденційність, і все ж описують різні події з різними ідентифікаторами та різним зберіганням. Читати один як інший — це шлях, яким розслідування звертають не туди.
Два журнали, дві події
Запис резолвера відповідає на питання про найменування: цей клієнт запитав це ім'я в цей час, і відповіддю було це. Запис VPN відповідає на питання про зв'язність: цей учасник встановив або втратив тунель, отримав цю адресу і передав приблизно стільки даних, перш ніж зникнути. Жоден не є записом про те, що користувач робив усередині сесії HTTPS, і жоден не замінює інший.
Ця відмінність має практичний наслідок для обіцянок. Твердження, що постачальник VPN не журналює активність тунелю, нічого не говорить про резолвер, який він надає, а політика зберігання резолвера нічого не говорить про те, хто підключився до тунелю. Кожне твердження належить своєму оператору і своїй системі.
Простежте запит, перш ніж читати будь-який із журналів
Запит доходить до резолвера лише тоді, коли шлях справді його питає. Застосунок може використовувати резолвер операційної системи, запускати власний зашифрований DNS-клієнт або прочитати відповідь із кешу й нічого не надіслати. Тому журнал резолвера, який нічого не показує, не є доказом того, що ім'я ніколи не використовувалося; це доказ того, що в цього резолвера не питали.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerОстання команда читає власний журнал локального резолвера, що не те саме, що журнал вищого сервера. Якщо ваші запити виходять через DNS over HTTPS до постачальника, локальна заглушка може нічого не показувати, тоді як у постачальника є повний запис, і постачальник — інший оператор з іншою політикою.
Що кожен запис може і чого не може показати
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
Пов'язати їх — це справжня робота, і пов'язати вдається не завжди. Резолвер, який журналює адреси клієнтів, можна порівняти з VPN, який виділяє адреси з відомого пулу, і це порівняння дає правдоподібний зв'язок між запитаним ім'ям і тунелем, який залишається зв'язком між двома записами, а не записом про людину.
Зашифрований DNS змінює транспорт, а не видимість на кінцевій точці. Резолвер і далі отримує питання, на яке відповідає, як RFC 8484 ясно показує, і зберігання в тому резолвері — рішення політики, а не властивість протоколу.
Де розділений DNS і кеші плутають історію
Кілька резолверів — це норма. Схема з розділеним DNS надсилає внутрішні імена на внутрішній сервер, а все інше — на публічний, тож одне розслідування може охоплювати два журнали, які ніколи не призначалися для об'єднання, і два налаштування зберігання, які ніколи не призначалися для порівняння. Бачити запити в обох — доказ того, що схема працює, а не доказ витоку.
Кеші ріжуть в інший бік. Популярне ім'я може годинами обслуговуватися з кешу, тож запис резолвера показує перший запит, а далі нічого, тоді як застосунок користувача спокійно далі розв'язує те саме ім'я. Відсутність записів після певного моменту не означає, що після цього моменту ім'я ніхто не використовував.
Фоновий трафік — третє викривлення. Телефон, який під час завантаження розв'язує ім'я телеметрії, браузер, який розв'язує домен пошукової підказки, і програма оновлення, яка зв'язується щогодини, — усі вони з'являються в журналі резолвера поруч з ім'ям, яке вам справді важливе. Обсяг у цьому журналі — не увага, і підрахунок запитів — не підрахунок візитів. Журнал резолвера — це запис питань, а питання дешево генерувати.
Ставте питання про зберігання окремо
Для кожної системи поставте три питання: хто збирає, що збирається і як довго це зберігається. Потім запитайте, хто може це читати і за якою процедурою. Обговорення RFC 8484 про DNS over HTTPS — добре нагадування про те, що зашифрований транспорт не прибирає кінцеву точку, а власна документація оператора — єдине надійне твердження про те, що ця точка зберігає.
Коли твердження про конфіденційність робиться про «VPN», розкладіть його на складники, перш ніж прийняти: оператор тунелю, резолвер, який надає тунель, будь-який вищий резолвер, до якого доходять ці запити, і застосунки на пристрої. У кожного своя відповідь, і твердження, правильне для одного, зазвичай повторюють так, ніби воно охоплює всі чотири.
Для пошуку несправностей використовуйте той самий поділ. Запитайте, який застосунок зробив запит і який резолвер на нього відповів, а потім подивіться в журнал, який справді володіє цією подією. Здогад із іншого журналу економить хвилину і коштує півдня.