Дневници на DNS резолвера срещу дневници на 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 към доставчик, локалната подставка може да не показва нищо, докато доставчикът има пълния запис, а доставчикът е различен оператор с различна политика.

Какво може и какво не може да покаже всеки запис

Съединяването им е мястото, където е истинската работа, и съединяването им не винаги е възможно. Резолвер, който записва адресите на клиентите, може да се сравни с VPN, който назначава адреси от известен пул, и това сравнение създава правдоподобна връзка между заявено име и тунел, която остава връзка между два записа, а не запис за човек.

Криптираният DNS променя транспорта, а не видимостта в крайната точка. Резолверът все още получава въпроса, на който отговаря, както RFC 8484 ясно показва, и съхранението в този резолвер е решение на политика, а не свойство на протокола.

Къде разделеният DNS и кешовете объркват историята

Няколко резолвера са нормални. Дизайнът с разделен DNS изпраща вътрешните имена към вътрешен сървър, а всичко останало към публичен, така че едно разследване може да включва два дневника, които никога не е било предвидено да се комбинират, и две настройки за съхранение, които никога не е било предвидено да се сравняват. Да виждаш заявки и в двата е доказателство, че дизайнът работи, а не доказателство за изтичане.

Кешовете режат в обратната посока. Популярно име може да бъде отговаряно от кеша с часове, така че записът на резолвера показва първата заявка и след това нищо, докато приложението на потребителя продължава спокойно да резолвва същото име. Липсата на записи след определено време не означава, че никой не е използвал името след това време.

Фоновият трафик е третото изкривяване. Телефон, който резолвва име за телеметрия при зареждане, браузър, който резолвва домейн за предложение за търсене, и програма за обновяване, която се свързва на всеки час, всички те се появяват в дневника на резолвера редом с името, което наистина ви интересува. Обемът в този дневник не е внимание и броенето на заявки не е броене на посещения. Дневникът на резолвера е запис на въпроси, а въпросите се генерират евтино.

Задавайте въпросите за съхранението поотделно

За всяка система задайте три въпроса: кой събира, какво се събира и колко дълго се съхранява. След това попитайте кой може да го чете и по какъв процес. Обсъждането на RFC 8484 за DNS over HTTPS е добро напомняне, че криптираният транспорт не премахва крайната точка, а собствената документация на оператора е единственото надеждно твърдение за това какво съхранява тази крайна точка.

Когато се прави твърдение за поверителност относно „VPN“, разделете го на компоненти, преди да го приемете: операторът на тунела, резолверът, който тунелът предоставя, всеки горен резолвер, до който достигат тези заявки, и приложенията на устройството. Всяко има свой отговор и твърдение, вярно за едно, редовно се повтаря, сякаш покрива и четирите.

За отстраняване на проблеми използвайте същото разделение. Попитайте кое приложение е направило заявката и кой резолвер е отговорил, след което погледнете дневника, който наистина притежава това събитие. Гадането от другия дневник спестява минута и струва следобед.