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