Fuatilia swali la DNS hatua kwa hatua ili kupata chanzo halisi
Anwani ya resolver inayosukumwa kwa mteja haiamui chanzo ambacho resolver huona. Fuatilia mteja, kipitishaji na seva inayopokea, kisha andika njia.
Kumpa mteja anwani ya resolver huamua swali zinapelekwa wapi, si chanzo ambacho resolver atakiona. Uelekezaji, upitishaji na utafsiri hupata zamu zao kati ya ncha mbili. Mwongozo wa maswali ya chanzo hufuatilia swali hatua kwa hatua na kuandika kile kila mwangalizi aliona kwa kweli. Mpangilio ni muhimu, kwa sababu dai linalotolewa kabla ya uchunguzi ni dhahania yenye muundo bora tu.
Andika mpangilio kabla ya kukusanya ushahidi
Maeneo manne yanaweza kukuambia kitu kuhusu chanzo cha DNS, na si yote yanasema kitu kimoja. Kiini cha mteja kinajua chanzo ambacho kingetumia, kipitishaji kinajua kilichotuma juu, kifaa kinachotafsiri kinajua kilichokiandika upya, na resolver inayopokea inajua kilichofika. Andika ni yapi kati ya haya unaweza kufikia kwa kweli kabla ya kukusanya chochote.
| 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 |
Andika pia matarajio yako, ukiwemo resolver unayodhani inatumika. Njia iliyogawanywa inaweza kutuma swali mahali pengine kabisa, na akiba inaweza kujibu bila kubadilishana chochote juu, kwa hivyo dhana inayohifadhiwa akilini tu haitastahimili mshangao wa kwanza. Weka muundo uliotangazwa na njia iliyozingatiwa katika safu tofauti za noti moja; pale mbili hazipatani, umepata swali linalostahili kufuatiliwa.
Angalia ni mchakato upi ulituma swali kwa kweli
Anza kwa mteja: andika anwani ya resolver, jina la swali na muda, kisha thibitisha ni mchakato upi ulilituma. Mstari wa kwanza hapa chini unataja mchakato unaoshikilia soketi ya UDP, na hiyo ni ukaguzi ambao kichwa hiki kinaahidi. Ikiwa mchakato huo ni msaidizi wa kivinjari au mazingira ya utekelezaji ya kontena badala ya resolver ya mfumo, sehemu iliyobaki ya ufuatiliaji inaeleza njia ambayo hakuna aliyetaka.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Kwenye mwenyeji mwenye violesura kadhaa, tambua anwani ya chanzo ambayo kiini huchagua kwa lengo hilo kabla ya kuangalia mahali pengine. Hiyo ni sehemu ya mwisho ambapo njia iko chini ya udhibiti wako kikamilifu, na ni thamani utakayolinganisha na kile resolver inaripoti. Kutopatana ni ishara kwamba kitu katikati kiliandika pakiti upya, au kwamba maswali mawili tofauti yalitumwa.
Weka majina ya majaribio kuwa ya ndani, kwa sababu jina la ndani linalotumwa kwa resolver ya umma halithibitishi chochote kuhusu njia ya ndani na huchapisha jina ambalo hukuhitaji kulichapisha. Kivinjari chenye DNS salama kilichowashwa hakitajitokeza kabisa katika orodha hiyo ya soketi, na kutokuwepo huko ndiko jibu lenyewe.
Kipitishaji hufanya swali la pili, tofauti
Kipitishaji hubadilisha kubadilishana moja kuwa mbili. Ombi la chini hufika, kisha kipitishaji hutuma swali lake mwenyewe juu kutoka anwani inayochagua. Mpangilio wake, si mteja, huamua kile resolver ya juu inaona.
mwongozo wa dnsmasq unastahili kusomwa kwa sababu hiyo: unaandika jinsi kipitishaji huchagua seva za juu na kufunga upande wake wa kusikiliza, na hakuna chochote katika mpangilio huo kinachobeba chanzo cha mteja juu. Kwa hivyo kumbukumbu ya resolver inayoonyesha anwani ya lango ni kawaida, si uthibitisho wa hitilafu. Kutokuwepo pia kunaweza kusomwa vibaya kwa urahisi huo huo, kwa sababu mgongano wa akiba hautengenezi swali lolote la juu na huonekana sawa kabisa na swali ambalo halikufika kamwe. Soma mpangilio wa kipitishaji na hali ya akiba yake kabla ya kutoa mojawapo ya hitimisho mbili. Maswali mawili, maeneo mawili ya kuangalia.
Soma chanzo kwenye resolver inayopokea
Uchunguzi pekee unaomaliza hili huchukuliwa upande wa seva. Kila kitu kinachokisiwa kutoka orodha ya violesura vya mteja hubaki kuwa dhahania hadi resolver iripoti kilichofika kwa kweli.
tcpdump -ni any port 53 and host 10.20.30.53Nasa kwenye mwenyeji wa resolver, weka unasa mfupi na wenye mipaka, na uhifadhi mahali ambapo sera inaruhusu. Ikiwa chanzo kilichozingatiwa ni anwani iliyotafsiriwa, swali linalofuata ni kifaa kipi kilifanya utafsiri na kama sera yake ndiyo iliyokusudiwa. Unasa hujibu kilichofika; hauelezi kwa nini sera iliruhusu. Taja mwangalizi na hatua katika noti, kwa sababu dai la faragha kuhusu lango ni dai kuhusu hatua hiyo na si kuhusu njia yote.
Andika ugunduzi kama njia, si kama anwani
Andika mteja, resolver, kipitishaji chochote, chanzo kilichozingatiwa katika kila hatua na sera inayokitawala. Rekodi kama hiyo hujibu maswali mengi ya baadaye bila unasa mwingine. Ichora kama mnyororo, kwa sababu orodha ya anwani huficha hatua ipi ilitoa ipi.
Ambatisha tarehe, toleo la mteja na marekebisho ya mpangilio kwenye mchoro, ili msomaji wa baadaye aweze kusema kama bado inatumika. Tenganisha chanzo cha usafirishaji na kila kitu kingine ambacho huduma huchakata, kwa sababu kuona anwani ya lango hakuambii chochote kuhusu kile kingine kinachohifadhiwa. Eneo la resolver pia haliambii chochote kuhusu mteja yupi aliuliza. Kutenganisha madai hayo ndiko kunakofanya hitimisho liweze kutetewa wakati wa mapitio.