Regjistrat e zgjidhësit DNS kundrejt regjistrave të lidhjes VPN: çfarë mban secili
Një zgjidhës regjistron emrat për të cilët iu kërkua të përgjigjet; një VPN regjistron ngjarjet e tunelit nga implementimi i vet. Një politikë ruajtjeje nuk mbulon tjetrën.
Regjistri i zgjidhësit DNS dhe regjistri i lidhjes VPN janë të dy regjistrime rrjeti, të dy të dobishëm dhe të pazëvendësueshëm. Zgjidhësi merr emrat për të cilët iu kërkua të përgjigjet. Pika fundore e VPN trajton lidhjet e tunelit dhe regjistron çfarëdo që implementimi i saj zgjodhi të regjistrojë rreth tyre. Mund të jenë në të njëjtën ndërtesë, të operohen nga i njëjti ekip dhe të mbulohen nga i njëjti njoftim privatësie, dhe prapë përshkruajnë ngjarje të ndryshme me identifikues të ndryshëm dhe ruajtje të ndryshme. Leximi i njërit sikur të ishte tjetri është mënyra se si hetimet dalin nga rruga.
Dy regjistra, dy ngjarje
Një hyrje e zgjidhësit i përgjigjet një pyetjeje rreth emërtimit: ky klient kërkoi këtë emër në këtë kohë, dhe përgjigjja ishte kjo. Një hyrje e VPN i përgjigjet një pyetjeje rreth lidhshmërisë: ky homolog vendosi ose humbi një tunel, iu caktua kjo adresë dhe transferoi përafërsisht kaq të dhëna para se të zhdukej. Asnjëra nuk është regjistrim i asaj që bëri përdoruesi brenda një sesioni HTTPS, dhe asnjëra nuk zëvendëson tjetrën.
Dallimi ka një pasojë praktike për premtimet. Deklarata se një ofrues VPN nuk regjistron aktivitetin e tunelit nuk thotë asgjë për zgjidhësin që ai ofron, dhe politika e ruajtjes e një zgjidhësi nuk thotë asgjë për kë u lidh me tunelin. Çdo pretendim i takon operatorit të vet dhe sistemit të vet.
Ndiqni pyetësorin përpara se të lexoni cilindo prej regjistrave
Një pyetësor arrin te një zgjidhës vetëm nëse rruga vërtet e pyet atë. Një aplikacion mund të përdorë zgjidhësin e sistemit operativ, të ekzekutojë klientin e vet të kriptuar DNS, ose të lexojë një përgjigje në cache dhe të mos dërgojë kurrë asgjë. Pra, një regjistër zgjidhësi që nuk tregon asgjë nuk është provë që një emër nuk u përdor kurrë; është provë që ky zgjidhës nuk u pyet.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager
Ai komandë i fundit lexon ditarin e vetë zgjidhësit lokal, i cili nuk është i njëjtë me regjistrin e serverit sipërm. Nëse pyetësorët tuaj dalin përmes DNS over HTTPS drejt një ofruesi, stub-i lokal mund të mos tregojë asgjë ndërsa ofruesi ka regjistrimin e plotë, dhe ofruesi është një operator tjetër me politikë tjetër.
Çfarë mund dhe çfarë nuk mund të tregojë secili regjistrim
| 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 |
Lidhja e tyre është puna e vërtetë, dhe lidhja nuk është gjithmonë e mundur. Një zgjidhës që regjistron adresat e klientëve mund të krahasohet me një VPN që cakton adresa nga një grup i njohur, dhe ky krahasim prodhon një lidhje të besueshme midis një emri të pyetur dhe një tuneli, e cila mbetet lidhje midis dy regjistrave dhe jo regjistrim i një personi.
DNS i kriptuar ndryshon transportin, jo dukshmërinë në pikën fundore. Zgjidhësi ende merr pyetjen së cilës i përgjigjet, siç RFC 8484 e bën të qartë, dhe ruajtja në atë zgjidhës është vendim politike dhe jo veti e protokollit.
Ku DNS i ndarë dhe cache-t e ngatërrojnë historinë
Disa zgjidhës janë normale. Një dizajn me DNS të ndarë dërgon emrat e brendshëm te një server i brendshëm dhe gjithçka tjetër te një publik, kështu që një hetim i vetëm mund të përfshijë dy regjistra që nuk ishin menduar kurrë të kombinoheshin dhe dy cilësime ruajtjeje që nuk ishin menduar kurrë të krahasoheshin. Të shohësh pyetësorë në të dy është provë që dizajni funksionon, jo provë e një rrjedhjeje.
Cache-t presin në drejtimin tjetër. Një emër popullor mund të përgjigjet nga cache për orë të tëra, kështu që regjistri i zgjidhësit tregon pyetësorin e parë dhe pastaj asgjë, ndërsa aplikacioni i përdoruesit vazhdon me gëzim të zgjidhë të njëjtin emër. Mungesa e hyrjeve pas një kohe të caktuar nuk do të thotë që askush nuk e përdori emrin pas asaj kohe.
Trafiku i sfondit është shtrembërimi i tretë. Një telefon që zgjidh një emër telemetrie në nisje, një shfletues që zgjidh një domen sugjerimi kërkimi dhe një përditësues që lidhet çdo orë shfaqen të gjithë në një regjistër zgjidhësi pranë emrit që ju intereson vërtet. Vëllimi në atë regjistër nuk është vëmendje, dhe numërimi i pyetësorëve nuk është numërimi i vizitave. Regjistri i zgjidhësit është regjistrim pyetjesh, dhe pyetjet janë të lira për t'u gjeneruar.
Bëni pyetjet e ruajtjes veçmas
Për çdo sistem, bëni tri pyetje: kush mbledh, çfarë mblidhet dhe sa kohë ruhet. Pastaj pyetni kush mund ta lexojë dhe me çfarë procesi. Diskutimi i RFC 8484 për DNS over HTTPS është një kujtesë e mirë se transporti i kriptuar nuk e heq pikën fundore, dhe dokumentacioni i vetë operatorit është deklarata e vetme e besueshme për atë që mban ajo pikë fundore.
Kur bëhet një pretendim për privatësinë për „VPN-në“, ndajeni në komponentë përpara se ta pranoni: operatori i tunelit, zgjidhësi që tuneli ofron, çdo zgjidhës sipërm që arrijnë këta pyetësorë, dhe aplikacionet në pajisje. Secili ka përgjigjen e vet, dhe një pretendim i saktë për njërin përsëritet rutinish sikur të mbulonte të katërt.
Për zgjidhjen e problemeve, përdorni të njëjtën ndarje. Pyetni cili aplikacion e bëri pyetësorin dhe cili zgjidhës iu përgjigj, pastaj shikoni regjistrin që zotëron vërtet atë ngjarje. Hamendja nga regjistri tjetër kursen një minutë dhe kushton një pasdite.