Дневници на 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“, поделете го на компоненти пред да го прифатите: операторот на тунелот, резолверот што тунелот го дава, секој надреден резолвер до кој стигнуваат тие барања и апликациите на уредот. Секој има свој одговор, а тврдењето точно за еден редовно се повторува како да ги покрива сите четири.

За решавање проблеми, користете ја истата поделба. Прашајте која апликација го направила барањето и кој резолвер одговорил на него, потоа погледнете го дневникот што навистина го поседува тој настан. Гаѓањето од другиот дневник штеди една минута и чини едно попладне.