DNS mbi TLS plus një VPN: cila pjesë mbrohet

DNS mbi TLS kripton shkëmbimin midis një klienti dhe resolver-it që zgjodhi, dhe resolver-i vazhdon ta lexojë emrin. Kjo fjali zgjidh pjesën më të madhe të konfuzionit rreth DoT plus një VPN. Tuneli vendos se cilën rrugë merr kërkesa e kriptuar, ndërsa resolver-i vazhdon të mësojë çfarë u pyet. Asnjëri mekanizëm nuk zëvendëson tjetrin, dhe asnjëri nuk e bën tjetrin të tepërt.

Katër kontrolle vendosin nëse rregullimi që keni është ai që mendoni se keni.

Kontrolli 1: çfarë mbulon kriptimi

DoT e mbështjell shkëmbimin DNS në TLS, kështu që një vëzhgues në rrugë sheh një lidhje drejt një adrese dhe porti, jo një emër në një kërkesë. Vetë resolver-i dekripton dhe përgjigjet. Krahasojeni me DNS mbi HTTPS: të dy kriptojnë dhe përdorin transportë të ndryshëm, prandaj një rrjet që lejon trafikun e web-it nuk lejon automatikisht një lidhje DoT.

Ky dallim ka rëndësi kur një portal captive ose një kuti e ndërmjetme filtrimi lejon 443 dhe bllokon 853. Mjeti që funksionoi atje nuk është provë se tjetri do të funksionojë.

Kontrolli 2: cilën rrugë merr kërkesa

Rruga është çështje e politikës së klientit. Një resolver DoT mund të arrihet përmes tunelit, jashtë tij, ose nëpërmjet një rruge që ndryshon me rrjetin. Cila ndodh varet nga rrugët dhe nga fakti nëse klienti mbron vetë socket-in e tij DNS. Një tunel që kap gjithë trafikun zakonisht e merr kërkesën me vete, çfarëdo që thotë adresa e resolver-it.

Të shohësh një adresë resolver-i të palës së tretë në një test nuk provon një anashkalim, dhe të shohësh kriptim nuk provon marrësin e synuar. Lexoni resolver-in dhe rrugën veçmas, pastaj vendosni nëse çifti është ai që keni projektuar.

Kontrolli 3: emrat e brendshëm

Një organizatë që publikon emra të brendshëm ka nevojë për një resolver që mban ato regjistrime. Një shërbim DoT publik nuk e njeh hapësirën tuaj private të emrave, dhe drejtimi i klientit tek ai garanton që ata emra do të dështojnë. Ky është regresi praktik më i zakonshëm kur dikush aktivizon DNS të kriptuar në një pajisje të menaxhuar.

Mbani resolver-in e brendshëm për prapashtesat e brendshme dhe kriptoni atë kërcim nëse politika e kërkon, në vend që ta zëvendësoni me një ofrues publik.

Kontrolli 4: sjellja në dështim

Një konfigurim i rreptë i resolver-it pa një resolver të arritshëm prodhon një dështim të zgjidhjes së emrave ndërsa tuneli mbetet lart. Shikoni mënyrën e platformës dhe alternativin e saj të dokumentuar në vend që të prekni çelësat ose certifikatat.

Një alternativ që përdor në heshtje DNS të thjeshtë është një vendim politike, jo një komoditet. Vendosni nëse dështimi duhet të jetë i dukshëm ose duhet të degradohet në diçka më të dobët, dhe shkruani përgjigjen.

Besoni certifikatën, jo përgjigjen

Përdorni emrin e hostit të ofruesit dhe konfigurimin e verifikimit të dokumentuara për shërbimin. Fikja e kontrolleve TLS që një resolver i panjohur të përgjigjet ju jep një kanal të kriptuar drejt një pike fundore të paverifikuar, që është më keq se kërkesa e thjeshtë që zëvendësoi në një aspekt konkret: duket e sigurt. Specifikimi i DNS mbi TLS parashtron pritshmërinë e autentikimit pas atij kontrolli.

Një përgjigje nga një resolver që nuk mund ta autentikoni është një pohim, jo një rezultat.

Çfarë lë kjo pa shpjeguar

DoT nuk e fsheh emrin nga resolver-i, nuk e fsheh adresën e destinacionit të lidhjes nga rrjeti dhe nuk vendos nëse kërkesa kaloi nëpër tunel. Këto janë tre pyetje të ndara me tre përgjigje të ndara.

Shkruani identitetin e resolver-it, rrugën e transitit dhe politikën e emrave të brendshëm si tre rreshta. Pyetja e radhës për DNS që do të merrni do të jetë një prej tyre.