DNS-retumilaj protokoloj kontraŭ VPN-konektaj protokoloj: kion enhavas ĉiu

DNS-retumila protokolo kaj VPN-konekta protokolo ambaŭ estas retaj registroj, ambaŭ utilaj, kaj ne interŝanĝeblaj. La retumilo ricevas nomojn, kiujn oni petis ĝin respondi. La VPN-finpunkto pritraktas tunelajn konektojn kaj registras tion, kion ĝia efektivigo elektis registri pri ili. Ili povas troviĝi en la sama konstruaĵo, esti administrataj de la sama teamo kaj esti kovritaj de la sama privateca avizo, kaj tamen ili priskribas malsamajn eventojn kun malsamaj identigiloj kaj malsama konservado. Legi unu kvazaŭ ĝi estus la alia estas kiel enketoj misvojas.

Du protokoloj, du eventoj

Erizo de la retumilo respondas demandon pri nomado: tiu kliento petis tiun nomon je tiu tempo, kaj la respondo estis tio. Erizo de la VPN respondas demandon pri konektebleco: tiu samtavolano starigis aŭ perdis tunelon, ricevis tiun adreson, kaj transdonis proksimume tiom da datumoj antaŭ ol ĝi foriris. Neniu el ili estas registro pri tio, kion la uzanto faris ene de HTTPS-sesio, kaj neniu anstataŭas la alian.

La distingo havas praktikan konsekvencon por promesoj. Aserto, ke VPN-provizanto ne registras tunelan agadon, diras nenion pri la retumilo, kiun ĝi disdonas, kaj konserva politiko de retumilo diras nenion pri tio, kiu konektiĝis al la tunelo. Ĉiu aserto apartenas al sia propra operatoro kaj sia propra sistemo.

Sekvu la peton antaŭ ol legi iun el la du protokoloj

Peto atingas retumilon nur se la vojo vere demandas ĝin. Aplikaĵo povas uzi la retumilon de la operaciumo, lanĉi sian propran ĉifritan DNS-klienton, aŭ legi kaŝmemoran respondon kaj neniam sendi ion. Do retumila protokolo, kiu montras nenion, ne estas pruvo, ke nomo neniam estis uzata; ĝi estas pruvo, ke oni ne demandis ĉi tiun retumilon.

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

Tiu lasta komando legas la propran taglibron de la loka retumilo, kio ne samas al la protokolo de la supra servilo. Se viaj petoj eliras per DNS over HTTPS al provizanto, la loka stumpo povas montri nenion dum la provizanto havas la kompletan registron, kaj la provizanto estas alia operatoro kun alia politiko.

Kion ĉiu registro povas kaj ne povas montri

Kunigi ilin estas la vera laboro, kaj kunigi ilin ne ĉiam eblas. Retumilon, kiu registras klientajn adresojn, oni povas kompari kun VPN, kiu asignas adresojn el konata provizujo, kaj tiu komparo produktas kredindan ligon inter petita nomo kaj tunelo, kiu restas ligo inter du registroj anstataŭ registro pri persono.

Ĉifrita DNS ŝanĝas la transporton, ne la videblecon ĉe la finpunkto. La retumilo ankoraŭ ricevas la demandon, kiun ĝi respondas, kiel RFC 8484 klare montras, kaj konservado ĉe tiu retumilo estas politika decido anstataŭ eco de la protokolo.

Kie disigita DNS kaj kaŝmemoroj konfuzas la rakonton

Pluraj retumiloj estas normalaj. Disigita-DNS-dezajno sendas internajn nomojn al interna servilo kaj ĉion alian al publika, do unu enketo povas impliki du protokolojn, kiuj neniam estis destinitaj kunigi, kaj du konservajn agordojn, kiuj neniam estis destinitaj kompari. Vidi petojn ĉe ambaŭ estas pruvo, ke la dezajno funkcias, ne pruvo pri liko.

Kaŝmemoroj tranĉas la alian vojon. Populara nomo povas esti respondata el kaŝmemoro dum horoj, do la registro de la retumilo montras la unuan peton kaj poste nenion, dum la aplikaĵo de la uzanto daŭre feliĉe solvas la saman nomon. Manko de erizoj post certa tempo ne signifas, ke neniu uzis la nomon post tiu tempo.

Fona trafiko estas la tria distordo. Telefono, kiu solvas telemetrian nomon ĉe ŝaltiĝo, retumilo, kiu solvas domajnon de serĉsugesto, kaj ĝisdatigilo, kiu raportas ĉiuhore, ĉiuj aperas en retumila protokolo apud la nomo, pri kiu vi vere zorgas. Volumo en tiu protokolo ne estas atento, kaj nombri petojn ne estas nombri vizitojn. Retumila protokolo estas registro de demandoj, kaj demandojn malmultekostas generi.

Demandu la konservajn demandojn aparte

Por ĉiu sistemo, demandu tri demandojn: kiu kolektas, kio estas kolektata, kaj kiom longe ĝi estas konservata. Poste demandu, kiu povas legi ĝin kaj laŭ kiu procezo. La diskuto de RFC 8484 pri DNS over HTTPS estas bona memorigo, ke ĉifrita transporto ne forigas la finpunkton, kaj la propra dokumentaro de operatoro estas la sola fidinda aserto pri tio, kion tiu finpunkto konservas.

Kiam aserto pri privateco estas farata pri “la VPN”, disigu ĝin en komponentojn antaŭ ol akcepti ĝin: la tunela operatoro, la retumilo, kiun la tunelo disdonas, ajna supra retumilo, kiun tiuj petoj atingas, kaj la aplikaĵoj en la aparato. Ĉiu havas sian propran respondon, kaj aserto preciza por unu estas rutine ripetata kvazaŭ ĝi kovrus ĉiujn kvar.

Por misfunkcia diagnozo, uzu la saman disigon. Demandu, kiu aplikaĵo faris la peton kaj kiu retumilo respondis ĝin, poste rigardu la protokolon, kiu vere posedas tiun eventon. Diveni el la alia protokolo ŝparas minuton kaj kostas posttagmezon.