Mga log ng resolver ng DNS kumpara sa mga log ng koneksyon ng VPN: ano ang hawak ng bawat isa
Ang resolver ay nagtatala ng mga pangalang hiniling na sagutin; ang VPN ay nagtatala ng mga pangyayari sa tunel mula sa sarili nitong implementasyon. Hindi sinasakop ng isang patakaran sa pagtatago ang isa.
Ang log ng resolver ng DNS at ang log ng koneksyon ng VPN ay parehong mga talaan ng network, parehong kapaki-pakinabang at hindi mapagpapalit. Tinatanggap ng resolver ang mga pangalang hiniling na sagutin. Pinangangasiwaan ng endpoint ng VPN ang mga koneksyon sa tunel at itinatala ang anumang pinili ng implementasyon nito na itala tungkol sa mga ito. Maaaring nasa iisang gusali ang mga ito, pinapatakbo ng iisang koponan at saklaw ng iisang abiso sa privacy, at gayon pa man ay naglalarawan sila ng magkaibang mga pangyayari na may magkaibang mga identifier at magkaibang pagtatago. Ang pagbasa ng isa na parang ito ang isa pa ay ang paraan kung paano nalilihis ang mga imbestigasyon.
Dalawang log, dalawang pangyayari
Ang isang entry sa resolver ay sumasagot sa tanong tungkol sa pagpapangalan: hiniling ng client na ito ang pangalang ito sa oras na ito, at ang sagot ay ito. Ang isang entry sa VPN ay sumasagot sa tanong tungkol sa pagkakakonekta: itinatag o nawala ng peer na ito ang isang tunel, binigyan ito ng address na ito, at naglipat ng halos ganito karaming data bago ito nawala. Wala sa dalawa ang talaan ng ginawa ng user sa loob ng isang session ng HTTPS, at wala sa dalawa ang pumapalit sa isa.
Ang pagkakaibang ito ay may praktikal na bunga para sa mga pangako. Ang pahayag na hindi nagtatala ang isang provider ng VPN ng aktibidad ng tunel ay walang sinasabi tungkol sa resolver na ibinibigay nito, at ang patakaran sa pagtatago ng isang resolver ay walang sinasabi tungkol sa kung sino ang kumonekta sa tunel. Bawat pag-aangkin ay pagmamay-ari ng sarili nitong operator at sarili nitong sistema.
Sundan ang query bago basahin ang alinman sa dalawang log
Nakararating lamang ang isang query sa isang resolver kung talagang tinatanong ito ng landas. Maaaring gamitin ng isang aplikasyon ang resolver ng operating system, magpatakbo ng sarili nitong naka-encrypt na client ng DNS, o magbasa ng naka-cache na sagot at hindi kailanman magpadala ng anuman. Kaya ang log ng resolver na walang ipinapakita ay hindi patunay na hindi kailanman ginamit ang isang pangalan; ito ay patunay na hindi tinanong ang resolver na ito.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager
Binabasa ng huling utos na iyon ang journal ng lokal na resolver mismo, na hindi katulad ng log ng upstream na server. Kung ang iyong mga query ay lumalabas sa pamamagitan ng DNS over HTTPS patungo sa isang provider, maaaring walang ipakita ang lokal na stub habang hawak ng provider ang kumpletong talaan, at ang provider ay ibang operator na may ibang patakaran.
Ano ang maaari at hindi maaaring ipakita ng bawat talaan
| 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 |
Ang pag-uugnay sa kanila ang tunay na gawain, at ang pag-uugnay ay hindi laging posible. Ang isang resolver na nagtatala ng mga address ng client ay maihahambing sa isang VPN na naglalaan ng mga address mula sa kilalang pool, at ang paghahambing na iyon ay gumagawa ng makatwirang ugnayan sa pagitan ng isang tinanong na pangalan at isang tunel, na nananatiling ugnayan sa pagitan ng dalawang talaan at hindi talaan ng isang tao.
Binabago ng naka-encrypt na DNS ang transportasyon, hindi ang pagiging nakikita sa endpoint. Natatanggap pa rin ng resolver ang tanong na sinasagot nito, gaya ng RFC 8484 nilinaw, at ang pagtatago sa resolver na iyon ay desisyon sa patakaran at hindi katangian ng protocol.
Kung saan ginugulo ng split DNS at mga cache ang kuwento
Normal lamang ang maraming resolver. Ang disenyong may split DNS ay nagpapadala ng mga panloob na pangalan sa isang panloob na server at lahat ng iba pa sa isang pampublikong server, kaya ang isang imbestigasyon ay maaaring may kasamang dalawang log na hindi kailanman inisip na pagsamahin at dalawang setting sa pagtatago na hindi kailanman inisip na ihambing. Ang makita ang mga query sa pareho ay patunay na gumagana ang disenyo, hindi patunay ng pagtagas.
Ang mga cache ay pumuputol sa kabilang direksyon. Ang isang sikat na pangalan ay maaaring sagutin mula sa cache nang maraming oras, kaya ang talaan ng resolver ay nagpapakita ng unang query at pagkatapos ay wala, habang ang aplikasyon ng user ay patuloy na masayang nilulutas ang parehong pangalan. Ang kawalan ng mga entry pagkatapos ng isang tiyak na oras ay hindi nangangahulugang walang gumamit ng pangalan pagkatapos ng oras na iyon.
Ang trapik sa background ang ikatlong pagbaluktot. Ang teleponong naglulutas ng pangalan ng telemetry sa pagboot, ang browser na naglulutas ng domain ng suhestiyon sa paghahanap, at ang updater na nag-uulat bawat oras ay lahat lumilitaw sa log ng resolver sa tabi ng pangalang talagang mahalaga sa iyo. Ang dami sa log na iyon ay hindi pansin, at ang pagbilang ng mga query ay hindi pagbilang ng mga pagbisita. Ang log ng resolver ay talaan ng mga tanong, at ang mga tanong ay murang likhain.
Itanong nang hiwalay ang mga tanong tungkol sa pagtatago
Para sa bawat sistema, itanong ang tatlong bagay: sino ang nangongolekta, ano ang kinokolekta, at gaano katagal ito itinatago. Pagkatapos ay itanong kung sino ang makababasa nito at sa ilalim ng anong proseso. Ang talakayan ng RFC 8484 tungkol sa DNS over HTTPS ay isang magandang paalala na hindi inaalis ng naka-encrypt na transportasyon ang endpoint, at ang sariling dokumentasyon ng operator ang tanging mapagkakatiwalaang pahayag tungkol sa kung ano ang itinatago ng endpoint na iyon.
Kapag may pag-aangkin tungkol sa privacy tungkol sa “VPN”, hatiin ito sa mga bahagi bago tanggapin: ang operator ng tunel, ang resolver na ibinibigay ng tunel, anumang upstream na resolver na naaabot ng mga query na iyon, at ang mga aplikasyon sa device. Bawat isa ay may sariling sagot, at ang isang pag-aangkin na tumpak para sa isa ay karaniwang inuulit na parang sinasakop ang lahat ng apat.
Para sa pag-troubleshoot, gamitin ang parehong paghahati. Itanong kung aling aplikasyon ang gumawa ng query at aling resolver ang sumagot, pagkatapos ay tingnan ang log na talagang nagmamay-ari ng pangyayaring iyon. Ang paghula mula sa kabilang log ay nagtitipid ng isang minuto at nagkakahalaga ng isang hapon.