DNSSEC o VPN: alin ang nagtatago ng iyong mga DNS query?

Dalawang mekanismo ang binibigyan ng parehong trabaho at wala sa kanila ang gumagawa nito. Sinasagot ng DNSSEC kung ang datos na natanggap mo ay talagang nagmula sa zone na naglalathala nito, at ang VPN ang nagpapasya kung aling landas tatahakin ng iyong mga packet. Wala sa kanila ang nagtatago sa lahat ng kaso ng pangalang itinanong mo, at ang mga setting na mukhang dapat gumawa nito ay karaniwang tungkol sa transport o routing at hindi sa validation. Ang pagpangalan muna sa layer ay ginagawang tiyak na tanong ang malabong tanong tungkol sa privacy.

Tatlong pag-aangkin na nagsasama sa isa

Ang pagiging tunay ay ang pag-aangkin na ang sagot ay ang inilathala ng zone at hindi binago sa daan. Ang pagiging kompidensiyal ay ang pag-aangkin na walang sinuman sa landas ang makababasa ng query o sagot. Ang routing ay ang pag-aangkin na ang mga packet ay sumusunod sa landas na pinili mo, at iyon ang ibinibigay ng isang tunnel.

Tinatrato ng DNSSEC ang una at wala itong sinasabi tungkol sa dalawa. Tinatrato ng DoT at DoH ang pangalawa para sa pagtalon hanggang sa resolver. Tinatrato ng VPN ang pangatlo at maaari ring makaapekto sa pangalawa, ngunit bilang side effect lamang ng kung saan pupunta ang trapiko.

Ang trapiko ng aplikasyon ay ikaapat na kaso: pinoprotektahan at pinapatunayan ng HTTPS ang palitan sa web sa pagitan ng iyong client at ng site, at walang layer ng DNS ang pumapalit dito.

Ano ang kaya at hindi kaya ng validation ng lagda

Sinusuri ng resolver na nagpapatunay ang kadena ng mga lagda mula sa zone hanggang sa naka-configure na anchor ng pagtitiwala, pagkatapos ay nagbabalik ng sagot na may nakatakdang bandila ng authenticated data kapag nagtagumpay ang pagsusuri. Ang bandilang iyon ay ebidensiya tungkol sa datos, hindi tungkol sa koneksyon o sa mga intensyon ng destinasyon.

Hindi nito mapipigilan ang lehitimong may-ari ng zone na maglathala ng tunay na mga rekord para sa isang serbisyong hindi mo dapat pagkatiwalaan. Ang wastong lagda na sagot mula sa isang komprometidong domain ay wasto pa ring lagda, at walang opinyon ang DNSSEC kung karapat-dapat ang domain na iyon sa iyong mga kredensyal.

Wala rin itong itinatago. Ang query at sagot ay tumatawid sa network sa anyong mababasa ng resolver at ng sinumang tagamasid sa landas na iyon, maliban kung may ibang layer na nagpoprotekta sa transport. Ang lagda na sagot at pribadong sagot ay magkaibang katangian, at ang isang deployment ay maaaring may isa lamang. Subukan ang pareho kung may kahalagahan sa iyo ang alinman.

Saan talaga nagmumula ang pagiging kompidensiyal

Binabalot ng naka-encrypt na transport patungo sa resolver ang palitan ng DNS sa TLS, kaya nakikita pa rin ng resolver ang tanong ngunit hindi ang landas sa pagitan mo at nito. Inililipat nito ang pagtitiwala sa halip na alisin ito: mas nagtitiwala ka sa resolver at mas kaunti sa lokal na network.

Maaaring magdala ang VPN ng mga query sa isang resolver sa kabilang panig, na nagbabago sa landas at sa resolver na nakakakita sa mga ito. Ito ay desisyon sa routing na may kahihinatnan sa privacy, at sa isang pinamamahalaang network ang panloob na resolver ang maaaring tanging makasagot sa mga panloob na pangalan.

Ang kombinasyong talagang gusto ng mga tao ay karaniwang tatlong bagay nang sabay: naka-on ang validation, naka-encrypt na transport patungo sa resolver na pinili nila, at TLS ng aplikasyon sa destinasyon. Bawat isa ay independiyente, at ang paglaktaw ng isa ay nag-iiwan ng ibang puwang.

Suriin nang hiwalay ang validation at transport

Dalawang pagsubok ang lumulutas sa karamihan ng kalituhan. Ang una ay nagtatanong kung pinatunayan ng resolver ang sagot; ang pangalawa ay kung protektado ang transport. Nabigo sila sa magkaibang paraan at wala sa kanila ang nagpapahiwatig ng isa.

Ang mga command na ito ay naglilimbag ng mga bandila mula sa isang query na nagpapatunay, inuulit ang query na naka-off ang pagsusuri, at nagpapatakbo ng lokal na validation gamit ang delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Ang sagot na may bandila ng authenticated data at may lagda ay nagpapakita ng validation sa resolver na iyon. Ang kabiguan ng validation gamit ang delv ay nagpapakita ng putol na kadena sa isang lugar sa pagitan ng zone at ng anchor ng pagtitiwala, na problema sa paglalathala at hindi problema sa tunnel. Ang pag-timeout na walang anumang bandila ay problema sa transport o abot, at ang ituring ito na kabiguan ng lagda ay magdadala sa iyo sa maling layer.

Ano ang gawin kapag sinira ng VPN ang paghahanap

Kung gumana ang paghahanap bago ang tunnel at huminto pagkatapos, ihambing ang resolver na ginagamit ng bawat landas. Ang hinati na tunneling, panloob na resolver na maaabot lamang sa pamamagitan ng tunnel, at client na nagsusulat muli ng mga setting ng resolver ay binabago ang sagot nang hindi hinahawakan ang DNSSEC.

Ang pag-off ng validation sa buong mundo ay maling unang hakbang, dahil inaalis nito ang tanging mekanismong nag-uulat ng panghihimasok at hindi nito inaayos ang resolver na hindi maabot. Paliitin muna ang depekto: resolution, transport, validation, pagkatapos ay patakaran. Ang pangatlo lamang ang pag-aari ng DNSSEC, at ang pangalawa lamang ang pag-aari ng naka-encrypt na transport.