DNS-resolverlogboeke teenoor VPN-verbindingslogboeke: wat elkeen bevat

'n DNS-resolverlogboek en 'n VPN-verbindingslogboek is albei netwerkrekords, albei nuttig, en nie uitruilbaar nie. Die resolver ontvang name wat hy gevra is om te beantwoord. Die VPN-eindpunt hanteer tonnelverbindings en teken aan wat sy implementering ook al gekies het om daaroor op te teken. Hulle kan in dieselfde gebou staan, deur dieselfde span bedryf word en onder dieselfde privaatheidskennisgewing val, en tog beskryf hulle verskillende gebeure met verskillende identifiseerders en verskillende bewaartermyn. Om die een te lees asof dit die ander is, is hoe ondersoeke skeefloop.

Twee logboeke, twee gebeure

'n Resolverinskrywing beantwoord 'n vraag oor naamgewing: hierdie kliënt het op hierdie tydstip vir hierdie naam gevra, en die antwoord was dit. 'n VPN-inskrywing beantwoord 'n vraag oor konnektiwiteit: hierdie eweknie het 'n tonnel opgestel of verloor, het hierdie adres toegewys gekry, en het omtrent soveel data oorgedra voordat dit verdwyn het. Nie een is 'n rekord van wat die gebruiker binne 'n HTTPS-sessie gedoen het nie, en nie een vervang die ander nie.

Die onderskeid het 'n praktiese gevolg vir beloftes. 'n Stelling dat 'n VPN-verskaffer nie tonnelaktiwiteit aanteken nie, sê niks oor die resolver wat hy uitdeel nie, en 'n resolver se bewaarbeleid sê niks oor wie aan die tonnel gekoppel het nie. Elke bewering hoort by sy eie operateur en sy eie stelsel.

Volg die navraag voordat jy enige van die twee logboeke lees

'n Navraag bereik 'n resolver net as die pad dit werklik vra. 'n Toepassing kan die bedryfstelsel se resolver gebruik, sy eie geënkripteerde DNS-kliënt laat loop, of 'n gekasde antwoord lees en nooit iets stuur nie. Dus is 'n resolverlogboek wat niks wys nie, nie bewys dat 'n naam nooit gebruik is nie; dit is bewys dat hierdie resolver nie gevra is nie.

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

Daardie laaste opdrag lees die plaaslike resolver se eie joernaal, wat nie dieselfde is as die opstroombediener se logboek nie. As jou navrae deur DNS over HTTPS na 'n verskaffer vertrek, kan die plaaslike stomp niks wys terwyl die verskaffer die volledige rekord het, en die verskaffer is 'n ander operateur met 'n ander beleid.

Wat elke rekord wel en nie kan wys nie

Om hulle te koppel is waar die werklike werk lê, en om hulle te koppel is nie altyd moontlik nie. 'n Resolver wat kliëntadresse aanteken, kan vergelyk word met 'n VPN wat adresse uit 'n bekende poel toeken, en daardie vergelyking lewer 'n geloofwaardige skakel tussen 'n nagevraagde naam en 'n tonnel, wat 'n skakel tussen twee rekords bly eerder as 'n rekord van 'n persoon.

Geënkripteerde DNS verander die vervoer, nie die sigbaarheid by die eindpunt nie. Die resolver ontvang steeds die vraag wat hy beantwoord, soos RFC 8484 dit duidelik maak, en bewaring by daardie resolver is 'n beleidsbesluit eerder as 'n eienskap van die protokol.

Waar gesplete DNS en kasgeheue die verhaal verwar

Verskeie resolvers is normaal. 'n Gesplete-DNS-ontwerp stuur interne name na 'n interne bediener en alles anders na 'n publieke een, so 'n enkele ondersoek kan twee logboeke betrek wat nooit bedoel was om gekombineer te word nie, en twee bewaarinstellings wat nooit bedoel was om vergelyk te word nie. Om navrae by albei te sien, is bewys dat die ontwerp werk, nie bewys van 'n lek nie.

Kasgeheue sny die ander kant toe. 'n Gewilde naam kan ure lank uit die kas beantwoord word, so die resolver se rekord wys die eerste navraag en dan niks, terwyl die gebruiker se toepassing dieselfde naam gelukkig bly opklaar. 'n Afwesigheid van inskrywings ná 'n sekere tyd beteken nie dat niemand die naam ná daardie tyd gebruik het nie.

Agtergrondverkeer is die derde verwringing. 'n Foon wat by die opstart 'n telemetrienaam opklaar, 'n blaaier wat 'n soekvoorstel-domein opklaar, en 'n opdateringstoepassing wat elke uur inklok, verskyn almal in 'n resolverlogboek langs die naam waaroor jy werklik omgee. Volume in daardie logboek is nie aandag nie, en om navrae te tel is nie om besoeke te tel nie. 'n Resolverlogboek is 'n rekord van vrae, en vrae is goedkoop om te skep.

Vra die bewaarvrae afsonderlik

Vra vir elke stelsel drie vrae: wie versamel, wat word versamel, en hoe lank dit bewaar word. Vra dan wie dit kan lees en onder watter proses. Die RFC 8484-bespreking van DNS over HTTPS is 'n goeie herinnering dat geënkripteerde vervoer nie die eindpunt verwyder nie, en 'n operateur se eie dokumentasie is die enigste betroubare stelling oor wat daardie eindpunt bewaar.

Wanneer 'n bewering oor privaatheid oor “die VPN” gemaak word, verdeel dit in komponente voordat jy dit aanvaar: die tonneloperateur, die resolver wat die tonnel uitdeel, enige opstroomresolver wat daardie navrae bereik, en die toepassings op die toestel. Elkeen het sy eie antwoord, en 'n bewering wat vir een akkuraat is, word gereeld herhaal asof dit al vier dek.

Vir foutsporing, gebruik dieselfde verdeling. Vra watter toepassing die navraag gedoen het en watter resolver dit beantwoord het, en kyk dan na die logboek wat daardie gebeurtenis werklik besit. Om uit die ander logboek te raai, spaar 'n minuut en kos 'n middag.