Dnevnik razreševalnika DNS in dnevnik povezav VPN sta oba omrežna zapisa, oba uporabna in nista zamenljiva. Razreševalnik prejme imena, na katera je bil pozvan odgovoriti. Končna točka VPN obravnava predorske povezave in zapisuje, kar se je njena izvedba odločila o njih zapisati. Lahko sta v isti stavbi, ju upravlja ista ekipa in zanju velja isto obvestilo o zasebnosti, pa vendar opisujeta različne dogodke z različnimi identifikatorji in različno hrambo. Branje enega, kot da je drugi, je pot, po kateri preiskave zaidejo.

Dva dnevnika, dva dogodka

Vnos v razreševalniku odgovarja na vprašanje o poimenovanju: ta odjemalec je ob tem času zahteval to ime in odgovor je bil ta. Vnos v VPN odgovarja na vprašanje o povezljivosti: ta nasprotni člen je vzpostavil ali izgubil predor, prejel je ta naslov in prenesel približno toliko podatkov, preden je izginil. Noben ni zapis o tem, kaj je uporabnik počel znotraj seje HTTPS, in noben ne nadomešča drugega.

Razlika ima praktično posledico za obljube. Trditev, da ponudnik VPN ne zapisuje dejavnosti predora, ne pove ničesar o razreševalniku, ki ga ponuja, politika hrambe razreševalnika pa ne pove ničesar o tem, kdo se je povezal s predorom. Vsaka trditev pripada svojemu operaterju in svojemu sistemu.

Sledite poizvedbi, preden preberete kateri koli dnevnik

Poizvedba doseže razreševalnik le, če jo pot zares vpraša. Aplikacija lahko uporabi razreševalnik operacijskega sistema, zažene lastnega šifriranega odjemalca DNS ali prebere odgovor iz predpomnilnika in nikoli ničesar ne pošlje. Zato dnevnik razreševalnika, ki ne pokaže ničesar, ni dokaz, da ime ni bilo nikoli uporabljeno; je dokaz, da tega razreševalnika niso vprašali.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Zadnji ukaz bere lastni dnevnik krajevnega razreševalnika, kar ni isto kot dnevnik nadrejenega strežnika. Če vaše poizvedbe odhajajo prek DNS over HTTPS k ponudniku, krajevni stub morda ne pokaže ničesar, medtem ko ima ponudnik popoln zapis, in ponudnik je drug operater z drugo politiko.

Kaj lahko in česa ne more pokazati posamezni zapis

RecordTypically showsDoes not show
Resolver logQueried name, client address, time, responseWhich page was fetched, or what the tunnel did
VPN connection logPeer identity, assigned address, connect and disconnect times, volumeWhich name the application asked for
Application or proxy logRequests, status codes, sometimes full URLsResolved addresses for every dependency

Povezati jih je pravo delo in povezati jih ni vedno mogoče. Razreševalnik, ki zapisuje naslove odjemalcev, je mogoče primerjati z VPN, ki dodeljuje naslove iz znanega nabora, in ta primerjava ustvari verjetno povezavo med poizvedenim imenom in predorom, ki ostaja povezava med dvema zapisoma, ne zapis o osebi.

Šifrirani DNS spremeni prenos, ne vidnosti na končni točki. Razreševalnik še vedno prejme vprašanje, na katero odgovarja, kot RFC 8484 jasno kaže, in hramba pri tem razreševalniku je odločitev politike in ne lastnost protokola.

Kjer razdeljeni DNS in predpomnilniki zapletejo zgodbo

Več razreševalnikov je običajno. Zasnova z razdeljenim DNS pošilja notranja imena na notranji strežnik in vse drugo na javnega, zato lahko ena preiskava vključuje dva dnevnika, ki nista bila nikoli mišljena za združitev, in dve nastavitvi hrambe, ki nista bili nikoli mišljeni za primerjavo. Videti poizvedbe v obeh je dokaz, da zasnova deluje, ne dokaz uhajanja.

Predpomnilniki režejo v drugo smer. Priljubljeno ime je lahko iz predpomnilnika odgovorjeno ure in ure, zato zapis razreševalnika pokaže prvo poizvedbo in nato nič, medtem ko aplikacija uporabnika še naprej veselo razrešuje isto ime. Odsotnost vnosov po določenem času ne pomeni, da nihče ni uporabil imena po tem času.

Ozadnji promet je tretja popačitev. Telefon, ki ob zagonu razrešuje ime telemetrije, brskalnik, ki razrešuje domeno predloga iskanja, in posodabljalnik, ki se javi vsako uro, se vsi pojavijo v dnevniku razreševalnika ob imenu, ki vam je res pomembno. Obseg v tem dnevniku ni pozornost in štetje poizvedb ni štetje obiskov. Dnevnik razreševalnika je zapis vprašanj, vprašanja pa je poceni ustvariti.

Vprašanja o hrambi postavite ločeno

Za vsak sistem postavite tri vprašanja: kdo zbira, kaj se zbira in kako dolgo se to hrani. Nato vprašajte, kdo to lahko bere in po kakšnem postopku. Razprava o RFC 8484 o DNS over HTTPS je dober opomnik, da šifriran prenos ne odpravi končne točke, in lastna dokumentacija operaterja je edina zanesljiva trditev o tem, kaj ta končna točka hrani.

Ko se trditev o zasebnosti nanaša na „VPN“, jo pred sprejetjem razdelite na sestavne dele: operater predora, razreševalnik, ki ga predor ponuja, kateri koli nadrejeni razreševalnik, do katerega te poizvedbe dosežejo, in aplikacije v napravi. Vsak ima svoj odgovor, trditev, ki je točna za enega, pa se rutinsko ponavlja, kot da pokriva vse štiri.

Za odpravljanje težav uporabite isto delitev. Vprašajte, katera aplikacija je ustvarila poizvedbo in kateri razreševalnik je nanjo odgovoril, nato poglejte v dnevnik, ki tej dogodki resnično pripada. Ugibanje iz drugega dnevnika prihrani minuto in stane popoldne.

Sorodni članki