Sundan ang DNS query hakbang-hakbang upang mahanap ang tunay na pinagmulan
Ang itinulak na resolver address ay hindi nagtatakda kung aling pinagmulan ang nakikita ng resolver. Sundan ang kliyente, ang tagapasa at ang tumatanggap na server, pagkatapos isulat ang landas.
Ang pagbibigay sa kliyente ng resolver address ay nagtatakda kung saan ipinapadala ang mga query, hindi kung aling pinagmulan ang makikita ng resolver. Ang routing, pagpapasa at pagsasalin ay may kanya-kanyang pagkakataon sa pagitan ng dalawang dulo. Sinusundan ng runbook para sa mga tanong sa pinagmulan ang query hakbang-hakbang at itinatala kung ano talaga ang nakita ng bawat tagamasid. Mahalaga ang pagkakasunod-sunod, dahil ang pahayag na ginawa bago ang obserbasyon ay hulaan lamang na may mas magandang format.
Isulat ang kaayusan bago ka mangolekta ng ebidensya
Apat na lugar ang makapagsasabi sa iyo ng isang bagay tungkol sa pinagmulang DNS, at hindi lahat ay nagsasabi ng parehong bagay. Alam ng kernel ng kliyente kung aling pinagmulan ang gagamitin nito, alam ng tagapasa kung ano ang ipinadala nito paitaas, alam ng device na nagsasalin kung ano ang muling isinulat nito, at alam ng tumatanggap na resolver kung ano ang dumating. Isulat kung alin sa mga ito ang talagang maaabot mo bago ka mangolekta ng kahit ano.
| 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 |
Isulat din ang iyong inaasahan, kabilang ang resolver na sa tingin mo ay ginagamit. Ang hatirang ruta ay makapagpapadala ng query sa ibang lugar nang lubusan, at ang cache ay makasasagot nang walang anumang palitan paitaas, kaya ang palagay na itinatago lamang sa memorya ay hindi makakalampas sa unang sorpresa. Itago ang nakasaad na disenyo at ang naobserbahang landas sa magkahiwalay na hanay ng parehong tala; kapag hindi sila magkasundo, natagpuan mo ang tanong na sulit sundan.
Suriin kung aling proseso ang talagang nagpadala ng query
Magsimula sa kliyente: itala ang resolver address, ang pangalan ng query at ang oras, pagkatapos ay kumpirmahin kung aling proseso ang nagpadala nito. Pinangalanan ng unang linya sa ibaba ang prosesong may hawak ng UDP socket, at iyon ang pagsusuring ipinangako ng pamagat na ito. Kung ang prosesong iyon ay katulong ng browser o runtime ng container sa halip na system resolver, inilalarawan ng natitirang bahagi ng bakas ang landas na walang sinumang humiling.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Sa host na may maraming interface, alamin muna kung aling source address ang pinipili ng kernel para sa destinasyong iyon bago ka tumingin sa ibang lugar. Iyon ang huling punto kung saan ang landas ay ganap na nasa ilalim ng iyong kontrol, at iyon ang halagang ihahambing mo sa iniuulat ng resolver. Ang hindi pagtutugma ay hudyat na may muling sumulat ng packet sa gitna, o may dalawang magkaibang query na ipinadala.
Itago ang mga pangalan ng pagsubok bilang panloob, dahil ang panloob na pangalan na ipinadala sa pampublikong resolver ay walang pinatutunayan tungkol sa panloob na landas at naglalathala ng pangalang hindi mo kailangang ilathala. Ang browser na may naka-enable na secure DNS ay hindi lilitaw sa listahan ng socket na iyon, at ang kawalan na iyon mismo ang sagot.
Gumagawa ang tagapasa ng pangalawa at hiwalay na query
Ginagawang dalawa ng tagapasa ang isang palitan. Dumarating ang kahilingan mula sa ibaba, at pagkatapos ay ipinapadala ng tagapasa ang sarili nitong query paitaas mula sa address na pinipili nito. Ang configuration nito, hindi ang kliyente, ang nagtatakda kung ano ang nakikita ng resolver sa itaas.
manwal ng dnsmasq ay sulit basahin dahil doon: idinodokumento nito kung paano pumipili ang tagapasa ng mga server sa itaas at kung paano nito binibigkis ang panig ng pakikinig, at wala sa kaayusang iyon ang nagdadala ng pinagmulan ng kliyente paitaas. Kaya ang log ng resolver na nagpapakita ng gateway address ay normal, hindi patunay ng sira. Ang kawalan ay kasingdaling mabasa nang mali, dahil ang cache hit ay hindi gumagawa ng anumang query paitaas at mukhang kapareho ng query na hindi kailanman dumating. Basahin ang configuration ng tagapasa at ang estado ng cache nito bago gumawa ng alinman sa dalawang konklusyon. Dalawang tanong, dalawang lugar na titingnan.
Basahin ang pinagmulan sa tumatanggap na resolver
Ang tanging obserbasyong nagtatakda nito ay kinukuha sa panig ng server. Anumang hinango mula sa listahan ng interface ng kliyente ay nananatiling hipotesis hanggang sa iulat ng resolver kung ano ang talagang dumating.
tcpdump -ni any port 53 and host 10.20.30.53Kunin ang capture sa host ng resolver, panatilihing maikli at limitado ang capture, at itago ito kung saan pinapayagan ng patakaran. Kung ang naobserbahang pinagmulan ay isinaling address, ang susunod na tanong ay aling device ang nagsagawa ng pagsasalin at kung ang patakaran nito ang nilalayon. Sinasagot ng capture kung ano ang dumating; hindi nito ipinaliliwanag kung bakit pinahintulutan ito ng patakaran. Pangalanan ang tagamasid at ang hakbang sa tala, dahil ang pahayag tungkol sa privacy ng isang gateway ay pahayag tungkol sa hakbang na iyon at hindi tungkol sa buong landas.
Isulat ang natuklasan bilang landas, hindi bilang address
Itala ang kliyente, ang resolver, anumang tagapasa, ang naobserbahang pinagmulan sa bawat hakbang at ang patakarang namamahala rito. Sinasagot ng gayong tala ang karamihan sa mga tanong sa hinaharap nang walang isa pang capture. Iguhit ito bilang kadena, dahil itinatago ng listahan ng address kung aling hakbang ang gumawa ng alin.
Ilakip sa guhit ang petsa, bersyon ng kliyente at rebisyon ng configuration, upang masabi ng susunod na mambabasa kung may bisa pa ito. Ihiwalay ang pinagmulan ng transportasyon sa lahat ng iba pang pinoproseso ng serbisyo, dahil ang makakita ng gateway address ay walang sinasabi tungkol sa ano pa ang itinatago. Ang lokasyon ng resolver ay wala ring sinasabi tungkol sa aling kliyente ang nagtanong. Ang paghihiwalay sa mga pahayag na iyon ang gumagawa sa konklusyon na maipagtatanggol sa pagsusuri.