Ndjek pyetjen DNS hap pas hapi për të gjetur burimin e vërtetë
Një adresë resolver e imponuar nuk vendos se cilën burim sheh resolveri. Ndjek klientin, forwarderin dhe serverin që pranon, dhe shkruaj rrugën.
T'i japësh një klienti një adresë resolver përcakton ku dërgohen pyetjet, jo cilën burim do të shohë resolveri. Rrugëtimi, përcjellja dhe përkthimi marrin secili radhën e vet midis dy skajeve. Një manual procedure për çështjet e burimit ndjek pyetjen hap pas hapi dhe shënon çfarë pa në të vërtetë secili vëzhgues. Rendi ka rëndësi, sepse një pohim i bërë para vëzhgimit është thjesht një supozim me formatim më të mirë.
Shkruaj rregullimin para se të mbledhësh prova
Katër vende mund të të thonë diçka për një burim DNS, dhe nuk thonë të gjithë të njëjtën gjë. Bërthama e klientit e di cilën burim do të përdorte, një forwarder e di çfarë dërgoi sipër, një pajisje që përkthen e di çfarë rishkruajti, dhe resolveri që pranon e di çfarë mbërriti. Shkruaj cilat prej tyre mund t'i arrish vërtet para se të mbledhësh gjë.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Shkruaj edhe pritshmërinë tënde, përfshirë resolverin që mendon se është në përdorim. Një rrugë e ndarë mund të dërgojë një pyetje diku krejt tjetër, dhe një cache mund të përgjigjet pa asnjë shkëmbim sipër, prandaj një supozim i mbajtur vetëm në mendje nuk do t'i mbijetojë surprizës së parë. Mbaj projektimin e deklaruar dhe rrugën e vëzhguar në kolona të ndara të të njëjtës shënim; kur të dy nuk pajtohen, ke gjetur pyetjen që ia vlen të ndiqet.
Kontrollo cili proces e dërgoi vërtet pyetjen
Nis nga klienti: shëno adresën e resolverit, emrin e pyetjes dhe kohën, dhe pastaj konfirmo cili proces e dërgoi. Rreshti i parë më poshtë emërton procesin që mban socketin UDP, dhe ky është kontrolli që premton ky titull. Nëse ai proces është një ndihmës shfletuesi ose një runtime kontejneri në vend të resolverit të sistemit, pjesa tjetër e gjurmës përshkruan një rrugë që askush nuk e kërkoi.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Në një host me disa ndërfaqe, gjej fillimisht cilën adresë burimi zgjedh bërthama për atë destinacion para se të shikosh diku tjetër. Kjo është pika e fundit ku rruga është plotësisht nën kontrollin tënd, dhe është vlera që do të krahasosh me atë që raporton resolveri. Një mospërputhje është sinjali se diçka në mes e rishkruajti paketën, ose se u dërguan dy pyetje të ndryshme.
Mbaji emrat e provës të brendshëm, sepse një emër i brendshëm i dërguar te një resolver publik nuk provon asgjë për rrugën e brendshme dhe publikon një emër që nuk kishe nevojë ta publikosh. Një shfletues me DNS të sigurt të aktivizuar nuk do të shfaqet fare në atë listë socketësh, dhe ajo mungesë është vetë përgjigja.
Forwarderi bën një pyetje të dytë, të veçantë
Një forwarder e kthen një shkëmbim në dy. Kërkesa poshtë mbërrin, dhe pastaj forwarderi dërgon pyetjen e vet sipër nga një adresë që e zgjedh. Konfigurimi i tij, jo klienti, vendos se çfarë sheh resolveri sipër.
Manuali i dnsmasq ia vlen të lexohet për këtë arsye: dokumenton se si një forwarder zgjedh serverë sipër dhe lidh anën e dëgjimit, dhe asgjë në atë rregullim nuk e çon burimin e klientit sipër. Një regjistër resolveri që tregon një adresë gateway është pra normal dhe jo provë e një defekti. Mungesa është po aq e lehtë për t'u lexuar gabimisht, sepse një goditje cache nuk prodhon asnjë pyetje sipër dhe duket identike me një pyetje që nuk mbërriti kurrë. Lexo konfigurimin e forwarderit dhe gjendjen e cache-s së tij para se të nxjerrësh njërën nga dy përfundimet. Dy pyetje, dy vende për të shikuar.
Lexo burimin te resolveri që pranon
Vëzhgimi i vetëm që e zgjidh këtë merret në anën e serverit. Çdo gjë që nxirret nga lista e ndërfaqeve të klientit mbetet hipotezë derisa resolveri të raportojë çfarë mbërriti vërtet.
tcpdump -ni any port 53 and host 10.20.30.53Bëj kapje në hostin e resolverit, mbaje kapjen të shkurtër dhe të kufizuar, dhe ruaje atje ku politika e lejon. Nëse burimi i vëzhguar është një adresë e përkthyer, pyetja tjetër është cila pajisje e kreu përkthimin dhe nëse politika e saj është ajo e synuar. Një kapje përgjigjet se çfarë mbërriti; nuk shpjegon pse politika e lejoi. Emërto vëzhguesin dhe hapin në shënim, sepse një pohim privatësie për një gateway është pohim për atë hap dhe jo për gjithë rrugën.
Shkruaj gjetjen si rrugë, jo si adresë
Shëno klientin, resolverin, çdo forwarder, burimin e vëzhguar në çdo hap dhe politikën që e rregullon. Ai regjistër u përgjigjet shumicës së pyetjeve të ardhshme pa një kapje tjetër. Vizatoje si zinxhir, sepse një listë adresash fsheh cili hap prodhoi cilën.
Bashkangjit datën, versionin e klientit dhe rishikimin e konfigurimit vizatimit, që një lexues i mëvonshëm të mund të thotë nëse vlen ende. Ndaj burimin e transportit nga çdo gjë tjetër që përpunon shërbimi, sepse të shohësh një adresë gateway nuk thotë asgjë për çfarë tjetër ruhet. As vendndodhja e një resolveri nuk thotë asgjë për cili klient pyeti. Mbajtja e këtyre pohimeve të ndara është ajo që e bën përfundimin të justifikueshëm në rishikim.