Kapja e Split-DNS: thoni ku u mor çdo vëzhgim

Dy persona zgjidhin të njëjtin problem Split-DNS dhe marrin adresa zgjidhësi të ndryshme. Njëri përdori një mjet kërkimi, tjetri kapi paketa në përshtatës, dhe i treti lexoi diagnostikimin e vetë klientit. Asnjëri nuk gënjen dhe asnjëri nuk përshkruan të njëjtën fazë. Emërtimi i pikës së vëzhgimit e kthen kontradiktën në hartë.

Një kërkim, disa pika vëzhgimi

Për një emër të brendshëm ka të paktën pesë vende për të parë: aplikacioni dhe API-ja e zgjidhësit që thërret, politika e domenit në fuqi te klienti, një kapje në përshtatës ose filtër, një kufi i kontrolluar portë dhe zgjidhësi që merr vërtet pyetjen.

Secili përgjigjet një pyetjeje tjetër, dhe asnjëri i vetëm nuk provon ku shkoi pyetja.

Një kapje në përshtatës tregon paketa, jo qëllim. Nuk thotë cilin zgjidhës zgjodhi klienti, dhe një kapje bosh mund të nënkuptojë një përgjigje të ruajtur në memorie ose një API tjetër zgjidhësi, jo një paketë të hedhur. Trajtoni çdo vëzhgim si provë për një fazë. Pastaj montoni fazat në një rrugë.

Filtri i klientit qëndron midis aplikacionit dhe telit

Një klient VPN me Split-DNS zbaton përputhjen e domeneve përpara se paketa të largohet nga makina. Emrat në prapashtesën e tunelezuar shkojnë te zgjidhësi i brendshëm; gjithçka tjetër shkon te ai lokal. Filtri është politikë, dhe politika mund të ndryshojë sipas platformës dhe versionit të klientit.

Udhëzimet e Secure Client për Split-DNS të Cisco mbulojnë përputhjen e domeneve dhe filtrin e Windows, dhe ndajnë atë që sheh një aplikacion kur përdor API-në e natyrshme të zgjidhësit nga ajo që sheh një mjet si nslookup. Pikërisht ato dallime janë çështja.

Filloni nga profili në fuqi dhe një kërkim i zakonshëm i aplikacionit. Çdo test që emërton një server të caktuar është një devijim i qëllimshëm; shpjegojeni me diagnostikimin e vetë klientit dhe mos lejoni që të bëhet kriteri i pranimit.

nslookup ndjek një rrugë tjetër nga aplikacioni

nslookup ndërton vetë pyetjen DNS dhe mund të anashkalojë politikën e zgjidhësit të sistemit operativ. Kjo e bën atë një mjet të dobishëm për t'i bërë një pyetje të caktuar një serveri të caktuar, dhe një mjet mashtrues për të provuar çfarë do të përjetojë një aplikacion.

Në Windows, tabela e politikës së zgjidhjes së emrave vendos cila prapashtesë përdor cilin server. Leximi i saj tregon politikën që do të ndjekë aplikacioni, dhe shpesh kjo është pjesa që mungon.

Lexoni politikën dhe pastaj bëni të njëjtën pyetje përmes zgjidhësit normal:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Zgjidhësit e kriptuar fshehin pyetjen, jo lidhjen

Një shfletues me zgjidhësin e vet DNS-over-HTTPS është një rast krejt tjetër. Pyetja del brenda TLS, kështu që një kapje paketash tregon një lidhje me një adresë zgjidhësi por jo emrin që kërkohet.

Së pari përcaktoni politikën e menaxhuar të shfletuesit, pastaj krahasojeni me një kërkim të sistemit operativ. Një shfletues që lejohet të zgjedhë zgjidhësin e vet mund të mos e shohë fare politikën Split-DNS.

E njëjta kujdes vlen për çdo klient që sjell zgjidhësin e vet. Një kapje që identifikon lidhjen në distancë nuk është provë për emrin e pyetjes. Nëse ju nevojitet emri, merreni nga regjistrat e vetë zgjidhësit ose nga diagnostikimi i aplikacionit, me rregullat e privatësisë që zbatohen.

Krahasoni me një test të etiketuar

Zgjidhni një emër të brendshëm të miratuar për test, plus një emër publik që nuk mbart kuptim të ndjeshëm. Për secilin, shënoni kohën, llojin e regjistrit, përgjigjen dhe politikën që prisnit.

Ku lejohet, krahasoni marrjen në zgjidhës me një vëzhgim të ngushtë të klientit ose portës:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Kurrë mos dërgoni emra privatë te zgjidhës publikë të palidhur vetëm për të krijuar një krahasim, dhe redaktoni gjithçka që ndani. Së fundi, ndani një përgjigje të saktë DNS nga lidhja e shërbimit që vjen pas: adresa private e zgjidhur ende ka nevojë për një rrugë dhe një autorizim aplikacioni.